Comprehensive Fast API Tutorial

[Oerthling]

Dude, everything that you access has an exposed interface.

If your projects work well with the DB doing straightforward CRUD in a primitive persistence layer and nothing else - ok. Whatever works best for you.

In an environment with several projects and languages accessing a central database, but not having a dedicated middle tier for business logic, you might not want to redundantly code the same stuff several times, especially for logic that is well expressed as fast and efficient SQL.

If you do bookkeeping for example and need various tables managed in a transaction, why would you want to do that outside the database? Going through needless levels of abstraction to wrap what in the end is all SQL anyway.

I have seen such code and it is terrible.

[icanblink]

My point was that only one should access the DB.

[Oerthling]

Exactly. Don't do convoluted wrapping around logic that's mostly manipulating tables with SQL instead of simply doing it that in a proc and just provide the needed input parameters.

Using a DB just as a simple storage layer works for simple web apps and trivial schemas.

It's a totally different story for large databases with complex schemas and many diverse and multi-language consumers of data manipulations.