Best practice for procedure-trigger code development with VCS and AI tools?

[Alexander Skara]

Hi!

Is there best practice and tooling for development of procedure/trigger/function code, that takes into account:

1) version control (VCS: SVN, Git);

2) needs of AI tooling, like Cursor IDE.

Historically there could be 2 approaches:
1) keep one large metadata files in VCS;

2) keep migrations in VCS

But AI tooling may work better, if all the DB code is extracted as files - each procedure and trigger code can have separate files. E.g. our current database has 1.6k procedures and 1k triggers.

AI tools - Is suppose may easily work with the current metadata files and not try to edit some part of metadata while scanning all the migrations to search for the latest versions of procedures and triggers that are needed to develope the current procedure or code?

How it is?

I am currently (with the advice of ChatGPT) thinking about SVN repo with:
/objects

  /procedures

  /triggers

/migrations

/metadata - just one file for any case

Is this the right design?

And what about tooling? For the proposed design to work, there shall be tool, that:

1) extract database metadata into multiple procedure and trigger files?

2) that scans the recently changed procedure and trigger files and puts them back into database.

Option 2) may not be needed, because the development already happens in the database and before the release it maye be extracted into procedures and triggers and diffed with SVN master version...

Although I am not sure about this...

Any best practice?

regards, Alex

[Dimitry Sibiryakov]

Alexander Skara wrote 31.07.2026 14:06:
> Historically there could be 2 approaches:
> 1) keep one large metadata files in VCS;
> 2) keep migrations in VCS
>
> But AI tooling may work better, if all the DB code is extracted as files - each
> procedure and trigger code can have separate files. E.g. our current database
> has 1.6k procedures and 1k triggers.

Nothing prevent you from having every SP and trigger in separate files using
them from the main script by command INPUT.

--
WBR, SD.

[Tomasz Tyrakowski]

On 31.07.2026 at 14:06, Alexander Skara wrote:
> Is there best practice and tooling for development of
> procedure/trigger/function code, that takes into account:
> 1) version control (VCS: SVN, Git);
> 2) needs of AI tooling, like Cursor IDE.
>
> Historically there could be 2 approaches:
> 1) keep one large metadata files in VCS;
> 2) keep migrations in VCS
>
> But AI tooling may work better, if all the DB code is extracted as files -
> each procedure and trigger code can have separate files. E.g. our current
> database has 1.6k procedures and 1k triggers.
>
> AI tools - Is suppose may easily work with the current metadata files and
> not try to edit some part of metadata while scanning all the migrations to
> search for the latest versions of procedures and triggers that are needed
> to develope the current procedure or code?

I'm not in a position to decide which practices are the best, I can only
share with you what has worked for me for over 20 years (but of course
it depends on many factors, e.g. your existing workflow, maybe team
size, deployment environment, etc.).

1. Each trigger and procedure in its own source file, versioned.
2. Migrations (weekly in our case), each in its own file, versioned.
After applying a particular migration in production, touching it may
cost you your fingers ;) (next week = a new migration file).
3. No single big metadata file - you can easily extract the metadata
from a database with isql, at any moment. I always keep an up-to-date,
empty, unused database aside, applying all migrations to it together
with migrating production DBs.

regards
Tomasz