Złe praktyki w projektowaniu baz danych: czy popełniasz te błędy?

Ilekroć jako programista otrzymujesz zadanie oparte na istniejącym kodzie, musisz stawić czoła wielu wyzwaniom. Jednym z takich wyzwań — najczęściej najbardziej wymagającym — jest zrozumienie modelu danych aplikacji.

Zwykle masz do czynienia z mylącymi tabelami, widokami, kolumnami, wartościami, procedurami składowanymi, funkcjami, ograniczeniami i wyzwalaczami, których sens zajmuje dużo czasu. A kiedy już to zrobią, zaczniesz zauważać wiele sposobów na poprawę i wykorzystanie przechowywanych informacji.

Jeśli jesteś doświadczonym programistą, prawdopodobnie zauważysz również rzeczy, które na początku można było zrobić lepiej, np. wady projektowe.

W tym artykule dowiesz się o niektórych typowych złych praktykach projektowania baz danych, dlaczego są one złe i jak możesz ich uniknąć.

Zła praktyka nr 1: Ignorowanie celu danych

Dane są przechowywane do późniejszego wykorzystania, a celem jest zawsze ich przechowywanie i odzyskiwanie w najbardziej efektywny sposób. Aby to osiągnąć, projektant bazy danych musi z góry wiedzieć, jakie dane będą reprezentować, w jaki sposób i w jakim tempie zostaną pozyskane, jaka będzie jej objętość operacyjna (tj. ile danych jest oczekiwanych) i na koniec , jak będzie używany.

Na przykład przemysłowy system informacyjny, w którym dane są codziennie zbierane ręcznie, nie będzie miał tego samego modelu danych, co system przemysłowy, w którym informacje są generowane w czasie rzeczywistym. Czemu? Ponieważ obsługa kilkuset lub tysięcy rekordów miesięcznie różni się od zarządzania ich milionami w tym samym okresie. Szczególne względy muszą być podjęte przez projektantów, aby zachować wydajność i użyteczność bazy danych, jeśli wolumeny danych mają być duże.

Ale oczywiście ilość danych nie jest jedynym aspektem do rozważenia, ponieważ cel danych wpływa również na poziom normalizacji, strukturę danych, rozmiar rekordu i ogólną implementację całego systemu.

Dlatego dokładna znajomość celu tworzonego systemu danych prowadzi do rozważań przy wyborze silnika bazy danych, projektowanych encji, rozmiaru i formatu rekordu oraz zasad zarządzania silnikiem bazy danych.

Ignorowanie tych celów doprowadzi do powstania projektów, których podstawy są wadliwe, choć strukturalnie i matematycznie poprawne.

Zła praktyka nr 2: Słaba normalizacja

Projektowanie bazy danych nie jest zadaniem deterministycznym; dwóch projektantów baz danych może przestrzegać wszystkich reguł i zasad normalizacji dla danego problemu iw większości przypadków wygeneruje różne układy danych. Jest to nierozerwalnie związane z twórczą naturą inżynierii oprogramowania. Istnieją jednak pewne techniki analityczne, które mają sens w każdym przypadku, a stosowanie ich jest najlepszym sposobem na dotarcie do bazy danych, która działa najlepiej.

Mimo to często mamy do czynienia z bazami danych, które zostały zaprojektowane w locie bez przestrzegania najbardziej podstawowych zasad normalizacji. Musimy to jasno powiedzieć: każda baza danych powinna być przynajmniej znormalizowana do trzeciej normalnej postaci, ponieważ jest to układ, który najlepiej reprezentuje twoje encje, a jego wydajność będzie najlepiej zrównoważona między zapytaniami a wstawianiem-aktualizowaniem-usuwaniem rekordów .

Jeśli natkniesz się na stoły, które nie są zgodne z 3NF, 2NF, a nawet 1NF, rozważ przeprojektowanie tych tabel. Wysiłek, który w to zainwestujesz, zwróci się w bardzo krótkim okresie.

Zła praktyka nr 3: Redundancja

Bardzo związana z poprzednim punktem, ponieważ jednym z celów normalizacji jest jej zmniejszenie, redundancja to kolejna zła praktyka, która pojawia się dość często.

Nadmiarowe pola i tabele to koszmar dla programistów, ponieważ wymagają one logiki biznesowej, aby zachować aktualność wielu wersji tych samych informacji. Jest to obciążenie, którego można uniknąć, jeśli dokładnie przestrzega się zasad normalizacji. Chociaż czasami nadmiarowość może wydawać się konieczna, należy ją stosować tylko w bardzo szczególnych przypadkach i wyraźnie udokumentować, aby można ją było uwzględnić w przyszłych zmianach.

Typowe złe skutki nadmiarowości to niepotrzebny wzrost rozmiaru bazy danych, podatność danych na niespójność i spadek wydajności bazy danych, ale – co ważniejsze – może prowadzić do uszkodzenia danych.

Zła praktyka nr 4: Zła integralność referencyjna (ograniczenia)

Integralność referencyjna jest jednym z najcenniejszych narzędzi udostępnianych przez silniki baz danych w celu utrzymania najwyższej jakości danych. Jeśli na etapie projektowania nie zaimplementowano żadnych ograniczeń lub bardzo niewiele ograniczeń, integralność danych będzie musiała całkowicie opierać się na logice biznesowej, co czyni je podatnymi na błędy ludzkie.

Zła praktyka nr 5: Niewykorzystywanie funkcji silnika DB

Korzystając z silnika bazy danych (DBE), masz potężne oprogramowanie do zadań związanych z obsługą danych, które uprości tworzenie oprogramowania i gwarantuje, że informacje są zawsze poprawne, bezpieczne i użyteczne. DBE świadczy usługi takie jak:

• Widoki, które zapewniają szybki i wydajny sposób przeglądania danych, zazwyczaj denormalizując je na potrzeby zapytań bez utraty poprawności danych.
• Indeksy, które pomagają przyspieszyć zapytania w tabelach.
• Funkcje agregujące, które pomagają analizować informacje bez programowania.
• Transakcje lub bloki zdań zmieniających dane, które są wykonywane i zatwierdzane lub anulowane (wycofywane), jeśli wydarzy się coś nieoczekiwanego, dzięki czemu informacje są zawsze poprawne.
• Blokady, które zapewniają bezpieczeństwo i poprawność danych podczas wykonywania transakcji.
• Procedury składowane udostępniające funkcje programistyczne umożliwiające wykonywanie złożonych zadań związanych z zarządzaniem danymi.
• Funkcje umożliwiające zaawansowane obliczenia i transformacje danych.
• Ograniczenia, które pomagają zagwarantować poprawność danych i uniknąć błędów.
• Wyzwalacze, które pomagają zautomatyzować działania, gdy na danych wystąpią zdarzenia.
• Optymalizator poleceń (planer wykonania), który działa pod maską, zapewniając, że każde zdanie zostanie wykonane w najlepszym wydaniu i zachowując plany wykonania na przyszłe okazje. Jest to jeden z najlepszych powodów, dla których warto używać widoków, procedur zapisanych w bazie i funkcji, ponieważ ich plany wykonania są przechowywane na stałe w DBE.

Nieznajomość lub ignorowanie tych możliwości zaprowadzi rozwój na wyjątkowo niepewną ścieżkę i na pewno do błędów i przyszłych problemów.

Zła praktyka nr 6: złożone klucze podstawowe

Jest to rodzaj kontrowersyjnego punktu, ponieważ wielu projektantów baz danych mówi obecnie o używaniu pola generowanego automatycznie z identyfikatorem całkowitym jako klucza podstawowego zamiast złożonego zdefiniowanego przez kombinację dwóch lub więcej pól. Jest to obecnie określane jako „najlepsza praktyka” i osobiście się z tym zgadzam.

Jest to jednak tylko konwencja i oczywiście DBE pozwalają na zdefiniowanie złożonych kluczy podstawowych, które zdaniem wielu projektantów są nieuniknione. Dlatego, podobnie jak w przypadku nadmiarowości, złożone klucze podstawowe są decyzją projektową.

Uważaj jednak, jeśli oczekuje się, że tabela ze złożonym kluczem podstawowym ma miliony wierszy, indeks kontrolujący klucz złożony może wzrosnąć do punktu, w którym wydajność operacji CRUD jest bardzo obniżona. W takim przypadku znacznie lepiej jest użyć prostego klucza podstawowego o identyfikatorze całkowitym, którego indeks będzie wystarczająco zwarty i ustanowić niezbędne ograniczenia DBE, aby zachować unikatowość.

Zła praktyka nr 7: Słabe indeksowanie

Czasami będziesz mieć tabelę, którą musisz wykonać w wielu kolumnach. W miarę wzrostu tabeli zauważysz, że SELECT w tych kolumnach zwalnia. Jeśli tabela jest wystarczająco duża, pomyślisz logicznie, aby utworzyć indeks dla każdej kolumny, której używasz do uzyskiwania dostępu do tej tabeli, tylko po to, aby niemal natychmiast stwierdzić, że wydajność operacji SELECT poprawia się, ale INSERT, UPDATE i DELETE spada. Wynika to oczywiście z faktu, że indeksy muszą być zsynchronizowane z tabelą, co oznacza ogromne obciążenie dla DBE. Jest to typowy przypadek nadmiernego indeksowania, który można rozwiązać na wiele sposobów; na przykład posiadanie tylko jednego indeksu we wszystkich kolumnach innych niż klucz podstawowy, którego używasz do wykonywania zapytań w tabeli, uporządkowanie tych kolumn od najczęściej używanych do najmniej może zapewnić lepszą wydajność we wszystkich operacjach CRUD niż jeden indeks na kolumnę.

Z drugiej strony, posiadanie tabeli bez indeksu w kolumnach, które są używane do wykonywania zapytań, jak wszyscy wiemy, prowadzi do słabej wydajności przy SELECTach.

Również wydajność indeksu zależy czasami od typu kolumny; indeksy w kolumnach INT pokazują najlepszą możliwą wydajność, ale indeksy w VARCHAR, DATE lub DECIMAL (jeśli ma to sens) nie są tak wydajne. Ta uwaga może nawet prowadzić do przeprojektowania tabel, do których należy uzyskać dostęp z najlepszą możliwą wydajnością.

Dlatego indeksowanie jest zawsze delikatną decyzją, ponieważ zbyt duże indeksowanie może być równie złe, jak zbyt małe, a typ danych kolumn do indeksowania ma duży wpływ na ostateczny wynik.

Zła praktyka nr 8: Złe konwencje nazewnictwa

To jest coś, z czym programiści zawsze borykają się w obliczu istniejącej bazy danych: zrozumienie, jakie informacje są w niej przechowywane przez nazwy tabel i kolumn, ponieważ często nie ma innego sposobu.

Nazwa tabeli musi opisywać encję, którą zawiera, a nazwa każdej kolumny musi opisywać informacje, które reprezentuje. Jest to łatwe, ale zaczyna się komplikować, gdy tabele muszą być ze sobą powiązane. Nazwy zaczynają być bałaganiarskie i, co gorsza, jeśli są mylące konwencje nazewnictwa z nielogicznymi normami (np. „Nazwa kolumny musi mieć 8 znaków lub mniej”). Ostateczną konsekwencją jest to, że baza danych staje się nieczytelna.

Dlatego konwencja nazewnictwa jest zawsze konieczna, jeśli baza danych ma trwać i ewoluować wraz z obsługiwaną aplikacją. Oto kilka wskazówek, jak ustanowić zwięzłą, prostą i czytelną:

• Brak ograniczeń rozmiaru nazwy tabeli lub kolumny. Lepiej mieć opisową nazwę niż akronim, którego nikt nie pamięta ani nie rozumie.
• Nazwy, które są równe, mają to samo znaczenie. Unikaj posiadania pól o tej samej nazwie, ale o różnych typach lub znaczeniach; prędzej czy później będzie to mylące.
• O ile nie jest to konieczne, nie bądź zbędny. Na przykład w tabeli „Item” nie ma potrzeby umieszczania kolumn takich jak „ItemName”, „PriceOfItem” lub podobnych nazw; Wystarczy „Nazwa” i „Cena”.
• Uważaj na zastrzeżone słowa DBE. Jeśli kolumna ma nosić nazwę „Indeks”, co jest słowem zastrzeżonym SQL, spróbuj użyć innego, np. „Numer indeksu”.
• Jeśli trzymasz się prostej reguły klucza podstawowego (pojedyncza liczba całkowita generowana automatycznie), nazwij ją „Id” w każdej tabeli.
• Jeśli dołączasz do innej tabeli, zdefiniuj wymagany klucz obcy jako liczbę całkowitą o nazwie „Id”, po której następuje nazwa połączonej tabeli (np. IdItem).
• Jeśli nazywasz ograniczenia, użyj przedrostka opisującego ograniczenie (np. „PK” lub „FK”), po którym następuje nazwa tabeli lub tabel, których dotyczy. Oczywiście oszczędne używanie podkreśleń („_”) pomaga uczynić rzeczy bardziej czytelnymi.
• Aby nazwać indeksy, użyj przedrostka „IDX”, po którym następuje nazwa tabeli i kolumna lub kolumny indeksu. Użyj również „UNIKALNY” jako prefiksu lub sufiksu, jeśli indeks jest unikalny i w razie potrzeby podkreśl.

W Internecie istnieje wiele wskazówek dotyczących nazewnictwa baz danych, które rzucą więcej światła na ten bardzo ważny aspekt projektowania baz danych, ale dzięki tym podstawowym można przynajmniej uzyskać dostęp do czytelnej bazy danych. To, co jest tutaj ważne, to nie rozmiar ani złożoność wytycznych dotyczących nazewnictwa, ale konsekwencja w ich przestrzeganiu!

Kilka uwag końcowych

Projektowanie baz danych to połączenie wiedzy i doświadczenia; branża oprogramowania bardzo się rozwinęła od samego początku. Na szczęście dostępna jest wystarczająca wiedza, aby pomóc projektantom baz danych osiągnąć najlepsze wyniki.

W całym Internecie istnieją dobre wytyczne dotyczące projektowania baz danych, a także złe praktyki i rzeczy, których należy unikać w projektowaniu baz danych. Po prostu wybierz i trzymaj się tego.

I nie zapominaj, że uczysz się tylko poprzez eksperymenty, błędy i sukcesy, więc śmiało zacznij już teraz.