NYCPHP Meetup

[Ajai Khattri]

> 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).


> 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).


>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

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

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



p.s. What the hell is v-webmail? Your email was unreplyable in Pine and 
WebMail. I had to manually copy and paste your comments...


-- 
Aj.