On extending DBMSes

Problem: you have some data for your company. The data has to be accessed from multiple applications (think accounting, personnel, sales and so on). How do you make sure business rules are obeyed - because if there's a bug in even one application, it will ruin the data and thus every other application.

I agree with pretty much everything Fabian Pascal has to say about relational databases. The RDB *is* the place where data should live, and ideally it should be the place for business logic too - because business logic is about data.

However, there are a few problems with this - mainly because of a lack in implementation, not in the theory of the relational database:


  • No existing DBMS (Database Management System) - the actual implementation of the relational database theory - can support thousands of concurrent users, let alone millions.

  • It is hard to do user management / authentication in the same database as your business data - in fact, it might be a good idea to have separate databases for users (think Active Directory) and the actual data you care about.

  • The SQL language sucks for general purpose programming. It is difficult to write complex business rules in, and even more difficult to port to another vendor.



For these reasons, one should write an application whose main purpose is to "guard" the (main) database and enforce the business rules; think of it as "extending" the DBMS. [1] All other applications should go through this "gatekeeper" application.

I guess this is some sort of "pattern" - an architecture that can be used to solve a number of problems.



[1] Note: some DBMSes allow you to write "plugins" or "user functions" in a different language. The problem is, these are also not easily portable, so I would recommend against it.

Comments

Popular posts from this blog

Posting dynamic Master / Detail forms with Knockout

Comparing Excel files, take two

EF Code First: seeding with foreign keys