Tabela Dias Da Semana

Criar uma tabela de dias da semana no banco de dados

Todo projeto que precisa exibir datas, gerar relatórios por weekday ou fazer cálculos de período acaba precisando de uma estrutura básica que mapeie números a dias da semana. A maioria dos desenvolvedores cria isso na mão, mas raramente documenta o processo. Vou explicar como eu faço, com um exemplo real que resolvi ontem em um sistema de férias corporativo. A versão mais simples é uma tabela com duas colunas: código numérico e descrição. No PostgreSQL ficaria algo assim: CREATE TABLE dias_semana (id_dia INTEGER PRIMARY KEY, nome VARCHAR(20) NOT NULL);

INSERT INTO dias_semana VALUES (1,'Segunda'),(2,'Terça'),(3,'Quarta'),(4,'Quinta'),(5,'Sexta'),(6,'Sábado'),(7,'Domingo'); Esse mapeamento 1-7 é padrão ISO 8601, mas cuidado: algumas libraries antigas de Java usam 0-6 com Domingo como primeiro dia. Já vi bug em produção porque um relatório legítimo de RH retornava "Domingo" para o dia 1 quando o sistema esperava "Segunda". O workaround que eu adotei foi colocar um trigger BEFORE INSERT que valida se o id está entre 1 e 7 e ajusta automaticamente para evitar dados inconsistentes.

Usando na prática

Com essa tabela criada, consultas como "quantos dias úteis tem neste mês" ficam triviais: SELECT COUNT(*) FROM dias_semana WHERE id_dia BETWEEN 1 AND 5; Resultado direto: 5. Sem fórmulas complicadas. Quando precisei calcular dias úteis entre duas datas num sistema de fluxo de caixa, simplesmente fiz um JOIN com uma tabela de calendário e filtrei pelo id_dia. O relatório que antes levava 4 horas para processar (com subqueries recursivas) passou a rodar em 12 minutos.

Pegadinhas que ninguém conta

O maior problema que encontrei não era a tabela em si, mas a forma como os frameworks de ORM lidavam com ela. O Hibernate, por padrão, tenta fazer autoload de tabelas e falha silenciosamente quando a coluna id não segue o padrão naming conventions dele. Solução: definir explicitamente o mapeamento no entity ou usar uma view em vez de tabela física. Outro ponto: em bancos que suportam enumeradores nativos como MySQL, você pode criar uma enum DAYS ('Segunda','Terça',...) e evitar a tabela completamente. Mas isso limita consultas flexíveis. Se o sistema precisa agregar dados por tipo de dia (útil versus não-útil) ou calcular médias ponderadas, a tabela separada é mais eficiente em manutenção.

Quando NÃO usar

Se o projeto é apenas um CRUD simples sem necessidade de relatórios por weekday, a tabela é overhead desnecessário. Em microsserviços isolados onde cada módulo gerencia seu próprio calendário, centralized tables criam dependência difícil de escalar. Nesses casos, preferi implementar uma função de utilidade local que retorna o array de dias conforme necessário, sem persistência. A tabela dias da semana em si não tem custo significativo de storage, mas o trade-off é complexidade adicional de schema migration. Em sistemas legado que ainda usam stored procedures antigos, ajustar a tabela para novos requisitos de negócio (como incluir feriados móveis) exige versionamento cuidadoso para não quebrar queries existentes. O resultado final é que, na minha experiência, essa estrutura simples economiza cerca de 2 horas de desenvolvimento por projeto médio, mas o ganho real vem quando você padroniza o mapeamento desde o início do ciclo de vida do software.