Real requirements vs business requirements

Question

Let's say I have an account creation form, which fills a user database. Let's say this database table has 6 columns: UserID, UserLogin, Password, Email, Demographic1, Demographic2.

The program really requires UserID, UserLogin, and Password. It can't function without. The rest are "business requirements", the company would like to know these things. They are "required".

Would it be better to structure my application and database so that these are actually required, or to enforce this constraint in business logic?

My gut is telling me the 2nd choice, but in nearly all the production code I've seen, the 1st is usually the case.

Is this lack of planning, or some sort of imprinting on programmers from the business/pm (they tell me it's required, I'll make it required). Or, is there a compelling reason?

Answer 1

By putting these constraints in the database, you are asking the database to help enforce your business logic. There are good reasons for enforcing such constraints in the database.

1. The database is your reference. It needs to be as correct as possible. Putting not null constraints in the database helps that. It enforces some of the business rules even if it is not the front end GUI that is inserting the data, for example bulk inserts from a batch or a developer/dba changing the data using SQL to 'fix' a problem.
2. It does actually help the developer to understand the data constraints. Digging through code to find out if a value cannot be null is sometimes a bit difficult, but looking at the db is easy. Similarly, if you're producing reports and you know that a column is not null, then it becomes easier.
3. If you KNOW that a value should not be null and it is an error if it is null, this allows fail-fast behaviour. If anyone inserts a null value without going through the business logic, or due to a bug, then the bug will be found quicker than if you allowed nulls in the database.

Ask yourself the question: would you remove foreign key constraints as well? After all, they are only business constraints. You can enforce them through business logic after all.

The question for me is how many constraints to put in the database. As a general rule, I create two types of constraints in the database: foreign keys and not null constraints. These are quick wins, and uncontroversial. For your point about duplication of code, you're correct, you are theoretically duplicating a check, but the benefits outweigh any minor problems. So I put checks in the business logic AND I add a not-null constraint in the database.

You can go further with different types of check constraint, but that's normally not the case for me, because now you're really starting to duplicate code.

Enforcing foreign key and not-null constraints in the database isn't a perfect or complete system, but it does find bugs, it protects your data, and it helps you with your job.

Answer 2

Real requirements for us normally refer to Technical Requirements which is what the program truly requires in order to operate. We usually enforced them in the structural design such as as DB constraint in your case.

Business requirements deals with what the business perceives in order to make the app acceptable. In most cases, but not all, this usually involves how the ROI is generated from the program that we develop. In our projects, the demographic info is usually tied to some kind of marketing campaign, a data that can be used later to promote things to the users, or something similar.

I find that business people normally do not adequately explain to us the necessity of business requirements and simply stating them as "required". Just stating that without having us understand the context is making it hard for us to determine how it should be implemented. If we know that the business requirements are core to the business and the company may lose a lot if we don't implement it correctly then obviously we would choose a more fail safe way to implement it. In your case, that would probably by embedding it in the structural constraint itself.

In order to answer your question, it's important to understand the context and the needs of the business requirements that are proposed by the business/pm. Since you are in same team, you should know that in order to make the best technical decision. As a personal belief, when in doubt, I always go for a stronger check and validation (though this is not necessary always resulting in the best decision).

Hope that helps

Answer 3

I'm not sure I really understand your question. If the domain you are working on defines user as an Entity, and requires user entity to have email, demographic, etc, then these fields are required and should be persisted in some type of permanent storage (db, file, etc).

Answer 4

Go for what YOU think is best; YOU are the programmer --> one database with UserID, UserLogin, and Password and couple other databases to that.

The thing is, as with many things in life, in the end YOU will be responsible for what your choices were, and you can distinguish yourself by making the choices better than your customer. A customer is like a child, and you are the parent. You want the child to be happy, so sometimes you have to make choices for it that are more probable to make it happy in the longer run. Even when your child (client) and your mother-in-law (boss) are sucking you in another direction...

Answer 5

You should do both. Constrain the database to require this and if necessarily bubble up the exception. This is so that if you ever do sql inserts/updates that this rule will be there.

However, on the business side, this is represented visually as required on the form and as validation logic which pops up a nicer error message.