Qual a importância das tabelas de pesquisa?

• 
  se você tiver valores de dados como {Open; Closed; etc } repetido nas tabelas de dados, que é duplicação de dados , um simples erro de normalização:se esses valores forem alterados, talvez seja necessário atualizar milhões de linhas, o que é um design muito limitado.
  
  • 
    Esses valores devem ser normalizados em uma tabela de referência ou pesquisa, com um curto CHAR(2) PK:
    

    O  Open
    C  Closed
    U  [NotKnown]
    

  • 
    Os valores de dados {Open;Closed;etc } não são mais duplicados nos milhões de linhas. Também economiza espaço.
    
  • 
    o segundo ponto é a facilidade de mudança, se Closed foram alterados para Expired , novamente, uma linha precisa ser alterada e isso se reflete em todo o banco de dados; enquanto nos arquivos não normalizados, milhões de linhas precisam ser alteradas.
    
  • 
    Adicionando novos valores de dados , por exemplo. (H,HalfOpen ) é simplesmente uma questão de inserir uma linha.
    
• 
  in Arquitetura Aberta termos, a tabela Lookup é uma tabela comum. Ele existe no catálogo [compatível com SQL]; contanto que a FOREIGN KEY relação foi definida, a ferramenta de relatório também pode encontrá-la.
  
• 
  ENUM é um não-SQL, não o use. No SQL, o "enum" é uma tabela de pesquisa.
  
• 
  O próximo ponto diz respeito ao significado da chave.
  
  • Se a chave não tiver sentido para o usuário, tudo bem, use um {INT;BIGINT;GUID;etc } ou o que for adequado; não os numere de forma incremental; permitir "lacunas".
  • Mas se a chave for significativa para o usuário, não use um número sem significado, use uma chave relacional significativa.
• 
  Agora algumas pessoas entrarão na tangente em relação à permanência dos PKs. Isso é um ponto à parte. Sim, claro, sempre use um valor estável para um PK (não "imutável", porque tal coisa não existe e uma chave gerada pelo sistema não fornece exclusividade de linha).
  
  • 
    {M,F } é improvável que mude
    
  • 
    se você usou {0,1,2,4,6 }, bem, não mude, por que você quer. Esses valores deveriam ser sem sentido, lembre-se, apenas uma chave significativa precisa ser alterada.
    
  • 
    se você usar chaves significativas, use códigos alfabéticos curtos, que os desenvolvedores possam entender prontamente (e inferir a descrição longa). Você apreciará isso apenas quando codificar SELECT e perceba que você não precisa JOIN cada tabela de pesquisa. Usuários avançados também, apreciá-lo.
    
• 
  Como os PKs são estáveis, principalmente em tabelas de pesquisa, você pode codificar com segurança:
  
  WHERE status_code = 'O' -- Open
  
  Você não precisa JOIN a tabela de pesquisa e obtenha o valor de dados Open , como desenvolvedor, você deve saber o que significam os PKs de pesquisa.
  

• Se você fizer isso em seu banco de dados desde o início, não precisará atualizá-lo (e o código) posteriormente.

Seu exemplo

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

Outro exemplo

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