3

The business team in my company has come up with a new field to add to one of our entities. For new instances of this entity, it'll be calculated dynamically, but for previously existing instances, we need to set up a default value of, at the moment, 15. I can easily set that as the default value in the db, but to me, it is part of the business logic. Not only can it change in the future, but it is also separated from the rest of the business logic, all of which is so far in the application level. It'll be even somehow hidden to developers.

I can, not so elegantly, write some code at application level that will set that value when new instances are reloaded. But this is uglier.

My question is then, is it ok to put this "business logic" in the database?

EDIT: I'm not asking about pros/cons of different architectures with the business logic in the DB/app, but as stated in the title edit, about this concrete case of a default value.

user3748908
  • 1,607
  • 2
  • 14
  • 15
  • 3
    Possible duplicate of [How much business logic should the database implement?](http://softwareengineering.stackexchange.com/questions/194446/how-much-business-logic-should-the-database-implement) – gnat Nov 01 '16 at 15:09
  • Does your app have a configuration data table? A table where app properties can be modifed dinamicaly in runtime? Or this magic number (15) is going to be a mere column default value? – Laiv Nov 01 '16 at 15:37
  • @Laiv No, this is the first time this comes up, so I don't have a configuration data table yet. Then yes, this magic number would be a mere column default value – user3748908 Nov 01 '16 at 16:22
  • What do you mean 'at the moment 15', in 6 months time will you expect to be able to change this number for all clients that existed before the migration? If so, I'll change my answer. – Nathan Cooper Nov 01 '16 at 16:46
  • 1
    Can a ... Yes it can be. If you are asking for aproval, then these pros/cons matters. Possibility and suitability are different things. – Laiv Nov 01 '16 at 17:04

3 Answers3

5

You need to migrate some data. This logic belongs in that script. The script should change current entries to 15, but you absolutely shouldn't leave artifacts of that decision in your schema. After the migration, the number '15' isn't part of your domain, so shouldn't appear in a constraint or default.

If you expect to be able to change this default value post migration, you're going to have to have some way of indicating a pre-migration entity. Either use a null value for this, add an 'entity version' column (or something) or use some kind of inheritance based table structure. Then interpret this as 15 in the code.

If there is a default value for new clients after the migration (which it sounds like there isn't) that could belong in the table schema as a default value, but I would prefer to see it in the the code.

When I say 'In the code', I mean that's where the decisions are. It's okay to have the actual number 15 in some table or configuration depending on how it changes, why it changes and how distributed your system is.

Nathan Cooper
  • 1,319
  • 9
  • 15
  • Agreed, with the caveat that a 15 *might* be an appropriate entry for a check constraint or even added to a separate table with a foreign key constraint depending on what it represents. Only the OP can determine that, though. Constraints and Defaults exist to enforce data integrity so they should be utilized as a secondary check to your code (where appropriate). –  Nov 02 '16 at 15:15
2

This is one of those questions where you might get two equally valid answers from different sides of the camp. You mentioned you don't want an explanation on pros and cons of different approaches, so let me just get straight to the core of your question.

Is a magic number default value for a table column considered part of business logic?

The answer is Yes.

One could write out a business requirement as a rule or a declaration in such a way that:

If X is not specified for business entity Y, then the value of X property of that business entity should be 15.

Everything else aside is an implementation detail. This is a clear cut business requirement with a well defined conditional statement. This conditional fits the description of business logic.

Not pointing out the obvious best practice here of where business logic belongs and what databases are meant to do and do well (cough no business logic in the database! cough), that question was asked and well answered many times on this site.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
0

"I can easily set that as the default value in the db, but to me, it is part of the business logic." To be precise - it is not part of the business logic, exact value is part of business logic configuration. It is absolutely normal for development team to have no knowledge is it '15' or 'ACME'.

I do not recommend to "write some code at application level that will set that value when new instances are reloaded". KISS if you have no real reason.

What you might consider

  1. In application upgrade procedure prompt user to provide this exact value (or somehow else receive it from outside of your code) and then populate column in db with it. Often you can calculate the value from existing data, but it seems not to be the option in this situation.
  2. In application documentation have a passage that this specific version prompts for this specific setting on installation. Meaning "before installation of this version ask business team to provide the value for the setting".
Vlad
  • 559
  • 1
  • 3
  • 6