Meu colega de trabalho criou uma tabela SQL de 96 colunas

Aqui estamos em 2010, engenheiros de software com 4 ou 5 anos ou experiência, ainda projetando tabelas com 96 colunas de fraturamento.

Eu disse a ele que seria um pesadelo.
Mostrei a ele que precisamos usar ordinais para fazer a interface do MySQL com C #.
Expliquei que as tabelas com mais colunas do que linhas são um cheiro enorme.

Ainda assim, recebo a mensagem "Vai ser mais simples assim".

O que devo fazer?

EDIT *

Esta tabela contém dados de sensores.
Temos o sensor 1 com
Dynamic_D1X
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

Bem, eu finalmente deixei esse emprego. É um sinal quando o outro programador fica escuro durante meses, é outro sinal quando o gerenciamento não percebe que isso é um problema

Talvez ele tenha feito isso por um bom motivo, como performances ou ROI? .

A melhor coisa a fazer é fazer perguntas a ele. Com uma certa quantidade de "por quê", você certamente o fará entender que ele provavelmente está errado por si só (se ele realmente está).

Eu mesmo tive um caso que não está relacionado a performances, mas a um retorno do investimento (ROI). Eu tinha uma tabela contendo objetos que tinham um valor específico para cada hora da semana (168h em uma semana). Tivemos a opção de criar uma tabela ObjectHour que contivesse o valor, mas também uma chave para o Object e o número do dia do número de horas. Mas também tivemos a oportunidade de colocar os 168 valores na linha. Provavelmente gostou do que seu colega fez.

Os desenvolvedores estimaram as duas soluções. A solução simples (168 colunas) era muito mais barata do que sua contrapartida bem projetada. Para exatamente o mesmo resultado para o cliente.

Decidimos optar pela solução simples / mais barata para concentrar nossos esforços em itens mais importantes, como segurança.

Teremos muitas oportunidades para melhorar isso no futuro. O tempo de colocação no mercado era a prioridade para nós na época.

Infelizmente, o desenvolvedor médio ainda pensa nos bancos de dados relacionais como grandes arquivos simples. A única maneira de melhorar é se alguém assumir o comando e liderar pelo exemplo. Recentemente, liderei uma grande reformulação de um esquema importante em nosso banco de dados e segui práticas relacionais comuns. De repente, nossos procedimentos armazenados ficaram mais elegantes e todos os índices adequados pareciam se encaixar como se tivessem nascido para isso. O desenvolvedor orientado pelo ego nunca acreditará em você sem provas.

Algo semelhante foi discutido anteriormente no StackOverflow .

Em geral, ter muitas colunas em uma tabela não significa necessariamente que você está fazendo algo errado, mas definitivamente deve levantar algumas bandeiras vermelhas para que você observe atentamente o design. Às vezes, uma mesa enorme é a escolha certa, mas em muitos casos, outras alternativas fazem mais sentido. Por exemplo, uma opção é dividir o armazenamento em duas tabelas: uma tabela que identifica suas entidades e outra tabela que é efetivamente um armazenamento de chave / valor dos atributos que descrevem essas entidades (para que você possa ter no máximo 96 linhaspara cada entidade). Outros projetos também são possíveis. Converse com seus colegas de equipe e descubra qual solução é melhor, dependendo da normalização dos dados, legibilidade do código e manutenção (insira instruções com 96 atributos a serem preenchidos?), Implicações de desempenho, com que frequência novos atributos (colunas) podem ser adicionados ou alterados, quão escassos os dados são (quantas das 96 colunas serão preenchidas e quantas permanecem NULL?) e implicações nos relatórios. Qualquer desenvolvedor deve ser capaz de justificar razoavelmente suas decisões de design e mostrar que a relação custo / benefício (e sim, toda decisão de design é uma troca) está a seu favor. Sua responsabilidade não é reclamar ou criticar, mas propor alternativas e garantir que elas pensem nessas questões.

É normalizado com 96 colunas? Satisfaz 1, 2, 3 etc NF?

Pode ser que você tenha 96 atributos separados para na entidade.

Caso contrário, faça-o ler Joe Celko no Simple Talk

Depende completamente.

Projetos de banco de dados normalizados / não normalizados têm suas vantagens e desvantagens.

Meu primeiro design de banco de dados foi uma coisa normalizada de beleza. Era flexível e extensível. Também foi uma PITA incrível para qualquer pessoa, exceto eu, lidar com o nível de código, e foi uma PITA suave para mim.

Minha próxima tentativa foi uma estrutura plana e foi (a) muito mais rápida e (b) muito mais fácil de codificar. E não será uma tarefa enorme normalizar mais tarde.

Portanto, pode ser um cheiro, mas algum outro design de banco de dados terá sua própria variedade deliciosa de cheiros.

Faça com que ele leia este artigo sobre dívida técnica . Se ele ainda decidir mantê-lo assim, pelo menos você ofereceu uma opinião construtiva.

Olhando para o post (editado), fica claro que esta é uma tabela desnormalizada. O que você deveria fazer? A meu ver, você tem algumas opções:

1. Grite com seu colega de trabalho para aprender como fazer seu trabalho. É improvável que seja produtivo, mas provavelmente convencerá outros colegas de trabalho a não mexer com você. A reputação de maníaco gritante pode ser útil (não me pergunte como eu sei).
2. Grite com o chefe que o colega de trabalho é um idiota. Preveja um desastre e trabalhe ativamente para sabotar o projeto. Culpe tudo no design do banco de dados produzido por um colega de trabalho incompetente. Pode levar diretamente a ...
3. Sair. Melhor se a ideia for sua, mas o nº 2 pode levar à demissão involuntária. Tente não arranhar os joelhos no asfalto / concreto / cascalho se arremessado da janela pelo chefe enfurecido e / ou colegas de trabalho. (Observe que o estudo anterior é importante aqui. Suas chances de sobrevivência diminuem acentuadamente se o escritório dos chefes estiver acima do térreo e você se sentir impelido pela janela. Planeje com antecedência !! )
4. Beba muito - ou, mude para a Califórnia e acenda (assumindo que a prop. 19 (ou o que seja)) passa. Nada como alguns disparos e uma doobie para melhorar a visão de alguém sobre os colegas de trabalho (ou pelo menos ouvi dizer). (Anúncio de serviço público: KIDS! Essas pessoas são profissionais! NÃO tente fazer isso em casa!)

Compartilhe e curta.

Eu vou falar mal aqui e supor que ele vai cortar e colar muito código para trabalhar com esta tabela "Nova".

Nesse caso, você provavelmente não terá uma dívida técnica adicional. Ele acabou de dividir sua parte da dívida técnica e pode estar a caminho de algum tipo de grande unificação das coisas.

Se ele tem alguma metodologia testada e verdadeira que requer uma coisa de 96 colunas, considere os benefícios reais de fazê-lo de uma maneira diferente neste caso específico. Se não houver, dê a ele o benefício da dúvida, mas lembre-o de que na próxima vez em que você quiser participar da fase de planejamento, na próxima vez em que ele fizer o que todos consideramos uma atitude bastante idiota.

Depende totalmente dos casos de uso do aplicativo que acessará o esquema, que parte dos dados é necessária por vez. De alguma forma, isso pode justificar o design da tabela.

Eu o enviava para a idade da pedra e o forçava a usar arquivos ou pelo menos ensinava-o a usar bolhas.

Realmente, 96 colunas ... Isso não pode estar certo, nunca. Talvez um ORM ajudaria. (A menos que você precise de desempenho, mas possa ter alguém que entenda melhor o DB para lidar com isso)

Vou ser votado no inferno por isso, mas é exatamente por isso que meparei as responsabilidades de modelagem de dados e engenharia de software em minha loja. Os programadores raramente parecem pensar nas formas de conjuntos e, em vez disso, se concentram no uso de dados (em vez de manter a terceira forma normal, indexação ou outros problemas de desempenho do banco de dados). Nós, como programadores, também tendemos a discordar mais sobre essas decisões de arquitetura de banco de dados do que talvez devêssemos, com base em nossa inexperiência em questões de modelagem / arquitetura de dados puros. IMHO, eu gosto de ter arquitetos e modeladores de dados que aceitam requisitos, constroem tabelas / procs / etc. E deixem de lidar comigo com os resultados.

Porém, sem saber as razões reais para esse projeto (trabalhei em sensores climáticos que possuem bem mais de 96 saídas numéricas diferentes = grande número de colunas da tabela) ... isso parece exalar uma irritação.