Architecture and Data Blog

Thoughts about intersection of data, devops, design and software architecture

Version Control your work..

Using version control for non code assets

So we version control/source control everything on our project.. code/data/artifacts/diagrams etc. yesterday I said why not extend it to my writings to everything I have. So I started this long journey of refactoring my folder layout and making a nice folder structure to hold all the things I have written about have other artifacts in the process of writing and moved them all to subversion, now all my example code and writings are all under version control that gets backed up everyday….

Posted by Pramod Sadalage on Friday, June 6, 2008

Writing a SQL to generate a SQL

Generating SQL code using SQL

We had a weird requirement on our project recently..

Find all the Rows in All the tables that do not comply with the Constraints that we have in development but not in QA environments

Posted by Pramod Sadalage on Tuesday, May 6, 2008

Enforcing your assumptions about database functionality

Testing the behavior of the database

When you are writing xUnit tests you are in certain ways trying to make sure that the test breaks when the code that is being tested changes the assumptions you made when writing the Test and Production code. Similarly if you are relying on the database to throw a error when you put invalid data, then you should write a test around this assumption, so that when someone changes the database to not behave the way you assumed it to behave, the test you wrote will break and it will force the team to think about the change to the database that is being undertaken.

Posted by Pramod Sadalage on Friday, June 8, 2007

Database Testing revisited

Testing the database layer that interacts with the database is critical.

Some time ago I wrote about what it means to do database testing.. more I think about this and having had some strange situations recently I want to add more to the list of things we should be testing. Persistence Layer. We should persist the objects to the database using the applications persistence layer and retrieve the objects using the same mechanism and test that we get the same object back.

Posted by Pramod Sadalage on Thursday, November 9, 2006

Move your DBAs to the Project team locations"

Many IT organizations I have seen have groups of specialists, typical are UNIX Group, DBA group etc. When a project starts the developers on the project have to meet with all the Groups (I have more experience with the DBA group, so I write with the DBA group in mind) that they need to interact with and explain to the groups their design, the projects operational needs and other requirements, later when development starts they have to email these groups about all the setup that needs to be done and also the day to day changes that are needed.

Posted by Pramod Sadalage on Tuesday, May 23, 2006

To allow NULLs or NOT

When to allow NULLs or NOT, is critical domain discussion

Database designs I have seen tend to not constrain the data in the database. For example make the Item.ManufacturerID non-nullable and make it a foreign key to the Manufacturer table. Similarly Manufacturer.Name and Item.Rate as non-nullable columns. In any greenfield application (existing production application is a topic for another post). When you design table(s) lets say you have Item and Manufacturer table as shown below CREATE TABLE Item (ItemID NUMBER NOT NULL, ManufacturerID NUMBER, Name VARCHAR2(128), Rate NUMBER, CONSTRAINT PK_ITEM PRIMARY KEY (ItemID) ); CREATE TABLE Manufacturer (ManufacturerID NUMBER NOT NULL, Name VARCAHR2(128), CONSTRAINT PK_MANUFACTURER PRIMARY KEY (ManufacturerID) ); For now let’s talk about NOT NULL constraint.

Posted by Pramod Sadalage on Wednesday, February 8, 2006

Presentation on Database Refactoring

My Presentation on Database Refactoring at QCon was recorded and is live now on infoQ here

Posted by Pramod Sadalage on Monday, January 1, 0001