Search SSWUG.ORG:

EDITORIALS

Editorial Rss
12345678910...
TitleDate

It's Time to Break Your Business Rules Out of Your Database



mI know I’m going to upset a lot of folks who have been programming database systems for a long time. So, just be prepared. I’m linking together a lot of thoughts from previous editorials, and reader contributions, to suggest reasoning for a current trend. Let me start with the assertion, and then we’ll see if we can validate it reasonably.
 
Assertion: Place business logic in business logic controller rather than in your database.

Us traditional DBAs say, it is best to keep your business rules close to the data, so that data does not become corrupt. Centralized data, centralized rules, means you have less risk of inconsistency. You can also take advantage of database tools to manage consistency. Defaults, constraints, validations, referential integrity are all built into a relational engine, providing a LOT of power.

If you are creating a commercial application, all of your rules are exposed for the world to see. In SQL Server, even if you encrypt your stored procedures, they are easily un-encrypted. If you obfuscate your table, column, procedure, and function names you make your system that much harder to work with yourself. So, if your business logic is in another tier from data storage, you can better protect your assets. To be fair, they can be reverse engineered as well, by the motivated hacker. But that is a lot more difficult.

Here is another reason. As we are seeing with micro services, whether SOA based, or otherwise, you can simplify your business rules by constraining them to a single responsibility. Doing so often results in sharded data storage. In that case the need for the rules may be repeated in different shards.  However, with micro services, they can be applied in a single engine.

Generally, databases don’t scale. So, if you need more power, you have to buy a bigger server. If your logic is not centralized on the database, you can more easily shard data to multiple databases on multiple servers, gaining higher scalability. 

If your database server is not using resources to implement business logic, you are going to have a greater amount of capacity for the same machine, simply because it is performing CRUD operations only. The other logic is much easier to scale out, and your smaller server can support more clients.

Tomorrow I’ll share a couple of real world experiences.

Keep the comments coming. I don’t believe you all agree, and it is always useful to hear differing opinions.

Cheers,

Ben
 
8/28/2015
12345678910...