I don't see how putting business rules into the database limits accessability to them. Enterprise applications have database connectors/adapters.
How is a business rule in an application cleaner and "API-like"? Do you mean creating a library (e.g. perl module) of routines that implement policy? How is that "cleaner" than calling a stored procedure in a package? Have you used stored procedures and databases as back ends to applications?
Regarding your last paragraph, that's the whole reason why this topic is here. Everyone knows not to build business rules into the interface. The question is where to put them instead. That's what we are discussing here.
If I can boil down your post, I think you are saying that you prefer coding business logic in a library of a particular language. What language?
In general, I would put it into the place that is easiest to maintain. I've put it into stored procedures and views in the past. SQL is relatively portable as are stored procedures due to their conciseness.
I upgraded 5.2 with all packages suggested on www.linuxhq.com. After recompiling kernel 2.2.1 I get VFS error message "can't mount root filesystem". Has anyone else had this problem?
Slashdot Mirror
Tried it, too complex (feature rich) for less savvy family members.
I've been very happy with http://www.futurequest.net/
They have great technical faqs (http://www.aota.net/) giving all the details that you need to make your services work.
I've since transitioned to my own server, but I recommend futurequest to those that ask.
In reality most Americans couldn't find North Korea on a map and never give the country a moment's thought.
The same could have been said of Iraq.
I don't see how putting business rules into the database limits accessability to them. Enterprise applications have database connectors/adapters.
How is a business rule in an application cleaner and "API-like"? Do you mean creating a library (e.g. perl module) of routines that implement policy? How is that "cleaner" than calling a stored procedure in a package? Have you used stored procedures and databases as back ends to applications?
Regarding your last paragraph, that's the whole reason why this topic is here. Everyone knows not to build business rules into the interface. The question is where to put them instead. That's what we are discussing here.
If I can boil down your post, I think you are saying that you prefer coding business logic in a library of a particular language. What language?
I should clarify my above point, definitely don't put business logic into the presentation layer of the application.
In general, I would put it into the place that is easiest to maintain. I've put it into stored procedures and views in the past. SQL is relatively portable as are stored procedures due to their conciseness.
Definately don't put it into the application.
I've been very happy w/ Futurequest
I upgraded 5.2 with all packages suggested on www.linuxhq.com. After recompiling kernel 2.2.1 I get VFS error message "can't mount root filesystem". Has anyone else had this problem?