5 ms·
Doesn't seem like that common of a problem to have to ship code that has to work with different databases. But if I ever had to do such a thing I would just sti
by guelo 10y ago
Doesn't seem like that common of a problem to have to ship code that has to work with different databases. But if I ever had to do such a thing I would just stick with ANSI SQL.
- koolba 10y agoThere's no such thing as ANSI SQL for real world applications on real world databases. Even something as simple as limiting the number of rows returned varies widely (TOP vs LIMIT vs rownum). The correct answer is to forget about database independence and double down on just one[1] so you can use it to its full potential. [1]: And obviously it should be Postgres...
- xxs 10y agoand you missed "fetch first" which is the ANSI thing
- chii 10y ago> common of a problem to have to ship code that has to work with different database when you are not writing a SaaS, but shipping a piece of software for a customer to run on their own server, it's a very common use case to support different database vendors - especially in enterprise software.
- flukus 10y agoGenerally the database to use is dictated by the software, that or it will support one or two, not any database.
- akud 10y agoIt's useful to, for instance, run your test suite against an in-memory database like sqlite or hsql, but use a "real" database in production.
- RussianCow 10y agoI think using VMs or something like Vagrant is a much better solution to that problem. You generally don't want to test against something that's drastically different than what you run in production.