Many web developers think that the answer to this question is: “As a useless artifact fit for a museum”.
Probably the most common perspective among JavaEE developers is: “As a place to store persistent copies of our classes”.
Organizations having a history with databases might answer: “We have the same kind of database design that we always had. Then the developers go write everything else in the middle tier.”
Organizations that still think databases are useful might answer: “We write our batch code as stored procedures, but all of our UI code is in the middle tier.”
I have a more “Thick Database” perspective. My answer to the role of the database in web architecture is: “Anything to do with the business rules associated with the business objects or their interaction should be stored as closely as possible to the objects themselves (in the database). Things having to do with the UI should be stored with the UI code. Interfaces between the database and the UI could be stored either with the UI or with the objects, but given the tools that Oracle provides, those interfaces should be database objects.”
There are a number of ideas in my answer to be discussed in more detail:
- Store business object code with the objects. I think this position is pretty hard to argue against, yet I see many shops that do not even think about object logic as a concept. It is all just “code.” I find this ironic because the whole concept behind OO thinking involves encapsulation, yet few self-identified OO professionals think this way. If the code is near the objects (in the database)performance is better, fewer context switches are required, and lots of other nice things are possible.
- UI code stays with the UI. Similarly, this one is a no-brainer. Keep all of the UI stuff in one place. However, in my world, I do all of my UI work in the database as well, but I do keep it in its own area for management purposes. Formspider™ lets me use PL/SQL for UI scripting. I appreciate the fact that I do not having to use different programming languages in different parts of my system.
- Interfaces could be near the UI code (e.g. ADF BC, Hibernate, TopLink) but are better coded in the database. I prefer that the database be isolated from the developers. I do this by building INSTEAD OF trigger views to present the data in the way that it needs to be displayed on the screens. Then the screens can simply point to these UI views. All of the complexity (and even the physical database design) is hidden from the UI developers.
Leave a Reply