Колко важни са справочните таблици?

Отговорът зависи малко дали сте ограничени до безплатен софтуер като PostGreSQL (не напълно съвместим с SQL) или ако мислите за SQL (т.е. съвместим с SQL) и големи бази данни.

В SQL съвместим, Отворена архитектура бази данни, където има много приложения, използващи една база данни, и много потребители, използващи различни инструменти за отчети (не само приложенията) за достъп до данните, стандартите, нормализацията и изискванията за отворена архитектура са важни.

Въпреки хората, които се опитват да променят определението за "нормализация" и т.н., за да отговарят на тяхната постоянно променяща се цел, нормализирането (науката) не се е променило.

• ако имате стойности за данни като {Open; Closed; etc } се повтаря в таблици с данни, тоест дублиране на данни , проста грешка при нормализиране:ако промените тези стойности, може да се наложи да актуализирате милиони редове, което е много ограничен дизайн.

  • Такива стойности трябва да бъдат нормализирани в справочна или справочна таблица с кратък CHAR(2) PK:

    O  Open
    C  Closed
    U  [NotKnown]
    

  • Стойностите на данните {Open;Closed;etc } вече не се дублират в милионите редове. Освен това спестява място.

  • втората точка е лесната промяна, ако Closed бяха променени на Expired , отново трябва да се промени един ред и това се отразява в цялата база данни; докато в ненормализираните файлове милиони редове трябва да се променят.

  • Добавяне на нови стойности на данни , напр. (H,HalfOpen ) тогава е просто въпрос на вмъкване на един ред.

• в Отворена архитектура термини, таблицата за търсене е обикновена таблица. Той съществува в каталога [SQL съвместим]; стига FOREIGN KEY връзката е дефинирана, инструментът за отчет може също да намери това.

• ENUM е не-SQL, не го използвайте. В SQL "enum" е справочна таблица.

• Следващата точка е свързана със значимостта на ключа.

  • Ако ключът е безсмислен за потребителя, добре, използвайте {INT;BIGINT;GUID;etc } или каквото е подходящо; не ги номерирайте постепенно; позволете „пропуски“.
  • Но ако ключът е значим за потребителя, не използвайте безсмислено число, използвайте смислен релационен ключ.

• Сега някои хора ще влязат в допирателни по отношение на постоянството на PKs. Това е отделна точка. Да, разбира се, винаги използвайте стабилна стойност за PK (не е „неизменяем“, защото такова нещо не съществува и генерираният от системата ключ не осигурява уникалност на редове).

  • {M,F } е малко вероятно да се променят

  • ако сте използвали {0,1,2,4,6 }, добре, не го променяйте, защо бихте искали. Тези стойности трябваше да бъдат безсмислени, запомнете, трябва да се промени само смислен ключ.

  • ако все пак използвате смислени ключове, използвайте кратки азбучни кодове, които разработчиците могат лесно да разберат (и да изведат дългото описание от). Ще оцените това само когато кодирате SELECT и осъзнайте, че не е нужно да JOINs всяка таблица за търсене. Оценяват го и опитни потребители.

• Тъй като PKs са стабилни, особено в справочните таблици, можете безопасно да кодирате:

  WHERE status_code = 'O' -- Open

  Не е нужно JOINs Таблицата за търсене и получете стойност на данни Open , като разработчик, вие трябва да знаете какво означават Lookup PKs.

И накрая, ако базата данни е голяма и поддържа функции BI или DSS или OLAP в допълнение към OLTP (както могат правилно нормализираните бази данни), тогава таблицата за търсене всъщност е измерение или вектор в Dimension-Fact анализи. Ако го нямаше, тогава би трябвало да бъде добавен, за да отговори на изискванията на този софтуер, преди да могат да се монтират подобни анализи.

• Ако направите това със своята база данни от самото начало, няма да се налага да я надграждате (и кода) по-късно.

Вашият пример

SQL е език на ниско ниво, поради което е тромав, особено когато става въпрос за JOINs . Това е, което имаме, така че трябва просто да приемем тежестта и да се справим с нея. Вашият примерен код е добре. Но по-простите форми могат да направят същото.

Инструмент за отчет ще генерира:

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

Друг пример

За банкови системи, където използваме кратки кодове, които са смислени (тъй като са смислени, ние не ги променяме със сезоните, ние просто добавяме към тях), като се дава таблица за справка като (внимателно подбрани, подобно на ISO кодовете на държави) :

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

Код като този е често срещан:

WHERE InstrumentTypeCode LIKE "Eq%"

И потребителите на графичния интерфейс ще изберат стойността от падащо меню, което показва
{Equity/Common Share;Over The Counter },
не {Eq;OTC;OF }, а не {M;F;U }.
Без таблица за справка не можете да направите това нито в приложенията, нито в инструмента за отчети.