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?
Odpowiedzi:
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:
Z bazami danych masz:
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ą.
źródło
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.
źródło
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.
źródło
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.
źródło
projektowanie bazy danych nie może być wykonane całkowicie bez uwzględnienia sposobu wykorzystania danych, oto krótka lista kroków:
źródło
Aby pomyślnie zaprojektować bazę danych, musisz najpierw rozważyć kilka rzeczy:
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.
źródło
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).
źródło
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.
źródło
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
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.
źródło