Qual é a melhor abordagem para substituir campos em um banco de dados?

5

Eu tenho um banco de dados que contém projetos e cada projeto contém muitas amostras. Eu quero um valor de limite de nível de projeto, para acionar o realce quando um campo na amostra está acima desse limite. Eu também quero ser capaz de substituir o limite no nível de amostra individual.

Então, vejo duas maneiras de implementar isso:

  1. mantenha o campo de limite (somente) na amostra e acione isso para ser preenchido quando o projeto for salvo.

  2. têm campos de limite de nível de amostra e de projeto e usam apenas o campo de amostra quando é relevante (parece haver alguma redundância com esse modelo, embora represente mais precisamente a situação)?

Existem vantagens / problemas com uma das abordagens?

    
por wobbily_col 19.04.2013 / 15:11
fonte

3 respostas

1

Na verdade, é uma simples descida com base na frequência com que você atualiza o limite do projeto vs. com que frequência você consulta as amostras.

Se o limite do nível do projeto não for atualizado com muita freqüência, copiaria o limite para cada linha de amostra (talvez com uma coluna extra para indicar um valor substituído). Isso tornará as consultas mais simples e rápidas.

Por outro lado, se você atualizar o limite padrão com frequência. Mantenha-o no nível do projeto e obtenha o (pequeno) desempenho atingido para a junção em todas as consultas.

    
por 20.04.2013 / 02:05
fonte
0

Sua segunda opção oferece mais flexibilidade com o mínimo de complexidade extra.

No registro de amostra, tenha um campo anulável que mantenha o nível de limite local. Configure o campo para null se a amostra tiver que usar o limite padrão do projeto. Se você estiver usando o SQL, é simples aderir às tabelas e usar isnull para obter o valor limite:

SELECT Field1, Field2, ISNULL(sample.threshold, project.threshold) as Threshold FROM ...
    
por 20.04.2013 / 04:42
fonte
0

Eu escolheria sua segunda opção, armazenando apenas o valor de substituição nos registros de amostra quando for diferente do limite do projeto (armazenado no registro do projeto).

Essa parece ser a solução mais limpa para mim (armazenando informações sobre o projeto com o registro do projeto e os dados específicos da amostra com a amostra), mas, mais importante, há um problema com sua primeira opção.

Por exemplo, se você armazenar o limite do projeto nas amostras onde não há limite específico de amostra e você tiver um limite de projeto de 5:

| Sample Name | Threshold | 
| Sample A    | 5         | 
| Sample B    | 5         | 
| Sample C    | 5         | 

Você atualiza o Sample C para ter um limite de 6:

| Sample Name | Threshold |
| Sample A    | 5         |
| Sample B    | 5         |
| Sample C    | 6         |

Você atualiza o limite do projeto para 6:

| Sample Name | Threshold |
| Sample A    | 6         |
| Sample B    | 6         |
| Sample C    | 6         |

Se você quiser mudar o limiar do projeto, você não pode distinguir C de A e B, o que significa que ele também será alterado de volta para 5, o que pode não ser o que você deseja.

Você poderia armazenar um sinalizador para indicar que o limite é específico da amostra para evitar essa situação, mas isso parece redundante quando comparado ao armazenamento do limite do projeto no projeto e ter nulos no limite de amostra, a menos que seja definido.

    
por 21.04.2013 / 15:55
fonte