Where to build business logic in DB or web service & how ?
-
MS Access has one big thing going for it, though. It's used by a lot of people that have no interest in being programmers. A programmer tasked with making a business environment stronger would be a waste of money if s/he tries to move every little power user idea/creation onto a real database platform. Better that the programmer in such an environment is willing to share knowledge and even learn a bit about MS Access in order to better interact with the power user set.
Don't get me wrong, when someone with the knowledge level starts laying on the VB in order to get Access to do more I see an opportunity to move somone with the mindset over to a more powerful environment. However, there are real business reasons why MS Access does real database work, not just management tasks.
Everett Wilson
ewilson10@yahoo.com -
To get back to where this question came from....
I'm not heavily schooled in Databases etc, however, I have a good number of years experience working with them, and attempting to display the results you get when you query them. It is noticeable that the one thing SQL Server doesn't offer is a presentation layer. It is also noticeable, that ASP offers a good, platform independent (for the user) , presentation layer.
So, now we have the three components.
Data belongs in the database,
Content is what you get when you make an extract of that data using any business logic,
Style is how you display it.
For me, the extraction belongs in the database, so that is where my business rules tend to end up these days.
That's my take on it anyway.
-
I read this article. It discusses...one of the main issues of the db becoming a bottleneck, and a case for alot(if not all) business logic in the business logic layer.
http://www.codeproject.com/gen/design/DudeWheresMyBusinessLogic.asp
Here is an image showing what (could) happen for a system that is designed from the ground up, scaleability wise. But the article does into it much deeper.
The url has a comments section (at the end of his article) if you have issues with his presentation. I'm only sharing information here.
..
-
I'm sure you think I'm just being argumentative, but the author of that article is an idiot. The most notable attribute of the article is its incoherence. He uses terminology interchangeably and it's clear that he doesn't know much about data management fundamentals. It's not uncommon for the ignorant to use the term "database" to mean either a database (a logical grouping of tables etc...), or a database management system (SQL Server, Oracle, DB2), but this guy even uses it to mean a server (hardware)!
His portability arguments don't hold a drop of water. No matter where the SQL code resides, if you move from one DBMS (NOT "database") vendor to another, every bit of your SQL will have to be reviewed. The only exception is if you utilize some sort of data abstraction software like Hibernate that generates the SQL code for you depending on which DBMS you are hitting, but there is a cost associated with those as well...
This guy spends quite a bit of time talking about formatting, and I don't think anyone in their right mind would argue that formatting, or any other display issues, should be handled by the DBMS. So his arguments there amount to nothing more than a flimsy straw man for him to bash.
The same thing is true of his discussion of stored procedures. Although there are many (myself included) who would argue that for a number of reasons, it makes sense to use stored procedures as the core of your data access layer. I won't go into those arguments here because it isn't really relevant to the topic of business logic. I'll agree with him to say that if you are using stored procedures (or SQL of any sort) to handle formatting, or complex procedural logic, that probably isn't the best place for it. So once again he sets up a straw man and proceeds to whack away at it.
When he finally swerves into the real issue, the author says things like "The database should not have any knowledge of what a customer is, but only of the elements that are used to store a customer." Maybe a friend of his should take him aside and explain (very slowly) that determining the attributes, relationships, and constraints that apply to (and thus define) a customer IS AS CLOSE TO "knowledge" AS A COMPUTER CAN GET (at least for now)! Furthermore, if he doesn't realize that those are core "business logic" functions, then he needs to spend more time reading and thinking and a whole lot less time spouting his ignorance in the form of worthless opinions.
The glittering gem of his ignorance is when he says "Databases were designed for storage and retrieval..." I'm sure that Dr. Codd would be thrilled to discover that he had merely reinvented the wheel, and a rather square one at that since DBMS's are pretty inefficient storage and retrieval mechanisms compared with files (although in fairness, they do usually include a pretty handy query language...). Once again the author shows his confusion between "databases" and "database management systems", but the main point is that this idiot apparently believes that the relational model is concerned with "storage and retrieval." The relational model of data management is PURELY LOGICAL; it has NOTHING WHATSOEVER TO DO WITH STORAGE, RETRIEVAL, OR ANY OTHER PHYSICAL MATTERS, INCLUDING PERFORMANCE!
So now, if the RM is purely logical; how in the world could a database that is designed using relational principles NOT be concerned with "business LOGIC"? What other kind of logic might it be concerned with? The answer, of course, is that it is wholly concerned with “business logic.” A properly designed relational database (not DBMS) captures and represents those business rules that define what the data is. What is also true is that the same data may be put to multiple uses (I don’t suppose the author would recognize this as a key aspect of data independence), so the RM, and by extension, "databases" (at least properly designed ones) are not that concerned with the specific uses to which the data they manage is put, or how it is presented, that is the job of the application(s) so there is a valid point to saying that certain "business logic" functions belong in the application, but it is inexcusable to claim that business logic should be excluded from the database. The logical result of such nonsense is a return to application managed files for "data storage and retrieval." Even the most ignorant “databases are for storage and retrieval” cheerleaders would balk at such an idea, but why? I think it’s simply intellectual laziness, they are too lazy to figure out the real benefits of using relational databases, but they are also too lazy to wean themselves off of that handy query language, so they are stuck muttering their almost incomprehensible platitudes and comfort themselves in the “knowledge” that their opinions are accepted as common sense by their peers. Of course they dismiss those of us who dare to challenge their myopic views as “mean”, “hidebound”, or laughably “Database Lords?” Meanwhile “DBAs” who are likewise ignorant, or weak willed enough to play their Reindeer Games are praised as “enlightened”, “reasonable”, or even more laughably “Database Presidents?!?”
Call me “Protector of the Realm”… Ahh, who am I kidding? Just call me “Benevolent Dictator!”
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
-
I'm not going to go quite as far as DCPETERSON here, but I would agree the author of the article SHOLIDAY posted expresses an inconsistent and self-contradictory view in the article.
I found two statements particularly interesting.
1) The database should not be able to relate which tables should store a customer object and it should treat the tables independently with reference to a customer object. The database's job is to store rows in tables that represent the customer. Apart from the referential integrity constraints, data types, null ability, and indexes that make data retrieval more expedient, the database should have no functional knowledge of what exactly constitutes a customer in the business layer.
--- OK Someone tell me how the RDBMS can enforce referential integrity without being 'able to relate which tables store a customer object?" What is this 'functional knowledge?' As DCP points out, the RDBMS stores data not knowledge.
2)But in many enterprises, especially large ones there are dozens or hundreds of developers, and just one, or a few DBAs and the DBAs sit at the top of the enterprise chain of command.
--- I'm not sure about the 'top of the chain' part of this atatement but the author explains that DBAs are reluctant to let developers decide database design. The fatal flaw with his argument is that most developers are experts in their development language(s) but novices at database design and data integrity concepts. DBAs shouldn't tell them how to code, they should recognize that professional DBAs don't just grab these crazy ideas out of thin air to irritate them. Their are sound reasons a DBA insists on some things.
-- This statement also reveals (and ignores) a basic truth of today's business world. The enterprise may have dozens or hundreds of developers and one DBA. Let the many developers with varied levels of knowledge make database related decisions, write code to the design they choose. Then when the data integrity (or the data itself) is irretrievably lost and the business suffers financial loss, what happens? The DBA is fired.
There is a reason trained DBAs are given the responsibility of maintaining what many business leaders will tell you is one of the most valuable assets of an emterprise, its data. It makes no sense to give this responsiblity to a trained professional and then deny them the authority required to safeguard it. In my work, I try to accomodate every request of the developers. However, there are times I have to say 'No' and usually when I explain why the answer is no, the developers accept and we work out a suitable solution together.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply