Jak důležité jsou vyhledávací tabulky?

Odpověď trochu závisí, zda jste omezeni na freeware, jako je PostGreSQL (ne plně kompatibilní s SQL), nebo pokud uvažujete o SQL (tj. kompatibilní s SQL) a velkých databázích.

V souladu s SQL, Otevřená architektura databáze, kde existuje mnoho aplikací využívajících jednu databázi a mnoho uživatelů používajících různé nástroje pro vytváření sestav (nejen aplikace) pro přístup k datům, jsou důležité požadavky na standardy, normalizaci a otevřenou architekturu.

Navzdory lidem, kteří se pokoušejí změnit definici „normalizace“ atd., aby vyhovovala jejich neustále se měnícímu účelu, se normalizace (věda) nezměnila.

• pokud máte hodnoty dat například {Open; Closed; etc } se opakuje v datových tabulkách, to je duplikace dat , jednoduchá chyba normalizace:pokud se tyto hodnoty změní, možná budete muset aktualizovat miliony řádků, což je velmi omezený design.

  • Takové hodnoty by měly být normalizovány do referenční nebo vyhledávací tabulky s krátkým CHAR(2) PK:

    O  Open
    C  Closed
    U  [NotKnown]
    

  • hodnoty dat {Open;Closed;etc } již nejsou duplikovány v milionech řádků. To také šetří místo.

  • druhým bodem je snadnost změny, pokud je Closed byly změněny na Expired , opět je potřeba změnit jeden řádek a to se projeví v celé databázi; zatímco v nenormalizovaných souborech je třeba změnit miliony řádků.

  • Přidávání nových hodnot dat , např. (H,HalfOpen ) je pak jednoduše otázkou vložení jednoho řádku.

• v Otevřená architektura Vyhledávací tabulka je běžná tabulka. Existuje v katalogu [vyhovující SQL]; tak dlouho jako FOREIGN KEY byl definován vztah, nástroj pro vytváření sestav to dokáže najít také.

• ENUM je Non-SQL, nepoužívejte jej. V SQL je "enum" vyhledávací tabulka.

• Další bod se týká smysluplnosti klíče.

  • Pokud je klíč pro uživatele bezvýznamný, v pořádku, použijte {INT;BIGINT;GUID;etc } nebo cokoliv je vhodné; nečíslujte je postupně; povolit „mezery“.
  • Pokud je však klíč pro uživatele smysluplný, nepoužívejte nesmyslné číslo, použijte smysluplný relační klíč.

• Nyní se někteří lidé dostanou k tangentám ohledně stálosti PK. To je samostatný bod. Ano, samozřejmě, vždy používejte stabilní hodnotu pro PK (není "neměnný", protože nic takového neexistuje a systémem vygenerovaný klíč nezaručuje jedinečnost řádku).

  • {M,F } se pravděpodobně nezmění

  • pokud jste použili {0,1,2,4,6 }, tak to neměň, proč bys to chtěl. Tyto hodnoty měly být bezvýznamné, pamatujte, že je třeba změnit pouze smysluplný klíč.

  • pokud používáte smysluplné klíče, používejte krátké abecední kódy, kterým vývojáři snadno porozumí (a odvodí z nich dlouhý popis). To oceníte pouze tehdy, když zakódujete SELECT a uvědomte si, že se nemusíte JOIN každá vyhledávací tabulka. Také zkušení uživatelé to ocení.

• Protože PK jsou stabilní, zejména ve vyhledávacích tabulkách, můžete bezpečně kódovat:

  WHERE status_code = 'O' -- Open

  Nemusíte JOIN vyhledávací tabulku a získejte datová hodnota Open , jako vývojář byste měli vědět, co vyhledávací PK znamenají.

Konečně, pokud byla databáze velká a kromě OLTP podporovala funkce BI nebo DSS nebo OLAP (jak to umí správně normalizované databáze), pak je vyhledávací tabulka ve skutečnosti dimenzí nebo vektorem v Dimension-Fact analýzy. Pokud by tam nebyl, musel by být přidán, aby byly splněny požadavky tohoto softwaru, než bude možné takové analýzy připojit.

• Pokud to se svou databází provedete od začátku, nebudete ji (a kód) později muset upgradovat.

Váš příklad

SQL je nízkoúrovňový jazyk, takže je těžkopádný, zvláště pokud jde o JOINs . To je to, co máme, takže musíme jen přijmout břemeno a vypořádat se s tím. Váš ukázkový kód je v pořádku. Jednodušší formuláře však dokážou totéž.

Nástroj sestavy by vygeneroval:

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

Další příklad

Pro bankovní systémy, kde používáme krátké kódy, které jsou smysluplné (protože jsou smysluplné, neměníme je s ročními obdobími, pouze je přidáváme), máme k dispozici vyhledávací tabulku, jako je (pečlivě zvolená, podobně jako ISO kódy zemí) :

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

Běžný je tento kód:

WHERE InstrumentTypeCode LIKE "Eq%"

A uživatelé GUI by si vybrali hodnotu z rozbalovací nabídky, která zobrazuje
{Equity/Common Share;Over The Counter },
nikoli {Eq;OTC;OF }, nikoli {M;F;U }.
Bez vyhledávací tabulky to nelze provést ani v aplikacích, ani v nástroji pro vytváření přehledů.