NYCPHP Meetup

[Kenneth Downs]

Ajai Khattri wrote:
>> On Tue, 11 Sep 2007, Kenneth Downs wrote:
>>
>> That's a personal opinion, not a system requirement.
>>     
>
> We *can* agree that SQL is not PHP (or Ruby or Python).
>   

Sure.

>
>   
>> What's a "conceptual relationship?"  If you put your data into tables, 
>> then the relationships between the tables are foreign keys.  That's easier 
>> to handle in set-based SQL, the language that was designed to do it.
>>     
>
> Noone writes apps in pure SQL :-)
>
> One has to take off their OOP hat, replace with a SQL hat, and 
> translate what you are trying to build into whatever tables / rows / 
> columns / relations you can model in SQL. So if you're using an OOP 
> language (and I do include PHP5 in that category) you have to do that 
> mapping anyway (until we get object-based databases perhaps). In fact, 
> most data structures need to be mapped (how do you store a tree in a 
> relational database? You don't, at least not without some mapping 
> process to SQL).
>
>   

What I am saying is no, you don't have to do that mapping, not if you 
think of data in terms of tables and rows, which is after all what it 
is, and think of code in terms of functions and classes, which is, after 
all, what it is.

OOP is wonderful for organizing code.  I have always found it superb at 
organizing UI based code, but horrible for business rules.

But my central point is that code is so different from table-based data, 
it requires different "hats" as you say above, that trying to make one 
look like the other is ultimately counter-productive.  In particular, I 
find it a mistake to make an object for each table and then to try to 
extend the object model to handle things like foreign keys.

Consider an analogy.  Most PHP programmers must learn HTML, CSS, and 
Javascript to some level of competence in order to code in PHP.  This is 
considered necessary and good, and we encourage one another to learn to 
do that stuff right, the way it wants to be done.  But come the database 
and we all decide we can somehow avoid learning the principles of DB 
design and try to make it look like PHP code.  We accept the obligation 
to learn HTML, CSS and Javascript, and even a few things about HTTP 
headers and so forth, but we think it is optional to learn SQL and to 
treat the database as what it is.  That really puzzles me.  The only 
explanation I can come up with is people must be using really simple 
databases so that the inefficiencies at large table counts just never 
show up.

This is probably where we simply disagree, though I hope we've fleshed 
out the positions to the point of usefulness to somebody sitting on the 
fence.

>   
>> Actually you don't need ORM for that, you just need a generalized set of 
>> commands, like "db_query" instead of "pg_query" and "mysql_query". 
>>     
>
> In other words, another layer of abstraction? Like ORM but not using 
> objects? :-) For me, it comes down to a choice between dealing with mappings 
> and all the database plumbing that that entails vs. letting an ORM layer 
> manage all that so I can concentrate on business logic and application 
> flow.
>
> Of course, there's always a trade off, like most things - I just think 
> writing say:
>
> event = Event.find(1)
> event.title = "New title"
> event.save
>
> more naturally expresses what Im doing than:
>
> UPDATE events SET TITLE="New title" where id=1
>   

ORM is definitely not a generalized (or abstracted as we say incorrectly 
these days) database layer.  It is the attempt to cast database 
operations in object-oriented actions, using objects to implement 
validation, relationships, and other stuff.

Your example above, by contrast, is not really ORM, it is just an update 
routine implemented using OO code.  My own looks very similar but does 
not use OO code, because none is necessary:

$row = array();
$row['first_name'] = 'Arkady';
$row['last_name'] = 'Bogdanov';
sql_insert('sometable',$row);

...and you can do the same for the other three basic operations of 
delete, update, and select.  But your example and mine both stress what 
I said in the beginning, PHP is fine for row-by-row operations, that is 
what it is good at.

But when you need to start doing reporting or on-screen displays, and 
the query requires even one or two joins, your performance tanks unless 
you just break down and write the query:

SELECT blah,blah,blah
    FROM table 1
    JOIN table 2 on x = y
  WHERE filters,filters,filters

Then recurse through the results and spit out your HTML or generate your 
PDF or whatever.  Trying to treat the rows as objects in that case is 
taking a good idea where it was never meant to go.


> Once you start defining and updating many-to-many relationships, the SQL 
> becomes much more complex compared to writing code.
>   

Again, not my experience.  But that is probably because I implement the 
business logic on the database server, and I generate the code to do so 
out of a data dictionary.  I haven't manually coded that stuff for 3 
years and I hope I never have to again :)

> I know I won't convince you but I think it important for people to hear 
> both sides and make up their own minds.
>
>   

Yup, couldn't agree more.

It has been fun debating the topic.

-- 
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com    www.andromeda-project.org
631-689-7200   Fax: 631-689-0527
cell: 631-379-0010

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070912/b2f009a4/attachment.html>