Peter J. Holzer <hjp-pgsql@hjp.at> writes:
> In my applications I use SQL heavily. RDBMs are good at processing
> queries, so use them for that. If all you want is a key-value store,
> don't use PostgreSQL. I'm not very fond of ORMs. I know what I want to
> do and can express it in SQL. An ORM makes me translate that into a
> different (and usually inferior) query language, which is then
> translated back into SQL. That doesn't make things easier for me.
>
Could not agree more! My experience has been that ORMs just get in the
way. Worse yet, when I've investigated performance problems raised by
developers, I've often found it is due to the ORM layer, which is unable
to map more complex queries efficiently.
The only 'layer' I've ever used which I liked was HugSQL. I quite liked
this approach as you write the queries in SQL and these get exposed to
the application layer as high level functions, so gives a nice clean interface.
>
> I come from Oracle, not MySQL, But I have also used MySQL, and I guess
> the very wide gap in capabilities between Oracle and MySQL made me
> cautious about putting too much into the database. There is also the
> expectation that you should be able to use a different database engine
> (SQL is a standard, right?) just like you should be able to use a
> different C compiler, but in practice that never works. And of course I
> wasn't very impressed with PL/SQL. (PostgreSQL gives you a much wider
> range of languages for stored procedures than Oracle, but PL/PerlU still
> isn't quite the same as Perl (And I suspect it's the same for Python).
>
> hp
Again, totally agree. Nice in theory and reminds me of the 'write once,
run everywhere' dream. Very few of the places I've worked have actually
maintained cross database functionality for long, if at all. The problem
is that while SQL may have a standard, how that standard is implemented
is very different. When I have worked at places which tried to be
database neutral, they inevitably give up as they find that in the end,
they needed to maintain separate SQL or have separate database
maintenance teams anyway. You will only get seamless SQL across
different databases if your SQL is very basic, in which case, you
probably don't need a full blown RDMS anyway. Most of the time, your
choice of database will be dictated by your dominate platform in the
market your application targets.
--
Tim Cross