Jak podchodzisz do projektowania baz danych? [Zamknięte]

14

Jestem przede wszystkim programistą i mam kilka osobistych projektów, które chcę rozpocząć.

Jedną z rzeczy, która mnie denerwuje, jest projektowanie baz danych. Przeszedłem przez szkolną normalizację db i takie tam, ale to było kilka lat temu i nigdy nie miałem doświadczenia w projektowaniu relacyjnych baz danych poza szkołą.

Jak podchodzisz do bazy danych z perspektywy aplikacji internetowej? Jak zaczynasz i na co zwracasz uwagę? Jakie są flagi ostrzegawcze?

bron
źródło
8
Dobry projekt bazy danych dla aplikacji internetowych jest taki sam jak dobry projekt bazy danych dla dowolnej aplikacji. Dostępnych jest wiele książek wprowadzających, które dobrze radzą sobie z podstawami.
Robert Harvey
1
@harvey Jakieś książki, które możesz polecić?
bron

Odpowiedzi:

14

Najlepsza książka, jaką kiedykolwiek kupiłem na temat projektowania baz danych, to Projektowanie baz danych dla zwykłych śmiertelników autorstwa Michaela Hernandeza ISBN: 0-201-69471-9. Amazon Listing Zauważyłem, że ma trzecie wydanie.

Link do trzeciej edycji

Przeprowadzi Cię przez cały proces (od początku do końca) projektowania bazy danych. Polecam zacząć od tej książki.

Musisz nauczyć się patrzeć na rzeczy w grupach lub kawałkach. Projektowanie baz danych ma proste elementy składowe, podobnie jak programowanie. Jeśli dobrze zrozumiesz te proste elementy składowe, możesz rozwiązać każdy projekt bazy danych.

W programowaniu masz:

  • Jeśli konstruuje
  • Jeśli jeszcze konstruuje
  • Wykonaj pętle While
  • Czy do pętli
  • Konstrukcja skrzynek

Z bazami danych masz:

  • Tabele danych
  • Tabele wyszukiwania
  • Relacje jeden do jednego
  • Relacje jeden do wielu
  • Relacje wiele do wielu
  • Klucze podstawowe
  • Klucz obcy

Im prościej, tym lepiej. Baza danych to nic innego jak miejsce, w którym umieszczasz dane w dziurkach. Zacznij od określenia, jakie są te dziury w kubeczkach i jakie rzeczy w nich chcesz.

Nigdy nie będziesz tworzyć idealnego projektu bazy danych przy pierwszej próbie. To jest fakt. Twój projekt będzie podlegał kilku udoskonaleniom w trakcie procesu. Czasami rzeczy nie wydają się oczywiste, dopóki nie zaczniesz wprowadzać danych, a potem masz chwilę ah ha .

Sieć przynosi własne zestawy wyzwań. Problemy z pasmem. Bezpaństwowość. Błędne dane z procesów, które się rozpoczynają, ale nigdy się nie kończą.

Michael Riley - AKA Gunny
źródło
11

Zajmuję się zarówno programowaniem obiektowym, jak i projektowaniem baz danych (głównie transakcyjnych, ale niektóre OLAP), aw moich okolicznościach jest wiele powtarzających się motywów (przynajmniej z OLTP).

Praktykowanie normalizacji 3nf pomaga mi przećwiczyć pewien wariant zasady pojedynczej odpowiedzialności. Tabela powinna reprezentować koncepcję w twoim systemie - a koncepcje powinny odnosić się do siebie tak, aby próbowały naśladować rzeczywistość; na przykład, jeśli buduję system, w którym klient może mieć 0 lub wiele działań, tworzę tabelę klientów i tabelę działań. Tabela aktywności ma relację klucza obcego do tabeli klienta. Podczas budowania procedur przechowywanych upewnij się, że użyję sprzężenia zewnętrznego, aby dołączyć do klienta i działania, ponieważ wymaganie biznesowe, aby klient mógł mieć 0 działań.

Uważam też na możliwości rozszerzenia, używając tabel mostów (linków). Na przykład, gdybym próbował reprezentować regułę biznesową, w której książka mogłaby mieć nieograniczoną (zmienną) liczbę autorów, stworzyłbym tabelę książek, tabelę autorów oraz tabelę mostu / łącza, która zawiera odniesienia do kluczy obcych do obu Książka i autor.

Ponadto używam kluczy zastępczych na wszystkich tabelach (zwykle kolumny z automatyczną inkrementacją tożsamości, ale być może prowadnice - kompromisem z prowadnicami w kodzie jest to, że zajmują więcej miejsca w pamięci niż zwykła liczba całkowita) i unikam polegania na naturalnych kluczach dla mojej wyszukiwania (z wyjątkiem tabel mostów / linków). Domyślnie tworzę również indeksy w kolumnach wspólnych kluczy obcych i od czasu do czasu sprawdzam procedury składowane / zapytania systemowe w celu optymalizacji strategii indeksowania. Inną strategią indeksowania, której używam, jest szukanie miejsc w kodzie, w których buduję kolekcję na podstawie kolumny wyszukiwania i dodam odpowiednie indeksy do kolumn wyszukiwania.

Tim Claason
źródło
10

Najpierw projektuję schemat bazy danych, a następnie używam ORM do tworzenia obiektów z niego. W ten sposób jestem trochę stara szkoła; Nie ufam ORM w tworzeniu inteligentnego, wydajnego schematu bazy danych. To jest praca ludzi i część rzemiosła projektowania oprogramowania.

Robert Harvey
źródło
1
ORM nie wymyśla twojego schematu. Buduje go na podstawie tego, co zrobiłeś w swoich obiektach. Jeśli budujesz swoje obiekty ze schematu, w rzeczywistości delegujesz ważne zadanie na swoją głupią ORM.
1
@ Pierre303 Schemat jest oparty na zasadach programowania w tym ORM, które mogą nie idealnie pasować do twojej sytuacji / projektu. Może utworzyć suboptymalną bazę danych. Widziałem okropne rzeczy wychodzące z ORM nawet na poziomie zapytania.
m4tt1mus
@ Pierre303, myślę, że ten komentarz pokazuje dokładnie, dlaczego budowanie z ORm jest złym pomysłem, właściwie zaprojektowana baza danych nie powinna bezpośrednio pasować do obiektów używanych w aplikacji. Często istnieje wiele innych rzeczy potrzebnych do prawidłowego zaprojektowania bazy danych, których to nie wziąłoby pod uwagę, ani nie wziąłoby to pod uwagę, jakie struktury są najbardziej wydajne dla bazy danych, a nie aplikacji.
HLGEM
@HLGEM: prawdopodobnie nie mogłeś pracować z zaawansowanymi ORM, takimi jak Hibernacja, i napisz ten komentarz
OH, w jaki sposób orm obsługuje kontrole i pola potrzebne do celów innych niż aplikacja?
HLGEM
5

Uważam, że książka Billa Karwina, SQL Antipatterns , jest naprawdę przydatna do planowania baz danych. Najbardziej kompleksowo robi to, że baza danych oferuje wiele możliwości ochrony integralności i znaczenia twoich danych oraz że częstym błędem projektantów jest ignorowanie tych funkcji z różnych kuszących powodów. Biorąc pod uwagę te problemy od samego początku i informując ich, że cały projekt jest wart zachodu, a później próbuje przełamać pęknięcia na papierze.

Wolę używać bazy danych, która ma kompleksowe ograniczenia w celu wymuszenia logiki biznesowej i integralności na poziomie bazy danych. Często widzę bazę danych jako aplikację, a wszystko, co uzyskuje do niej dostęp, jest zwykłym interfejsem. To sprawia, że ​​dodanie innych „interfejsów” jest przyjemniejszym i prostszym doświadczeniem i ma pozytywne korzyści dla bezpieczeństwa.

Uważam również, że ważne jest, aby wziąć pod uwagę strukturę bazy danych jako zmieniającą się jednostkę, zamiast zakładać, że musisz ją zawinąć i zapieczętować, zanim zaczniesz cokolwiek innego. Powinieneś zaplanować zmianę i umieścić DB w swoim systemie wersjonowania. Jest ładny esej na ten temat: Evolutionary Database Design autorstwa Martina Fowlera i Pramoda Sadalage'a (a także całą książkę na ten temat autorstwa Sadalage'a, chociaż tego nie przeczytałem).

Wreszcie, peryferyjne problemy kont / ról użytkowników, sprzętu / lokalizacji / połączenia hosta itp. Są ważne i czasami pomijane. Pamiętaj o tym również podczas planowania.

Ian Mackinnon
źródło
5

projektowanie bazy danych nie może być wykonane całkowicie bez uwzględnienia sposobu wykorzystania danych, oto krótka lista kroków:

  • napisz krótkie zdania opisujące relacje między bytami
  • narysuj diagram relacji jednostka reprezentujący zdania
  • utwórz znormalizowany logiczny model danych z diagramu ER
  • stworzyć macierz CRUD dla aplikacji i podmiotów
  • użyj matrycy, aby zweryfikować pokrycie cyklu życia każdego podmiotu
  • wyodrębnij podchemy dla każdej aplikacji
  • sprawdź ścieżki nawigacyjne w podsekcjach dla każdej operacji głównej / CRUD
  • rozważ raporty, które będą wymagane
  • zaprojektować fizyczny model danych w oparciu o wszystkie powyższe; denormalizować, dzielić i używać schematów gwiezdnych tam, gdzie jest to właściwe
Steven A. Lowe
źródło
Lepiej upewnij się, że prawidłowo otrzymałeś raport, jeśli chcesz zadowolić ludzi, którzy wystawiają czeki.
JeffO
3

Aby pomyślnie zaprojektować bazę danych, musisz najpierw rozważyć kilka rzeczy:

  • Jakie dane muszę przechowywać i jak są one powiązane z innymi danymi, które przechowuję. Jak te dane będą musiały się zmieniać z czasem? Czy muszę być w stanie zobaczyć migawkę w czasie (to zamówienie z 2009 roku), czy też potrzebuję tylko tego, co jest aktualne (tylko aktywni użytkownicy)?
  • Jak mogę się upewnić, że moje dane są znaczące i zachowują znaczenie w miarę upływu czasu (integralność danych)?
  • Jak mogę się upewnić, że dostęp do danych jest szybki?
  • Jak mogę zabezpieczyć moje dane?

Dlatego zanim zaczniesz projektować bazę danych, musisz najpierw dowiedzieć się o normalizacji i funkcjach bazy danych używanych do zachowania integralności danych.

Następnie musisz zrozumieć dostrajanie wydajności. Nie jest to przedwczesne, wydajność jest krytycznym punktem awarii większości baz danych i jest bardzo trudna do naprawienia, gdy masz miliony rekordów.

I wreszcie musisz zrozumieć, jak zabezpieczyć dane i jakie dane należy zabezpieczyć oraz jakie wewnętrzne kontrole są potrzebne, aby upewnić się, że dane nie zostaną złośliwie zmienione lub że możesz śledzić zmiany w czasie, aby dowiedzieć się, kto i kiedy dokonano zmiany i można było powrócić do poprzednich wersji.

Pomocne jest również przeczytanie informacji o refaktoryzacji baz danych przed rozpoczęciem, ponieważ będzie trzeba później dokonać refaktoryzacji, a także pomocna wiedza na temat konfigurowania rzeczy, aby można było refaktoryzować tak łatwo, jak to możliwe.

Zasadniczo dane przeżywają tę aplikację przez wiele lat, jest ona sercem aplikacji i nie należy jej traktować jako jakiegoś głupiego magazynu danych, który jest w większości nieistotny.

HLGEM
źródło
2

Ogólnie rzecz biorąc, dobry projekt bazy danych to dobry projekt bazy danych - większe pytanie dotyczące korzystania z Internetu będzie dotyczyło sposobu uzyskiwania dostępu do danych i zarządzania rzeczami, które można uznać za wymagające stanu, którego zasadniczo nie ma w sieci.

Myśląc o tym, moje podejście opiera się na naprawdę dużym doświadczeniu ... ale niezależnie od tego, czy zaczynasz od schematu, czy obiektów, próbujesz zrobić to samo, tj. Zbudować użyteczny model danych - dla znacznej liczby projekty może istnieć dość bezpośredni związek między modelem a schematem (nie we wszystkich przypadkach i prawdopodobnie nie dla wszystkich tabel / obiektów), więc tak naprawdę chodzi o zbudowanie przyzwoitego modelu, poczynając od tego, gdzie czujesz się komfortowo i pracując stamtąd.

Jeśli chodzi o budowanie przyzwoitego modelu - @Tim ma go w dół dla baz danych i zasadniczo zbudowanie modelu obiektowego będzie zasadniczo podobne - co jest wyjątkowe, co jest hierarchią, gdzie jest wiele do wielu relacji itp., Jednak niezależnie od tego dostać się do bazy danych, upewnij się, że robisz wszystkie dobre rzeczy.

Upewnij się także, że masz skrypty lub kod ddl w kodzie, aby umożliwić tworzenie schematu od zera i aktualizowanie go podczas wprowadzania zmian (kod ddl jest moją preferowaną metodą - mam system i działa).

Murph
źródło
2

Zaczynam od dużej tablicy i kilku różnych kolorów długopisu. Różne kolory oznaczają różne rzeczy. I właśnie zaczynam rysować. Zazwyczaj rysuję rzeczy, które są wyraźne na czarno, rzeczy, które są prawdopodobnie na niebiesko, i rzeczy, które są mało prawdopodobne na zielono. Kolor czerwony oznacza ważne uwagi. Obficie usuwam i przerysowuję. Zastanawiam się nad tym, jakie rodzaje pytań muszę wykonać, i upewnij się, że model to obsługuje. Jeśli tak się nie stanie, będę go poprawiać, dopóki nie zrobi tego.

W końcu, jeśli model stanie się zbyt duży, przeniosę go do Visio i popracuję nad kawałkami na tablicy.

Na koniec myślę o punktach rozszerzenia. Największym błędem, jaki widzę większość ludzi, jest zaprojektowanie ich bazy danych, a następnie powiedzenie „Skończyłem z bazą danych” i przejście dalej. Nigdy nie skończyłeś z bazą danych. Każda otrzymana prośba o zmianę może zejść aż do tego poziomu. Zastanów się, jak go dodać. Zastanów się, jakie rodzaje wniosków są prawdopodobne i sprawdź, czy jesteś w stanie je podłączyć. Jeśli nie myślisz w ogóle o rozszerzalności, popadniesz w duże długi projektowe, gdy pojawią się te żądania zmiany.

Jeśli chodzi o „SQL, a następnie ORM” i odwrotnie, to zależy od Ciebie. Upewnij się tylko, że Twój model jest dobrym fundamentem.

Hounshell
źródło
Podchwytliwe to ... Zgadzam się, że należy wziąć pod uwagę przyszłość projektu (a reszta jest dobra, stąd opinia), ale niejednokrotnie miałem bazy danych, które mają pola, a nawet tabele, które nigdy się nie przydają, ponieważ Zaprojektowałem w przyszłości, która nigdy się nie wydarzyła. Mam teraz tendencję do budowania w celu rozwiązania problemu - ale (i to jest moja karta „wyjdź z więzienia”) upewniam się, że mam mechanizm, który pozwala mi łatwo aktualizować schemat (i ponieważ robię to z kod może w razie potrzeby zastosować skomplikowane manipulacje)
Murph,
Właśnie to starałem się osiągnąć. Zbuduj to, czego potrzebujesz, nic więcej. Ale jeśli nie planujesz później ekspansji, to czy byłeś kiedyś w godzinach szczytu w zatoce? Jest to doskonały przykład tego, co dzieje się, gdy nie zastanawiasz się, jak być może konieczne będzie rozszerzenie.
Hounshell,
I dla lepszego wyjaśnienia kolorów: czarny jest dla rzeczy, które wiem są poprawne. Zwykle proste rzeczy, których tak naprawdę nie ma inny schemat, który ma sens. Niebieski oznacza rzeczy, które mogę nieco zmienić. Rzeczy, które prawdopodobnie mają rację, ale mogę je usunąć. Zielony jest dla rzeczy, w których naprawdę burzę mózgów i raczej prawdopodobnie wymażę.
Hounshell,
1

Najpierw projektuję obiekty, a następnie używam ORM (takich jak nHibernate) do stworzenia schematu. Daje mi to większą elastyczność niż wykonywanie odwrotności.

Kolejnym krokiem jest optymalizacja wygenerowanego schematu.

Dawno nie widziałem projektu, w którym tabele bazy danych zostały zaprojektowane jako pierwsze.


źródło
Tak. O ile nie jesteś guru DB, db db o to, aby dbanie było tak proste, jak to absolutnie możliwe. Powinien być wystarczająco dobry, aby obsługiwać aplikację. Wstępna optymalizacja jest zła. Wstępna optymalizacja, gdy nie wiesz, co robisz, jest okropna. Jeśli napotkasz problemy (a prawdopodobnie nie będziesz) tylko wtedy przyprowadź prawdziwego eksperta.
ElGringoGrande
1
@ElGringoGrande O ile nie jesteś dbguru, nie musisz projektować bazy danych dla aplikacji innych niż najbardziej rudymetryczne. Jeśli będzie potrzebował więcej niż 10 tabel i pomieści nie więcej niż 100 000 rekordów, a ty nie masz profesjonalnego projektanta baz danych, to robisz to źle.
HLGEM
Bzdury. Zaprojektowałem bazę danych, która ma ponad 160 tabel i miliony wierszy (największa tabela ma nieco ponad milion rekordów dla klienta średniej wielkości. Największy klient ma ponad 5 milionów). Większość klientów ma kilkaset jednoczesnych użytkowników, a największy ponad 2 tysiące użytkowników. I nie jestem DB Guru, ani go nie zatrudniliśmy. Zrobiłem kilka z tych projektów DB dla różnych aplikacji. Chłopcze spieprzyłem.
ElGringoGrande
1
ElGringoGrande: Jeśli zaprojektowałeś takie bazy danych, z setkami równoczesnych użytkowników i milionami wierszy w tabelach, a użytkownicy są zadowoleni, jesteś db-guru. Być może jeszcze tego nie zauważyłeś.
ypercubeᵀᴹ
1

Niewiele rzeczy, które dotychczas nie zostały jednoznacznie stwierdzone przez innych stypendystów:

  • Najlepiej, aby projekt bazy danych wykonał ktoś profesjonalny. Oczywiście można się uczyć, ale nie sugerowałbym budowania średniego lub dużego modelu, jeśli ktoś nie jest dobrze zorientowany w modelowaniu lub projektowaniu baz danych. Powodem tego jest to, że koszt złego projektu jest zwykle bardzo wysoki.

  • Dobrze poznaj cele systemu i wymagania użytkowników. Bez znajomości wymagań nie można zaprojektować poprawnego modelu danych.

  • Wiedz, który kod zrobić w programach i który kod zająć się DB. Jest to wymagane, aby poprawnie ustawić kolumnę danych null, a nie null itp. Jest to również wymagane, aby poprawnie określić RI.

  • Dobrze określ swoje klucze podstawowe. Idź po proste klucze, kiedy możesz.

  • Rozważ potrzebę integracji z innymi aplikacjami.

  • Rozważ zastosowanie uniwersalnych modeli danych i przestrzegaj standardów branżowych w zakresie nazewnictwa i wielkości kolumny danych.

  • Pomyśl o przyszłych potrzebach (jeśli są znane i mają zastosowanie)

  • Niech Twój tryb zostanie sprawdzony przez innych.

  • Użyj narzędzia do modelowania - albo narzędzie ERD, albo narzędzie UML.

  • Przejrzyj i zrozum wygenerowany kod DDL. Nie bierz tego za pewnik.

Bez szans
źródło