Quelle est l'importance des tables de recherche ?

La réponse dépend un peu si vous êtes limité à des logiciels gratuits tels que PostGreSQL (pas entièrement conforme à SQL), ou si vous pensez à SQL (c'est-à-dire conforme à SQL) et à de grandes bases de données.

En conformité SQL, Architecture ouverte les bases de données, où de nombreuses applications utilisent une base de données et de nombreux utilisateurs utilisant différents outils de rapport (pas seulement les applications) pour accéder aux données, les normes, la normalisation et les exigences d'architecture ouverte sont importantes.

Malgré les personnes qui tentent de changer la définition de "normalisation", etc. pour répondre à leur objectif en constante évolution, la normalisation (la science) n'a pas changé.

• si vous avez des valeurs de données comme {Open; Closed; etc } répété dans les tables de données, c'est-à-dire la duplication des données , une simple erreur de normalisation :si ces valeurs changent, vous devrez peut-être mettre à jour des millions de lignes, ce qui est une conception très limitée.

  • Ces valeurs doivent être normalisées dans une table de référence ou de recherche, avec un court CHAR(2) PC :

    O  Open
    C  Closed
    U  [NotKnown]
    

  • Les valeurs de données {Open;Closed;etc } ne sont plus dupliqués dans les millions de lignes. Cela permet également d'économiser de l'espace.

  • le deuxième point est la facilité de changement, si Closed ont été remplacés par Expired , encore une fois, une ligne doit être modifiée, et cela se reflète dans l'ensemble de la base de données ; alors que dans les fichiers non normalisés, des millions de lignes doivent être modifiées.

  • Ajout de nouvelles valeurs de données , par exemple. (H,HalfOpen ) consiste alors simplement à insérer une ligne.

• dans Architecture ouverte termes, la table de recherche est une table ordinaire. Il existe dans le catalogue [conforme SQL]; tant que la FOREIGN KEY relation a été définie, l'outil de rapport peut également la trouver.

• ENUM est un Non-SQL, ne l'utilisez pas. En SQL, "l'énumération" est une table de recherche.

• Le point suivant concerne la signification de la clé.

  • Si la clé n'a pas de sens pour l'utilisateur, très bien, utilisez un {INT;BIGINT;GUID;etc } ou tout ce qui convient ; ne les numérotez pas progressivement ; autoriser les "espaces".
  • Mais si la clé est significative pour l'utilisateur, n'utilisez pas un nombre sans signification, utilisez une clé relationnelle significative.

• Maintenant, certaines personnes entreront dans des tangentes concernant la permanence des PK. C'est un point distinct. Oui, bien sûr, utilisez toujours une valeur stable pour un PK (non "immuable", car rien de tel n'existe et une clé générée par le système ne fournit pas l'unicité des lignes).

  • {M,F } sont peu susceptibles de changer

  • si vous avez utilisé {0,1,2,4,6 }, eh bien ne le changez pas, pourquoi voudriez-vous. Ces valeurs étaient censées n'avoir aucun sens, rappelez-vous, seule une clé significative doit être modifiée.

  • si vous utilisez des clés significatives, utilisez des codes alphabétiques courts, que les développeurs peuvent facilement comprendre (et en déduire la longue description). Vous ne l'apprécierez que lorsque vous codez SELECT et réalisez que vous n'êtes pas obligé de JOIN chaque table de consultation. Les utilisateurs expérimentés l'apprécient également.

• Étant donné que les PK sont stables, en particulier dans les tables de recherche, vous pouvez coder en toute sécurité :

  WHERE status_code = 'O' -- Open

  Vous n'êtes pas obligé JOIN la table de recherche et obtenir le valeur de données Open , en tant que développeur, vous êtes censé savoir ce que signifient les Lookup PKs.

Enfin, si la base de données était volumineuse et prenait en charge les fonctions BI ou DSS ou OLAP en plus d'OLTP (comme le peuvent les bases de données normalisées), alors la table de recherche est en fait une dimension ou un vecteur, dans Dimension-Fact analyses. Si ce n'était pas le cas, il faudrait alors l'ajouter pour satisfaire aux exigences de ce logiciel, avant que de telles analyses puissent être montées.

• Si vous procédez ainsi à votre base de données dès le départ, vous n'aurez pas à la mettre à niveau (ainsi que le code) ultérieurement.

Votre exemple

SQL est un langage de bas niveau, il est donc lourd, surtout en ce qui concerne les JOINs . C'est ce que nous avons, alors nous devons simplement accepter l'encombrement et y faire face. Votre exemple de code est bien. Mais des formulaires plus simples peuvent faire la même chose.

Un outil de rapport générerait :

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

Un autre exemple

Pour les systèmes bancaires, où nous utilisons des codes abrégés significatifs (puisqu'ils sont significatifs, nous ne les modifions pas avec les saisons, nous les ajoutons simplement), étant donné une table de recherche telle que (choisi avec soin, similaire aux codes de pays ISO) :

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

Un code comme celui-ci est courant :

WHERE InstrumentTypeCode LIKE "Eq%"

Et les utilisateurs de l'interface graphique choisiraient la valeur dans une liste déroulante qui affiche
{Equity/Common Share;Over The Counter },
pas {Eq;OTC;OF }, pas {M;F;U }.
Sans table de recherche, vous ne pouvez pas faire cela, ni dans les applications, ni dans l'outil de rapport.