Peter J. Holzer <hjp-pg...@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