Show HN: Write universally accessible SQL, not library-specific ORM wrapper APIs

Re:Show HN: Write universally accessible SQL, not library-sp... by dwohnitmok on Tuesday August 10, 2021 @12:15PM (#28130654)

Over time I've come to see DB-independence as a benefit that is seldom realized and therefore not a strong point in favor of a given system.

Data is generally far more valuable than application code and often times your database will far outlive your application code (and sometimes even your choice of programming language).

Moreover if you're using DB-specific features rather than generic SQL, there's usually a strong business need driving it that would cause DB-specific coupling even in a supposedly DB-independent ORM.

[ Parent | on HN ]

Re:Show HN: Write universally accessible SQL, not library-sp... by jcpst on Tuesday August 10, 2021 @01:43PM (#28131862)

> Data is generally far more valuable than application code and often times your database will far outlive your application code (and sometimes even your choice of programming language).

I agree with this. At my current company, we have stored procedures that are over 30 years old still running. The original application code was VB6, then VB.NET, and now there are C# NET5 services. There’s also all kinds of other document stores, but that old SQL DB isn’t going away any time soon.

[ Parent | on HN ]