• Wprowadzenie
• Jakie opcje są dostępne, które mogą być używane do pracy deweloperskiej?
• Czego oczekują deweloperzy?
• Jak różne są edycje
• Czy wybór wpływa na używane narzędzia?
• LocalDB
  • Korzyści z LocalDb dla deweloperów
  • Negatywy LocalDb dla deweloperów
• Jakie są inne edycje?
  • Express Edition
  • Developer Edition
  • Web, Standard, i Enterprise Editions
  • Azure SQL Database
• Kontenerowa wersja dowolnej edycji
• Podsumowanie

Wprowadzenie

Jako programista potrzebuję bazy danych SQL Server, na podstawie której mogę tworzyć i testować kod. Istnieje kilka opcji do wyboru i różne problemy, o których trzeba pamiętać. W tym artykule przyjrzymy się możliwościom wyboru i decyzjom, które należy podjąć. Edycja LocalDb serwera SQL została stworzona, aby być oczywistą edycją dla deweloperów; Czy ten pomysł ma sens praktyczny i jakie alternatywne zalety mają inne edycje dla deweloperów?

Praca deweloperska zwykle wymaga wielu instancji serwera. Czy powinny one być współdzielone na jednym serwerze, czy rozproszone na wielu serwerach lub maszynach wirtualnych? Czy wszystkie serwery deweloperskie powinny mieć tę samą edycję? Czy mądrze jest polegać na połączeniu internetowym i stawiać wszystkie serwery rozwojowe w chmurze, czy też jest miejsce na tradycyjny “SQL Server na laptopie”.

Przed SQL Server 2005 nie było trudno wybrać edycję, której użyjesz do rozwoju. Poza samym produktem, istniała tylko darmowa edycja deweloperska. Następnie stało się to bardziej skomplikowane i nadal to robi, z kilkoma interesującymi permutacjami nadchodzącymi dla deweloperów wraz z wprowadzeniem kontenerów do Windows 2016 i SQL Server 2016.

Jakie są opcje, które można wykorzystać do pracy deweloperskiej?

Obecnie jest:

• Express Edition
• Developer Edition
• Web Edition
• Standard Edition
• Enterprise Edition
• LocalDb
• Azure baza danych + Amazon RDS
• Kontenerowa wersja dowolnej edycji

Istnieje również edycja zwana Compact Edition, która została wycofana, ale nadal jest dostępna. Ma pewne podobieństwa do SQL Server, ale ma bardzo małą powierzchnię i działa w procesie. Compact Edition działa w dialekcie SQL, ale nie jest to edycja SQL Servera. To naprawdę nie jest odpowiednia instancja programistyczna do opracowywania i testowania kodu, który zostanie wdrożony do SQL Server.

Czego chcą programiści?

1. Produktywność
   Jestem najbardziej produktywny jako twórca baz danych, gdy mam własną instancję na własnej maszynie, którą mogę dowolnie zatrzymywać, uruchamiać, upuszczać i tworzyć. Kiedy baza danych lub instancja znajduje się na współdzielonym serwerze, uważam, że rozwój jest wolniejszy – albo inni ludzie zmieniają rzeczy, nad którymi pracuję, albo robią inne rzeczy, aby przerwać to, co powinno być szybkim cyklem rozwoju, wdrażania i testowania.
2. Prostota
   Programista powinien mieć swobodę spędzania czasu na pisaniu, testowaniu i debugowaniu kodu, a każdy czas spędzony na zarządzaniu zasobami, takimi jak bazy danych SQL Server, oznacza, że ma mniej czasu na robienie rzeczy, które są rzeczywiście przydatne i zapewniają wartość dla firmy.
3. Dokładność
   W idealnym świecie każdy programista miałby szybką, lokalną, dokładną replikę produkcji z danymi, które są jak najbardziej zbliżone do danych produkcyjnych. Dzięki temu mogliby przetestować, że ich zmiany będą zachowywać się tak samo na produkcji, jak w środowisku deweloperskim. Muszą istnieć niezliczone aplikacje, które działają superszybko na maszynie deweloperskiej, ale wolniej, gdy są wdrożone w architekturze 3-tier z dużą ilością opóźnień i połączeń sieciowych pomiędzy usługami. Ważne jest również, aby sprawdzić, czy kod napisany dla jednej bazy danych będzie rzeczywiście działał na innej bazie danych. Jeśli masz SQL Server 2008 R2 w produkcji, nie byłoby sensu rozwijać się z SQL 2016 używając tabel in-memory.

Jak różne są edycje?

Podczas tworzenia i testowania aplikacji bazodanowej, często ważne jest, aby wiedzieć, że kiedy piszemy kod i możemy zobaczyć, jak działa w rozwoju, uzyskamy podobne zachowanie w produkcji. Edycje są zdefiniowane przez funkcje, które są zainstalowane i włączone; kod w rdzeniu silnika jest taki sam, niezależnie od tego, czy używasz jednej z darmowych edycji, czy edycji enterprise. Problem pojawia się, gdy używasz, powiedzmy, funkcji tylko dla przedsiębiorstw w rozwoju, ale masz tylko instancję edycji Standard w produkcji. Pełne porównanie tych edycji jest opublikowane przez Microsoft tutaj “Features Supported by the Editions of SQL Server 2016”

Czy wybór wpływa na narzędzia, które są używane?

Wszystkie instancje zachowują się tak samo pod względem głównego silnika i języka; jeśli więc masz narzędzie, które może zarządzać edycją Enterprise, to w zasadzie może również zarządzać każdą inną edycją. Nie wszystkie narzędzia w przeszłości trzymały się tej zasady: istniała kiedyś wersja SQL Management Studio dla SQL Express, która była ograniczona do braku możliwości zarządzania funkcjami pełnej edycji. Teraz SQL Server Management Studio jest wstecznie kompatybilne z poprzednimi wersjami i bocznie kompatybilne ze wszystkimi edycjami. Jest on obecnie dostępny jako darmowy plik do pobrania, dzięki czemu można zarządzać dowolną instancją bez konieczności posiadania pełnej licencji.

Drugim ograniczeniem jest to, że aby korzystać z LocalDb, należy zmienić bibliotekę klienta SQL, a więc starsze wersje SQLOLEDB i .Net nie są w stanie się połączyć – jeśli masz aplikację, która została napisana w .net, która jest wcześniejsza niż wersja 4, to może się nie połączyć.

Jaki wybór edycji mamy do rozwoju?

LocalDb

Bez specyficznych wymagań, których LocalDb nie może spełnić, to musi być pierwszy wybór dla programistów. Przyjrzyjmy się, czym jest, a następnie jakie korzyści oferuje.

LocalDb jest okrojoną wersją SQL Server, która została specjalnie zaprojektowana tak, aby była lekka i łatwa do szybkiego uruchomienia i zatrzymania. Oznacza to kompromis, więc istnieją pewne ograniczenia dla niego, ale naprawdę jest to świetny wybór dla większości programistów, ponieważ można szybko tworzyć, używać i niszczyć instancje, które są specyficzne dla jednego konkretnego użytkownika.

LocalDb ma kilka dodatkowych korzyści: Współdzieli te same binaria dla każdej instancji, więc nie musisz zużywać dużo miejsca na dysku dla każdej instancji, której potrzebujesz. Oznacza to, że naprawdę łatwo jest uruchomić jedną z nich, jeśli okaże się, że potrzebujesz nowej instancji w ferworze sesji programistycznej.

Tworzenie nowej LocalDb jest proste: Wystarczy w powłoce poleceń wpisać poniższe:

Tworzy to nową instancję, której możesz użyć o nazwie “nazwa instancji”, na moim komputerze utworzenie nowej instancji zajmuje około 4 sekund, a następnie około 2 sekund na jej uruchomienie. Instalacja nowej instancji dowolnego z pozostałych typów SQL Servera jest mierzona w minutach do godzin.

Jeśli masz zainstalowanych wiele wersji LocalDb, możesz utworzyć dowolną z nich naprawdę łatwo, po prostu wykonując ten kod w powłoce poleceń:

Otrzymasz listę taką jak:

Wtedy gdybyś potrzebował instancji 2012 wpisałbyś:

W ten sposób otrzymasz nową instancję SQL Server 2012, do której możesz się podłączyć.

Podłączenie do LocalDb jest nieco inne niż podłączenie do standardowej instancji: Zamiast łączyć się z nazwą maszyny i podawać port lub nazwę instancji, podajesz słowo “(localdb)”, a następnie nazwę instancji, więc jeśli instancja nazywa się “test-instancja”, przekazałbyś to jako nazwę serwera:

Aby dowiedzieć się, jakie masz instancje, możesz użyć:

To wyświetli listę instancji LocalDb, aby zbadać jedną dalej podaj nazwę instancji do ostatniego polecenia np:

Wynikiem będzie. będzie

• nazwa
• wersja
• do jakiego użytkownika należy
• czy została uruchomiona czy nie
• ostatni czas uruchomienia

Jeśli jest uruchomiona, podaje również ścieżkę do nazwanego potoku, na którym jest uruchomiony. Jeśli masz klienta, który nie rozumie nazwy serwera (localdb), to być może możesz połączyć się przez nazwane rury do instancji.

LocalDb jest świetny do rozwoju przeciwko, ponieważ jest tak szybki do tworzenia i uruchamiania instancji, jeśli często pracujesz nad różnymi projektami, możesz zatrzymywać i uruchamiać instancje i mieć wiele różnych instancji dostępnych bez kosztów ogólnych konieczności ich utrzymania i przechowywania na dysku. Oczywiście mają one te same minusy co Express, ponieważ są okrojonymi wersjami SQL Server. Nie ma na przykład indeksowania pełnotekstowego, co może uniemożliwić ich użycie w niektórych aplikacjach.

Korzyści z LocalDb dla rozwoju:

• Szybki rozwój, łatwo jest tworzyć nowe instancje dla rozwoju i testowania.
• Współdzieli binaria pomiędzy wszystkimi instancjami tej samej wersji, więc nie zajmujesz dużo miejsca na dysku lub nie musisz utrzymywać wielu różnych wersji

Negatywy LocalDb dla rozwoju:

• Nie zawiera niektórych podstawowych funkcji, takich jak SQL Agent
• nie obsługuje FILESTREAM
• nie może być subskrybentem replikacji merge,
• zezwala tylko na lokalne kolejki dla Service Broker.
• always runs under the users security context;

What other editions are there?

Express Edition

Edycja Express to bezpłatna wersja SQL Server, która jest przeznaczona dla małych baz danych z niewielką liczbą użytkowników. W wersji 2016 Express jest ograniczona do czterech rdzeni, 1GB pamięci ram na instancję i maksymalnego rozmiaru bazy danych 10 GB. Chociaż jest to rozsądny rozmiar, nie jest on wystarczająco duży dla większości produkcyjnych aplikacji bazodanowych, ale jest przydatny do prac rozwojowych, jeśli instancja rozwojowa nie wymaga wielu zasobów i jest mała oraz jeśli nie rozwijasz żadnej funkcjonalności, która zależy od funkcji Standard lub Enterprise-only.Zalety Express dla prac rozwojowych:

• Problemy z wydajnością będą bardziej widoczne w pracach rozwojowych
• Nie ma komplikacji licencyjnych dla prac rozwojowych
• Nadaje się zarówno do rozwoju indywidualnego, jak i współdzielonego.
• Usługi sieciowe mogą być skonfigurowane tak samo jak w przypadku pełnych edycji, więc można łączyć się za pomocą tcp ze zdalnych maszyn i mogą być używane przez usługę SQL Browser do zezwalania na połączenia przy użyciu nazwy instancji
• Można go swobodnie pobierać i instalować

Negatywy Express dla rozwoju:

• Nie zawiera pełnego zestawu funkcji jednej z wersji produkcyjnych
• Wymaga pełnej standardowej instalacji, aby utworzyć nową instancję, wymaga to czasu na instalację i aktualizację oraz dość dużo miejsca na dysku na instancję
• Nie powinna być używana do testowania obciążenia lub wydajności

Developer Edition

Developer edition to w pełni funkcjonalna edycja Enterprise programu SQL Server, która ma usunięte wszystkie ograniczenia. Jest to świetne rozwiązanie, jeśli tworzysz aplikację, która korzysta z edycji Enterprise, ale jeśli tworzysz aplikację, która korzysta z edycji Standard, może się okazać, że uzyskasz lepszą wydajność niż w produkcji lub skończysz używać funkcji, która jest tylko w wersji Enterprise. To może być kosztowny błąd, aby rozwijać kod, tylko dowiedzieć się, że nie może być uruchomiony, kiedy go wdrożyć.

Jeśli pracujesz na jednej aplikacji bazy danych i będzie wdrożenie do istniejącego serwera, który jest przy użyciu edycji Enterprise, a następnie nie można przejść daleko źle, jeśli używasz edycji deweloperskiej SQL Server.

Licensing dla SQL Server 2000 oznaczało, że edycja deweloperska była bezpłatna, tak długo, jak użycie było do rozwoju i testowania, a nie jako produkcyjnej bazy danych. Jeśli zdecydowałbyś się na użycie edycji deweloperskiej do produkcji, wtedy byłaby ona wyceniona jak edycja enterprise. Kiedy wydano SQL 2005, zmiana w licencjonowaniu oznaczała, że istniała niewielka opłata w wysokości 50 dolarów za możliwość korzystania z edycji deweloperskiej. Oznaczało to, że wiele osób nie było w stanie korzystać z wersji deweloperskiej, szczególnie w zespołach, w których deweloperzy rzadko korzystali z SQL lub nie posiadali subskrypcji MSDN, która dostarczała deweloperom licencji na edycję deweloperską. Było to szczególnie widoczne w zespołach innych niż .net, którym zdarzyło się używać SQL Server.

Zgodnie z przewodnikiem licencjonowania SQL Server 2016, “SQL Server Developer Edition nie może być używany w środowisku produkcyjnym lub z danymi produktu” – zakładając, że “dane produktu” oznaczają “dane produkcyjne”, wydaje się, że nie jest możliwe tworzenie kopii zapasowych i przywracanie produkcyjnej bazy danych do testowania, chyba że licencjonujesz serwer jako serwer produkcyjny. Przewodnik mówi również, że edycja deweloperska może być używana za darmo, jeśli dołączysz do programu “Dev Essentials” – jeśli potrzebujesz innej edycji, takiej jak Enterprise lub Standard, aby rozwijać/testować, możesz uzyskać do nich dostęp za pomocą subskrypcji “Visual Studio”.

Zalety edycji Developer dla rozwoju:

• Edycja Developer jest pełnoprawną edycją Enterprise, więc jeśli testujesz i działa ona na Developer, to kod powinien zachowywać się tak samo jak produkcyjny serwer Enterprise.

Zalety edycji Developer dla rozwoju:

• Właściwa tylko do rozwoju bazy danych dla Enterprise Edition. Ponieważ niektóre z funkcji i zachowań edycji Developer brakuje w Web lub Standard Edition, Twój system produkcyjny będzie miał mniej funkcji niż środowisko deweloperskie, co nigdy nie jest dobrym pomysłem.
• Używa dość dużo miejsca na dysku na instancję
• Licencjonowanie nie jest jasne, więc wymaga sprawdzenia z przedstawicielem licencjonowania Microsoft

Web, Standard i Enterprise editions

Te wersje wymagają licencji, aby być używane w produkcji. Edycję Web można kupić tylko za pośrednictwem dostawców hostingu aplikacji. Często najbezpieczniej jest rozwijać się w oparciu o edycję SQL Server, którą będziesz wdrażać, z pewnością dla wszelkich testów wydajności lub skalowalności, jeśli nie dla codziennego rozwoju. Jak omówiono z edycji Development, licencjonowanie jest trochę niejasne i może potencjalnie trzeba zapłacić za licencję do korzystania z jednej z tych edycji w środowisku dev lub testowym.

The web edition nie jest ogólnie dostępna i zazwyczaj trzeba kupić licencje na to przez dostawcę hostingu, który dodaje trochę dodatkowej złożoności.

Korzyści z edycji produkcyjnych dla rozwoju:

• Będziesz rozwijać i testować w środowisku, które jest podobne do produkcyjnego, co jest prawie zawsze dobrą rzeczą dla programistów.

Negatywy edycji produkcyjnych dla rozwoju:

• Wymaga pełnej standardowej instalacji, aby utworzyć nową instancję: To wymaga czasu na instalację i aktualizację, a także dość dużo miejsca na dysku na instancję
• Licencjonowanie nie jest jasne i wymaga sprawdzenia z przedstawicielem licencjonowania Microsoft

Azure SQL Database

Używanie dostawców chmury do hostowania baz danych dla Ciebie może mieć prawdziwy sens podczas rozwijania i testowania, ale mają one pewne minusy. Oprócz ceny, którą trzeba zapłacić za korzystanie z nich, trzeba również zrozumieć, że opóźnienie między maszyną a bazą danych będzie zazwyczaj znacznie wyższe niż w przypadku instancji lokalnej lub nawet lokalnej sieci LAN. Będziesz również potrzebował stałego połączenia z bazą danych, więc te wieczorne dojazdy kończące kawałek pracy w pociągu są mało prawdopodobne.

Używanie ich do czystej pracy deweloperskiej, gdzie ciągle wdrażasz zmiany i uruchamiasz skrypty, prawdopodobnie nie jest idealne, ale mogą naprawdę wejść w swoje własne testy, zwłaszcza jako część zautomatyzowanych zestawów testowych, które działają w hostowanych dostawcach, takich jak Appveyor lub VSTS.

Możliwość tworzenia nowej instancji, wdrażania kodu i uruchamiania testów jest świetna w procesie ciągłej integracji (ci), dzięki czemu można uruchamiać wiele buildów jednocześnie bez konieczności utrzymywania konkretnej instancji lub bazy danych dla każdego builda – po przejściu na pojedynczy build jako część procesu ci to proste podejście do wdrażania baz danych naprawdę pomaga.

Korzyści z Azure SQL Database dla rozwoju:

• Prostota w tworzeniu nowych baz danych, zwłaszcza że można to zautomatyzować
• Brak konserwacji instancji rozwojowych, więc brak łatania, brak kopii zapasowych itp.

Negatywy Azure SQL Database dla rozwoju:

• Bardziej nadaje się do testowania niż rozwoju, ponieważ wymagane jest stałe połączenie i będzie wolniejsze niż rozwijanie lokalnie
• Musisz płacić za minutę korzystania z bazy danych

Kontenerowa wersja dowolnej edycji

Windows 2016 i SQL Server 2016 mają wsparcie dla uruchamiania SQL Server w kontenerze. Th-s daje nam całą elastyczność, którą uzyskujemy z LocalDb i Azure+AWS do szybkiego uruchamiania i zatrzymywania instancji. Powinniśmy również dostrzec korzyści płynące z braku konieczności łatania każdej instancji indywidualnie, o ile używamy wspólnych obrazów dla naszych instancji.

Windows 2016 został już wydany, więc możemy teraz potencjalnie tworzyć i wyrzucać instancje SQL Server (na pewno SQL Server 2016) całkiem prosto, jeśli mamy Windows 10 lub Windows 2016. Jeśli jesteśmy przywiązani do wcześniejszej wersji systemu Windows lub wersji SQL Server, wówczas stworzenie obrazu, który działa, może nie być tak proste.

Gdy uzyskamy powszechne przyjęcie kontenerów w systemie Windows, powinno to oznaczać, że możemy tworzyć nowe instancje oraz uruchamiać i zatrzymywać instancje bez długiego procesu instalacji. Na tym etapie wydaje się, że uruchamianie i zatrzymywanie instancji będzie wolniejsze niż w przypadku LocalDb.

Jeśli testujesz swoje bazy danych w środowisku przypominającym chmurę, takim jak usługa Microsoft VSTS, możesz również stwierdzić, że uruchomienie instancji LocalDb jest wykonalne, ponieważ jest ona już zainstalowana. W przeciwieństwie do tego, pobieranie obrazu bazy danych SQL Server 2016, a następnie uruchamianie go może zająć zbyt wiele minut budowania.

Podsumowanie

Podczas tworzenia kodu dla baz danych SQL Server my, jako programiści, mamy trzy główne wymagania:

• we to be productive as quick as possible;
• we want our environment to be as simple as possible;
• we don’t particularly want to rely on good internet connectivity;
• chcemy używać wersji testowej, która symuluje prawdziwy świat z punktu widzenia funkcjonalności (niekoniecznie wydajności dla codziennego rozwoju)

LocalDb jest zazwyczaj odpowiedzią dla większości programistów SQL Server i, chyba że masz specyficzne wymagania, które oznaczają, że nie możesz go użyć, bardzo bym go polecił.