Essa é uma maneira padrão de criar um banco de dados?

Recentemente, aprendi sobre como os relacionamentos são definidos no banco de dados no trabalho e fiquei imaginando se essa é uma prática padrão.

Digamos que temos dois processos: Processo A e Processo B. O processo B depende dos resultados do Processo A, portanto, existe um relacionamento que precisa ser definido entre uma execução do Processo B e uma execução do Processo A. É assim que o relacionamento é definido:

TableProcessA:
Id

e

TableProcessB:
Id
ProcessAId

Agora, até este ponto, as coisas fazem sentido para mim, mas as coisas ficam um pouco estranhas para mim e para minha compreensão do design da mesa. Sempre que uma linha é criada em TableProcessA ou TableProcessB, uma função é chamada que cria um ID globalmente exclusivo para cada um. Portanto, basicamente, todos os campos de ID em TableProcessA e TableProcessB não conterão nenhuma correspondência, porque os IDs não são apenas exclusivos de sua tabela, mas de todo o banco de dados.

Minha pergunta é: qual é o padrão? Fui criado com a idéia de que cada tabela deveria simplesmente ter um ID de incremento automático exclusivo da tabela e não de todo o banco de dados.

Esta não é uma prática tão estranha. Esses são chamados GUIDs ou IDs globalmente exclusivos. A idéia é que, dado um GUID, você possa dizer exatamente a que parte de dados o ID pertence, pois será único em qualquer lugar . Os GUIDs são mais usados ​​quando você mescla fontes diferentes de dados semelhantes; por exemplo, inventário para diferentes lojas.

Eu faria algumas pesquisas e descobriria por que essa é uma prática comum em seu ambiente. Talvez seja necessário, talvez não seja.

Em princípio, ter IDs únicos em um banco de dados não é tão ruim, mas é bastante incomum na minha experiência. A menos que haja um requisito específico para manter chaves de ID globalmente exclusivas, o uso da identidade normal deve ser bom, pois os tipos ou objetos de entidade tendem a ser específicos ao tipo e geralmente não resultam em junções inadequadas.

Como um aparte de sua pergunta, sugiro enfaticamente não usar GUIDs como chaves primárias ou substitutas, pois ocupa quatro vezes o espaço de um int. Agora, nos dias de discos com vários gigabytes, você pode dizer que não é importante, mas quando você tem alguns milhões de linhas de dados, ainda são necessários recursos para ler do disco ou transferir através de uma rede, ainda mais se eles forem incluídos em quaisquer índices. Enquanto eu estou nos índices de assuntos, os GUIDs são ruins nas chaves primárias devido à natureza aleatória e geralmente causam fragmentação significativa.

Agora é provável que seja tarde demais para esse banco de dados, mas lembre-se disso para o futuro

Seus processos podem criar registros que contêm o GUID como uma referência à instância do processo, mas o uso dos GUIDs como chave não é necessariamente ideal.

Vejo três principais desvantagens do uso de GUIDs como chaves do banco de dados e as evitaria a menos que você tenha algum motivo convincente para usá-las. Observe que a propriedade globalmente exclusiva não oferece vantagens sobre o uso de uma chave que é localmente exclusiva em uma tabela, porque você já sabe de qual tabela os dados vieram.

Inconveniência: não é muito fácil digitar um GUID se você deseja fazer uma consulta ad-hoc do banco de dados, por exemplo:

select *
  from Foo
 where FooID = 12345

vs

select *
  from Foo
 where FooID = convert (uniqueidentifier, '5E64E653-35F0-4803-B459-F5F59C701F22')

O último praticamente significa que você precisa de uma fonte do GUID para recortar e colar.

2. Ordinalidade natural: uma chave primária de incremento automático tem o efeito colateral de ordenar naturalmente suas transações na ordem em que foram inseridas no sistema. Isso geralmente é bastante útil. Os GUIDs normalmente não são gerados em ordem; portanto, eles não são úteis nesse sentido.

3. Tamanho: menos de um problema nos dias de hoje, mas um GUID tem 16 bytes de comprimento. Ocupa mais espaço na tabela e quaisquer índices que a incluam.

Não vou dizer que é normal, mas também não é anormal definir as coisas dessa maneira.