Be ready to change your mind

Tell us about the experiences, the code, the posts that inspired you, and all the gory details in between. And what is it that makes you so passionate about this topic that "It Depends" gets tossed out the window? Pull out your soapbox and tell us all about it - this is the invitation of Deborah Melkin for T-SQL Tuesday #152 - It Depends.

Although "the sentence" is not mentioned on the list given by Deborah, I want to write about one sentence, which unexpectedly terminated a long episode in my professional career as a programmer, and which builds my main, archetypical answer including "it depends". This sentence comes from The Clean Code Blog, the post's title is: The Clean Architecture, and the sentence is:

The database is a detail.

Before I read this, I was diving deeply and broadly into Books Online Ocean, SQL Server Central Sea, Simple Talk Lake, SQL Server Tips Pond... I spent more than 10 years on understanding SQL Server database details.

I designed, implemented, and modified many useful databases made with different RDBMS engines, not only Microsoft. I spent many hours improving my coding style in T-SQL. I was proud that I can do everything with SQL, with respect to the relational model, of course, avoiding procedural code as a rule, but using procedures in an elegant manner, similar to object-oriented and functional code. I was sure my code is faster, more readable, and more beautiful than that produced by my colleagues. I was asked to teach others, because of my technical skills in this area.

And then – this sentence. Breathe slowly, Gerard.

I have started a draft of the angry reply, that database is not a detail, Uncle Ben. I took Joe Celko's SQL for Smarties: Advanced SQL Programming - Joe Celko was one of my masters - to find arguments. Then I realized that he teaches SQL as the language of data modeling, as the language of constraints, and avoids procedural extensions, considering them an unnecessary addition.

Even after recalling this opinion of a master, it was hard to change my mind. But after two years I was quite sure that Uncle Ben was correct. If the database is not a detail, I am limited in many aspects of programming.

I had to ask myself, am I still a programmer, being a hard SQL programmer?

Programmers are looking for optimal models, optimal algorithms, and optimal architectures. But if the database is in the heart of the project, if the database is the architecture, it’s hard to not build the next CRUD frontend. If you are only a SQL programmer, you are limited by the selection of a limited tool.

If the database is the base of the solution, then everything should be designed with the preliminary question of whether SQL Server (or another weapon of choice) does not have an answer for a particular design question.

And ... did your client really order a CRUD frontend? Not. Even in the order form, the database was a detail, wasn't it?

But where is "it depends"?

There are many cases.

Sometimes you need to use the resources which are available here and now. You do not have people in the team who know other approaches well. You have an existing SQL Server license. You need to start the project as soon as possible. If you use SQL Server with all the features in the starting point, you can move forward at the speed of light.

And maybe this is enough to achieve the goal because it is a database application indeed, with only simple logic? No rocket science. There are so many database-centric projects.

You don’t need to build useless abstraction on the database layer. Abstraction is not necessarily useful. Applying an ORM as a rule is usually discussable.

But on the other hand, the database - especially the relational model, although we also have other database models - is also an abstraction. And as abstraction, it is sometimes useless, sometimes counterproductive, and sometimes even wrong. Applying a particular RDBMS engine, as a rule, is usually discussable.

It depends on what you should choose because the database is a detail in architecture, not the main decision - that’s the point of twist in my professional career as a programmer.