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
_______________________________________________
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
