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 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ę?

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.

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!

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.

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.

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.

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ę.

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)

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ć?

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.