Czy należy zaprojektować bazę danych przed napisaniem kodu aplikacji?

57

Jaki jest najłatwiejszy i najbardziej wydajny sposób zaprojektowania bazy danych? Z mojego punktu widzenia istnieje kilka opcji projektowania magazynu danych aplikacji:

  1. Zaprojektuj bazę danych najlepiej jak potrafisz na początku przed napisaniem kodu aplikacji . Daje to zaletę posiadania podstawowej struktury danych, z której można pracować. Moim zdaniem wadą tego jest to, że będziesz mieć wiele zmian jako specyficznych dla aplikacji, które wpływają na to, co / gdzie / jak zmieniają się dane w całym cyklu rozwoju aplikacji.
  2. Zaprojektuj bazę danych, gdy aplikacja zacznie działać . Gdy potrzebujesz kilku obiektów bazy danych podczas pisania aplikacji, rozwijasz bazę danych równolegle (chronologicznie) do aplikacji. Zaletami byłyby mniej zmian w strukturze bazy danych, jakie widzę. Wadą byłby podział czasu i prac rozwojowych między kod aplikacji i tworzenie baz danych.

Z własnego doświadczenia, co uważasz za najbardziej produktywną i wydajną metodę?

Thomas Stringer
źródło
Dziel i rządź z SDLC
Premraj 24.04.15
1
Flywaydb.org może Cię zainteresować. Umożliwia kontrolę wersji schematu bazy danych.
Thorbjørn Ravn Andersen

Odpowiedzi:

41

Oprócz innych odpowiedzi ...

Najpierw uchwycenie modelu koncepcyjnego powinno określać zakres i wymagania. Na tej podstawie możesz uzyskać logiczne i fizyczne modele danych.

Gdy jest to w większości statyczne, masz stabilną bazę danych, na której można zbudować aplikację. Jest to sprzeczne z pierwszą opcją.

Twój drugi punkt zakończy się nieporządną, niemożliwą do utrzymania kulą błota . Model danych nigdy nie zostanie naprawiony: jeśli nie zaprojektowałeś go z góry, nie będziesz miał czasu, aby go naprawić przed wysyłką. Będziesz zbyt zajęty hakowaniem rzeczy razem.

Nastąpią niewielkie zmiany w schemacie, łączenie lub dzielenie tabel, zmiana relacji itp., Ale na zlokalizowanych „wyspach”, a model + podstawowy projekt pozostaną niezmienione.

gbn
źródło
6
Stabilność jest ważna, ponieważ nazwy tabel i widoków, nazwy kolumn, nazwy procedur składowanych itp. Są publicznym interfejsem bazy danych. (I prędzej czy później będzie wiele aplikacji współużytkujących ten interfejs.)
Mike Sherrill „Cat Recall”
Powiedziałbym, że jest to dość wyidealizowane podejście, z mojego doświadczenia wynika, że ​​drastyczne zmiany zdarzają się od czasu do czasu, musimy być zwinni i szybko dostosowywać się do nowych wymagań i ciągle refaktoryzować.
zinking
@zinking: W tej chwili robię to zwinnie.
gbn
@ gbn, przepraszam, że mogę zadać poniższe pytanie tutaj. Nie mam pojęcia, jak sobie z tym poradzić. Prosimy spojrzeć. stackoverflow.com/questions/46285924/... . Uprzejmie zasugeruj mi lepsze rozwiązanie.
RGS
27

Trudno będzie znaleźć jakikolwiek nowoczesny dział oprogramowania, który nie obsługuje żadnej wersji Agile. Dla porównania, DBA utknęły w mrocznych czasach, myśląc, że odpowiedź @ RobPallera zawiera wciąż powszechne miejsce.

Modyfikowanie schematu bazy danych nigdy nie było tak proste jak modyfikowanie kodu, dlatego niechętnie przyjęto zwinne podejście do tworzenia i utrzymywania bazy danych. Teraz, gdy mamy narzędzia i techniki do działania w sposób podobny do programistów, zdecydowanie powinniśmy. To, że zmiana schematu nie jest łatwa, nie oznacza, że ​​nie możesz i że nie powinieneś.

Nie opowiadam się za przypadkowym podejściem do projektowania baz danych (patrz komentarze), a jedynie podejściem, które bardziej odzwierciedla podejście zwinnego zespołu programistów. Jeśli jesteś częścią zwinnego projektu, nie będziesz mieć wymagań dotyczących pracy, która może ( lub nie musi ) wystąpić w przyszłości, więc projektuj to, co wiesz, że jest potrzebne, a nie to, co może być.

Wydaje mi się, że to oddaje mój głos na twoją opcję 2 i podejrzewam, że mógłbym znaleźć się na tym zimnie!

Mark Storey-Smith
źródło
4
Agile i bazy danych idą w parze z zastrzeżeniami. Zwinność jest granicą dla VLDB: może brakować czasu na sprawdzenie poprawności i przetestowanie zmian w miliardowych tabelach wierszy między wynikami. A „zwinny rozwój” to nie to samo, co „hurtowe zmiany” z powodu braku uprzedzeń
gbn
2
Nie mogłem się zgodzić więcej: brak przemyślenia, ale nie sądzę, żeby miało to znaczenie dla pytania. Nie chodzi o to, czy należy podchodzić do projektowania przypadkowo, ale czy model danych powinien ewoluować wraz z aplikacją. Problemy z VLDB wymagają edycji, którą dodam.
Mark Storey-Smith
3
Przeczytałem pytanie jako „nową aplikację bez jeszcze DB”, a nie „istniejącą aplikację wymagającą zmian w DB”
gbn,
Podobnie, brakuje mi gdzieś twojego punktu :) Jeden do zabrania na czat?
Mark Storey-Smith
4
+1 za ogólny sentyment Twojej odpowiedzi, ale „Modyfikacja schematu bazy danych nigdy nie była tak łatwa jak modyfikacja kodu” naprawdę zależy od tego, ile masz kodu (i ile ma lat). IMO odwrotnie jest bardziej ogólnie prawdą
Jack Douglas
12

Twój logiczny model danych powinien skutecznie wychwytywać wymagania biznesowe aplikacji. Twój fizyczny projekt bazy danych powinien być oparty na logicznym modelu danych w połączeniu z niezbędnymi zmianami, które zdaniem DBA są potrzebne, aby zmaksymalizować wydajność RDBMS.

Jeśli okaże się, że musisz wprowadzić liczne zmiany w projekcie baz danych w całym cyklu życia aplikacji, oznacza to dwie rzeczy:

  1. Pełzanie zakresu - zezwalasz na wprowadzanie nowych wymagań w nieodpowiednim czasie.
  2. Niewystarczające wymagania biznesowe - Twoi projektanci danych (lub analitycy systemowi) nie przetłumaczyli w wystarczającym stopniu wymagań analityków biznesowych. Spowodowało to niekompletny lub niepoprawny model danych do obsługi wymagań aplikacji.

Biorąc to pod uwagę, po przejściu aplikacji na produkcję, nierzadko trzeba cofać się i wprowadzać iteracyjne zmiany w modelu danych, aby wspierać naturalną ewolucję aplikacji lub podstawowych procesów biznesowych.

Mam nadzieję że to pomoże.

RobPaller
źródło
7
Dodanie wielu nowych wymagań w trakcie projektu nie jest „nieodpowiednie”. Jest to coś, co twoje metody programistyczne powinny wspierać i zachęcać www.agilemanifesto.org/principles.html
nvogel
1
Doskonale zdaję sobie sprawę z niektórych zasad zwinnego rozwoju i jestem ich zwolennikiem w zakresie hurtowni danych, jeśli ma to sens dla firmy. Dzięki za komentarz.
RobPaller,
11

Miałem luksus projektowania kilku baz danych o średniej złożoności, wszystkich używanych w firmach, z różnymi interfejsami, w tym stronami internetowymi, dostępem i C #.

Zwykle usiadłem i wcześniej opracowałem schemat bazy danych. To zawsze miało dla mnie jak najbardziej sens. Jednak nie było ani jednego przypadku, w którym nie skończyłem na wprowadzaniu zmian, dodawaniu nowych tabel lub utrzymywaniu aspektów, które mnie niepokoiły i były zasadniczo zbyt późno, aby je naprawić.

Nie sądzę, że lekarstwem jest najpierw napisanie kodu. I nie sądzę, że problemem są „niewystarczające wymagania biznesowe”, a przynajmniej nie takie, które można by w pełni rozwiązać. Użytkownicy nie wiedzą, czego potrzebują, a ja nie mam mocy, aby zmusić ich do myślenia, bycia mądrzejszym, bardziej świadomym lub lepiej odpowiadającym na moje pytania. Albo kłócą się, a ja każe mi zrobić coś w określony sposób.

Systemy, które buduję, zwykle znajdują się w nowych obszarach, w które nikt wcześniej nie wchodził. Nie mam wkładu ze strony organizacji, zasobów ani narzędzi do wykonania tego rodzaju pracy, którą mógłby opracować zespół programistów najlepszych projektantów, którzy otrzymywaliby wynagrodzenie jako zespół dziesięć razy więcej niż robię, aby budować różne rzeczy dwa razy więcej.

Jestem dobry w tym co robię. Ale jest tylko jedna osoba, która robi to w środowisku, które „nie rozwija”.

To powiedziawszy, coraz lepiej odkrywam reguły biznesowe. I widzę coś w rodzaju trzeciej opcji:

Przed zaprojektowaniem bazy danych i przed napisaniem dowolnego kodu narysuj przybliżone ekrany pokazujące działanie aplikacji. Muszą być narysowane ręcznie, aby nikt nie komentował czcionki, rozmiaru lub wymiarów - chcesz tylko funkcję.

Dzięki foliom i kawałkom papieru możesz wymieniać i wkładać, jedna osoba będzie komputerem, dwie będą użytkownikami nietechnicznymi, ekspertami w tej dziedzinie (dwie będą mówić na głos), a jedna osoba będzie facylitatorem, który robi notatki i rysuje informować użytkowników o ich procesach myślowych i nieporozumieniach. Użytkownicy „klikają” i przeciągają i piszą w polach, „komputer” aktualizuje ekran i każdy może zapoznać się z projektem. Dowiesz się rzeczy, których inaczej nie nauczyłbyś się, dopóki nie zajmiesz się procesem rozwoju.

Być może sam sobie zaprzeczam - może to odkrycie lepszych wymagań. Ale chodzi o to, aby najpierw zaprojektować aplikację, bez pisania kodu. Zacząłem robić to na małą skalę i działa! Pomimo problemów w moim środowisku, pomaga mi lepiej zaprojektować bazę danych od samego początku. Dowiaduję się, że kolumna musi przejść do nowej tabeli nadrzędnej, ponieważ istnieje wiele typów. Dowiaduję się, że lista robocza musi mieć stałe zlecenia, które nie pochodzą ze zintegrowanego systemu zamówień. Uczę się różnych rzeczy!

Moim zdaniem jest to ogromna wygrana.

ErikE
źródło
+1 Świetna odpowiedź. Ułatwienie opracowania wymagań jest OGROMNYM plusem w projekcie złożonym z wielu zainteresowanych stron.
Zayne S Halsall,
10

Dla większości celów wybrałbym opcję 2: Zbuduj bazę danych równolegle z innymi komponentami. Tam, gdzie to możliwe, zastosuj iteracyjne podejście i zapewnij kompleksową funkcjonalność, budując każdy element.

To wymaga pewnej dyscypliny projektowej. Zastosuj normalizację rygorystycznie (Boyce-Codd / Fifth Normal Form) za każdym razem, gdy zmieniasz bazę danych, aby zachować jakość i nie skończyć na modelu ad-hoc i niespójnym. Bądź tak agresywny, jak to możliwe, stosując reguły biznesowe i związane z nimi ograniczenia baz danych. W razie wątpliwości lepiej jest wcześnie wymusić ograniczenie - zawsze możesz je usunąć później. Bądź inteligentny w kwestii kolejności wdrażania elementów architektonicznych, aby zminimalizować dług techniczny. Mają dobry zestaw wytycznych dotyczących projektowania baz danych, do których kupuje cały zespół programistów.

Wszystko to oczywiście musi iść w parze z innymi dobrymi praktykami inżynierii rozwoju: ciągłą integracją, automatyzacją testów, a przede wszystkim z perspektywy bazy danych, tworzeniem danych testowych. Tworzenie danych testowych danych o realistycznych rozmiarach powinno odbywać się bez przerwy w każdej iteracji.

nvogel
źródło
2
Czy nie sądzisz, że do zdefiniowania modelu koncepcyjnego potrzebne byłoby pewne myślenie z góry?
gbn
Pewne myślenie z góry może być przydatne, ale próba wcześniejszego zdefiniowania całego modelu zwykle przynosi efekt przeciwny do zamierzonego. Model powinien być zgodny z wymaganiami biznesowymi i dopasowywać się do rezultatów projektu (w tym aplikacji) w miarę ich ewolucji. Nie możesz i nie powinieneś oczekiwać, że te rzeczy się nie zmienią. Również utworzenie całego modelu z góry może faktycznie utrudnić inne prace rozwojowe z powodu potrzeby stworzenia fałszywych interfejsów do obsługi jeszcze nieużywanych części schematu.
nvogel
Podejrzewam @dportas i pracuję w podobnych środowiskach :)
Mark Storey-Smith,
9

W świecie architektury sformułowano „Formę podąża za funkcją”, a następnie stosowano ją przy budowie wysokich budynków. To samo należy zastosować do infrastruktury DB i rozwoju aplikacji.

Wyobraź sobie, że piszesz aplikację, decydując w locie, że potrzebujesz stolika tutaj i stolika tam. Po zakończeniu aplikacji masz ogromną liczbę tabel traktowanych jako tablice. Patrząc na wszystkie stoły obok siebie, stoły na pewno nie będą miały rymu ani powodu.

Niestety, niektóre sklepy deweloperów wybiorą coś takiego jak memcached, załadują je danymi w pamięci RAM (traktując to jak kanał danych) i będą miały bazę danych, taką jak MySQL lub PostgreSQL, zachowującą się po prostu jako pamięć danych.

Zachętą do korzystania z bazy danych powinno być jej prawidłowe spojrzenie: jako RDBMS. Tak, system zarządzania relacyjnymi bazami danych. Kiedy korzystasz z RDBMS, Twoim głównym celem powinno być nie tylko ustanowienie tabel do przechowywania, ale także do ich pobierania. Relacje między tabelami należy modelować na podstawie danych, które chcesz zobaczyć, i sposobu ich prezentacji. Powinno to opierać się na spójności i integralności danych wraz ze znanymi regułami biznesowymi. Te reguły biznesowe można kodować w aplikacji (Perl, Python, Ruby, Java itp.) Lub w bazie danych .

WNIOSEK

Zdecydowanie wybrałbym opcję 1. Wymaga to odpowiedniego planowania, modelowania danych i bieżącej analizy danych. Powinno to jednak zminimalizować zmiany w bazie danych na dłuższą metę.

RolandoMySQLDBA
źródło
1
@RolandoMySQLDBA, zakładasz, że projekt bazy danych zbudowany podczas tworzenia aplikacji będzie gorszy niż projekt zbudowany wcześniej? Dlaczego? Przeciwnie jest często prawdą.
nvogel
1
@dportas: Kładę nacisk na opcję 1 w zakresie minimalizacji zmian w projekcie DB. 2/3 mojego programowania kariery technologicznej spędziłem w sklepach, w których bardzo skomplikowane modele danych i infrastruktura były przekształcane niemal co miesiąc pod wpływem kaprysu. Czułem się na takich zmianach, ponieważ potrzeby i cele biznesowe nie były wyryte na kamieniu. Jestem w tym dość stara szkoła. Nie ma nic złego w byciu trochę indywidualistą, o ile projekt nie powoduje długu technicznego (tak, czytam, że odpowiadasz).
RolandoMySQLDBA 12.10.11
2
+1 za „użycie RDBMS jako relacyjnej bazy danych, a nie kubła bitowego dla tablic” - w zależności od tego, jakie podejmiesz podejście
Jack Douglas,
2
@dportas: chociaż jest to prawda (zmiana reguł biznesowych), dobrze zaprojektowana baza danych nie zmieni się radykalnie między iteracją (lub sprintem, czy czymkolwiek) a innym, ponieważ odzwierciedla wszystkie odpowiednie struktury danych procesu pracy. Jeśli tak się stanie (radykalna zmiana), oznacza to niepowodzenie reguł biznesowych przechwytujących działania.
Fabricio Araujo
3
@dportas: nie wszystkie zmiany DB, tylko RADYKALNE. Niewielkie zmiany są częścią działalności związanej z tworzeniem oprogramowania. Ale konieczność dzielenia danych w 2 różnych bazach danych w trakcie pracy to błąd w projekcie i przechwytywaniu reguł biznesowych. (Właściwie to mi się zdarzyło.
Fabricio Araujo
9

Myślę, że należy to zrobić przed pojawieniem się jakiegokolwiek kodu aplikacji, ale nie przed zaprojektowaniem aplikacji.

Mój typowy przepływ pracy, jeśli praca sama to:

  1. Określ, co musi zrobić aplikacja
  2. Sprawdź, czy którekolwiek z zadań można rozbić na komponenty wielokrotnego użytku
  3. Określ, w jaki sposób każde zadanie musi współdziałać z przechowywaniem danych - jakie pytania będą zadawać o dane, jak często będą pisać itp.
  4. Zaprojektuj bazę danych, aby była w stanie odpowiedzieć na wszystkie pytania, które musimy zadać, i powinna dobrze wykonywać najczęstsze zadania.
  5. Napisz aplikację.

Ponieważ często pracuję w ramach zespołu i jesteśmy rozproszeni geograficznie (i w różnych strefach czasowych), zwykle mamy wstępne spotkanie wstępne:

  1. Określ, co musi zrobić aplikacja.
  2. Określ, gdzie są dobre punkty, aby podzielić aplikację na samodzielne komponenty
  3. Określ, w jaki sposób każdy komponent będzie wymagał interakcji z innymi.
  4. Uzgodnij interfejs API dla każdej interakcji.

Następnie wracamy do domu, piszemy naszą część, a jeśli komponent potrzebuje własnej pamięci lokalnej, o ile opiekun tej części utrzymuje interfejs API swojego modułu w spójny sposób. Główne miejsce do przechowywania danych jest obsługiwane jako moduł z własnym interfejsem API i oczekuje się, że ludzie będą do niego pisać. (w przypadkach, w których szybkość DB jest krytyczna, API to definicje tabel, a jeśli zostaną wprowadzone zmiany, używamy widoków lub innego mechanizmu do prezentacji starszej wersji do czasu aktualizacji wszystkich modułów)

Joe
źródło
1
Opcją 2 jest to, że przy zwinnej metodologii nie znasz 1, 2 lub 3 wykraczającej poza zakres przewidziany dla następnego sprintu. Zmiana jest nieunikniona, jeśli chodzi o zakres, wymagania i oczekiwania.
Mark Storey-Smith
8

Mam na myśli następującą zasadę: „możesz uzyskać tylko z bazy danych informacje, które masz do wygenerowania”. Więc najpierw projektuję bazę danych, a potem kod.

Dlaczego? Bez względu na to, jakiej metodologii / języka / zestawu narzędzi używam, jeśli wszystkie istotne dane są dobrze zaprojektowane i przechowywane w DB, mogę je odzyskać. Bez względu na to, czy jest w C # / Delphi / FORTRAN / COBOL / Assembly / VBA lub Crystal Reports; Zaprojektowane przez OO lub związane z wydarzeniem / danymi / czymkolwiek; zwinny lub wodospad. Jeśli dane tam są, mogę je odzyskać, jeśli używane narzędzia mogą połączyć się z bazą danych. Mogę tworzyć raporty sprzedaży, jeśli mogę WYBRAĆ zamówienia na przychody kwartału - nawet jeśli będę musiał zapisywać je bajt po bajcie na asemblerze.

Jeśli odpowiednich danych nie ma, a nawet jeśli są, ale (nie) ustrukturyzowane w sposób uniemożliwiający odzyskanie potrzebnych informacji - jak je kodować?

Fabricio Araujo
źródło
7

Jak zwykle to zależy;)

Załóżmy na przykład, że mamy niewielki działający prototyp opracowany w Pythonie i używający płaskich plików, a użytkownicy są zadowoleni z funkcji prototypu, więc wszystko, co musimy zrobić, to wyprodukować go, używając RDBMS jako zaplecza . W takim przypadku można oczekiwać, że zrobi to dobrze za pierwszym razem - problem jest niewielki i dobrze zdefiniowany. W takich przypadkach możliwe jest zaprojektowanie z góry.

Z drugiej strony, gdy odkrywamy wymagania w środowisku Agile, potrzebujemy kilku iteracji, aby je lepiej zrozumieć. W takich sytuacjach baza danych ewoluuje wraz z resztą aplikacji. Tak zwykle robimy. Ponieważ możemy refaktoryzować tabele OLTP na żywo bez żadnych przestojów i przy niskim ryzyku, czujemy się komfortowo z możliwością refaktoryzacji bazy danych.

AK
źródło