Hoe ga je wijzigingen in de database in bron controle te houden?

stemmen
22

We maken gebruik van SQL Server 2000/2005 en Vault of SVN op de meeste van onze projecten. Ik heb niet gevonden een fatsoenlijke oplossing voor het vastleggen van database schema / proc veranderingen in broncode besturingssysteem.

Onze huidige oplossing is nogal omslachtig en moeilijk uit te voeren (script uit het object dat u te veranderen en zich verbinden aan de database).

We hebben veel ideeën over hoe dit probleem met een aantal aangepaste ontwikkeling aan te pakken, maar ik ga liever het installeren van een bestaand instrument (betaalde tools zijn prima).

Dus: hoe u uw database wijzigingen in de code te houden? Heeft u aanbevolen instrumenten?


Bewerk:

Bedankt voor alle suggesties. Wegens tijdgebrek, ik liever niet mijn eigen hier te rollen. En de meeste van de suggesties de fout dat ze de dev nodig om enkele procedure te volgen.

In plaats daarvan zou een ideale oplossing van de SQL-database op veranderingen te controleren en eventueel geconstateerde veranderingen in SCM plegen. Bijvoorbeeld, als SQL Server had een add-on die elk DML veranderen met de gebruiker die de wijziging zou kunnen opnemen, dan plegen het script van dat object aan SCM, zou ik blij zijn.

We spraken intern over twee systemen: 1. In SQL 2005 gebruiken objectmachtigingen om u te beperken in het veranderen van een object totdat u een checkout deed. Vervolgens wordt de checkin procedure zou het script het in de SCM. 2. Voer een geplande taak om eventuele wijzigingen op te sporen en te plegen ze (anoniem) naar SCM.

Het zou mooi zijn als ik de gebruiker-actie deel zou kunnen overslaan en laat het systeem te behandelen dit allemaal automatisch.

De vraag is gesteld op 09/12/2008 om 14:57
bron van user
In andere talen...                            


14 antwoorden

stemmen
3

oplossing Een arme man zou zijn om een ​​pre-commit hook script dat dumpt de laatste db schema in een bestand dat bestand hecht waarde aan uw SVN repository toe te voegen en hebben samen met uw code. Vervolgens kunt u de db schema bestanden diff van elke herziening.

antwoordde op 09/12/2008 om 15:01
bron van user

stemmen
1

Ik verbind gewoon de SQL-alter-Statement aanvulling op de volledige SQL-createdb-statement.

antwoordde op 09/12/2008 om 15:01
bron van user

stemmen
1

Hier is Jeff Atwood op Get Your Database Under Version Control .

antwoordde op 09/12/2008 om 15:03
bron van user

stemmen
15

Gebruik Visual Studio database-editie script van uw database. Werkt als een charme en u kunt elke Source besturingssysteem te gebruiken, natuurlijk het beste als het heeft VS plugins. Deze tool heeft ook een aantal andere handige functies. Bekijk ze hier in dit geweldige blog post

http://www.vitalygorn.com/blog/post/2008/01/Handling-Database-easily-with-Visual-Studio-2008.aspx

of check out MSDN voor de officiële documentatie

antwoordde op 09/12/2008 om 15:03
bron van user

stemmen
1

In SQL2000 het genereren van elk object in zijn eigen bestand , dan controleer hen allen in uw bron te controleren. Laat uw bron controle omgaan met de verandering geschiedenis.

In SQL 2005, moet u een beetje van de code te schrijven om alle objecten in afzonderlijke bestanden te genereren.

antwoordde op 09/12/2008 om 15:04
bron van user

stemmen
5

Ik moet zeggen dat ik denk dat een visual studio databank project is ook een redelijke oplossing voor de bron controle dilemma. Als het correct ingesteld kunt u de scripts in de database van de IDE uit te voeren. Als je script is oud, de meest actuele, voer het uit tegen de DB. Heeft u een script dat alle objecten reconstrueert en als je nodig hebt, nieuwe objecten moeten de dit script worden toegevoegd en met de hand, maar slechts eenmaal

Ik hou van elke tafel, proc en functioneren te zijn in zijn eigen bestand.

antwoordde op 09/12/2008 om 15:19
bron van user

stemmen
0

Onze DBA's regelmatig te controleren prod tegen wat er in SVN en geen voorwerpen onder de bron te beheersen verwijderen. Het duurt slechts een keer eerder de devlopers nooit vergeten om iets in de bron controle opnieuw te zetten.

We hebben ook niet toestaan ​​dat iemand om objecten te prod verplaatsen zonder een script als onze ontwikkelaars niet prod rechten hebben dit is gemakkelijk af te dwingen.

antwoordde op 09/12/2008 om 15:31
bron van user

stemmen
1

Rolling uw eigen vanaf nul zou het niet goed te doen, maar als je een sql vergelijking tool zoals gebruik Redgate SQL Vergelijk SDK om de wijziging bestanden te genereren voor u zou het niet erg lang om half-roll wat je wilt en dan maar eens kijken die bestanden in bronbeheer. Ik rolde iets dergelijks voor mezelf om wijzigingen van onze ontwikkeling van systemen op onze live-systemen in slechts een paar uur te werken.

antwoordde op 09/12/2008 om 15:34
bron van user

stemmen
1

In onze omgeving, hebben we nooit de DB handmatig te wijzigen: alle wijzigingen worden uitgevoerd door scripts op release tijd, en de scripts zijn in de versie controle systeem gehouden. Een belangrijk onderdeel van deze procedure is om zeker te zijn dat alle scripts opnieuw kunnen worden uitgevoerd tegen dezelfde DB de scripts zijn idempotent?) Zonder verlies van gegevens. Bijvoorbeeld, als u een kolom toe te voegen, zorg ervoor dat je niets doet als de kolom er al is.

Opmerkingen over de "suggesties de fout dat ze de dev nodig om enkele procedure te volgen" is echt een verklikker. Het is geen fout, is het een eigenschap. Versiebeheer ontwikkelaars helpt bij het volgen van procedures en maakt de procedures minder pijnlijk. Als u niet wilt procedures te volgen, hoeft u geen versiebeheer nodig.

antwoordde op 09/12/2008 om 17:32
bron van user

stemmen
0

In één project geregeld ik door zorgvuldige aandacht in het ontwerp dat alle belangrijke gegevens in de database automatisch opnieuw kunnen worden gemaakt van externe plaatsen. Bij het opstarten van de toepassing maakt de database als het ontbreekt, en vult deze uit externe gegevensbronnen, met behulp van een schema in de broncode van de app (en dus versiebeheer met de applicatie). De database naam van de winkel (een sqlite bestandsnaam hoewel de meeste database-managers kunnen meerdere databases) is voorzien van een schema versie, en verhogen we het schema versie wanneer we het plegen van een schema verandering. Dit betekent dat wanneer we de aanvraag om een ​​nieuwe versie met een ander schema dat een nieuwe database op te slaan automatisch wordt gemaakt en gevuld te herstarten. Moeten we een uitzending naar een oude schema dan is de nieuwe run van de oude versie zal worden met behulp van de oude database winkel ongedaan te maken, zodat we snel downgrades doen in geval van problemen.

In wezen, de database werkt als een traditionele applicatie hoop, met de voordelen van persistentie, veiligheid transactie, statische typen (handig omdat we gebruik maken van Python) en uniciteit beperkingen. Dat doen we echter helemaal niet zorgen te maken over het verwijderen van de database en opnieuw beginnen, en de mensen weten dat als ze proberen een aantal handmatige hack in de database dan zal het krijgen teruggekeerd op de volgende inzet, net als hacks van een proces staat krijgt teruggekeerd op de volgende herstart.

We hebben geen migratie scripts nodig omdat we net schakelen databasebestandsnaam en de toepassing opnieuw en het herbouwt zelf. Het helpt dat de toepassing gevallen zijn sharded één database te gebruiken per klant. Het vermindert ook de noodzaak voor database-back-ups.

Deze aanpak zal niet werken als je database op te bouwen uit de externe bronnen langer duurt dan je kan de applicatie naar beneden te blijven.

antwoordde op 15/12/2008 om 14:14
bron van user

stemmen
0

Als u gebruik maakt .Net en net als de aanpak Rails neemt met Migraties, dan zou ik aanraden Migrator.Net .

Ik vond een aardige tutorial, dat door middel van de oprichting ervan in Visual Studio wandelingen. Hij geeft ook een voorbeeld project om te verwijzen.

antwoordde op 18/09/2009 om 19:03
bron van user

stemmen
0

We ontwikkelden een aangepaste tool die onze databases wordt bijgewerkt. De database schema wordt opgeslagen in een database-neutrale XML-bestand dat vervolgens wordt gelezen en verwerkt door de tool. Het schema wordt opgeslagen in SVN, en we voegen de juiste commentaar om te laten zien wat er veranderd. Het werkt vrij goed voor ons.

Terwijl dit soort oplossing is zeker overkill voor de meeste projecten, is het zeker maakt het leven makkelijker op keer.

antwoordde op 18/09/2009 om 19:15
bron van user

stemmen
0

Met het oog op de verandering als insert-update te houden en te verwijderen zal er veel overhead voor de SVN zijn. Het is beter om alleen de ddl veranderingen zoals (te veranderen, drop, te maken) bijhouden welke het schema verandert. U kunt dit schema volgen gemakkelijk door het creëren van een tafel en een trgger om gegevens in te voegen die tabel doen. Elke keer dat u wilt u kunt de status verandering te krijgen door het opvragen van die tafel Er zijn een tal van bijvoorbeeld hier en hier

antwoordde op 26/06/2012 om 16:02
bron van user

stemmen
5

Het bijhouden van wijzigingen in de database rechtstreeks vanuit SSMS is mogelijk met behulp van diverse 3rd party tools. ApexSQL Source Control automatisch scripts elke database-object dat is opgenomen in versiebeheer. Commits kan niet automatisch worden uitgevoerd door de tool. In plaats daarvan moet de gebruiker kiezen welke wijzigingen zullen worden gepleegd.

Bij het krijgen verandert van een repository, ApexSQL Source Control is zich bewust van een SQL-database referentiële integriteit. Het zal dus een synchronisatie scripts met inbegrip van alle afhankelijke objecten die zullen worden verpakt in een transacties zo te creëren, ofwel alle wijzigingen in het geval er geen fout is opgetreden, of geen van de geselecteerde wijzigingen worden aangebracht worden toegepast. In ieder geval, database integriteit blijft onaangetast.

antwoordde op 07/12/2017 om 15:12
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more