For God's sake people, keep your business logic in one place!


For God's sake people, keep your business logic in one place. Don't be spreading it all over the board. Some in stored procedures, some in the views, some in the extraction-transformation-load layers (ETL), and some in the presentation layer, yet again some in an Excel by end consumers.


You guys understand fully what "Business Logic" is right? Are you sure? Well, think about it.


Anytime data itself is CHANGED (added, subtracted, recalculated, interpreted, ignored, or even RENAMED--yes, even renamed--because when you 'alias' a data field you've just given it YOUR understanding of what that field means in your mind--giving it 'business logic.')


Here’s an easy example of the last one. Certain data has three fields: Svc_BUID, Cust_BUID, and Order_BUID. You (the data-mover/code-writer middle man) figure, "Hey, this is all Services data, so obviously these people want to see the service business unit ID, so I'll alias that field--",SVC_BUID as 'BUID'." You just added Business Logic. Bam!


The exception (or better understanding) of that rule that:

Business Logic = anytime data itself is CHANGED,


is when you are dealing with the META-data. THAT is ok to mess with and you can spread that all over the board without scattering the golden rule of integrity in good data design ( keep your business logic in one place, in case you forgot already).


You do fully understand what "Meta Data" is right? Are you sure? Well, think about it.


"Meta" is ancient Greek for "above" or "over." Meta data is that abstracted concept of any information that isn't the information itself, but is ABOUT the information. (You have to squint one eye and tilt your head a bit to fully get this.) Meta-data is all that wonderful stuff that a database surrounds the actual data with. So yes, meta-data is the data type itself (int? varchar? nvarchar?), whether it's in XML, or a RDBMS, or on-the-fly bits, all the history of when, who, and where data came from, and again it is also the field name itself--which is the border of the data itself-- and actually belongs in BOTH categories--"data" AND "meta-data."


So, all meta-data CAN be altered, changed, adjusted, transformed, and slung about however you want.


That, in fact, IS the job of the pure IT person. To make one storage point of data properly talk to another storage point of data without actually changing the data itself. These "storage points" of data are things like the Oracle, the SQL Server, the Informatica process, the DTS package, the spreadsheet, even the PowerPoint or the ".txt", ".doc", ".xml", ".html", or ".dat" file type. (Even whether it's Unicode, ASCII, ANSI, UTF-16 etc. character type.) That is all meta-data.


So, let’s recap.


The main lecture point here was going to be:  For God's sake people, keep your business logic in one place.


But, we really had to back up and clearly define what business logic is. And to do that we had to clearly understand the difference between data and meta-data.


So if you’ve changed the data, you’ve added Business Logic. If you’ve changed the meta-data, good for you, hopefully it works, do it anywhere and everywhere you feel like. It doesn’t matter. For God's sake people, keep your business logic in one place!


Business logic: Anytime data itself is changed.