Jak ważne są tabele przeglądowe?

Odpowiedź zależy trochę, jeśli jesteś ograniczony do darmowego oprogramowania, takiego jak PostGreSQL (nie w pełni zgodny z SQL) lub jeśli myślisz o SQL (tj. zgodnym z SQL) i dużych bazach danych.

W zgodności z SQL Otwarta architektura bazy danych, w których wiele aplikacji korzysta z jednej bazy danych, a wielu użytkowników korzysta z różnych narzędzi raportowania (nie tylko do aplikacji) w celu uzyskania dostępu do danych, standardów, normalizacji i wymagań dotyczących otwartej architektury.

Pomimo ludzi, którzy próbują zmienić definicję „normalizacji” itp., aby dopasować się do ich ciągle zmieniającego się celu, Normalizacja (nauka) nie uległa zmianie.

• jeśli masz wartości danych takie jak {Open; Closed; etc } powtórzone w tabelach danych, czyli duplikacja danych , prosty błąd normalizacji:jeśli te wartości się zmienią, być może będziesz musiał zaktualizować miliony wierszy, co jest bardzo ograniczonym projektem.

  • Takie wartości powinny być znormalizowane do tabeli referencyjnej lub wyszukiwania, z krótkim CHAR(2) PK:

    O  Open
    C  Closed
    U  [NotKnown]
    

  • wartości danych {Open;Closed;etc } nie są już duplikowane w milionach wierszy. Oszczędza również miejsce.

  • drugi punkt to łatwość zmiany, jeśli Closed zostały zmienione na Expired , ponownie należy zmienić jeden wiersz, co znajduje odzwierciedlenie w całej bazie danych; podczas gdy w nieznormalizowanych plikach trzeba zmienić miliony wierszy.

  • Dodawanie nowych wartości danych , np. (H,HalfOpen ) to po prostu kwestia wstawienia jednego wiersza.

• w Otwarta architektura terminów, Tabela przeglądowa jest zwykłą tabelą. Istnieje w katalogu [zgodnym z SQL]; tak długo, jak FOREIGN KEY relacja została zdefiniowana, narzędzie raportowania również może to znaleźć.

• ENUM jest językiem innym niż SQL, nie używaj go. W SQL "enum" jest tabelą przeglądową.

• Następny punkt dotyczy znaczenia klucza.

  • Jeśli klucz nie ma znaczenia dla użytkownika, w porządku, użyj {INT;BIGINT;GUID;etc } lub cokolwiek jest odpowiednie; nie numeruj ich przyrostowo; zezwól na „luki”.
  • Ale jeśli klucz ma znaczenie dla użytkownika, nie używaj bezsensownej liczby, użyj znaczącego klucza relacyjnego.

• Teraz niektórzy ludzie wejdą w styczne dotyczące trwałości PK. To osobny punkt. Tak, oczywiście zawsze używaj stabilnej wartości PK (nie „niezmienne”, ponieważ coś takiego nie istnieje, a klucz generowany przez system nie zapewnia unikalności wiersza).

  • {M,F } raczej się nie zmieni

  • jeśli użyłeś {0,1,2,4,6 }, nie zmieniaj tego, dlaczego miałbyś chcieć. Te wartości miały być bez znaczenia, pamiętaj, tylko znaczący klucz należy zmienić.

  • jeśli używasz znaczących kluczy, użyj krótkich kodów alfabetycznych, które programiści mogą łatwo zrozumieć (i wywnioskować z nich długi opis). Docenisz to tylko wtedy, gdy zakodujesz SELECT i zdaj sobie sprawę, że nie musisz JOINs każdą tabelę przeglądową. Doceń to także zaawansowani użytkownicy.

• Ponieważ PK są stabilne, szczególnie w tabelach przeglądowych, możesz bezpiecznie kodować:

  WHERE status_code = 'O' -- Open

  Nie musisz JOINs tabela przeglądowa i uzyskaj wartość danych Open , jako programista powinieneś wiedzieć, co oznaczają instrukcje wyszukiwania PK.

Wreszcie, jeśli baza danych była duża i oprócz OLTP obsługiwała funkcje BI, DSS lub OLAP (tak jak mogą to robić prawidłowo znormalizowane bazy danych), wówczas tabela przeglądowa jest w rzeczywistości wymiarem lub wektorem w fakcie wymiaru ćwiczenie. Gdyby go tam nie było, musiałby zostać dodany, aby spełnić wymagania tego oprogramowania, zanim takie analizy będą mogły zostać zamontowane.

• Jeśli zrobisz to w swojej bazie danych od samego początku, nie będziesz musiał później uaktualniać jej (i kodu).

Twój przykład

SQL jest językiem niskiego poziomu, dlatego jest kłopotliwy, zwłaszcza jeśli chodzi o JOINs . To właśnie mamy, więc musimy po prostu zaakceptować obciążenie i sobie z tym poradzić. Twój przykładowy kod jest w porządku. Ale prostsze formularze mogą zrobić to samo.

Narzędzie raportowania wygeneruje:

SELECT p.*,
       s.name
    FROM posts  p, 
         status s
    WHERE p.status_id = s.status_id 
    AND   p.status_id = 'O'

Inny przykład

W przypadku systemów bankowych, w których używamy krótkich kodów, które mają znaczenie (ponieważ mają znaczenie, nie zmieniamy ich wraz z porami roku, po prostu je dodajemy), biorąc pod uwagę tabelę przeglądową, taką jak (starannie dobrane, podobne do kodów krajów ISO) :

Eq   Equity
EqCS Equity/Common Share
OTC  OverTheCounter
OF   OTC/Future

Kod taki jak ten jest powszechny:

WHERE InstrumentTypeCode LIKE "Eq%"

A użytkownicy GUI wybraliby wartość z listy rozwijanej, która wyświetla
{Equity/Common Share;Over The Counter },
nie {Eq;OTC;OF }, a nie {M;F;U }.
Bez tabeli przeglądowej nie możesz tego zrobić ani w aplikacjach, ani w narzędziu do raportowania.