

Two common mistakes when using databases  - muriithi
http://caml.inria.fr/pub/ml-archives/caml-list/2008/02/b75fe4f240d3a3985e50f9bd23013579.en.html

======
xirium
Portability shouldn't be under-estimated. An ex-colleague had the opportunity
to re-write a bad implementation. After gathering the requirements, he had a
very nice specification which was portable, lightweight and extensible. Then
management wanted to add direct SQL access because old systems had this
feature and that made them fast. My ex-colleague didn't want to budge on this
issue because the direct access was the reason for the re-write. Management
wouldn't budge on the issue either because they were former techies and that's
how stuff was implemented on less powerful hardware. Anyhow, the fellow got
frustrated and quit. That's how he became an ex-colleague.

~~~
bdfh42
Without getting down into the details of any one such case - my inclination
would always be to go with the solution that could run on "less powerful
hardware". That sort of efficiency has a way of proving to be just that -
efficient.

Efficient always trumps cool - unless you come from the developer generation
where efficient is the only cool.

------
Tichy
"Every single element in a relation (aka table) has to be exactly the same
type- no superclasses, no variant types."

Hibernate offers several ways to deal with subclassing. It is also not just
dumping objects in the database, like the person in the discussion does, it is
mapping the objects to database tables.

True, there may be things databases are not good at (recursion), but overall,
in my experience the mapping from objects to database works really well and
feels quite natural.

