3 ms·

> Use a good abstraction library and start coding. Seriously. I'm pretty skeptical of this approach. Cross platform development is a pain in the ass, whether

> Use a good abstraction library and start coding. Seriously. I'm pretty skeptical of this approach. Cross platform development is a pain in the ass, whether we're talking databases or operating systems. I say pick the most powerful database you can and marry it. Use its features to the fullest and ignore portability. I suggest db2 or oracle.

siculars 18y ago
if you are a startup you are not even considering db2 or oracle. you consider exactly what the op suggested. further, as your business grows so to will your needs. you may start with one backend in a particular configuration and evolve and/or migrate to a different configuration/platform. abstraction is "the right thing to do" (tm).
- kingkongrevenge 18y ago
  > if you are a startup you are not even considering db2 or oracle. Why not? The free versions exceed postgresql. If you succeed and face heavy load, then you just throw some money at the problem rather than blow hundreds of man-hours fidling with the hacks people use to scale the free DBMSes.
  - olefoo 18y ago
    You can just throw money at Postgres problems and make them go away. There are a number of very capable firms that do nothing but Postgresql support. And, they don't hold you captive w/ licensing. And if your needs are really that unique they can help you with building extensions to postgresql that support the capabilities you need. See http://www.commandprompt.com/support/ http://www.commandprompt.com/support/ for an example, or http://pgexperts.com/services.html http://pgexperts.com/services.html
- jmtulloss 18y ago
  Agreed. I love developing locally with a version controlled SQLite database and then deploying to *sql and having everything just work. Sometimes there are differences that need to be worked around (same as cross platform development), but starting with the assumption that your db might change is a good thing, in my opinion.
  - deleted 18y ago
    [deleted]
frossie 18y ago
For long term maintainability, absolutely abstraction is the way to go. Any pros and cons listed now can help you decide, but what about a year from now? Two? Five? This goes double if you are considering commercial products. For various reasons we are forced to use $Vendor, but we are not a commercial shop and we always have the fear factor that $Vendor will price us out (they occasionally try it on by "forgetting" our academic discount). We hid all the DB interactions in two layers (one to hide the relational nature of the database, and the other to hide the specific implementation). As a result, I am in the position to tell $Vendor "How much? Well, you can give us this price or we can move to postgress - either is fine by me". And mean it. And they can tell.

siculars 18y ago

if you are a startup you are not even considering db2 or oracle. you consider exactly what the op suggested. further, as your business grows so to will your needs. you may start with one backend in a particular configuration and evolve and/or migrate to a different configuration/platform. abstraction is "the right thing to do" (tm).

kingkongrevenge 18y ago
> if you are a startup you are not even considering db2 or oracle. Why not? The free versions exceed postgresql. If you succeed and face heavy load, then you just throw some money at the problem rather than blow hundreds of man-hours fidling with the hacks people use to scale the free DBMSes.
- olefoo 18y ago
  You can just throw money at Postgres problems and make them go away. There are a number of very capable firms that do nothing but Postgresql support. And, they don't hold you captive w/ licensing. And if your needs are really that unique they can help you with building extensions to postgresql that support the capabilities you need. See http://www.commandprompt.com/support/ http://www.commandprompt.com/support/ for an example, or http://pgexperts.com/services.html http://pgexperts.com/services.html
jmtulloss 18y ago
Agreed. I love developing locally with a version controlled SQLite database and then deploying to *sql and having everything just work. Sometimes there are differences that need to be worked around (same as cross platform development), but starting with the assumption that your db might change is a good thing, in my opinion.
- deleted 18y ago
  [deleted]

frossie 18y ago

For long term maintainability, absolutely abstraction is the way to go. Any pros and cons listed now can help you decide, but what about a year from now? Two? Five? This goes double if you are considering commercial products. For various reasons we are forced to use $Vendor, but we are not a commercial shop and we always have the fear factor that $Vendor will price us out (they occasionally try it on by "forgetting" our academic discount). We hid all the DB interactions in two layers (one to hide the relational nature of the database, and the other to hide the specific implementation). As a result, I am in the position to tell $Vendor "How much? Well, you can give us this price or we can move to postgress - either is fine by me". And mean it. And they can tell.