sql server - Database - Version Control - Managing dropped/deleted objects -


we want clean our database schema , drop/delete objects no longer being used.

we suspect sometime in future we'll want resurrect removed functionality.

we've discussed following options dealing dropped objects in version control:

  1. deleting .sql files source control once gone database , relying on version history store definitions. our concern approach sometime on years source control moved , lose history. seems difficult know recover if can't see dropped objects.

  2. leaving .sql files in source control updating definitions "drop proc {someproc}". approach our concerned leaving objects in version control no longer exists , risk losing history if vcs moved

  3. creating new repo dropped objects , migrating .sql files repo once have been dropped sql server.

we're working in windows environment , new working vcs databases. git + ssdt.

currently option 3 our preferred approach.

i see lot database code, happens on time people end stuff in database either not used or not work (think proc references table , table modified not proc).

the thing in source control (which looks have) , create tag or branch of code before , after deleting can back.

two things transpire, either code genuinely never used or used @ year end , when find out, world fall on head better have quick way back.

of course if had full suite of tests year end process safe :)

i wouldn't use option 3, keep history in main branch keep history it.

ed


Comments

Popular posts from this blog

html - Outlook 2010 Anchor (url/address/link) -

javascript - Why does running this loop 9 times take 100x longer than running it 8 times? -

Getting gateway time-out Rails app with Nginx + Puma running on Digital Ocean -