it-swarm-eu.dev

Proč bych měl používat Visual Studio 2010 přes SSMS pro vývoj mé databáze?

Visual Studio 2010 představuje databázové projekty a celou řadu souvisejících funkcí, které údajně usnadňují vývoj databáze. Vývoj serveru SQL Server Management Studio (SSMS) jsem používal mnoho let k vývoji své databáze bez problémů.

  • Proč bych se měl obtěžovat VS2010, když pro mě SSMS pracuje? Co konkrétně dělá lépe než SSMS?
  • Ale možná je můj předpoklad nesprávný a SSMS stále převyšuje VS pro vývoj databáze. Pokud ano, jakým konkrétním způsobem je to pravda?
42
Nick Chammas

Vlastně jsem byl s VS2010 trochu ohromen, abych byl upřímný. Myslím, že starý školní skript vytváří tabulku a soubory pro uložené procedury se snáze zpracovávají. Pokud potřebujete správu schémat, můžete získat Redgate SQL Compare Pro za několik set dolarů.

Pokud opravdu potřebujete nástroj pro modelování databází, pak Powerdesigner nebo Erwin odvede mnohem lepší práci, i když nejsou nijak zvlášť levné.

Přestože dávám přednost SSMS, použil jsem oba. Některé výhody a nevýhody:

  • SSMS má uživatelské rozhraní, které „dobře funguje“ pro vývoj SQL. Pouhé vytváření a používání skriptů pro vytváření je mnohem pohodlnější než obruče VS2010, které vás nutí přeskočit. Mnohem flexibilnější (+ SSMS).

  • VS2010 má základní správu schématu (tj. Generování rozdílu/patch skriptu) (+ VS2010). Není to však všechno tak dobré a má nějaké nedostatky. Například odpovídá omezením na jméno. Pokud máte zaškrtnutí nebo výchozí omezení ve sloupci bez jejich pojmenování, vygeneruje SQL Server za scénami náhodný název. To bude matit VS2010, pokud nainstalujete skript na jiný počítač, protože omezení mohou mít různá jména. Redgate je levnější a lepší. (+ VS2010, ale vadný).

  • VS2010 je opravdu nemotorný - pro každou tabulku nebo jiný objekt DB musíte mít jeden soubor. V podstatě musíte dělat věci způsobem VS2010, což je docela těžkopádné. (- VS2010)

  • VS2010 je také poněkud křehký a integrace řízení zdroje je šupinatá. I na jednoduché databázi je každá tabulka, omezení, uložená procedura, index a další databázový objekt vlastním souborem. Soubory jsou přidávány do projektu po celou dobu, mnohem rychlejší než typický programovací projekt s (řekněme) C #. S optimistickou souběžností má tendenci tiše upouštět soubory z projektu, když se odhlášení synchronizuje. I při dobré týmové disciplíně je zpětná vazba od uživatelského rozhraní o stavu velmi špatná. To by byla katastrofa na komplexním modelu. (-VS2010 - Málem bych se domníval, že je to chyba pro zastavení show pro velký projekt).

  • SSMS je dodáván se serverem SQL - nelze porazit cenu (+ SSMS).

  • VS2010 stále nemá správné úložiště, jako je například (řekněme) PowerDesigner nebo Oracle Designer. Datový model nelze snadno dotazovat, aniž byste jej nainstalovali do databáze. (- VS2010).

Celkově bych hodnotil VS2010 asi B-. Bylo to nemotorné na relativně jednoduchém databázovém projektu se dvěma tabulkami faktů a přibližně 15 dimenzemi.

Největší datový model, jaký jsem kdy udělal, byl pro systém řízení soudních případů, který měl kolem 560 tabulek. Nedoporučoval bych VS2010 pro projekt takové velikosti (udělal jsem to na Oracle Designer). V zásadě se snaží být chytrý a paradigma opravdu nefunguje tak dobře. Lepší je vám s nejmodernějším nástrojem pro modelování, jako je PowerDesigner, nebo jen ručně vytváříte skripty tabulky.

SSMS je jednoduchý a spolehlivý, ale ruční. Máte téměř nekonečnou kontrolu nad tím, jak chcete model spravovat. Zkombinujte jej se správcem schémat, jako je například Redgate SQL Compare, a možná se slušným nástrojem pro modelování, jako je PowerDesigner, a máte mnohem lepší balíček než VS2010.

Shrnutí Nejsem si jistý, zda bych mohl citovat jakékoli vrahové funkce nebo výhody kromě (možná) integrace s VS řešeními obsahujícími jiné projekty. Pokud již máte prémii VS2010 nebo konečnou verzi, dostanete nástrojem pro vývoj databází, který je vadný, váš nástrojový řetězec .Net. Bude integrovat DB projekty do vašeho VS řešení, takže můžete použít k vytvoření sproc implementačních skriptů.

VS však nemá žádný nástroj pro modelování, o kterém by se mluvilo, takže PowerDesigner nebo dokonce Erwin je v tomto ohledu lepší. Správa schémat Redgate je mnohem lepší a SQL Compare Pro je poměrně levná (asi 400 GBP IIRC). IMHO SSMS funguje mnohem lépe pro vývoj T-SQL, ale určitě to můžete udělat s VS2010.

Prémie VS2010 není o nic levnější než nejlepší nástroj pro modelování databází a konečný VS2010 je přinejmenším stejně drahý. Na úkor těsné integrace s vaším VS projektem byste pravděpodobně mohli dělat lépe s nástroji třetích stran.

Alternativa

Myslím, že člověk by neměl příliš struskovat VS2010, aniž by navrhl alespoň jednu alternativu a nastínil její výhody a nevýhody. Pro účely tohoto předpokládám velký projekt. Přestože v těchto dnech pracuji hlavně A/P, byl jsem zapojen do projektu s více než 100 zaměstnanci, kde jsem provedl datový model (a některé vývojové práce) a několik dalších v rozsahu 10 zaměstnanců, kde jsem pracoval hlavně jako analytik nebo vývojář. Většinou v těchto dnech pracuji na systémech datového skladu, ale větší projekty byly hlavně aplikace. Na základě mých zkušeností s různými nástroji uvádíme několik návrhů alternativního řetězce nástrojů:

  • VS2010 profesionální nebo vyšší. Možná budete chtít nebo nemusíte používat funkce řízení projektů prémiové nebo konečné.
  • Subversion, AnkhSVN a TortoiseSVN - lepší než TFS každý den a pěkně si hraje s VS. Je také docela dobře možné obdělávat místní úložiště pro souběžné vývojové pracovní stanice.
  • SSMS pro vývoj T-SQL - Řízení projektu a SC integrace není tak dobrá, ale dobře funguje pro vývoj DB).
  • Projekt VS2010 DB pro sledování sproc souborů - mírně nemotorný, pokud používáte SSMS, ale funguje dobře. Bude také generovat implementační skripty.
  • PowerDesigner - Lepší způsob modelování databáze a správy položek schématu DB. To také dělá UML, pokud se chcete silně zapojit do MDA. Pokud chcete řídit návrh DB z objektového modelu, můžete místo toho zvážit Sparx EA. To dělá nejlepší práci Meta CASE (rozšiřitelný meta model) jakéhokoli nástroje CASE, který jsem viděl, ačkoli jeho modelování databáze ponechává něco, co je žádoucí.
  • SQL Compare pro - Použijte pro generování opravných skriptů DB nebo k testování manuálních opravných skriptů (viz 1 níže).
  • Framemaker - Mnohem stabilnější a lepší groupwarové funkce než Word, pokud máte na analytice více analytiků. Podporuje také podmíněné zahrnutí, takže můžete mít verze verzí s verzí se změnami WIP skryté. MIF a MML usnadňují integraci dokumentů a datových slovníků API do specifikačních dokumentů. Je to docela užitečné udělat, protože je můžete křížově odkazovat ve specifikaci. Kotvy textových štítků zajišťují stabilitu křížových odkazů při opakovaném importu. TCS můžete také použít k jedinému zdrojovému dokumentu do výstupu PDF, HTML a CHM.
  • Open-source problem tracker - Mnoho dobrých open-source (např. TRAC, Bugzilla abychom jmenovali pár, které jsem použil). Open-source je jednodušší modifikovat nebo integrovat do vlastního workflow a nemůžete porazit cenu.
  • NUnit nebo jiné testovací nástroje - jakékoli automatizované testovací nástroje jsou pro vaše požadavky nejvhodnější.
  • Cokoliv kromě projektu MS - Považováno za škodlivé. Projekt MS je velmi pohledný a nutí projektovat plány do modelu, který účinně nepředstavuje nejistotu, riziko nebo závislost na zúčastněných stranách nebo jiných třetích stranách (viz 2 níže).

Pros: Lepší modelování databází a správa schémat než VS2010, lepší systém řízení verzí, snadnější přizpůsobení pracovního postupu sestavování a projektu, lepší správa specifikací a dokumentace.

Nevýhody: Více úsilí o integraci nástrojů, omezená integrace DB do procesu sestavování.

Předpoklady: Předpokládá, že řízení procesu změny/uvolnění je důležitější než automatizovaná nebo těsně integrovaná správa verzí pro schémata DB. Předpokládá také, že automatizovaná správa schématu DB není 100% spolehlivá.

Není strašně vyspělá technologie nebo úhledně integrovaná, ale u složitého projektu máte pravděpodobně větší zájem o kontrolu než roztomilé automatizované funkce. Tvrdil bych, že jste lepší se sadou nejlepších nástrojů plemene a bez ohledu na to, jak je domácí pivo připravuje a testuje skriptování, je nutné je integrovat. Jen se pokuste udržet sestavení (a) relativně snadno pochopitelné a (b) plně automatizované.

  1. QA na záplatách DB. Na velkém schématu budete možná chtít mít ruční opravný proces pro živé systémy, zejména pokud opravy zahrnují migraci dat. Například může být žádoucí mít skripty pro převrácení a převrácení, které v případě potřeby podporují vyrovnání změn. V tomto případě budete chtít mít zařízení, které otestuje, že oprava skutečně funguje správně. Pokud spravujete schéma databáze v úložišti, můžete otestovat skripty nastavením před databázemi a vygenerováním referenční databáze z úložiště. Spuštění opravného skriptu v databázi před by jej mělo synchronizovat s repositiry modelem. K testování lze použít nástroj pro porovnání schématu.

  2. V poslední době jsem provedl mnohem více datového skladu a integrační práce než vývoj aplikací na zakázku, takže se s tím setkávám častěji než ve většině případů vývojový tým. Nástroje a metodiky řízení projektů však při řízení externích zúčastněných stran vykonávají velmi špatnou práci. V integračním projektu, jako je datový sklad, opravdu chci vidět nástroj pro správu projektů, který skutečně tlačí externí závislosti (tj. Ty, které nekontroluji), tváří v tvář řízení programu. Na jakémkoli netriviálním integračním projektu jsou vnější závislosti zdaleka největšími hybateli promarněného času.

Od doby, kdy byla původně zveřejněna, jsem si pohrával s tím, jak na tuto otázku odpovědět. To je obtížné, protože případ VS2010 není o popisu vlastností a výhod nástroje. Jde o přesvědčování čtenáře, aby zásadně posunul svůj přístup k vývoji databáze. Není snadné.

Na tuto otázku existují odpovědi profesionálních databázových profesionálů, kteří mají kombinaci pozadí zahrnující DBA, vývojáře/dba a OLTP a datové sklady). Není pro mě životaschopné přistupovat k tomuto aspektu pro každou stránku databáze. vývoj v jednom sezení, takže se pokusím udělat důvod pro konkrétní scénář.

Pokud váš projekt splňuje tato kritéria, domnívám se, že pro VS2010 existuje přesvědčivý případ:

  • Váš tým používá VS2010 pro vývoj aplikací.
  • Váš tým používá TFS pro řízení zdrojů a správu sestavení.
  • Vaše databáze je SQL Server.
  • Váš tým již má nebo má zájem o automatizované testování VS.

Pokud hodnotíte vývoj databáze VS2010, vaše bible bude Visual Studio Database Guide z Visual Studio ALM Rangers . Všechny následující citace, které neobsahují odkazy, budou z tohoto dokumentu.

Pak jdeme ...

Proč se proces vývoje databáze liší od vývoje aplikací?

Data. Kdyby tomu tak nebylo, byla by databáze utlumená. Mohli jsme prostě DROP všechno v každém vydání a zapomenout na tuto problematickou správu změn.

Existence dat komplikuje proces změny databáze, protože data jsou často migrována, transformována nebo znovu načtena, když jsou změny zavedeny snahou o vývoj aplikací, které ovlivňují tvar databázových tabulek nebo jiných datových schémat. V průběhu tohoto procesu změn musí být data kvality výroby a provozní stav chráněny před změnami, které mohou ohrozit její integritu, hodnotu a užitečnost pro organizaci.

Co je špatného na SSMS?

Z nějakého důvodu se nazývá SQL Server Management Studio. Jako samostatný nástroj je nepraktické řídit vaše vývojové úsilí pokud se budete řídit přijímanými doporučenými postupy.

Pouze se skripty, abyste mohli smysluplně aplikovat zavedené postupy řízení zdrojů na svůj vývoj, musíte zachovat obě definice objektů (např. Skript CREATE TABLE) A změnit skripty (např. ALTER TABLE) A usilovně pracovat na tom, aby zůstaly synchronizované.

Řetězec verzí pro změny tabulky se docela rychle rozplývá. Velmi zjednodušující příklad:

-- Version 1
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20))

-- Version 2
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50))

-- Version 3
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))

Ve verzi 3 obsahuje skript pro změnu databáze:

ALTER TABLE dbo.Widget ADD Description VARCHAR(50)
ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)

Pokud je živá verze této databáze verze 1 a naše příští verze je verze 3, skript níže by byl vše, co bylo potřeba, ale místo toho budou provedeny oba příkazy ALTER.

ALTER TABLE dbo.Widget ADD Description VARCHAR(100)

5 let 4 týdny sprintu přidává některé zábavné verze skriptů a vyžaduje další manipulaci s lidmi, aby se minimalizoval dopad na dobu nasazení.

Takže je něco špatného na SSMS? Ne, je to dobré pro to, co je dobré pro správu, správu a správu serveru SQL. To, co ani předstírat, není, je pomoci vývojáři databáze s (někdy) velmi složitým úkolem řízení změn.


Pokud nemůžete sestavit každou verzi databáze ze zdroje a upgradovat na budoucí verzi, řízení zdroje je přerušeno. Pokud si to nemyslíte, zeptejte se Erica Sink .


A co SSMS + <- vložit nástroj pro porovnání schématu ->?

To je určitě krok správným směrem a odebírá se velká část manuálního úsilí potřebného k udržování skriptů. Ale (a je to velký, ale), obvykle se jedná o ruční kroky.

Populární nástroje pro porovnání schémat lze plně automatizovat a integrovat do procesu sestavování. Podle mých zkušeností je však běžnější praxí, že porovnání bude spuštěno ručně, výsledné skripty jsou zavěšeny, zkontrolovány pro kontrolu zdroje a poté provedeny ručně pro nasazení. Špatný.

Pokaždé, když jsme omylní lidé, se musíme zapojit do procesu sestavování nebo nasazování, představujeme riziko a tento proces učiníme neopakovatelným.

Pokud jste vy a váš tým mezi malými, kteří mají plně automatizované porovnání a nasazení schémat, klobouky se vám hodí! Vy jste s největší pravděpodobností otevřeni výhodám, které nabízí VS2010 jako:

  • Už jste přijali, že ruční kroky jsou nebezpečné.
  • Vidíte hodnotu automatizace.
  • Jste ochotni investovat čas nezbytný k tomu, aby to fungovalo.

Pokud nemůžete vytvořit sestavení v jednom kroku nebo jej nasadit v jednom kroku, proces vývoje a nasazení je přerušen. Pokud si to nemyslíte, zeptejte se Joela Spolského .


Proč VS2010?

Otázka @NickChammas představuje hledat vrahové funkce, které ukazují, proč VS2010 je hra měnič pro vývoj databáze. Nemyslím si, že na tomto základě dokážu případ.

Snad komicky, kde jiní vidí nedostatky v tomto nástroji, vidím silné důvody pro přijetí:

  • Budete muset změnit svůj přístup.
  • Vy a váš tým budete nuceni pracovat jiným způsobem.
  • Budete muset podrobně vyhodnotit dopad každé změny.
  • Budete vedeni k provedení každé změny idempotent .

Pokud jste jediným projektem DBA v projektu, který řídí všechny změny v databázi, musí tato úvaha znít absurdně hraničně. Pokud si však myslíte, že @ BrentOzar má smysl a jedním z nových pravidel je, že Každý je DBA , budete muset kontrolovat změnu databáze způsobem, se kterým může každý vývojář v týmu pracovat.

Přijetí databázových projektů může pro některé vývojáře vyžadovat mentální posun ( staré návyky ), nebo alespoň změnu procesů nebo pracovních postupů. Vývojáři, kteří vyvinuli databázové aplikace , kde produkční databáze představuje aktuální verzi databáze, budou muset přijmout přístup založený na zdrojovém kódu, kde se zdrojový kód stane prostředkem, ke kterému dochází k úpravám databází . V databázových projektech Visual Studio je projekt a zdrojový kód „Jedna verze pravdy“ pro schéma databáze a je spravován pomocí pracovních postupů SCM, které již vývojář nebo organizace pravděpodobně používá pro jiné části jejich aplikačního zásobníku. Pro data zůstává produkční databáze svou „jednou verzí pravdy“, jak má být.

Dospěli jsme k základnímu posunu, který je nezbytný pro úspěšné přijetí přístupu VS2010 k vývoji databáze ...

Zacházejte s databází jako s kódem

Žádné další změny živé databáze. Každá změna databáze bude sledovat stejný vzor jako změna aplikace. Upravit zdroj, sestavit, nasadit. Toto není dočasná změna směru od společnosti Microsoft, to je budoucnost pro SQL Server . Databáze jako kód je zde k pobytu.

Vývojář databáze definuje tvar objektu pro verzi aplikace, nikoli jak mutovat existující objekt v databázovém stroji na požadovaný tvar. Možná se ptáte sami sebe: Jak se to nasadí proti databázi, která již obsahuje tabulku zákazníků? Zde přichází do hry implementační engine. Jak bylo uvedeno výše, implementační stroj vezme kompilovanou verzi vašeho schématu a porovná ji s cílem nasazení databáze. Rozlišovací modul vytvoří potřebné skripty k aktualizaci cílového schématu tak, aby odpovídalo verzi, kterou nasazujete z projektu.

Ano, existují i ​​jiné nástroje, které se podobají vzoru, a pro projekty mimo omezení, která jsem kladl na svou odpověď, stojí za to se stejným způsobem zvážit. Ale pokud pracujete s Visual Studio a Team Foundation Server ALM, nemyslím si, že mohou soutěžit.

Co je špatného na projektech databáze VS2010?

  • Nejsou dokonalé . Ale pokud víte o omezeních a problémových oblastech, můžete je obejít.
  • Složité pohyby dat stále vyžadují péči a pozornost, ale jsou zajištěny pomocí skriptů před a po nasazení.

Edit: Takže o co jdeš?

@AndrewBickerton zmínil v komentáři, že jsem neodpověděl na původní otázku, takže se pokusím shrnout „Proč bych měl používat Visual Studio 2010 přes SSMS pro vývoj své databáze?“ tady.

  • SSMS není nástroj pro vývoj databáze. Ano, TSQL můžete rozvíjet pomocí SSMS, ale neposkytuje bohaté funkce IDE) VS2010.
  • VS2010 poskytuje rámec pro zpracování vaší databáze jako kódu.
  • VS2010 přináší statická analýza kód do vašeho databázového kódu.
  • VS2010 vám poskytuje nástroje pro plnou automatizaci cyklu sestavení a nasazení.
  • SQL2012 a Visual Studio vNext rozšiřují možnosti databázových projektů. Seznamte se nyní s VS2010 a máte náskok v nástrojích pro vývoj databází nové generace.
19
Mark Storey-Smith

VS může vypadat skvěle, pokud neznáte SSMS nebo jste použili nástroje třetích stran. Mezery ve VS vynikají, pokud používáte nástroje Red Gate pro srovnání schématu atd. A také bezplatné pluginy SSMS.

Řídicí bity zdroje jsou zavádějící: v produkční databázi je vaše referenční kopie. Ne to, co vývojář používá. Vidět

7
gbn

Používám Visual Studio značně (dobře, BIDS) pro návrh sestav SSRS a balíčky SSIS. Nemohl jsem dělat ani velmi dobře, pokud vůbec, v Management Studio. Visual Studio je mnohem úplnější a integrovanější vývojové prostředí a mnohem lépe se zapojuje do systémů řízení zdrojů. A to vše se odráží v ceně!

6
Peter Schofield

Upřímně řečeno, můj hlas jde přímo do SQL Server Management Studio pro návrh, vývoj a (samozřejmě) správu databáze. Je jednodušší napsat:

create table newTable
(
    someId int identity(1, 1) not null primary key clustered,
    ...... you get the idea
)

Poté klikněte na všechna správná místa. SSMS je skvělá dispozice a absolutní výbuch pro práci. A já jsem .NET softwarový vývojář od přírody. Ale pokud jde o návrh databáze a kódování, zvolím SSMS 11krát z 10.

6
Thomas Stringer

Neexistuje žádný osvědčený postup, ale s databázovým projektem VS 2010 a řadičem zdrojového kódu (VSS 2010, Subversion atd.) Můžete databázi aktualizovat.

Doporučuji nejprve navrhnout databázi přímo do SSMS. Poté, co je vaše databáze téměř připravena, importujte ji do projektu databáze VS 2010. Po dokončení importu musíte do projektu databáze vždy přidat nový skript, abyste mohli sledovat všechny změny. Pomocí funkce porovnání databázového projektu můžete získat všechny změny z vývojového serveru a importovat všechny tyto skripty přímo do projektu. Nyní stačí „potvrdit“ vaši změnu v ovladači zdrojového kódu.

S touto metodou můžete mít verzi verzí. Můžete si všimnout verze každé modifikace a vrátit zpět své změny.

To není jediná výhoda. U tohoto typu projektu můžete porovnat libovolné databáze s vaším projektem a skriptovat změny a pomocí příkazu SQL PowerShell Prompt můžete aktualizovat všechny své databáze se stejným skriptem: tento skript je schéma XML vaší databáze. Provede pouze potřebné příkazy k aktualizaci databází. Máte také možnost provést test jednotky v databázi. K dispozici je další dobrý článek pro projekt databáze zde . S funkcí rozmístění můžete mít pre-script a post-script. S těmito skripty můžete provést ověření ani vložit data do systémových tabulek.

Zde je dobrý postup krok za krokem pro projekt databáze.

5
Nico

Používám SSMS více než já VS2010, protože je to při instalaci SQL Serveru. To je pravděpodobně nejdůležitější věc, proč se SSMS používá více než VS2010, IMHO.

Také jsem zjistil, že prodejci jako Red-Gate vydávají nástroje, které se integrují do SSMS a ne nutně VS2010. To může být pozitivní v tom, že vám umožní zlepšit SSMS tam, kde společnost Microsoft ne. Jedním z příkladů je Red-Gate's SQL Source Control, což je doplněk k SSMS, který vám umožní připojit SSMS až k systému řízení vaší společnosti, ať už se jedná o Visual Team Foundation nebo co máte. VS2010 má toto vestavěné, ale ve srovnání s cenou nástroje Reg-Gate jsem právě ušetřil spoustu peněz, aniž bych musel kupovat VS2010.

Celkově si myslím, že jde o preference, pracujete s tím, v čem se cítíte dobře. Pokud trénujete novou osobu a trénujete je na VS2010, stane se to jejich preferencí, protože vědí, jak se s tím obejít.

Pokud jste začali hrát s SQL Server 2012, možná jste si všimli, že SSMS dostává make-up VS2010 pomalu, ale jistě. Takže nakonec možná nebudete schopni rozeznat rozdíl mezi nimi.

2
user507