Business rules inside the dabase - how to avoid

Finding a case study for what you speak will not be easy, and I suspect will do little to sway the opinion of your DBA. If you do find something, please post it to the list here.

Here are the fundamental problems with his approach (feel free to use these arguments against him):

1) Business logic is hidden / spread across multiple tiers. This is a biggie. If you are using triggers, etc you have business logic that is spread across both the actual code level and across the DB. For a developer that is going to implement a change you have effectively doubled the cost of that change. Plus your development team has to be well versed in both Java coding and in SQL / DB specific coding as well - if your DBA is doing proprietary things in Oracle... well, you get the picture.

2) Changes to DB. If you ever change DB solutions, or even want to switch to a new set of tables, you have to replicate all of that work. There is no real reason for doing that with todays technology - you are just creating more work and making your system(s) less flexible to change and more challenging to migrate.

3) Object / DB disconnect. When you get into the guts of things, there is a wide gap between what is considered best practices for DB design and what is considered best practices for OO design. This culminates in a lot of work going into how to map objects to DB's and vice versa. The differences between these paradigms can cause huge problems when you are implementing business logic in both tiers. Here is an example:

Let's say that you have a universal rule that states that you must have a full 9 digit zip code for all addresses. In the object world this type of rule implementation is simple - you simply enforce this rule on your Address object and use it everywhere you need an address. But in the DB world it is a common practice to embed this type of data within other tables. For instance, you have a customer table with address fields. Same thing for employees, vendors, etc.

Now in order to enforce that 9 digit rule you have to create a stored procedure (or a constraint, whatever) on each of the tables that contains address data. Add a new table with address data? Re-create the rule enforcement.

4) People - As you had mentioned (or maybe someone else did), most companies follow this formula; coders > DBA's. And they do it for good reason. By making the DBA the gate keeper for all of the rule logic you are increasing your "bus" risk factor (he gets hit by a bus, your company is screwed). Plus he is certainly increasing his own job security (I call this complexity based job security - the more complex I can make my work seem, the less likely anyone is to fire me). If I were to perform a risk assessment here I would definitely want my larger group of coders handling rule logic.

Hope this helps.

Jonathan House

jonathanhousea at 2007-7-12 12:17:26 >