Czy nadal potrzebujesz indeksowania po normalizacji bazy danych?

Czy po dobrej normalizacji nadal musisz indeksować tabelę? Jak to wpłynie na wydajność? Czy po dobrej normalizacji wpłynie to w jakiś sposób na wydajność?

Które kolumny są zwykle indeksowane, jeśli masz już klucz podstawowy i klucz obcy?

Wygląda na to, że normalizacja bazy danych już jest skuteczna. Mogłem jednak pominąć wpływ indeksowania na bazę danych. Czy jest to skuteczne tylko wtedy, gdy używane są zapytania? Jak to działa / działa i ulepsza bazę danych?

Tak. W rzeczywistości bardzo dobrze może być konieczne zwrócenie większej uwagi na swoje indeksy. Normalizacja polega na optymalnym przechowywaniu . Jest to często sprzeczne z prędkością pobierania , ponieważ stosowane są bardziej złożone zapytania ze skomplikowanymi połączeniami. Czasami osoby utrzymujące bazy danych, które wymagają szybkich prędkości pobierania, zdenormalizują lub uporządkują swoje dane w nieco mniej znormalizowanych strukturach, aby ułatwić wyszukiwanie.

Myślę, że źle zrozumiałeś, co robi indeksowanie wydajności bazy danych.

Indeks pomaga bazie danych znaleźć wiersze. Indeksy to wyspecjalizowane struktury danych, które w zamian za dodatkowe miejsce na dysku i pewną wydajność podczas wstawiania i aktualizowania pomagają silnikowi bazy danych w dopasowaniu wierszy.

Ponieważ wymagają one dodatkowej przestrzeni i kosztują (odrobinę) wydajności w celu zapewnienia ich aktualności, jako projektant bazy danych musisz jawnie tworzyć indeksy, aby dopasować je do wzorców aplikacji i zapytań.

Indeksy są prostopadłe do normalizacji bazy danych.

Tak po normalizacji nadal potrzebujesz indeksowania.

Tabele, z którymi pracujesz, korzystają tak samo jak tabele, które posiadałeś przed normalizacją. W rzeczywistości same są takie same: stoły.

Należy jednak wziąć pod uwagę jedną rzecz: indeksy pomagają szybciej odnaleźć dane. Normalizacja projektu bazy danych jest zawsze dobra, ale czasami ze względu na wydajność należy zdormalizować implementację. Ale dzieje się tak tylko w poszczególnych przypadkach.

Tak.

Indeksy to metoda przyspieszenia wyszukiwania danych. Niektóre zapytania są oparte na kluczach podstawowych, które zwykle są domyślnie indeksowane przez silnik bazy danych, ale inne zapytania prawdopodobnie wykorzystują inne kolumny. Często niektóre zapytania wyszukują według kolumn, które nawet nie są unikalne, a zatem nie mogą stać się kluczami głównymi po żadnej normalizacji. Prawdopodobnie będziesz musiał zaindeksować takie kolumny.

Jest tylko jeden sposób, aby dowiedzieć się, które indeksy utworzyć. Podjąć wszelkie zapytania w aplikacji, znaleźć reprezentatywnego przykładu parametry dla nich i mieć silnik bazy danych pokazują swoje plany zapytań (wszystkie silniki bazodanowe mają EXPLAIN, EXPLAIN QUERY PLANlub podobne polecenie; nazywa się to różnie w różnych silników) i test jak długo oni podjąć. Następnie twórz indeksy, które przyspieszają te, które były powolne. I nie zapomnij ponownie upuścić indeksów, które wypróbowałeś, ale nie pomogłeś uniknąć marnowania zasobów.

Indeksy są na ogół potrzebne we wszystkich tabelach oprócz najmniejszych. Prawie każdy klucz obcy powinien zostać zindeksowany, a samo skonfigurowanie FK nie oznacza, że ​​masz indeks (przynajmniej nie w niektórych bazach danych, sprawdź dokumentację db). Pola, do których często dołączasz lub których używasz, w których klauzule powinny być indeksowane, jeśli są to korzystne (potrzebujesz pewnej zmienności danych, aby na przykład booleanie nie skorzystali) i te, w których można indeksować.

Jednak każdy indeks spowalnia wstawianie \ aktualizacje \ usuwa podczas przyspieszania zaznaczeń, więc ostrożnie wybieraj swoje indeksy.

Indeksy mają kluczowe znaczenie dla akceptowalnej wydajności w bazie danych.

W przypadku trzeciej normalnej formy zdecydowanie potrzebujesz indeksów na wszystkich kluczach podstawowych.

To, czy potrzebujesz innych indeksów, zależy od sposobu korzystania z bazy danych. Na przykład, jeśli regularnie wyszukujesz klientów w określonym kodzie pocztowym, dobrym pomysłem może być indeksowanie kolumny z kodem pocztowym w tabeli klientów.