gestão de navios estrutura de banco de dados de discussão (deve desnormalizar?)

Question

O meu software foi em produção há alguns dias e agora eu quero discutir um pouco sobre a estrutura de banco de dados.

As coletas de software dados sobre navios, atualmente 174 detalhes de cada navio, cada detalhe pode ser um valor de texto, um valor de texto longo, um número (de um comprimento especificado, com ou sem um número especificado de casas decimais), uma data , uma data com o tempo, um campo booleano, um menu com muitos valores, uma lista de dados e muito mais.

Eu resolvi o problema com as seguintes tabelas

Ship:
- ID - smallint, Autoincrement identity
- IMO - int, A number that does not change for the life of the ship

ShipDetailType: 
- ID - smallint, Autoincrement identity
- Description - nvarchar(200), The description of the value the field contains
- Position - smallint, The position of the field in the data input form
- ShipDetailGroup_ID - smallint, A key to the group the field belongs to in the data input form
- Type - varchar(4), The type of the field as mentioned above

ShipDetailGroup
- ID - smallint, Autoincrement identity
(snip...)

ShipMenuPresetValue
- ID - smallint, Autoincrement identity
- ShipDetailType_ID - smallint, A key to the detail the values belongs to
- Value - nvarchar(100), The values preset in the menu type detail

ShipTextDetail
- ID - smallint, Autoincrement identity
- Ship_ID - smallint, A Key to the ship the detail belongs to
- ShipDetailType_ID - smallint, a Key to the detail type of the value
- Text - nvarchar(500), the field containing the detail's value
- ModifiedDate - smalldatetime
- User_ID - smallint, A key to the user table

ShipTextDetailHistory
(snip...) 
This table is the same as the ShipTextDetail and contains every change to the details.

Other tables for the list detail type, each with the specified fields required for the list, ...

Acabei de ler este artigo: http://thedailywtf.com/Articles/The_Inner-Platform_Effect aspx e http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056

Os artigos diz que este não é o caminho certo para lidar com o problema.

O meu cliente tem um GUI de gerenciamento para os detalhes e grupos como ele muda os detalhes descrições e acrescenta mais detalhes.

O formulário de entrada de dados é construído de forma dinâmica pela leitura da estrutura a partir dos DetailGroups e DetailTypes, cada tipo detalhe gera um controlo de entrada especificado.

Os comentários sugerem que uma outra maneira de resolver este assunto é dinamicamente criar e remover colunas da tabela.

O que você acha?

Diagrama Captura de tela: http://img24.imageshack.us/my. php? image = 66604496uk3.png

Answer 1

refactor seu código se:

• O seu cliente reclamou
• Você encontrou algo que não funcionou
• Você encontrou uma maneira que o código não poderia lidar com um mudar você soubesse que ia acontecer no futuro.

Você se lembrou de testes de unidade de gravação que lhe permitirá refactor, certo?

* estruturas Tanto quanto a estrutura que você tem lá, eu vi assim antes. É um pouco complicado, mas é padrão em muitos lugares. Uma coisa a lembrar é que, enquanto a sua possível adicionar e remover dinamicamente colunas de bancos de dados, o mecanismo de armazenamento interno do banco de dados não necessariamente esperam que você seja adicionando e removendo estas colunas continuamente. Mas eu não acho que isso é muito relevante em comparação com os pontos acima, que se resumem a:? * Será que funciona

Answer 2

Eu vi essa abordagem antes e ele é apresentado cargas de problemas de desempenho uma vez que o volume de dados tem crescido. O tipo de problemas você encontrará vir quando você precisa de retornar vários itens e usar vários critérios na sua cláusula WHERE. Você juntar-se para trás e para frente entre navio e ShipTextDetail para obter todas as suas selecionar colunas - talvez você tem que fazer isso 10/20 vezes? Você, então, fazer o mesmo para seus critérios talvez 2-3 vezes. Agora você tem uma consulta com tantos junta corre muito lentamente. Em seguida, você 'pré-cozinhar' alguns dos dados para melhorar o desempenho, ou seja, você arrastar para fora de dados comuns em uma estrutura de tabela fixa - ah você voltou com um modelo semi-normalizado.

A minha recomendação seria esta - você sabe as informações para 174 campos aqueles que são os seus principais atributos. Seu cliente pode acrescentar a essa lista, e pode alterar a descrição dos campos, mas ainda é um bom ponto de partida. Criar um DataModel adequada com base em torno daqueles, e então construir em um mecanismo extensability, como você já fez, mas apenas para os novos campos. Os metadados -. As descrições dos campos, pode residir em outra tabela, ou potencialmente em um arquivo de recurso (? Útil para internacionalização) e que dá alguma flexibilidade para os campos existentes

Eu concordo com Joe, você não pode ter problemas se o seu DB é pequeno, ou seja <1000 navios e suas seleciona são simples. Embora com 174 atributos para escolher este não parece provável. Eu acho que você deve mudar alguns dos campos 'óbvio' em primeiro lugar, ou seja, eu diria que você tem um Ship.Name, Ship.Owner, Ship.Weight, Ship.Registration ...

Good Luck.

Answer 3

Já fiz coisas semelhantes, mas há um par de problemas com esta implementação específica:

1. Você está armazenando números, booleanos, datas, etc. como strings. Isso pode ser inferior a ideal. Uma alternativa é implementar classes separadas (herdam uma base) para os diferentes tipos de dados, em seguida, armazená-los em mesas feitas para o seu tipo de dados.
2. Faça as propriedades que controlam mudança muito frequentemente? eles são um conjunto diferente por navio-tanque? Se não, talvez seja melhor para fazer objetos em vez de sacos de propriedade para armazenar todos os dados. Esses objetos podem então ser mantidas no banco de dados.

Answer 4

Do ponto de vista do desempenho, qualquer abordagem vai ficar bem. Quantos navios poderia haver? Todos os dados são indo para caber na memória RAM em qualquer servidor.