first the DB tables or domain model than DB tables?
Hello,
We are about to develop a new business application with about 1000 clients.
Our IT staff consists of two groups, Java programmers and system analysts. A fight has just been started about one question between the two groups. The question is: "Who should design the database, and how?"
Our business analysts (BA) say: BAs should design the database and the database must be designed first. We should consider one more option: having business rules in the database. This way the Java developers can run stored procedures like: hasAnyMoneyToTransfer, isItAGoodClientForServiceX and so on
Our java programmers (JP) say: Follow a SW methodology ( for example Unified Process ) and somebody should create a domain model and than in the design phase this domain model must be refined which gives us the database representation of the model.
My question is: What do you think? We should start designing the database or we should create a domain model? Should we store business rules in the DB or not?
Of course I want to create a domain model first but I need arguments against the first option. As far as I know this "first the database and everything starts from the database" concept was widely used about 10 years ago when business application usually meant two layered Delphi applications, and nobody in the business app field uses that.
[1384 byte] By [
Anteksia] at [2007-11-26 21:24:04]
# 1
Let me answer it this way. Tell them to both develop simultaneously. There should be a level of abstraction between the two anyway. So your domain is not directly mapped or beholden to your schema.
That being said, are those 'analysts' also whining that no ORM tools be used? I bet they are. I bet they also expect applets to query the database directly as opposed to even having a domain layer... I bet its just a power play on their parts to put them in the driver's seat of the development of the application.
And Business rules in the database? WOW. Why even have a domain?
Even if you had a legacy product with a database already in existence that you must use I still would design domain first. I would ask what the application should do. Then design the application to support that, then as a last step map the domain onto the database schema. Creating a bridge if I had too.
# 2
Is there anyone supervising the IT staff? Who is in charge? These types of issues should be addressed by a software architect. Your description does not include this position. Sounds like your IT staff needs to hire an outside consultant. Sun has a great consulting team as an FYI.
Are the Java programmers three-tier developers, or are they CS grads just out of school? Is there a database administrator?
Business rules shouldn't be implemented in stored procedures.
The first step is to gather the business requirements of the application. After the requirements are specified then someone responsible for the application should create an architectural design and a technical design. The business object model desgin and the database design should occur at the same time and be guided by whoever is in charge. Both groups have to work together as a team.
If the business analysts are responsible for the relational database design design then they should start the design at the same time.
If there is no software architect, and if there is no software engineer, then the programmers should start the design of the business object model and start weekly prayer meetings (any faith is ok). The model is not a copy of the database. Both designs should occur at the same time.
# 3
The answer to most of the questions in the OP are "it depends." And as GR2 correctly implies, the software architect is the right person to resolve that sort of decision.
Regardless of what else happens, you want a correctly normalized database that will play nicely with whatever other applications need to access it. Databases are for ever - individual applications come and go. So you need a third party here, the competent DBA. They're worth their weight in gold and I wish I worked with them more often.
# 4
Thank you for your answers. All of you, of course. I really appriciate that.
> Is there anyone supervising the IT staff? Who is in charge?
I'm in charge but I am not a technical lead but a "manager" lead. I know we need a software/system architect but my company or the management of the company doesn't share my opinion about that ( I have already tried to convince them. )
> Are the Java programmers three-tier developers,
> or are they CS grads just out of school?
We have experienced programmers one of them is very brilliant, he is very good at programming and seeing pros and cons if we have to choose a technology for example ( e.g. EJB or not EJB ). I thought he whould be the system architect by implication because no other way exists here.
> Is there a database administrator?
Yes, we have.
> The first step is to gather the business requirements
I thought we would follow this order:
1. requirements gathering
1.2. separating the functional requirement from non functional requirements
2. then comes the analysis
2.1 functional specification: use cases and activity diagrams
2.2 structural specification: class and object diagrams
2.3 behavioral specification: sequence diagrams
3. design ( this means refining the models we have and adding the non functional requirements to the things we have )
4. implementation
> I bet they are. I bet they also expect applets to query
> the database directly as opposed to even having a domain layer.
Yes, I think they expects that scenario. I need aguments in order to convince them that it is not good. I just feel it is not good but I have no arguments in my mind.
> And Business rules in the database? WOW. Why even have a domain?
The same as in my last answer. I feel that it is not good to store business rules in the database but how can I convince them? I checked the web but I have not find any good point against their opinion yet. I would appriciate any links on this topic
# 5
Requirements gathering is analysis. You need to analyse the business requirements. You need to analyse the non-technical requirements.
When designing the software architecture, you need to meet/satisfy the non-technical requirements, i.e. security, performance, manageability, etc.
Use case narratives should be written. Use case diagrams are trivial, in my opinion. You need statements that describe what the application should do. You need statements that describe everything that the application should do. Not how to do it, but what to do...everything.
Someone, maybe the 'brilliant' programmer, should create a technical object-oriented design that satisfies/meets the business requirements. In order to do this effectively, he needs to read the Use Case narratives/statements.
The object-oriented technical design should consist on one or more UML diagram types. Whatever the 'brilliant' programmer feels is neccessary.
At the same time, the 'brilliant' programmer should me meeting with the database administrator and the business analysts and guide them in the relational database design.
At the same time an executable prototype should be created which implements the most important business requirements that are described in the Use Case narratives.
# 6
If your database is intended only to be used as a persistence mechanism for this application, I would question whether you actually need a relational database at all.
If the database is actually used to store data for use outside of the application, then it should be designed with this purpose in mind. The application's needs are pertinent but should not be the only consideration in the database design.
My experience is that people who want all the business logic in the database tend to be very comfortable with databases but know very little about application design and implementation. The legitimate reasons for putting business logic in stored procedures is being satisfied in contemporary designs with service orientation. This doesn't mean you won't use stored procedures or that you won't use Java for these services, it's just not particularly relevant from an architectural perspective. You'll probably use both in many of these services.
I second the calls for separate design with communication between teams and an architect/technical arbitrator.
# 7
> If your database is intended only to be used as a
> persistence mechanism for this application, I would
> question whether you actually need a relational
> database at all.
>
> If the database is actually used to store data for
> use outside of the application, then it should be
> designed with this purpose in mind. The
> application's needs are pertinent but should not be
> the only consideration in the database design.
Good point. Our database should be used only as a persistence mechanism but we have to take other things into considerations as well. We have a legacy system to which we have to accomodate because the legacy system implements a lot of things and there is no political decision not to use the legacy system. So it is a must. There are data regurarly changed between the legacy app and our new app so I know we have to take care about that.
I thought we would be able to separate ourselves by defining clean interfaces and maybe using converter "programs" with which we can convert the legacy system's data structure into ours and vice versa. ( for example if the legacy app uses a special ID to identify a Client and on our side our domain model says we should use something else, that converter program handles that. The legacy ID would be on our side as well but we could use that only when we have to send data into the legacy app. Of course it is a bit complicated and I'm sure we would not be able to cover everything this way )
>
> My experience is that people who want all the
> business logic in the database tend to be very
> comfortable with databases but know very little about
> application design and implementation.
I agree.
# 8
> At the same time an executable prototype should be
> created which implements the most important business
> requirements that are described in the Use Case
> narratives.
We surely will make a ( throwaway ) prototype, because we want to try out our chosen technology ( probably EJB, this is a business app, I'm talking about ), and the deployment process as well.
Concerning the other things about the process of the project ( requirements, analysis, design, implementation, test, deployment ) I agree with you, I don't think we will have problem in this regard.
In the meantime I found links about the "Business logic in database or not?" topic.
For example this link says, that middle tier servers are cheaper ( application servers ) than DB servers, so that's why put business logic into database:
http://www.codeproject.com/gen/design/DudeWheresMyBusinessLogic.asp
This is a next one with broader view (pros and cons):
http://www.martinfowler.com/articles/dblogic.html
# 9
> We surely will make a ( throwaway ) prototype,
> because we want to try out our chosen technology (
> probably EJB, this is a business app, I'm talking
> about ), and the deployment process as well.
"Throwaway prototype"? That is one option. However, this is not what I had in mind.
I don't favor wasting time or throwing away good code that has been written. The prototypes that my team create evolve into production systems. When they start writing the actual code, they don't have "throwaway" in their minds. They have, "this is the beginnings of a great app and is directly tied to my performance (and paycheck).
Executable prototypes serve are a sort of measure that can be reviewed and modified. And at some point, no longer is a prototype, it is the application. Creating the application in this fashion is a best practice. "Throwaway prototypes"? emmph
# 10
>
> > And Business rules in the database? WOW. Why even
> have a domain?
> The same as in my last answer. I feel that it is not
> good to store business rules in the database but how
> can I convince them? I checked the web but I have not
> find any good point against their opinion yet. I
> would appriciate any links on this topic
Which is as bad as their insistence that it should be in the database.
A demarcation is set by the problem domain and not just because one feels that it is "better" one place or another.
It would be a very unusual database that did not have at least some business rules even when those rules might be duplicated in other levels. For instance a database might enforce a one to one relationship between entities because of a business rule.
Some of the things that might drive business rules into the database.
- External apps need access to business rules and those apps will NOT be java.
- Performance reasons.
# 11
> Some of the things that might drive business rules
> into the database.
> - External apps need access to business rules and
> those apps will NOT be java.
> - Performance reasons.
No. All access to the database is through the designed software. One interface. There shall be no direct database access. Direct access totally undermines having any business rules in Java in the first place. If you need access, create a bridge and connect to the Java program.
Rules in the db will tie your hands. I have done it, but in the end, I pulled them out. In some ways its a volation of encapsulation. You want one thing in one place, not spread across multiple places. Yes the database can enforce some things, but I prefer to leave the rules in the business code. Rules in the database are only considered sanity checks in my book.
# 12
> > Some of the things that might drive business rules
> > into the database.
> > - External apps need access to business rules and
> > those apps will NOT be java.
> > - Performance reasons.
>
> No. All access to the database is through the
> designed software. One interface. There shall be no
> direct database access. Direct access totally
> undermines having any business rules in Java in the
> first place. If you need access, create a bridge and
> connect to the Java program.
Have you used Crystal Reports?
Trying to route crystal reports through an app server is going to require a lot more work than just going through the database. And it could have a severe performance impact as well.
>
> Rules in the db will tie your hands.
Code is code. A business rule in java is code. A business rule in a database is just SQL.
If you have a problem managing code then that is a process problem not a technological/architecture problem.
And as I already pointed out I seriously doubt that you can design a database without incorporating some business rules. What do you think drives one to many versus one to one relationships?
> I have done it,
> but in the end, I pulled them out. In some ways its
> a volation of encapsulation. You want one thing in
> one place, not spread across multiple places.
In an ideal world things would be ideal. In my world things are never ideal. The only time they come close is when there is only one application. Enterprise systems are never ever close to ideal.
> Yes the database can enforce some things, but I prefer to
> leave the rules in the business code. Rules in the
> database are only considered sanity checks in my book.
Again I doubt that you can do that unless you design the database as nothing but a shell for a meta data solution (your java code then effectively becomes the database rather than letting the database do what it does.)
# 13
> No. All access to the database is through the
> designed software. One interface. There shall be no
> direct database access. Direct access totally
> undermines having any business rules in Java in the
> first place. If you need access, create a bridge and
> connect to the Java program.
I don't really agree with any of this. Business rules come in layers as much as anything else.
For example, anything that can be expressed as a constraint is best managed in the database, whereas rules that need to draw in data from external systems are often best applied in the (Java) application.
Some business rules are localised to specific systems anyway - they share a common database but have no need to access each others business rules.
# 14
eg business rules engine in a database, http://www.amazon.com/Build-Business-Rules-Engine-Functionality/dp/1558609180/ref=sr_1_3/103-7909570-3471801?ie=UTF8&s=books&qid=1174587629&sr=8-3
# 15
> eg business rules engine in a database,
> http://www.amazon.com/Build-Business-Rules-Engine-Func
> tionality/dp/1558609180/ref=sr_1_3/103-7909570-3471801
> ?ie=UTF8&s=books&qid=1174587629&sr=8-3
Presumably you read it?
Did most of the stuff seem to be common sense or was there some really unusual implementation ideas in it? Did it delve into custom interpreters?
# 16
did not finish it, it was 'unusual'. only for MS Access, in VB, but the code did not work for my version. The author replied to my query for source in eg plain text or word doc as i only want to read it but never responded after that.
if i remember correctly, one aspect of the approach requires changes to the users' tables, eg adding columns that the engine manipulates. don't recall having a full blow interpretor, but then i never really saw the entire code.
I would not recommend this book but the reviews show others liking it.
# 17
Not to be too catty, but I'd have trouble taking a book seriously that advocates "using Microsoft Access and Visual Basic for Applications" to build any kind of substantial application.
# 18
> > No. All access to the database is through the
> > designed software. One interface. There shall be
> > no direct database access. Direct access totally
> > undermines having any business rules in Java in
> > the first place. If you need access, create a bridge
> > and connect to the Java program.
I agree with this, with conditions. It depends upon what the data is that is in the database. If the data is specific to the application, then in no cases should any other application get to the data directly. And, no individual should be able to get to the data as well, except the DBA.
If there is data that can or will be used in other applications, either in house or third parties, they should get read access and/or a copy. For example, moving data from an OLTP system to an OLAP. An application should not be the interface for this type of process.
Business rules should be encapsulated in objects. Certain things, that some may call business rules should be implemented in the database.
A stored procedure that executes fancy updating and selection and projection with cartesian products needs to be implemented in the database language inside the database management system.
Business rules governing what users do with an application go in the Business tier in the business objects. There may be additional relational constraints in the database that support and help enforce the Business rules in the objects.
Many will not consider stored procedures and triggers "business rules" however. It depends upon who and where you are speaking I guess.
Business rules are much more than constraints though, in my opinion.
In best case scenario, a business should be able to switch database management systems (Oracle to MS SQL Server) with relative ease for a business application. The Java EE three-tier architecture is based upon this principle. However, not all enterprise applications can be created with "the best case scenario".
# 19
> Not to be too catty, but I'd have trouble taking a
> book seriously that advocates "using Microsoft
> Access and Visual Basic for Applications" to build
> any kind of substantial application.
Marketing hype to sell the book most likely. Access is for beginners and has the lowest cost. VB is an elementary programming language again for beginners. The authors were most likely unable to write to Oracle or SQL Server and targeted their effort to the lower level audiences not able to distinguish nonsense from fact from opinion, in my opinion.
In regards to reviews online, be wary, they might have been written by a mouse in a basement, or the author's cousins...
# 20
> Business rules are much more than
> constraints though, in my opinion.
As jschell correctly points out, certian types of constraint are explicitly dictated by the business requirements. How, then, is that not a business rule?
If you're saying that business rules include but are not limited to constraints, then sure, but I still believe that there are rules that are best encoded in the database for reasons of efficiency or what-have-you, and rules that are best encoded in external application logic.
(edit) Fixed typo.
# 21
> If you're saying that business rules include but are
> not limited to constraints, then sure, but I still
> believe that there are rules that are best encoded in
> the database for reasons of efficiency or
> what-have-you, and rules that are best encoded in
> external application logic.
Yes, you are correct. Certain rules/constraints cannot be implemented with Java and can only be implemented with SQL and inside the database management system.
In my opinion, "business rules are much more than constraints". Referrential integrity and the rules for 2nd and 3rd NF are constraints, I don't think them as "business rules".
Customers can only view their account records and no other records. This is an example of a business rule, in my opinion.
# 22
If it's defined by the business requirements rather than any intrinsic limitation of the database then it's a business rule. Plenty of business rules are best represented in the database as constraints. A typical example is: accounts belong to customers in a many-to-one relationship. They don't have to though - they could exist in a many-to-many relationship (the joint account of a married couple for example). Either way it's a business rule that should be expressed using database constraints. It should also be represented in the application logic.
# 23
> Not to be too catty, but I'd have trouble taking a
> book seriously that advocates "using Microsoft
> Access and Visual Basic for Applications" to build
> any kind of substantial application.
Every database that I have ever heard of can fail disasterastly.
Not to mention that most problems with database code or code in general is caused by programmers and not technology. Given that more inexperienced users are likely to us MS Access it is quite possible that there are more horror stories because of that.
As for VB at least a couple of years ago it was considered a significant contendor for rapid front end development. These days there are so many contenders claiming that they can be used for rapid front end developement it is rather hard for me to keep them all straight (particularly as I don't do GUIs.)
VB wouldn't be my language of choice but then neither would C these days. Yet I know one can still build substantial systems with C.
# 24
> > > No. All access to the database is through the
> > > designed software. One interface. There shall be
> > > no direct database access. Direct access totally
> > > undermines having any business rules in Java in
> > > the first place. If you need access, create a bridge
> > > and connect to the Java program.
>
> I agree with this, with conditions. It depends upon
> what the data is that is in the database. If
> the data is specific to the application, then in no
> cases should any other application get to the data
> directly. And, no individual should be able to get to
> the data as well, except the DBA.
Sounds good in theory.
And when the VP of finance tells you that he wants direct acces to the database so he can do queries are you going to tell him to get lost?
>
> If there is data that can or will be used in other
> applications, either in house or third parties, they
> should get read access and/or a copy. For example,
> moving data from an OLTP system to an OLAP. An
> application should not be the interface for this type
> of process.
>
Again a nice theory. One that you can certainly enforce if you are building a new system from scratch. But that isn't going to fly with existing systems.
>
> Many will not consider stored procedures and triggers
> "business rules" however. It depends upon who and
> where you are speaking I guess.
>
Yes I suppose if you simply define anything in the database as not being a business rule then that certainly settles it.
I however do not agree with that definition.
> Business rules are much more than constraints though,
> in my opinion.
>
Constraints are an example. They are not the only one. Very complex ones can exist.
> In best case scenario, a business should be able to
> switch database management systems (Oracle to MS SQL
> Server) with relative ease for a business
> application.
Not a reasonable suggestion at all.
Most businessed will never make a move from Oracle to MS SQL Server.
They certainly won't do it if they have any volume.
And creating database independent code is a myth for larger systems with volume. Performance will always require database specific SQL.
They might move from MS Access to SQL Server or even Oracle. But then they are likely to do it because the volume has exceeded the capability. And in that sort of situation is it likely that enterprise solutions have grown adhoc which makes it much more likely that database specific processes exist.
In an ideal world one could be insured that every business had significant process control, long term planning and architecture in place.
In the real world there are so few that have even one of those in place that the effective rate is zero percent.
Thus one needs to deal with what the real is and not what it should be.
> The Java EE three-tier architecture is
> based upon this principle. However, not all
> enterprise applications can be created with "the best
> case scenario".
Idealized again.
# 25
>
> Customers can only view their account records and no
> other records. This is an example of a business rule,
> in my opinion.
How are you going to manage business rules when the company is using a crystal reports server and the professional services group is generating reports using that for individual customers?
# 26
> Every database that I have ever heard of can fail
> disasterastly. [etc.]
Sure, you can build good applications using Access and VBA. And you can build a decent application using COBOL on a VME system. However, unless the target audience is already constrained in their choice of tools I wouldn't ever recommend either platform.
That the authors chose Access and VBA suggests one of two things to me:
1. That they are not comfortable in alternative environments.
2. That their target audience is not comfortable in alternative environments.
The first point would suggest that their experience is not broad enough for this to be a good book, the second that the text will be too specific to VB to be of more general use.
It's certainly possible that this book is the cat's knackers, but the choice of tools persuades me that it is probably not.
# 27
> > Every database that I have ever heard of can fail
> > disasterastly. [etc.]
>
> Sure, you can build good applications using Access
> and VBA. And you can build a decent application using
> COBOL on a VME system. However, unless the target
> audience is already constrained in their choice of
> tools I wouldn't ever recommend either platform.
>
Myself I let the requirements define the technology.
> That the authors chose Access and VBA suggests one of
> two things to me:
>
> 1. That they are not comfortable in alternative
> environments.
> 2. That their target audience is not comfortable in
> alternative environments.
3. They collected data and based on that data they chose tools which addressed the widest market based on the collected data.
>
> The first point would suggest that their experience
> is not broad enough for this to be a good book, the
> second that the text will be too specific to VB to be
> of more general use.
>
> It's certainly possible that this book is the cat's
> knackers, but the choice of tools persuades me that
> it is probably not.
I believe I have seen a book that provided examples in more than one language.
I certainly haven't seen many. I am not confident that I have even seen more than two.
So based on your argument if the book used C++ then it would be worthless to Java programmers as well?
Myself I am going to hang on to my Algorithms book by Sedgewick because even though I haven't programmed in Pascal in a long time and I really don't expect to ever program in it again I find the book perfectly readable and usable.
# 28
> Myself I let the requirements define the technology.
Unless you had to use COBOL to satisfy some pre-existing set of circumstances - essentially legacy systems related - can you suggest a set of requirements that would lead you to use it?
> 3. They collected data and based on that data they
> chose tools which addressed the widest market based
> on the collected data.
Maybe.
> So based on your argument if the book used C++ then
> it would be worthless to Java programmers as well?
I said that it suggested it, not that it could not be otherwise.
None of this is intended as the last definitive comment on the book, but all of it suggests to me that it's probably not very good. I could be quite wrong; theoretical possibilities aside, what do you think? Or do you have no opinion on the matter?
# 29
> > Customers can only view their account records and
> > no other records. This is an example of a business
> > rule, in my opinion.
>
> How are you going to manage business rules when the
> company is using a crystal reports server and the
> professional services group is generating reports
> using that for individual customers?
"How" depends on "What". It really depends upon what the business rules are, and, what the business/doman requirements are. Crystal Reports has many APIs, i.e. interfaces for Java, C++ and VB. If an application is for report development, then the application should be designed using the appropriate API and have business rules either encapsulated in application's business tier, or, also have business rules and constraints implemented in stored procedures inside the database management system.
The E.pihany system is a perfect example of a mixture of both (www.epiphany.com).
# 30
> > Myself I let the requirements define the
> technology.
>
> Unless you had to use COBOL to satisfy some
> pre-existing set of circumstances - essentially
> legacy systems related - can you suggest a set of
> requirements that would lead you to use it?
No but then I am not familar with COBOL. On the other hand for MS Access.
1. Windows only target.
2. Stand alone app.
3. Minimal user set up (general consumer target market.)
4. Small volume.
5. Database support needed (implicit.)
With the above I would choose MS Access.
>
> > So based on your argument if the book used C++ then
> > it would be worthless to Java programmers as well?
>
> I said that it suggested it, not that it could not be
> otherwise.
>
> None of this is intended as the last definitive
> comment on the book, but all of it suggests to me
> that it's probably not very good. I could be quite
> wrong; theoretical possibilities aside, what do you
> think? Or do you have no opinion on the matter?
Myself I would rather it used Java or C#. But that is because I am familar with those so there would be less confusion on my part, rather than because VB suggests anything to me.
I would withhold judgement until I actually get a chance to browse through the book. I have bought books that on first glance seemed good, and on a complete reading seemed excellent and which I spent years quoting only to be finally told (and proven) that the book was wrong. The language choice for that book was java.
I have browsed a number of other books and found stuff useful to me in a variety of languages. My library includes java, C, C++, assembler, C#, Pascal, Forth, SQL, T-SQL, PL/SQL, Perl and a variety of general programming concepts. I have never used Forth and the last assembler book I bought was bought a number of years after my last assembler project. At times I buy books and know that I do not have the knowledge to adaquetly judge whether the book is worthwhile. Certainly that is true of some of the Oracle and Perl books that I have. And those are languages that I know. (And I still don't have enough knowledge to judge those books.)
You will note there are no VB books.At least at one time I considered buying some. But as far as I know and as far as the market suggests it tends to be used in GUI intensive and small shops for stand alone apps. And I am not interested in neither of those. I have however worked in various dialets of Basic years ago but there wasn't a lot of literature on it. If there had been then I would probably have some books on it.
Sometimes I don't look at books because the language is prominently displayed (like COBOL.) It isn't because I don't think that there isn't anything useful but rather because most of the useful knowledge won't be relevant (because it is language specific) to anything that I am doing or will be doing and with limited time finding the few nuggets it just won't be possible.
# 31
> > > Customers can only view their account records and
> > > no other records. This is an example of a business
> > > rule, in my opinion.
> >
> > How are you going to manage business rules when the
> > company is using a crystal reports server and the
> > professional services group is generating reports
> > using that for individual customers?
>
> "How" depends on "What". It really depends upon what
> the business rules are, and, what the business/doman
> requirements are. Crystal Reports has many APIs,
> i.e. interfaces for Java, C++ and VB. If an
> application is for report development, then the
> application should be designed using the appropriate
> API and have business rules either encapsulated in
> application's business tier, or, also have business
> rules and constraints implemented in stored
> procedures inside the database management system.
>
> The E.pihany system is a perfect example of a mixture
> of both (www.epiphany.com).
Not an answer.
I have written to a system where the business rules, over a number of years, were encapsulated in the reports (not the database and not an application layer.) The business was completely dependent on the reports and moreover many of the business rules were regulated by a large number of government bodies (federal, state, local.)
Refactoring involved moving the rules from the reports to the database - not an app server.
So are you suggesting that the only solution you would accept in that case would be to create a java layer to Crystal Reports (and I have done that as well and it is a lot of work) and then tie the reports to that?
Realizing of course that that is a performance hit? And that the users of those reports receive commisions based on the number of seconds (not minutes, not hours) on how long it takes to process a call?
Let me emphasize again that if and only if you are building a completely new system and you control all access to the system then excluding some possible performance related possibilities I don't have a problem with separating rules.
But that is a luxury that isn't often available.
# 32
> I would withhold judgement until I actually get a
> chance to browse through the book. I have bought
> books that on first glance seemed good, and on a
> complete reading seemed excellent and which I spent
> years quoting only to be finally told (and proven)
> that the book was wrong. The language choice for
> that book was java.
Do you mind if I ask what book that was? Just curious.
# 33
> > I would withhold judgement until I actually get a
> > chance to browse through the book. I have bought
> > books that on first glance seemed good, and on a
> > complete reading seemed excellent and which I
> spent
> > years quoting only to be finally told (and proven)
> > that the book was wrong. The language choice for
> > that book was java.
>
> Do you mind if I ask what book that was? Just
> curious.
I can't remember. I do know what I was quoting though, it had to do with the optimize versus non-optimize option flag having no impact. That book stated it. And I quoted it (no attribution) for years.
I believe I still have the book so I might be able to figure it out.
# 34
> Not an answer.
>
> I have written to a system where the business rules,
> over a number of years, were encapsulated in the
> reports (not the database and not an application
> layer.) The business was completely dependent on the
> reports and moreover many of the business rules were
> regulated by a large number of government bodies
> (federal, state, local.)
>
> Refactoring involved moving the rules from the
> reports to the database - not an app server.
Implementing the business rules for a database reporting application in the reports was a bad design, in my opinion. For an application of this type, having the rules implemented in the database management system is a good design. As I mention, it depends on "what" the application does and "what" it is used for.
> So are you suggesting that the only solution you
> would accept in that case would be to create a java
> layer to Crystal Reports (and I have done that as
> well and it is a lot of work) and then tie the
> reports to that?
There could be many reasons for having a Java component encapsulating reports from Crystal Reports in the Presentation tier.
>
> Realizing of course that that is a performance hit?
> And that the users of those reports receive
> commisions based on the number of seconds (not
> minutes, not hours) on how long it takes to process
> a call?
Depends on "what" type of reports. Strategic reports for analysis and decision making have no such time contraints. Strategic reports generated from a data warehosue are differenet then the example you highlight.
> But that is a luxury that isn't often available.
Depends on "what" type of application.
# 35
> >
> > Refactoring involved moving the rules from the
> > reports to the database - not an app server.
>
> Implementing the business rules for a database
> reporting application in the reports was a bad
> design, in my opinion.
Mine as well. But that isn't the point.
> For an application of this
> type, having the rules implemented in the database
> management system is a good design. As I mention, it
> depends on "what" the application does and
> "what" it is used for.
>
Which is what I already said.
> > So are you suggesting that the only solution you
> > would accept in that case would be to create a java
> > layer to Crystal Reports (and I have done that as
> > well and it is a lot of work) and then tie the
> > reports to that?
>
> There could be many reasons for having a Java
> component encapsulating reports from Crystal Reports
> in the Presentation tier.
Yes. But that isn't what I said.
The original suggestion was made that there was NEVER a reason to have business rules in the database.
I provided an example of a single case where that was not true - nothing more.
What I said was that I allow the requirements of the system to drive where business rules live. (And then provided an example.)
You seem to be trying to convince me of exactly that point.
# 36
Sounds good.
Not sure if you refer to my earlier statement, "Business rules shouldn't be implemented in stored procedures."
The key term here is "shouldn't". In the requirements world, the three key phrases are: MUST, SHOULD, MAY.
SHOULD - This word or the adjective "recommended" typically means that there may exist valid reasons in particular circumstances to either implement or ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
In the case of building a database reporting application, my earlier statement can be ignored.
If building a XYZ application, it should be implemented.
# 37
One other (I think) unmentioned reality is that the database will certainly outlive the J2EE application built to service it. Another J2EE application may supplant it, but how many of us have worked on the same database that evolved through COBOL, PowerBuilder, VB, Java and maybe .NET? The RDBMS is, in my experience, the most durable and long lived component in the architecture. So, putting business rules there does make sense to me on some level. On the other hand, it is more difficult to understand what is happening for a given request when one needs to examine Java and stored procedures to see what is happening. At least for me, staying in one IDE and language is easier.
- Saish
Saisha at 2007-7-21 18:16:50 >
# 38
> "Business rules shouldn't be implemented in stored
> procedures."
I just don't agree with this. You can have a system wherein all of the business rules are implemented in stored procedures. To say that you "should" not build such a system is justifiable only on the basis of some rather handwavy notions of architectural purity. I don't think that trying to proscribe such a solution is particularly helpful.
# 39
And to make things all the more confusing, many DB vendors support Java in the database. So it's not really a quesiton of java vs. stored procedures because stored procedures can be Java.
To Saish's point, which I agree with, I think often business logic in the database is really a rudimentary form of service orientation. I don't have a problem with it from an architectural standpoint but from an implementation view (developer's hat) I find it to be problematic. Stored procedure languages (e.g. PL/SQL) are very data-centric. I find that this makes them poorly suited to process centric logic. From my limited experience, the DBMS is a pretty substandard Java platform.
In short I guess what I am saying is that implementing data-specific business rules on the database makes pretty good sense but other platforms tend to be better suited for implementing process-specific rules.
# 40
Some "business rules" cannot be implemented with a DBMS SQL. For applications that have these, then my earlier statement applies as a guide, if "business rules" implementation has to be "squeezed" into stored procedures. Bad news here.
For a database reporting application, then it may have "business rules" that are very easy to implement in a DBMS SQL and it makes sense to implement them as close to the data as possible.
> In short I guess what I am saying is that
> implementing data-specific business rules on the
> database makes pretty good sense but other platforms
> tend to be better suited for implementing
> process-specific rules.
Elegant way of stating the issue. Much better than what I can write at this time. I still need to work on my presentation skills :o)
# 41
There's business rules and then there's business rules. Consider these two:
1. An order belongs to exactly one customer.
2. If the total extended sell price for the items in an order exceeds that order's customer's credit limit, then the order cannot be shipped unless the order's credit override flag has been set to "true".
You might choose to implement the first by setting various constraints in the database. But you might choose to implement the second in application code.
Edit: which (now that I read more carefully) is an example of what dubwai said in #39.
Message was edited by:
DrClap
# 42
> Sounds good.
>
> Not sure if you refer to my earlier statement,
> "Business rules shouldn't be implemented in stored
> procedures."
>
> The key term here is "shouldn't". In the requirements
> world, the three key phrases are: MUST, SHOULD, MAY.
>
> SHOULD - This word or the adjective "recommended"
> typically means that there may exist valid reasons in
> particular circumstances to either implement or
> ignore this item, but the full implications should be
> understood and the case carefully weighed before
> choosing a different course.
And again that is not qualified so I disagree.
The requirements drive the need, not the technology.
>
> In the case of building a database reporting
> application, my earlier statement can be ignored.
That isn't what I said.
I provided a specific example where the requirements of the system dictated that business rules needed to live in the database. The fact that the example was related to reports did not drive that decision but rather that the requirements did.
I have implemented other systems where the rules were definitely not in the database. Because the requirements/architecture of the system either allowed for that or even were dictated that way (customer driven.)
In another case certainly all of the rules and even most of the infrastructure was in the database (and yes that was an unusual system.) Again the technology didn't drive that.
# 43
> You might choose to implement the first by setting
> various constraints in the database. But you might
> choose to implement the second in application code.
>
> Edit: which (now that I read more carefully) is an
> example of what dubwai said in #39.
Wow, I wrote something people agree with? I must be getting ill. I'd better go home for the day.
# 44
> > I would withhold judgement until I actually get a
> > chance to browse through the book. I have bought
> > books that on first glance seemed good, and on a
> > complete reading seemed excellent and which I
> spent
> > years quoting only to be finally told (and proven)
> > that the book was wrong. The language choice for
> > that book was java.
>
> Do you mind if I ask what book that was? Just
> curious.
Found it...
"Practical Java Programming Language Guide" by Haggar.
It specifically says....
"Because the -O compiler option of the Sun Java 2 SDK compiler has no effect on the generated code, there is currently no need to use it."
