Architecture and Data Blog

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

Using liquibase to load data and ignore some columns

Loading data into tables is needed many times on projects to load test, Liquibase provides a method to load data into tables with lots of customization. In the example shown below, I’m loading zip code data with the following column layout

"Zipcode","ZipCodeType","City","State","LocationType","Lat","Long","Location","Decommisioned","TaxReturnsFiled","EstimatedPopulation","TotalWages"

Synonyms as abstraction layer

In many development shops, developers are not allowed to access the database schema directly, and are not allowed to create tables, indexes, views etc, instead are given access via a different schema that allows SELECT, UPDATE and DELETE access on data. The general reason is to avoid developers creating database objects without


MSSQL JDBC Driver behavior"

My latest project involves talking to MS-SQL Server using the JDBC driver and Java. While doing this we setup the database connection and had a simple SQL to get the first_name and last_name for a unique user_id from the application_user table in the database. SELECT first_name,last_name FROM application_user WHERE user_id = ? Given the above SQL, we did not think too much about performance as the user_id was indexed. The java code as below was used to run the SQL.

With so much pain, why are stored procedures used so much

Deciding when to used stored procedures is an important design decision that needs to be made with lots of thought

I keep encountering situations where all the business logic for the applications is in stored procedures and the application layer is just calling the stored procedures to get the work done and return the data. There are many problems with this approach some of them are. Writing stored procedure code is fraught with danger as there are no modern IDE’s that support refactoring, provide code smells like “variable not used”, “variable out of scope”.

Article about Behavior Driven Database Design is out

Database schema has behavior encoded in them and its imperative that it be tested

Recently I have been thinking a lot about making specification and behavior expected about the database and the code that interfaces with the databases executable. The Behavior Driven Design has a lot of parallels in the database world. Just finished writing a article about Behavior Driven Design applied to Databases or Behavior Driven Database Design. for Methods and Tools.

When does evolutionary design happen?

What part of the product, project, iteration, story or day does evolutionary design happen?

A question I get, mostly related to the evolutionary database design and development. When the pair (team) gets a new feature (story) to work on, the team looks at the existing table/database design and sees if the current design is enough to implement the feature they are working on. If the currency database design does support the feature they are trying to implement, then they do not have to change the database at all, they will move on to implement the feature and change the application code as necessary.