IDs de banco de dados padrão;valores do sistema e do usuário

Question

Como parte de nosso trabalho atual com bancos de dados, estamos analisando o processo de atualização de bancos de dados.

Um ponto que tem sido levantado recorrentemente é o de lidar com sistema vs.valores do usuário;em nosso projeto, os vals do usuário e do sistema são armazenados juntos.Por exemplo...

Temos uma lista de modelos.

1, <system template>

2, <system template>

3, <system template>

Eles são mapeados no aplicativo para uma enumeração (1, 2, 3)

Então um usuário entra e adiciona...

4, <user template>

...e...

5, <user template>

Então..emitimos um upgrade..e insira como parte de nossos scripts de atualização...

<new id> [6], <new system template>

ENTÃO!!...encontramos um bug no novo modelo do sistema e precisamos atualizá-lo...O problema é como?Não podemos atualizar o registro usando ID6 (pois podemos tê-lo inserido como 9 ou 999, então temos que identificar o registro usando algum outro mecanismo)

Então, chegamos a duas soluções possíveis para isso.

No canto vermelho (velocidade)....

Simplesmente iniciamos os IDs de usuário em 5.000 (ou algum outro valor) e testamos os dados em 10.000 (ou algum outro valor).Isso nos permitiria fazer modificações nos valores do sistema e testá-los até o limite inferior do próximo intervalo de ID.

Vantagem...Rápido e fácil de implementar,

Desvantagem...poderia ficar sem valores se não escolhermos um intervalo grande o suficiente!

No canto azul (escalabilidade)...

Armazenamos dados do sistema e do usuário separadamente, usamos GUIDs como Ids e mesclamos as duas listas usando uma visualização.

Vantagem... Escalável. Sem limites em relação ao tamanho do banco de dados.

Desvantagem..Mais complicado de implementar.(muitas para uma visualizações atualizáveis, etc.)

---

Eu escolho diretamente a primeira opção, mas procuro alguma munição para me apoiar!

Alguém tem alguma opinião sobre essas abordagens, ou mesmo uma(s) que perdemos?

Answer 1

Nunca tive problemas (desempenho ou desenvolvimento - TDD e testes unitários incluídos) usando GUIDs como ID para meus bancos de dados, e trabalhei em alguns bem grandes.Dar uma olhada aqui, aqui e aqui se você quiser saber mais sobre o uso de GUIDs (e os potenciais GOTCHAS envolvidos) como suas chaves primárias - mas não posso recomendá-lo o suficiente, pois mover dados com segurança e a sincronização do banco de dados se torna tão fácil quanto escovar os dentes pela manhã: -)

Para sua pergunta acima, eu recomendaria uma terceira coluna (se possível) que indique se o modelo é ou não baseado em usuário ou sistema, ou você pode pelo menos gerar GUIDs para modelos de sistema à medida que os insere e manter uma lista de aqueles disponíveis, para que, se você precisar atualizar o modelo, você possa direcionar esse mesmo GUID em seus bancos de dados DEV, UAT e/ou PRODUCTION sem medo de substituir outros modelos.A terceira coluna seria útil para selecionar todos os modelos de sistema ou usuário à vontade, sem a necessidade de separá-los em duas tabelas (isso é um exagero IMHO).

Espero que ajude,

Rob G.

Answer 2

Eu recomendo usar o segundo com a modificação de armazenar os valores do sistema e do usuário em uma tabela.GUID é bastante confiável dessa maneira.

Outra ideia:use qualquer ID baseado em texto (GUID não necessário), fornecido para os valores do sistema e gerado por uma sequência aleatória ou baseada em algum tipo de lógica personalizada para os valores do usuário.

Outra ideia:use a primeira abordagem, mas estenda a tabela com um sinalizador que mostra se um valor é sistema ou usuário.Talvez este seja o mais fácil.Ok, você precisa escrever algum tipo de mecanismo para atualizar o valor correto do sistema, mas isso pode ser feito facilmente.

Answer 3

+1 para o ID baseado em texto de Biri - defina uma coluna baseada em texto "template_mnemonic" e torne-a a chave primária.Este será um valor conhecido quando você inseri-lo como você, os desenvolvedores terão decidido sobre ele (ou gerado automaticamente) e você sempre poderá referenciar um modelo por seu mnemônico, independentemente de quantos modelos especificados pelo usuário existam.Também permite que os usuários tenham uma convenção de nomenclatura significativa para seus modelos.

Answer 4

Talvez eu não tenha entendido, mas você não poderia usar GUIDs como Ids e ainda ter os dados do usuário e do sistema juntos?Então você pode acessar os dados do sistema pelos GUIDs (não alteráveis).

Answer 5

Não acho que o GUID deva causar nenhum problema.

Se você quiser evitá-lo, use um sinalizador:

Eu não fiz

modelo qualquer que seja

sinalizador enum/int/bool

O sinalizador mostra se o valor real é um valor do sistema ou do usuário.

Se você quiser atualizar um valor do sistema, peça apenas os valores do sistema ordenados por ID, e ele mostrará a ordem real de inserção (você deve ter um bigint ou algo assim para o ID, para garantir que ele não fique cheio e isso não faz com que os IDs excluídos voltem a funcionar).Com esta lista o x.registro é o x.valor do sistema inserido.

Answer 6

Acho que existe uma terceira solução melhor.Parece-me que você está armazenando duas coisas diferentes na mesma tabela e que seria melhor criar duas tabelas separadas, uma para modelos de usuário e outra para modelos de sistema.Você poderá então criar uma visualização sobre as duas tabelas para fazê-las aparecer como um único objeto em seu aplicativo.Obviamente, não tenho conhecimento completo do seu aplicativo e isso pode ser impossível para você por uma série de razões, mas acho que é uma solução mais simples que GUIDs e muito mais segura que intervalos de IDs (sério, não faça intervalos de ID, pois isso te morder um dia)