Architecture and Data Blog

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

Database Testing revisited

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.

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.

To allow NULLs or NOT

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) ); Database designs I have seen tend to not constrain the data in the database.