Is database abstraction a myth?

Question

css

Developer A only uses the abstraction layer over the relational database. For example, ORM. On the contrary, developer B has read books and now wants to postpone database selection until better times - he has to write abstractions.

Abstracting the database layer means writing abstractions over all database functions + writing adapters. Writing adapters means implementing them ORDER BY, JOIN, WHERE, AND, ORby hand. Writing by hand means writing a bike that will suffer in performance. At least, if you are not an academic/team leader in the database development team.

Now the question is - why do we need to write sorting, if we can immediately useORDER BY\ORM directly? (Well, or covering the SQL layer, at most, with ORM). I doubt that, for example, something can happen in a project and a relational database can change to a non-relational one - these are two different types of database for different tasks. Why do we need to write abstractions for two types of database at once?

It's just that after trying to "postpone the decision to choose a database" and directly write abstractions / adapters, the option "choose a database \ ORM \ framework at the very beginning and not fool your brains" looks much more optimal. (You can also refer here to choose a specific ORM framework and not write abstractions over SQL)

Have you ever had to rewrite a project from one database to another? Do you think the database layer needs to be abstracted away from the specific database?

Answer 1

Answer 2

Blocks 1 and 3 must have one parent, and the 2nd another

Answer 3

Blocks 1 and 3 must be in the same block.
More or less like this:

<div class="main">
    <div class="1and3">
        <div class="block1">
        BLOCK1
        </div>
        <div class="block3">
        BLOCK3
        </div>
    </div>
    <div class="block2">
    BLOCK2
    </div>
</div>

Answer 4

The choice of this or that architecture is rarely justified by purely technical ideas - much more often, these are brilliant ideas of book authors (who write books, not code, if they wrote code, then before they started writing books) - such ideas from books look beautiful, excite the imagination and eventually give rise to digital freaks - like refusing to use stored procedures
In the first place will not even be books, but the trends of people entering the CEO’s office (or articles of pop bloggers that he reads. Again, pop bloggers do not write code, they write blogs (and emotionally trend at conferences)) - but they can give birth to the director the idea "and let's our PRODUCT work on all DBMS, it's so cool, then it will be possible to drive it to anyone - both those who host postgres, and Vasyan with kokrochDB!"
The reality is this is CRUD. Since its inception, CRUD has not been of interest to developers capable of serious theoretical calculations and building beautiful solutions, so it tolerated any perversions like COBOL. Modern computers are so fat and fast that you can put the DBMS of a medium-sized enterprise completely into RAM and score on the disk subsystem completely - and a 64-core processor will digest both 12 and 24 layers of abstraction.
CRUD will work through any perversions of coders with three months of PTU behind it, written in python (which is also created by a coder - no sane programmer would come up with worflow control using indentation).

Answer 5

DB abstraction is a bit off topic.
Here is the class:

public class Users
{
   public bool Create(string name, string password, string email) { /* ... */ }
   public bool Delete(string name) { /* ... */ }
}

This class abstracts the database, further along the code, in order to create a user or delete him, I resort only to calls to methods of this class. What he does inside, what he connects to, what SQL he sends where - I'm no longer interested.