Object Relational Mappers are evil (a meditation)

[Aaron Watters]

This is a bit off topic except that many Python
programmers seem to be allergic to typing SQL.

RESOLVED: Using ORMs leads lazy programmers
to make bad database designs. It's better to
carefully design your database with no invisible
means of support and there is no reason to not
use SQL directly for this purpose.

FOR EXAMPLE: Consider blogging. The most
successful blog software is WORDPRESS. Here
is the WordPress data model:

http://blog.kapish.co.in/wp-content/uploads/2009/03/wp_2.7.png

Beautiful, isn't it? It was designed by people who
thought about what they were doing and did it carefully.

Now let's look at the Sakai Blogger tool data model
(as reverse engineered by someone who had to
fix a bug -- there actually was no data design created
by the implementers):

confluence.sakaiproject.org/download/attachments/17072138/
entitymodel.pdf

How did the above happen? I suspect someone opened
up Eclipse and started typing, relying on the Hibernate
ORM to handle all the database stuff automagically. The
result is a massive headache for people like me. Another
one. I routinely open up the mysql prompt and start typing
"show tables", "describe table blah", "select * from blah limit 10"...
trying to figure out WTF Hibernate did with my data.

Occasionally I fantasize about making a non-trivial change
to one of these programs, but I strongly resist going further
than that because the ORM meatgrinder makes it somewhere
between extremely unpleasant and impossible to make any
non-trivial changes to a non-trivial program, especially after
it has been populated with data.

Ok I feel a little better now. Maybe I should get back
to work...

-- Aaron Watters
http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1200.wwiki

===

It has been said that democracy is the worst form of government except
all the others that have been tried.
Sir Winston Churchill
http://www.quotationspage.com/quote/364.html

 

[Bruno Desthuilliers]

Aaron Watters a écrit :

This is a bit off topic except that many Python
programmers seem to be allergic to typing SQL.

What I am mostly allergic to is manipulating sql queries as strings and
resultsets as lists of tuples. I strongly prefer a higher level
representation of both the queries and the resultsets. From this POV,
SQLAlchemy or Django's ORM are better than the primitive scheme above -
and don't have that much impact on db design.

RESOLVED: Using ORMs leads lazy programmers
to make bad database designs.

to me, a "lazy" programmer is someone that is mostly concerned with not
repeating itself. As such, "lazy" usually ends up with better designs
(db or whatever) !-)

It's better to
carefully design your database with no invisible
means of support and there is no reason to not
use SQL directly for this purpose.

I don't use SQL to *design* my databases, I use SQL (directly or
indirectly) to create and mananage my schemas and datas.

For the design part, I usually start with a pencil and some paper.

(snip remaining rant).

 

[Diez B. Roggisch]

This is a bit off topic except that many Python
programmers seem to be allergic to typing SQL.

RESOLVED: Using ORMs leads lazy programmers
to make bad database designs. It's better to
carefully design your database with no invisible
means of support and there is no reason to not
use SQL directly for this purpose.

FOR EXAMPLE: Consider blogging. The most
successful blog software is WORDPRESS. Here
is the WordPress data model:

http://blog.kapish.co.in/wp-content/uploads/2009/03/wp_2.7.png

Beautiful, isn't it? It was designed by people who
thought about what they were doing and did it carefully.

Now let's look at the Sakai Blogger tool data model
(as reverse engineered by someone who had to
fix a bug -- there actually was no data design created
by the implementers):

confluence.sakaiproject.org/download/attachments/17072138/
entitymodel.pdf

How did the above happen? I suspect someone opened
up Eclipse and started typing, relying on the Hibernate
ORM to handle all the database stuff automagically. The
result is a massive headache for people like me. Another
one. I routinely open up the mysql prompt and start typing
"show tables", "describe table blah", "select * from blah limit 10"...
trying to figure out WTF Hibernate did with my data.

I think your example is nonsense. Just comparing the two models based on
"they both are for blogging" is like comparing a cessna to a 747 - yes,
both are flying, but that's pretty much what they have in common.

It is pretty clear that sakai's data-model caters to a very
sophisticated *user*-model, with roles and permissions, and whatnot.
Plus other features. So it appears to be more in the CMS-league.

Now it's obviously easy to argue that this isn't needed for a simple
blog. Nonetheless, it doesn't make a point about ORM. With any ORM I
know (both in Java and Python) you could design the simple and straight
model WP uses.

And I've seen my fair share of convoluted, trashy pure-SQL-based DBs as
well.

So I think to make your point you need some more convincing arguments.

Diez

 

[Steve Holden]

I think your example is nonsense. Just comparing the two models based on
"they both are for blogging" is like comparing a cessna to a 747 - yes,
both are flying, but that's pretty much what they have in common.

It is pretty clear that sakai's data-model caters to a very
sophisticated *user*-model, with roles and permissions, and whatnot.
Plus other features. So it appears to be more in the CMS-league.

It's also pretty clear that the person who developed the sakai map had
nothing to guide them, making it difficult to divine any structural
regularity that may be present in the design. The entity-relationship
diagram doesn't even show the cardinality of the relationships, making
it much less useful than it otherwise might be.

As a result the whole thing looks like a dog's breakfast.

Now it's obviously easy to argue that this isn't needed for a simple
blog. Nonetheless, it doesn't make a point about ORM. With any ORM I
know (both in Java and Python) you could design the simple and straight
model WP uses.

And I've seen my fair share of convoluted, trashy pure-SQL-based DBs as
well.

Yup, me too. Many such designs make mistakes like using multiple columns
(or, even worse, comma-separated values) instead of many-to-many
relationships. Sad how such elegant tools are so badly abused so often,
isn't it?

So I think to make your point you need some more convincing arguments.

It seems to me that the biggest sin in databases is a failure to use
rigorous design techniques. If somebody doesn't understand relational
theory then they will probably not design database representations that
are easy to work with. If they do understand then the designs they
produce will operate just as easily with object relational mappers as
they do with direct SQL.

I suspect Aaron was really complaining about ignorance rather than
laziness (though the two do sometimes go together, and the former is
often but by no means invariably caused by the latter). But he'd have to
confirm or deny that.

regards
Steve

 

[Paul Rubin]

It seems to me that the biggest sin in databases is a failure to use
rigorous design techniques. If somebody doesn't understand relational
theory

Where does one find out about this? I've somehow managed to avoid
it for an awfully long time, but it begins to look useful. Thanks.

 

[Dennis Lee Bieber]

Where does one find out about this? I've somehow managed to avoid
it for an awfully long time, but it begins to look useful. Thanks.

Most decent college database textbooks should cover enough to get
started (Unfortunately, out of print: "Database Design" Gio Wiederhold)

I remember my college text (1978)... The chapters went:

Hierarchical databases
DBTG Network databases
(theoretical) Relational databases.

The next edition of the book, early 80s, went

Relational databases
(historical) Hierarchical
(obsolete) Network...

 

[Dennis Lee Bieber]

Yup, me too. Many such designs make mistakes like using multiple columns
(or, even worse, comma-separated values) instead of many-to-many
relationships. Sad how such elegant tools are so badly abused so often,
isn't it?

Probably created by people coming from the M$ Office world... "Hey!
an Access table looks just like an Excel spreadsheet!"

 

[Simon Forman]

Where does one find out about this?  I've somehow managed to avoid
it for an awfully long time, but it begins to look useful.  Thanks.

Go to the source: "The relational model for database management" by E. F. Codd
http://portal.acm.org/citation.cfm?id=77708

 

[Carl Banks]

This is a bit off topic except that many Python
programmers seem to be allergic to typing SQL.

RESOLVED:  Using ORMs leads lazy programmers
to make bad database designs.  It's better to
carefully design your database with no invisible
means of support and there is no reason to not
use SQL directly for this purpose.

Yeah sure, whatever. I'm sure a good programmer could use sql
directly and produce a tighter, faster, better-performing application
than an ORM-solution, same as you could use C to produce a tighter,
faster, better-performing application than a pure Python one.

No thanks, you can write your databases in database assembly language
if you want, I'll stick to my ORM, tyvm.

Isn't WordPress written in PHP? Are ORMs even possible in PHP? I can
almost rationalize use of direct sql if the alternative is some
hellspawn PHP ORM.



Carl Banks

 

[Bruno Desthuilliers]

Carl Banks a écrit :

Yeah sure, whatever. I'm sure a good programmer could use sql
directly and produce a tighter, faster, better-performing application
than an ORM-solution, same as you could use C to produce a tighter,
faster, better-performing application than a pure Python one.

It's certainly way easier to write good SQL than to write a good C
program, and even when using an ORM, it's sometimes worth "going down"
to hand-written SQL queries for some more or less complex cases. But I
guess this falls in the same category as recoding a couple core
functions in C for improved performances.

Isn't WordPress written in PHP? Are ORMs even possible in PHP?

There are (alas) some attempts. Nothing close to SQLAlchemy nor even
Django's - PHP is just not hi-level enough.

I can
almost rationalize use of direct sql if the alternative is some
hellspawn PHP ORM.

What _could_ possibly be done in PHP would at least be a higher-level
representation of sql expressions, that would make it easier to
dynamically build / modifie / combine queries. Working with "SQL as raw
strings" is both tiresome and error-prone when it comes to dynamically
generate complex queries. That part is IMHO *much* more important than
mapping tuples to objects.

 

[Bruno Desthuilliers]

Diez B. Roggisch a écrit :

Aaron Watters schrieb: (snip)
I think your example is nonsense. Just comparing the two models based on
"they both are for blogging"

FWIW, sakai seems to be a wiki, not a blog. And I would add that not
having a nice graphical *representation* of a schema doesn't imply the
schema is wrong from a relational design POV.

 

[Simon Forman]

Yeah sure, whatever.  I'm sure a good programmer could use sql
directly and produce a tighter, faster, better-performing application
than an ORM-solution, same as you could use C to produce a tighter,
faster, better-performing application than a pure Python one.

No thanks, you can write your databases in database assembly language
if you want, I'll stick to my ORM, tyvm.

Isn't WordPress written in PHP?  Are ORMs even possible in PHP?  I can
almost rationalize use of direct sql if the alternative is some
hellspawn PHP ORM.

I recently had the uncomfortable task of picking an ORM to use in a
php project for a start up.

There's something called RedBean http://www.redbeanphp.com/ that's
actually pretty effin sweet (IMHO). Sweet enough that I'm considering
porting it to python.

It's more of a RAD tool than something you'd want to use in production.

As far as the OP rant goes, my $0.02: bad programmers will write bad
code in any language, with any tool or system or environment they're
given. If you want to avoid bad code there's (apparently) no
substitute for smrt programmers who are familiar with the tools
they're using, not just the syntax but the underlying conceptual
models as well.

That said, "I feel ya bro'"

 

[jim-on-linux]

Python help,

In win32api line 10 is written:
mod = imp.load_dynamic(__name__, path)

traceback;
ImportError: DLL load failed: The specified module
could not be found.

import imp is available,
Where does
load_dynamic(__name__, path)
come from?

jim-on-linux

 

[MRAB]

Python help,

In win32api line 10 is written:
mod = imp.load_dynamic(__name__, path)

traceback;
ImportError: DLL load failed: The specified module
could not be found.

import imp is available,
Where does
load_dynamic(__name__, path)
come from?

The traceback is saying that it couldn't find the DLL you're trying to
load. Is the path you're giving correct? Does it point to a DLL?

 

[Mick Krippendorf]

Many such designs make mistakes like using multiple columns
(or, even worse, comma-separated values) instead of many-to-many
relationships.

BTW, the comma-separted-values-in-a-field is officially called the First
Anormal Form. There *has to be* some value to it since I've seen it used
quite a few times...

Mick.

 

[Ethan Furman]

BTW, the comma-separted-values-in-a-field is officially called the First
Anormal Form. There *has to be* some value to it since I've seen it used
quite a few times...

Mick.

Just because you've seen something, doesn't mean it has value; just
because something has value, doesn't mean the value outweighs the
associated disadvantages.

I'm not saying you're wrong, just that you may not be right. ;-)

~Ethan~

 

[Mick Krippendorf]

BTW, the comma-separted-values-in-a-field is officially called the First
Anormal Form. There *has to be* some value to it since I've seen it used
quite a few times...

Just because you've seen something, doesn't mean it has value; [...]

The setting of irony poti must've been to low... What I really meant to
say was: First Anormal Form is despicable, and anyone who uses it
schould Rot In Hell For All Eternities To Come! really!

Mick.

 

[Paul Rubin]

Just because you've seen something, doesn't mean it has value; just
because something has value, doesn't mean the value outweighs the
associated disadvantages.

The proliferation of tables required for the pure relational approach
is problematic enough that postgresql supports array-valued columns.
That comes across to me as an acknowledgement that the benefits of
"CSV in a field" are worth supporting in a somewhat less kludgy way.

 

[Ethan Furman]

BTW, the comma-separted-values-in-a-field is officially called the First
Anormal Form. There *has to be* some value to it since I've seen it used
quite a few times...

Just because you've seen something, doesn't mean it has value; [...]

The setting of irony poti must've been to low... What I really meant to
say was: First Anormal Form is despicable, and anyone who uses it
schould Rot In Hell For All Eternities To Come! really!

Mick.

If I knew what First Anormal Form was I (hope!) I would have seen the
irony. But it was still fun to wax philosophical for a moment. ;-)

~Ethan~

 

[Paul Rubin]

If I knew what First Anormal Form was I (hope!)

It appears to be a made-up term.