"The SQL-layer is hidden from a programmer."
From my personal experience: Ouch! While hiding the SQL layer might make development easier at first, this will hurt really bad when trying to scale the thing. When you have lots of complex data (as projects tend to do when they grow), you will
- need to look exactly into how transactions are handled to make sure your whole stack (APIs, core application, database backend) adheres to ACID principles as much as possible. Especially if your systems works with financial transaction of any kind (incl. online payment, shopping carts, etc)
- need to decide how your data is split and unified and how the relations between it works, both for performance for minimizing disk storage (and backup sizes)
- need to fine-tune statements for performance
- need to use advanced features of your selected database to optimize processing
- need to look into server side processing (triggers, functions) to minimize data roundtrips between the database and the application
- have to think about splitting data between fast and cheap tablespaces (current data on fast SSDs, seldomly used archive data on cheaper, slower spinning disks
- need to deal with internal and external audits of your code. Both for security, but also possible in a financial and/or legal context. That means you will need to know exactly how the data is managed.
- need to deal with privacy laws like the EU "General Data Protection Directive (GDPR)". That means you might have to run data audit and/or make sure that you scrub some data as perfectly as possible. If you don't know exactly how your database backend works, you might be in trouble.
Not every point on this list will apply to every project. But I've worked on enough projects with database backends over the last 30 or so years that i have run into every single one of those issues multiple times. Currently, i'm working on a point-of-sales system (in Austria/Europe), so financial audits are like "Tuesday", and GDPR compliance is a way of life. The software also runs on both high end servers (multi-user, cloud stuff) and somewhat low end touchscreen cash register hardware (offline single user systems)¹, so optimizing is also something i do for every single release.
In conclusion: Yes, hiding SQL and database internals from developers may help some developers start a project without having to learn SQL. But it has some serious downsides in my opinion.
¹ The Jassway OLP116W, running Linux and our software is quite popular with our customers. For many, it's the perfect form factor. With only 4GB of RAM, i have to run a PostgreSQL database, our webserver/framework/POS-Sytem, custom printer drivers, two webbrowsers, etc. And i have to keep all financial data for the lifetime of a cash register (a decade or longer) in the database, that's just how the financial laws in my country works. And it all needs to be fast, because wasted seconds add up and will get expensive for a business when calculated over a year.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.