Oprette, byg og valider SQL Database-projekter

Fuldført

Før du kan automatisere deployments, køre tests eller opdage skema-drift, har du brug for noget, en pipeline faktisk kan bygge. Det noget er et SQL-databaseprojekt.

Forstå SQL-databaseprojekter

Tænk på et SQL-databaseprojekt som din database i filform. Hver tabel, lagret procedure, visning og funktion ligger i sin egen .sql fil. Du erklærer hvert objekt én gang, og når du skal tilføje en kolonne eller ændre en datatype, redigerer du den enkelte fil.

Hvis du tidligere har arbejdet med migrationsscripts, er forskellen betydelig. Migrationsskripter er sekventielle. Du skriver en ALTER erklæring, håber den kører i den rigtige rækkefølge, og opbygger en voksende kæde af ændringer over tid. Et SQL-databaseprojekt tager den modsatte tilgang: du opretholder den ønskede sluttilstand for hvert objekt, og værktøjerne beregner forskellen mellem projektet og måldatabasen ved implementering.

Når du bygger projektet, er outputtet en .dacpac fil, en kompileret model af hele dit databaseskema. Du publicerer det .dacpac for at oprette en ny database eller opdatere en eksisterende. Byggeprocessen giver dig to ting, der betyder noget for CI/CD:

  • Validering: objektreferencer og T-SQL-syntaks kontrolleres mod en specifik version af SQL, før noget bliver implementeret.
  • Et deployerbart artefakt: bliver .dacpac den eneste pakke, der flyder gennem din pipeline til alle miljøer.

Vælg mellem originale og SDK-lignende projekter

SQL-databaseprojekter findes i to formater. Det oprindelige format er bygget på MSBuild (.NET Framework) og leveres med SQL Server Data Tools (SSDT) i Visual Studio. SDK-formatet er bygget på projekt-SDK'en Microsoft.Build.Sql og er formatet, der bruges af SQL Database Projects-udvidelsen til Visual Studio Code.

For nye projekter, vælg SDK-stil. Den bringer funktioner, som det oprindelige format ikke har:

  • .NET 8+ understøttelse, så du kan bygge cross-platform på Windows, Linux og macOS. Denne support er vigtig, når dine CI-runnere ikke er Windows-maskiner.
  • NuGet-pakkereferencer for databasereferencer, så afhængighedsstyring følger de samme mønstre som resten af .NET-økosystemet.
  • Standard globbing for .sql filer. Læg en fil i projektmappen, og den bliver automatisk inkluderet i buildet. Ingen manuelle filindtastninger nødvendige.

Hvis du har et eksisterende originalt projekt, kan du konvertere det til SDK-stil ved at ændre filen .sqlproj . Før du konverterer projektet, skal du tage backup af projektfilen og arkivere en .dacpac fra det nuværende projekt. Sammenlign et "før" og "efter" .dacpac for at bekræfte, at konverteringen bevarede alt.

Bemærkning

SDK-lignende SQL-projekter er generelt tilgængelige i Visual Studio Code og i forhåndsvisning i Visual Studio 2022. Visual Studio 2026 understøtter kun det oprindelige SQL-projektformat.

Opret og udfyld et projekt

Du kan oprette et SQL-databaseprojekt fra Visual Studio Code, Visual Studio eller kommandolinjen. Kommandolinjen er især praktisk til CI/CD-scenarier, hvor der ikke er noget grafisk miljø tilgængeligt.

For at skabe et nyt SDK-lignende projekt:

dotnet new sqlproj -n MyDatabaseProject

📝 Dette genererer en .sqlproj fil med SDK-format. Herfra tilføjer du databaseobjekter ved at lægge .sql filer i projektmappen. Standardmønsteret for globbing opfanger dem automatisk.

For eksempel, for at definere en tabel, opret Tables/Customers.sql:

CREATE TABLE [dbo].[Customers]
(
    [CustomerID] INT NOT NULL PRIMARY KEY,
    [FirstName] NVARCHAR(50) NOT NULL,
    [LastName] NVARCHAR(50) NOT NULL,
    [Email] NVARCHAR(100) NULL
);

Startende med en eksisterende database? Skema-sammenligningsværktøjer lader dig sammenligne en live database med et tomt projekt og importere forskellene, så du ikke behøver at genskabe hvert objekt manuelt.

Byg og valider projektet

Bygningen er stedet, hvor sikkerhedsnettet træder i kraft. Byggeprocessen validerer hver objektreference og tjekker T-SQL-syntaksen mod målplatformen. Hvis en visning refererer til en kolonne, der ikke eksisterer, fejler buildet. Hvis du bruger en vektorfunktion, der er tilføjet i SQL Server 2025, men dit projekt sigter mod SQL Server 2017 (Sql140), så fanger buildet det.

For at bygge videre fra kommandolinjen:

dotnet build MyDatabaseProject.sqlproj

📝 Buildet producerer som standard en .dacpac fil i mappen bin/Debug .

Build-output indeholder fejl (som blokerer buildet) og advarsler (såsom inkonsistent casing i objektnavne). Advarsler stopper ikke byggeriet, men de er værd at være opmærksom på. Du kan også aktivere SQL-kodeanalyseregler for at markere best practice-overtrædelser under buildet, hvilket fanger problemer som forældet join-syntaks, SELECT * i visninger eller uindekserede kolonner i IN prædikater.

Målplatformen sættes i .sqlproj filen og styrer, hvilke T-SQL-funktioner der består valideringen. Indstil det, så det matcher dit implementeringsmål, uanset om det er SQL Server 2025 eller Azure SQL Database.

Udrul projektet

Når du har en .dacpac, håndterer SqlPackage implementeringen. Installer det som et .NET globalt værktøj:

dotnet tool install --global microsoft.sqlpackage

Publicér derefter til en måldatabase:

sqlpackage /Action:Publish /SourceFile:bin/Debug/MyDatabaseProject.dacpac /TargetConnectionString:"Server=myserver.database.windows.net;Database=mydb;Authentication=Active Directory Default"

📝 SqlPackage er platformuafhængig og kører på Windows, Linux og macOS.

Hvad der sker under udsendelsen, afhænger af målet. For en ny database navigerer SqlPackage i objektafhængighedsgrafen og opretter hvert objekt i den korrekte rækkefølge, såsom referencetabeller før fremmednøgler. For en eksisterende database beregner den differentialet mellem og .dacpac det levende skema, og genererer derefter kun de ALTER udsagn, der er nødvendige for at lukke hullet. Mangler to kolonner? Du får én ALTER TABLE med begge tilføjelser. Processen er idempotent. Deploy det samme .dacpac fem gange, og det femte gennemspil ændrer ingenting. Du kan også sprede en enkelt .dacpac ud over en flåde af databaser, når du opgraderer flere lejere.

Før du implementerer direkte, kan du forhåndsvise de planlagte ændringer:

sqlpackage /Action:Script /SourceFile:bin/Debug/MyDatabaseProject.dacpac /TargetConnectionString:"..." /OutputPath:deploy-script.sql
sqlpackage /Action:DeployReport /SourceFile:bin/Debug/MyDatabaseProject.dacpac /TargetConnectionString:"..." /OutputPath:report.xml

Handlingen Script producerer præcis den T-SQL, der ville køre. Handlingen DeployReport producerer et XML-resumé af hver CREATE, ALTER, og DROP. Gennemgå en af dem, før du sender ændringer i produktion.

Vigtige takeaways

Et SQL-databaseprojekt gemmer hvert databaseobjekt som en deklarativ .sql fil, og buildet kompilerer dem til et enkelt .dacpac artefakt. SDK-lignende projekter (Microsoft.Build.Sql) understøtter .NET 8+, cross-platform builds, NuGet-pakkereferencer og standardglobbing for .sql filer. Byggeprocessen validerer objektreferencer og T-SQL-syntaks mod målplatformen, før noget når en database. SqlPackage beregner forskellen mellem databasen .dacpac og måldatabasen og genererer kun de sætninger, der er nødvendige for at lukke hullet. Brug og-handlingerne ScriptDeployReport til at forhåndsvise planlagte ændringer, før du deployerer til produktion. SQL-databaseprojektet, dets .dacpac artefakt og SqlPackage danner fundamentet for alt fremover, herunder versionskontrol, CI/CD-pipelines, skema-drift og test.