Dell Sala wrote:A table is, at minimum, data. But the table is also the most natural home of biz logic. You can attach triggers (server-side programs) that automatically fire on the three actions of insert, update, delete, and these triggers can contain all of your business logic. Consider this: code attached to the table is as simple as the world can get. Any other situation, such as putting the code out in the web layer, is a *complication*, and will always have drawbacks. The first is of course that your database is now helpless to defend itself against rogue apps. This is very important because the better the businessman you are, the more likely your software will be deployed by an IT department that demands access to the database. The second big problem is the ORM classes will always be more complex than the triggers they are by definition oxy-moronic: code that is by definition always attached to a specific table, yet by no possible mechanism can be positively synchronized with that table. Thirdly of course is performance, since application code is farther away from the server than trigger code, many functions will be forever doomed to be slower. Now, if you are on mySQL, some or much of this may not be possible. This explains why people will say that mySQL, despite ongoing improvements, is not a "real" database. So why don't people do it this way? Several reasons. First, they simply don't know they can. There is a second reason that is more justifiable, which is that it turns out to be a royal PITA to diddle around with triggers the way we do so effortlessly with our piles of PHP files. Another reason, which is harder to get into in an email, is an inclination to remain "platform independent" by avoiding coding in the proprietary language of a server product. Coders don't want their biz logic "locked" into Oracle syntax, or Postgres syntax, and so forth. The Andromeda solution is to store the database spec in a plaintext file and to generate the table definitions and triggers. This gives the Andromeda programmer: -> Simple editing of biz rules in a text file -> Platform independence, as we can generate SQL for multiple back-ends (this is only true in principle, we target only PostgreSQL at this time) -> All biz logic in the web server, its natural home -> All kinds of whiz-bang install/upgrade stuff -> Huge reduction in coding Hope this helps, and looking forward to seeing you this evening! |
begin:vcard fn:Kenneth Downs n:Downs;Kenneth adr;dom:;;347 Main Street;East Setauket;NY;11733 email;internet:[EMAIL PROTECTED] tel;work:631-689-7200 tel;fax:631-689-0527 tel;cell:631-379-0010 x-mozilla-html:FALSE url:http://www.secdat.com version:2.1 end:vcard
_______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
