data vs business logic

Question

Today my manager said: 'Amir, don't mix the business logic with data in database'. I surprisingly shocked! I said 'Where?'.

According to wikipedia business logic is:

In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed.

He said category and subcategory are business logic in our definition and requirements and you shouldn't create one-to-many relationship in database for them. Of course, you must encode them in logic and create some objects or xml for them.

Sometimes, it is difficult to separate logic and data. My question is what are your options or your experience about this part? How can I separate data and business rules according to requirements very well.

Answer 1

There are many schools of thought regarding what logic & rules you can put in the database, and this will vary somewhat on the capabilities and type of the database.

One thing for sure, though, is that if you don't put sufficient domain logic in your database to maintain your data's integrity, then you should wrap your database in a service and have all your applications access the service instead of the database directly.

I agree with Wikipedia that the entities, their relationships, and requirements about their referential integrity, as well as other constraints, are part of the business/domain logic — yet belong codified in the database (if, say, relational), or in a service wrapping the database, say, if NoSQL.  I don't think you can truly separate data & persistence from business/domain logic, as the data's schema simply is logic for and of the business domain.  (I don't think that using xml is going to fundamentally solve anything in this regard — it just moves the problem to another technology.)

I personally feel that one-to-many relationships sometimes are exactly what we need, yet other times can be thought of as an optimization on many-to-many relationships, and, as such can be a premature and (business/domain) limiting optimization.

For example, designing the data model to have one office per instructor/professor, or one department per instructor, could work well for a long time, then fall on its face when encountering a rare scenario that an instructor/professor teaches in two (or more) departments.

Other examples of premature optimization in schema is creating a separate identities for Teacher entity and a Student entity.  Now a student who teaches or a teacher who themselves takes a course has to have two identities in the system.  Preferred would be a Person entity that can play multiple roles as needed over time.  (This also goes to using many-to-many relationships over one-to-many.)

Answer 2

In your example case I understand category to be just a label that is structurally identical to subcategory: a string, possibly with a maximum length. According to your manager, the meaning assigned to that label is business logic.

This would imply that the choice of deeming something a category or a sub category is not fixed and will be made on a case-by-case basis, depending on scenario.

If this is not the case, you would want to store the parent-child relationships somewhere and you would be back at your database level.