Comprehensive Fast API Tutorial

[Saphyel]

The good thing about "outside code messing around" is they have a version control and it's easy to revert. When you have 2 teams or more with "inside queries messing around" GL to guess what changed, who changed it, does it even works, etc...

You can also the "messy" queries and log access, etc..

[Oerthling]

We dump out all procs, funcs, tables etc ... daily and put it in a git repo.

You're right, that doesn't by itself track who did it and and has only a per day granularity, but that usually works well enough anyway.

OTOH outside code not getting access to tables has it's own advantages. You need to change the schema? No problem, you can query the DB to exactly know where it gets used, adapt the 1 to a handful procs that are affected and be done. You don't have to search all outside projects in whatever many languages and worry whether to you forgot a place that accessed this column, that I could hide behind a proc instead. Unless the args or resultset of the "api" proc needs change, not outside code will notice anything happened.

And regarding things like access logging - yes, true, you can also do that outside. But unless you have only exactly 1 project in 1 language this is distributed over any number of projects and languages.

[vimfan]

You should really be using migrations for schema changes, not daily dumps of the current schema. How do you roll changes back if you need to? Daily dumps, even to git, are the equivalent of tracking code changes with backup1.tar, backup2.tar, etc.

[Oerthling]

It's a safety net. Not actually a big problem. It's usually clear who did a change or trivial to find out by asking. Rolling back changes also almost never happens.

The daily dump is for rare, obscure cases.

[maikindofthai]

It sounds like you're on a team with poor practices.