¿Es esta una forma estándar de diseñar una base de datos?

Recientemente aprendí sobre cómo se definen las relaciones en la base de datos en el trabajo, y me preguntaba si esta es una práctica estándar.

Digamos que tenemos dos procesos: el Proceso A y el Proceso B. El Proceso B depende de los resultados del Proceso A, por lo que hay una relación que debe definirse entre una ejecución del Proceso B y una ejecución del Proceso A. Así es como se define la relación:

TableProcessA:
Id

y

TableProcessB:
Id
ProcessAId

Ahora, hasta este punto, las cosas tienen sentido para mí, pero luego las cosas se ponen un poco extrañas para mí y mi comprensión del diseño de la mesa. Cada vez que se crea una fila en TableProcessA o TableProcessB, se llama a una función que crea una identificación globalmente única para cada uno. Básicamente, todos los campos de Id en TableProcessA y TableProcessB no contendrán coincidencias porque los Id no solo son exclusivos de su tabla, sino de toda la base de datos.

Mi pregunta es, ¿qué tan estándar es esto? Se me ocurrió la idea de que cada tabla simplemente debería tener una identificación de autoincremento que sea exclusiva de la tabla y no de toda la base de datos.

Esta no es una práctica tan rara. Esos se llaman GUID o ID únicos globales. La idea es que, dado un GUID, puede saber exactamente a qué datos pertenece la identificación porque será única en todas partes . Los GUID se utilizan mejor cuando fusionará diferentes fuentes de datos similares; por ejemplo, inventario para diferentes tiendas.

Investigaría un poco y descubriría por qué esta es una práctica común en su entorno. Tal vez sea necesario, tal vez no lo sea.

En principio, tener identificadores únicos en una base de datos no es tan malo, pero es bastante inusual en mi experiencia. A menos que exista un requisito específico para mantener claves de identificación únicas a nivel mundial, el uso de la identidad normal debería estar bien, ya que los tipos de entidad u objetos tienden a ser específicos de tipo y, por lo general, no dan lugar a uniones inapropiadas.

Como un aparte a su pregunta, sugeriría encarecidamente no usar GUID como claves primarias o sustitutas, ya que ocupa 4 veces el espacio de un int. Ahora, en los días de los discos de varios gigabytes, es posible que diga que no es importante, pero cuando tiene unos pocos millones de filas de datos, todavía se necesitan recursos para leer desde el disco o transferirlos a través de una red, aún más si se incluyen en algún índice. Mientras estoy en los índices de materias, los GUID son malos en las claves primarias debido a su naturaleza aleatoria y generalmente causan una fragmentación significativa.

Ahora es probable que sea demasiado tarde para esta base de datos, pero tenlo en cuenta para el futuro

Sus procesos pueden crear registros que contienen el GUID como referencia a la instancia del proceso, pero el uso de los GUID como clave no es necesariamente óptimo.

Veo tres desventajas principales de usar GUID como claves de base de datos, y las evitaría a menos que tenga alguna razón convincente para usarlas. Tenga en cuenta que la propiedad globalmente única no le ofrece ninguna ventaja sobre el uso de una clave que sea localmente única dentro de una tabla, porque ya sabe de qué tabla provienen los datos.

Inconveniencia: no es terriblemente fácil escribir un GUID si desea hacer una consulta ad-hoc de la base de datos, por ejemplo:

select *
  from Foo
 where FooID = 12345

vs

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

Esto último prácticamente significa que necesita una fuente del GUID para cortar y pegar.

2. Ordenación natural: una clave primaria de autoincremento tiene el efecto secundario de ordenar naturalmente sus transacciones en el orden en que se ingresaron en el sistema. Esto a menudo es bastante útil. Los GUID normalmente no se generan en orden, por lo que no son de utilidad a este respecto.

3. Tamaño: actualmente es un problema menor, pero un GUID tiene 16 bytes de longitud. Ocupa más espacio en la tabla y los índices que lo incluyen.

No diré que es normal, pero tampoco es anormal configurar las cosas de esta manera.