¿Qué tan lejos puedo tomar este diseño de base de datos?

Question

Estoy interesado en conocer los pros y los contras de crear un sistema personalizado compatible con una base de datos como la que se describe a continuación:

Tiene 6 tablas que lo admiten.

Entidad: Permite decir, cualquier cosa "física" que pueden existir y tener detalles almacenados en contra de ella (Hilton Hotel, de Tony Taxi, una barra)

del tipo de entidad: Una agrupación/tipo de entidad (bar, hotel, restaurante)

metadatos: Cualquier detalle describir o perteneciente a un elemento entidad (IR232PH, foo@bar.com, 555-555-555)

tipo de metadatos: Una agrupación/tipo de metadatos (Código postal, teléfono, correo electrónico, dirección)

entidad-relación: La capacidad de agrupar cualquier artículo entidad a otra (Entity1-Entity2, Entity3)

Entidad Tipo de relación: La agrupación/tipo de relación entre entidades.

Veo cómo este modelo es bueno para Entidades que son similares pero que no siempre tienen la misma cantidad de atributos.

¿Cuáles son los pro/contras de usarlo como lo es para las entidades como se describe?

• Un artista puede realizar (tipo de relación) en una reunión.
• Un artista puede ser de apoyo (tipo de relación) otro artista

¿Cuáles serían los pro/contras de usar también para almacenar las entidades más estándar como usuarios del sistema?

• Un usuario puede tener un favorito (tipo de relación) Lugar/artista/bar, etc.
• Un usuario puede tener una asistencia a (tipo de relación) evento

se lo toma en cuanto a tener las noticias y publicaciones en el blog en eso?

Answer 1

Esto es muy subjetivo, pero antes de subir por la escalera de abstracción hasta donde sugieres, prefiero codificar mi aplicación para usar DDL para modificar el esquema de base de datos para que coincida con los aspectos concretos de las entidades reales que estaba usando , en lugar de tener un esquema estático resumido hasta el punto de poder almacenar datos sobre cualquier entidad potencial.

En cierto modo, para ser un poco gracioso, en mi humilde opinión, lo que está sugiriendo que ya se ha hecho ... Se llama una base de datos relacional. Cada RDBMS es una herramienta de software diseñada para poder modelar cualquier conjunto posible de entidades y sus atributos, de una manera que modele con precisión esas entidades y las relaciones entre ellas.

Answer 2

Aunque ciertamente puede almacenar los datos en dicho modelo de datos, hay un par de problemas (al menos) con él.

El primer problema es controlar los datos. Cuando se describe un 'hotel', ¿cuál es el conjunto de atributos y metadatos que deben definirse? ¿Qué tipos de metadatos se pueden ingresar legítimamente para un hotel? En relación con eso, 'cuando elimino un hotel de la lista, ¿qué más tengo que eliminar'? Cuando borro todos los hoteles de la lista (y nunca quiero volver a almacenar información sobre hoteles), ¿qué más debo eliminar? Es aterradoramente (¿aterrador?) Fácil obtener toda clase de datos extraños, no referenciados, extraviados en la base de datos.

El segundo problema es recuperar los datos. Supongamos que quiero saber toda la información sobre un hotel específico. ¿Cómo escribo una consulta para eso? En realidad, incluso insertar los datos es difícil, pero seleccionarlo es, en todo caso, más difícil. Si solo quiero tres atributos, es fácil, si el hotel realmente los tiene todos. Es más difícil si el hotel solo tiene dos de los tres especificados. Pero supongamos que el hotel tiene 30 atributos, que no es mucho. Entonces es terriblemente difícil.

Lo que está describiendo es una versión trucada de un modelo conocido como el modelo de datos EAV o Entity-Attribute-Value. Generalmente se acepta que es una 'mala idea', para todos es una idea común.

Answer 3

Lo que usted describe también se conoce como triplestore. Un triple es un sujeto-objeto-predicado (Hotel HAS Rooms, Joe Likes HotelX, etc.). Existen mecanismos para ejecutar estas cosas (implementaciones triplestore), controlar los datos (por ejemplo, con ontologías) y consultarlos también (por ejemplo, el lenguaje SPARQL). Sin embargo, todo esto es bastante crudo y se sabe que tiene problemas de escalabilidad. Sin embargo, combinado con los enfoques NoSQL (indexar todos sus hoteles en una gran tienda de documentos, etc.), es un área interesante para vigilar.

Ver: http://en.wikipedia.org/wiki/Triplestore.