NYCPHP Meetup

[Kenneth Downs]

Dell Sala wrote:
>> In fact, the data tables are fully encapsulated by the database  
>> server and do not need to be encapsulated further into classes.   
>> Doing so introduces obfuscations which then must be un-obfuscated,  
>> so author ends up doing work to do accomplish an unnecessary goal,  
>> which then requires further work to undo.
>>     
>
> This is interesting. I've thought about this before, but haven't  
> heard anyone else express it. But a table is just data, no? I've  
> found it useful to wrap tables in classes so that I can attach  
> business logic to them.
>   
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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20061024/4fd59527/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ken.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20061024/4fd59527/attachment.vcf>