it-swarm.dev

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

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 początkowo przed napisaniem dowolnego 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 specyfikę aplikacji, które wpływają na to, co/gdzie/jak zmiany danych przez cały cykl tworzenia 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. Wadą byłby podział czasu i prac rozwojowych między kod aplikacji i tworzenie baz danych.

Co według twojego doświadczenia jest najbardziej wydajną i wydajną metodą?

57
Thomas Stringer

Oprócz innych odpowiedzi ...

Najpierw przechwytywanie 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ę brudną, 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.

42
gbn

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 łatwe 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 ) wystąpić w przyszłości, więc musisz zaprojektować to, co wiesz, 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!

27
Mark Storey-Smith

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

Jeśli stwierdzisz, że musisz wprowadzić wiele zmian w projekcie bazy danych w całym cyklu życia aplikacji, oznacza to dwie rzeczy:

  1. Pełzanie zakres - Pozwalasz na wprowadzenie 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.

12
RobPaller

Miałem luksus projektowania kilku baz danych o średniej złożoności, wszystkie używane 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. Lub 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ć 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 robi rozwoju”.

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 zamieniać i wyjmować, jedna osoba będzie komputerem, dwie będą użytkownikami nietechnicznymi, ekspertami w tej dziedzinie (dwie będą mówić głośno), 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 wszyscy mogą 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 IS lepsze wykrywanie wymagań. Ale chodzi o to, żeby 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.

11
ErikE

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 zmienisz 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 i 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.

10
nvogel

W świecie architektury wyrażenie „Forma podąża za funkcją” zostało wymyślone, a następnie przestrzegane 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 ogromna liczba tabel jest traktowana 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ą go danymi w RAM (traktując to jak kanał danych)) i będą miały bazę danych, taką jak MySQL lub PostgreSQL, zachowują się po prostu jak jednostka przechowywania danych.

Zachętą do korzystania z bazy danych powinno być jej prawidłowe spojrzenie: jako RDBMS. Tak, a Relacyjny System zarządzania bazą danych. Kiedy używasz RDBMS, Twoim celem z góry powinno być nie tylko ustanowienie tabel do przechowywania, ale także do ich pobierania. Relacje między tabelami powinny być modelowane 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ę.

9
RolandoMySQLDBA

Myślę, że należy to zrobić, zanim pojawi się jakakolwiek rzeczywista kod dla 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. Ustal, 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ę jako część 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ęść i 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)

9
Joe

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; OO zaprojektowany lub zdarzenie/dane/cokolwiek napędzane; zwinny lub wodospad. Jeśli dane tam są, mogę je odzyskać, jeśli narzędzia, których używam, mogą połączyć się z bazą danych. Mogę tworzyć raporty sprzedaży czy mogę WYBRAĆ zamówienia na przychody kwartału - nawet jeśli muszę to zapisać bajt po bajcie na Zgromadzeniu.

Jeśli odpowiednich danych nie ma, a nawet jeśli są, ale (nie) ustrukturyzowane w taki sposób, że nie mogę uzyskać potrzebnych informacji - jak je kodować?

8
Fabricio Araujo

Jak zwykle to zależy;)

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

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, jesteśmy zadowoleni z możliwości refaktoryzacji bazy danych.

7
A-K