July 2, 2016 at 7:33 pm
David.Poole (7/2/2016)
I suspect the "don't put business logic in the data tier" crowd will make loud noises.
I'm pretty sure you are right, in fact the noises are likely to be very loud.
But when that crowd makes loud noises I usually regard it as a reassuring sign that I haven't forgotten to include elementary error management in the system design.
Although I think they are right in the majority of cases I am in favour of implementing a check constraint for a data rule that can be expressed simply and clearly with a light weight constraint. If you are in an agile team the argument that it is "hidden" just doesn't stack up.
I wouldn't object to the "no business logic in the database crowd" if most of them didn't use it to demonstrate that all normalisation is bunk from beginning to end and to assert that data integrity is the applications job and it's a waste of resources to put any of it in the database. Unfortunately, most of the ones I've come across do make such claims. So I don't think they are right in the majority of cases. The problem is that a reasonable statement (that the only business logic that should be in the database is the logic which enforces what are often called data integrity rules) has been turned into absolute nonsense (the statement that no business logic at all should be in the database), and most of the crowd say "don't put business logic in the database" and mean that, not "don't put application logic other than data integrity logic in the database".
I would like to force those people to go on a decent error managemet course at a university that has a strong reputation for that topic, have them take MSc level classes and seminars for a few weeks, because then they would come out understanding that it is important to detect errors and not let an assumption that implies that errors can't happen (eg the assumption that the app developers and QA team will always deliver perfect bug-free code) prevent you from detecting them, becuse if you don't detect them you can do none of error containment, error correction, and error reporting all of which are essential if you need a reliable system.
Yes, the application should do all it reasonably can to ensure data integrity; but the database must not assume the application got all of that right, and must do everything it reasonably can to ensure that if the application allows something that would cause the data to be invalid to get through to the database, the database will prevent it from having that unwanted effect.
Tom
July 3, 2016 at 1:51 am
Tom,. I wish I could find the blog post which addressed the elephant in the room which was "define business logic".
The author felt that the term was too vague to be useful and was even vague enough to be harmful. They came up with separate classifications that collectively could be described as business logic but in separateness clearly fell into DB responsibilities, DAL responsibilities, middle ware responsibilities.
I remember thinking that the article represented an outbreak of common sense
July 3, 2016 at 7:38 am
David.Poole (7/3/2016)
Tom,. I wish I could find the blog post which addressed the elephant in the room which was "define business logic".The author felt that the term was too vague to be useful and was even vague enough to be harmful. They came up with separate classifications that collectively could be described as business logic but in separateness clearly fell into DB responsibilities, DAL responsibilities, middle ware responsibilities.
I remember thinking that the article represented an outbreak of common sense
Perhaps I saw that article, and if it is the one I,m thinking of it was mostly common sense but partly blindness. If it's not that one and really did adopt a completely sensible approach I too wish you could find it (so that you could post a link to it here).
The one I saw did split "business logic" into several categories. It advocated never doing the same sort of checks in more than one place (if I remember rightly the places were DB, data access layer, apps, and user interface/presentation layer. There are three issues with that: a performance issue, an error management issue, and a security issue.
(i) some integrity checks are cheaper to do in the database (eg uniqueness), others are cheaper to do in the app (eg range checks) or even in the user interface/presentation layer because that saves on calls to the database (and perhaps on calls to the app and to the data access layer).
(ii) errors that cause loss of data integrity are critical errors and ought to be checked for everywhere where it is reasonable to do do, not just in one place.
(iii) we should apply the "least capability" principle to all users in the database to protect against attempts to breach data security other than via the app, but each app must still apply that principle to its users and ensure that each them gets the appropriate subset of the capabilities available to the app.
Tom
July 3, 2016 at 11:02 am
My position is that the data asset is likely to outlive the application. It is also an infinitely reusable asset so has a long period to pay back any investment made in collecting and storing it.
If you accept that premise then the steps necessary to ensure the quality of the data are paramount.
If security has to be defence in depth then why not data quality? Especially as the data can generate revenue.
If the app does its job then the effect of the constraint will be invisible. If the app doesn't do it's job then an exception will be raised highlighting the fact. If the app silently ignores exceptions then from a data point of view the data is still protected. I don't know of many lead developers who would discard exceptions without appropriate handling
July 3, 2016 at 12:35 pm
David.Poole (7/3/2016)
My position is that the data asset is likely to outlive the application. It is also an infinitely reusable asset so has a long period to pay back any investment made in collecting and storing it.If you accept that premise then the steps necessary to ensure the quality of the data are paramount.
If security has to be defence in depth then why not data quality? Especially as the data can generate revenue.
If the app does its job then the effect of the constraint will be invisible. If the app doesn't do it's job then an exception will be raised highlighting the fact. If the app silently ignores exceptions then from a data point of view the data is still protected.
That makes sense, in fact it's the only sane way to look at it. Data integrity and security are paramount. It's also essential that performance is at least adequate, but performance can't be adequate if data quality isn't.
I don't know of many lead developers who would discard exceptions without appropriate handling
I've know quite a few who not only would but did do that. Many who did do it also lied to management about their error handling as well as about the performance of their software (which couldn't actually be measured yet because it didn't work); they usally lied about how close they were to gaving a working version too; and when presented witha set of requirements and a budget and timescale that was obviously utterly inadequate to enable the requirements to be met they would tell their managers that they could do it easily, thus ensuring that things would bget even worse than they aleady were.
Maybe I've seen more of that than most people, because I've quite often been put in to take over a project that was gettting nowhere and bring it back to life. In my experience lead developers (and project managers) who do disreagard exceptions (and think doing it is a good thing) seem to be a common cause of projects needing a manager who can fill holes insead of digging them deeper.
Tom
July 4, 2016 at 8:09 am
Jeff,
I'm trying to send you a private message about your previous post in this thread.
I'm getting this response from the system:
Send Private MessageExpand / Collapse
The following error occurred...
Sorry you cannot send this private message.
• The recipient has already exceeded their permitted number of private messages.
You should contact the recipient via other means and ask them to clear some private messages to allow you to send them a messages via the forum.
Return to previous page...
412-977-3526 call/text
Viewing 6 posts - 31 through 35 (of 35 total)
You must be logged in to reply to this topic. Login to reply