Utility for working with database sources

Question

SQL

Much is said about the best practice of storing database sources in hard currency, with each object being a separate file, and so on.

There are also many fashionable (and not so) deployers and changhe managers that allow you to manage changes to the database code, collect diff scripts, roll into databases and control the whole thing (Liquibase, dbdeploy, etc).

And there is some tool that would help directly manage the source code itself, for example:
- I could sketch a frame from folders and files to store the source codes of objects;
- assemble the final script from these sources, which can be used in some CI. Moreover, the assembly with various parameters, for example, partial (of a separate table or several tables), without FK, PC, indexes, etc. Assembly with test data, assembly with combat data and much more…
— control the relevance of stored objects, i.e. make sure that if a user was deleted from the repository, then all his objects should also disappear from the current version. If the table was crashed, then its indexes were also deleted (which are also stored in separate files and have their own change history);
- was it integrated into any collector (Ant, Maven)

?

Answer 1

Excuse me, but what do "database sources" mean?
DB source is usually understood as the source code of the database server - Mysql, Postgres for example.
And the “structure” of the database itself is a banal bundle of binary files with a base file, logs, indexes and other stuff.
Well, the structure of the database is actually a human-readable list of tables in the database, the structure of the tables themselves and access rights.
Or maybe I don't understand

Answer 2

If the system supports the migration mechanism, then it should be enough for you.
If there are problems with this (including not using offline solutions), then you can create an sql folder, in which you separately put the structure and fixtures (data). Well, and, accordingly, this folder in the hard currency.
But it is still preferable to understand the first option - migration is a more correct tool, IMHO.