Pros y contras de y formas de implementar identificador global único en la base de datos relacional?

Question

En relación con la primera parte de mi pregunta: recientemente me preguntaba cuáles son los beneficios y las ventajas de tener un identificador único para ciertas tablas en una base de datos relacional. Solo como ejemplo, la API Graph (Facebook) permite buscar diferentes tipos de objetos como "Usuarios", "Eventos", "Páginas", etc. utilizando la misma URL, por ejemplo, https://domain/251906384206 devuelve un objeto de tipo "Evento" mientras que https://domain/195466193802264 devuelve un objeto de tipo "Grupo".

¿Cuál es el beneficio de este enfoque en comparación con proporcionar una API menos "genérica", que se utilizaría de esta manera: https://domain/event/251906384206 o https://domain/group/195466193802264. En este caso, un identificador similar podría usarse para diferentes tipos de objetos porque cada tipo de objeto tiene su alcance identificador.

En cuanto a la segunda parte de la pregunta: ¿Cuáles son las opciones para implementar un identificador global único?

dos opciones que vienen a la mente son:

1. El uso de un enfoque basado en la herencia (tabla-por-clase, una sola mesa, etc.). Suponiendo que se utiliza un enfoque de tabla por clase (super tabla contiene identificador único como clave primaria solamente, subtabla que representa tipo de objeto contiene el mismo identificador como super tabla y datos adicionales), se requieren combinaciones entre super y sub tabla que parece escalar mal porque la súper mesa se convierte en un cuello de botella?

2. Proporcionar una tabla con 3 columnas, que contiene

   • identificador único,
   • objeto clave primar specifc tipo, y
   • nombre de tabla.

   Tablas adicionales por tipo de objeto que contiene una columna que hace referencia al identificador único como clave externa. Cada tabla específica de tipo de objeto tiene su propio ámbito de clave principal.

Ambos enfoques permitirían proporcionar una API genérica como la API FB mencionada anteriormente. El segundo enfoque permitiría usar claves primarias específicas de la tabla de objetos internamente y exponer el identificador único global únicamente. Sin embargo, si un identificador único global puede utilizarse internamente, el segundo enfoque también requerirá una unión.

¿Hay alguna experiencia con respecto a los pros/contras de un identificador global único y cuáles son las mejores prácticas para implementarlo?

Answer 1

Ambas formas propuestas de implementar el identificador global implican uniones de tablas grandes y una duplicación efectiva del número de registros en su base de datos (cada objeto existe por sí mismo pero también lo hace su padre/registro con su ID global).

Tengo la sensación de que sería mejor imponer identificaciones globales en la capa de acceso a aplicaciones/datos. Esto se puede hacer de manera trivial al exigir que los ID para cada tipo específico de objeto provengan únicamente de un subconjunto de posibles ID. Podría, por ejemplo, reservar el último/primer x bits de todos los ID para especificar el tipo de objeto. La parte restante de los ID, sería la "identificación real".

Si tiene miedo de los errores al asignar identificadores para la tabla específica, puede agregar una restricción de verificación que hará que la identificación sea correcta (por ejemplo, ID < 4000 AND ID> 10000). Si le preocupan los bits/bytes desperdiciados por el tipo de objeto en su identificador, podría exponer el ID global solo en su API de acceso a la base de datos, que concatenaría el ID de los objetos (realmente almacenados en una tabla) con sus ID de tipo (derivado del tipo de objeto).

Answer 2

"Un problema bien planteado, es un problema ya medio resuelto".

Me parece que está mezclando varios conceptos. Usted revisa otras aplicaciones de base de datos, pero parece que se confundió más en lugar de estar más informado.

Tiene varios objetos de diferentes clases y desea saber cómo almacenarlos en una base de datos. Esto generalmente se llama por el "nombre de fantasía" del mapeo relacional de objetos (O.R.M.).

Además, desea utilizar un identificador único global (G.U.I.D.) para identificar un objeto como objeto empresarial/de programación y una fila en una tabla.

Además, también desea utilizar un G.U.I.D. para identificar una clase u objeto de cierto tipo.

Digamos que está compilando una aplicación. donde tienes varios objetos. Hay varias clases de objetos como "Usuarios", "Eventos", "Páginas" y otros. Puede tener varios objetos de la misma clase/tipo, pero necesita una forma de identificar uno de otro. Para identificar a "John Doe" de Michigan, de "John Doe" de Queensland. Digamos que sus objetos van a usar una propiedad de tipo G.U.I.D.

Así que supongamos que crea una tabla para cada clase ("usuario" para "Usuarios", id estándar de tabla. Es singular y minúscula, aunque puede ignorarlo, "evento" para "eventos", etc.) . Cada tabla tiene varios campos que representan las propiedades de cada objeto. Por lo tanto, el "usuario" tendrá un campo como "GUID user_key" y quizás "user_name varchar (100)" y "user_birthdate datetime". Lo mismo ocurre con las otras tablas.

He usado "supertable" pero solo para aplicaciones muy específicas, no comunes. No creo que necesite una tabla que mezcle "usuarios", "eventos", "páginas". Tuve un caso en el que teníamos una supertable "clientes", más subtablas de "empresa" y "persona" con campos adicionales específicos. En algún momento, tuvimos que verificar las ventas para todos los clientes y hacer uniones con la tabla de "clientes". A veces, teníamos que ofrecer un descuento corporativo para los productos y explorar la subtabla de la "empresa".

En caso de que desee esta generalización/"IS a" supertable, no necesita tener un campo diferente para la clave primaria supertable y la clave primaria de la tabla de detalles, puede ser del mismo tipo.

Sugiero que evite a toda costa las teclas compuestas/compuestas ("clave maestra" más "otros" campos), use una sola clave principal de campo. También sugiero que asigne el G.U.I.D. clave usando la programación, no en la base de datos.

The G.U.I.D. usa más memoria y espacio en disco que una clave entera, pero es muy rápido y fácil obtener una clave que es muy difícil de duplicar.

Nuevamente, su pregunta es más acerca de cómo representar objetos en una base de datos que el uso de G.U.I.D.