Diseño de BD. Herencia

[DandyCC]

Imaginad que estéis desarrollando una aplicación en la que distintas entidades pueden mandar mensajes públicos e interactuar con los mensajes de otras entidades. Esas entidades pueden ser de varios tipos: usuarios simplemente, una administración pública, un centro de enseñanza, etc.

Para diseñar la BD se me ocurren dos opciones que creo que funcionarían pero no sé cuál es mejor o si hay alguna mejor aún que no se me haya ocurrido.

Opción 1: Tener una tabla por cada entidad. Para almacenar los mensajes que las entidades publican tendría que tener en la tabla donde almaceno los mensajes al menos dos campos para identificar a la entidad que lo publicó, su id y su tipo.

Opción 2: Crear una sola tabla (tbl_entidades, por ejemplo) de la que heredan el resto de entidades posibles. De esta forma, en la tabla donde se almacenan los mensajes sólo haría falta una clave foránea que apuntara a la id de la entidad que lo publicó. Esta opción me parece mejor que la anterior, pero el problema es que en la tabla de entidades no encuentro apenas atributos que sean comunes a todas las entidades. De hecho solo encuentro el slug, porque ni el nombre creo que valiese la pena meterlo en esa tabla, aunque tanto usuarios como otras entidades tienen uno.

¿Cuál os parece mejor? ¿Hay alguna alternativa mejor que no se me haya ocurrido?

Si os parece mejor la opción 2, ¿hace falta que las tablas que heredan de la tabla de entidades tengan su propio id o con definir como clave primaria el id que apunta a la tabla entidades es suficiente?

Gracias

[Libras]

Estas pensando como desarrollador, y la logica de desarrollo normalmente no aplica para bases de datos, a que te refieres con entidades? o para ti que es una entidad?

[DandyCC]

Sí, jejeje, soy desarrollador, no diseñador, de ahí mis problemas con esto

Una entidad es cualquier cosa (cualquier "ente") que en la aplicación puede mandar mensajes. Un ejemplo parecido sería twitter o facebook, donde quien publica es un usuario, pero puede estar representando a una empresa, a una administración pública, a sí mismo... La diferencia es que en esta aplicación los atributos de un usuario no tienen nada que ver con los de una empresa, y los de ésta tampoco tiene por qué ser iguales a los de una administración pública, así que no puedo juntarlos a todos en una sola tabla.

[Libras]

Entonces en ese caso a ti no te interesa que representa, puedes tener una tabla usuarios donde tengas las diferentes "entidades", que representa cada usuario es independiente de la base de datos eso es la logica de negocios, creo que deberias de explicar que es lo que hace tu aplicacion pero en terminos normales no de POO

[gnzsoloyo]

Iniciado por DandyCC

Sí, jejeje, soy desarrollador, no diseñador, de ahí mis problemas con esto

Una entidad es cualquier cosa (cualquier "ente") que en la aplicación puede mandar mensajes. Un ejemplo parecido sería twitter o facebook, donde quien publica es un usuario, pero puede estar representando a una empresa, a una administración pública, a sí mismo... La diferencia es que en esta aplicación los atributos de un usuario no tienen nada que ver con los de una empresa, y los de ésta tampoco tiene por qué ser iguales a los de una administración pública, así que no puedo juntarlos a todos en una sola tabla.

Como ya te ha dicho Libras, lógica de programación no es lógica de BBDD. SOn universos que se comunican pero no son portables de uno a otro.

En primer lugar, lo los mensajes que mande una "entidad" en tu contexto son irrelevantes para la BBDD, al menos en el sentido de "mensajes". La base NO maneja mensajes, en todo caso estos representan una Entidad del modelo E-R denominada "Mensaje", asociada con otra entidad "Usuario", la cual a su vez puede ser una jerarquía padre-hijo donde haya dos entidades débiles "Empresa" e "Individuo" que heredan su PK de Usuario.
A su vez, a nivel implementación todo eso podría desaparecer y quedar sólo dos tablas Usuario y UsuarioEmpresa, además de otra "Categoría", por ejemplo. Son decisiones de diseño en arquitectura de datos y no de diseño de interfases

No confundir.

Como sea, necesitarás profundizar un poco el tema del modelo entidad-relacion para poder visualizar las diferencias entre tus conceptos y los que aplican en BBDD, a fin de poder "traducir" tu definición funcional a estructuras de datos administrables. Todavía estás lejos de eso.

Para comenzar, sería práctico que nos dieras un listado de las reglas de negocio que se cumplen, a find epoder ayudarte a visualziar cual es la definición de relaciones y entidades, asi como la estructura física de datos que necesitarás.

[osmaymoya]

Estoy muy de acuerdo con lo que han planteado, solo puntualizar que no entiendo que quizo decir gnzsoloyo al expresar:
Cita:

SOn universos que se comunican pero no son portables de uno a otro.

Segun tengo entendido es posible ir de un Modelo Entidad Relacion (Representa entidades y sus relaciones) a un Modelo Relacional (Representa las tablas y sus relaciones) y viceversa.