Hola.
Estoy diseñando una DB para una especie de CMS desde 0 que quiero hacer (por favor, no me sugirais utilizar un CMS ya creado, estoy haciendo esto además de para utilizarlo para aprender programacion PHP, javascript y sobre el diseño y mantenimiento de DBs) y se me plantea una duda:
En caso de contenidos similares (por ejemplo; la ficha de una película y de una serie, en las cuales en una hipotética tabla tendrian el mismo dominio en todos los atributos); es mejor crear una única tabla "PelisySeries", añadiendo un campo que diga si es película o serie o dos tablas, "películas" y "series".
Las consultas serían, en caso de una búsqueda por el usuario tanto pedir una lista de películas o una de series como dos listas, una de cada.
En términos de rendimiento, que consume menos recursos del sistema (con recursos no me refiero a espacio en el HDD, sino en RAM y procesador):
-Consultar una tabla de peliculasyseries en busca de películas o series (es un o exclusivo)
frente a:
-Consultar en una tabla de películas O (exclusivo) en una de series en busca del contenido de su tipo.
En el caso anterior supongo que la segunda, debido a que la tabla es más pequeña; pero en el siguiente caso:
-Consultar una tabla de peliculasyseries en busca de películas y series
frente a:
-Consultar en una tabla de series las series y seguidamente en una tabla de películas las películas.
En ambos casos la búsqueda puede tener diferentes parámetros y tal, pero con resolver esta conslta creo que casi todas las dudas con el diseño básico de la DB estaran contestadas, a falta de que surjan futuras dudas.
En resumen mi duda podria resumnirse en algo como:
"En bases de datos con tablas de más de 200.000 filas, es rentable en términos de rendimiento dividir las tablas según un atributo (en este caso tipo_contenido) a cuyo dominio solo pertenecen 3 o 4 valores (por ej: pelis,series,juegos) en tablas diferentes? Ahorra tiempo la reduccion del número total de elementos a buscar frente al acceso a multiples tablas?)"
O sería mejor utilizar una vista? Que hace MySQL para mantener actualizada una vista; modificarla cada vez que se modifica la tabla origen o "crearse" por cada consulta que el usuario realiza?Es decir, si yo modifico una tabla apuntada por una vista y antes de que nadie más modifique la tabla 20 usuarios acceden a la vista; esta consumirá recursos para actualizarse 20 veces o solo 1?
Pregunta 2: Para almacenar mensajes privados que NO deben desaparecer del outbox del usuario que lo envia en caso de que el usuario que los recibe los elimine se me ocurren 2 cosas:
La peor: Guardar 2 veces el mensage, una en el inbox y otra en el outbox del usuario.
La que según creo es la mejor: Crear 1 sola version del mensage, con sender_id; msg_id y reciever_id. Crear tablas inbox y outbox que contengan msg_id; y a la hora de listar compruebe el out/inbox. Cuando NI el outbox NI el inbox listen un mensage, este podrá (o no, segun intereses) ser eliminado del sistema
Estoy diseñando una DB para una especie de CMS desde 0 que quiero hacer (por favor, no me sugirais utilizar un CMS ya creado, estoy haciendo esto además de para utilizarlo para aprender programacion PHP, javascript y sobre el diseño y mantenimiento de DBs) y se me plantea una duda:
En caso de contenidos similares (por ejemplo; la ficha de una película y de una serie, en las cuales en una hipotética tabla tendrian el mismo dominio en todos los atributos); es mejor crear una única tabla "PelisySeries", añadiendo un campo que diga si es película o serie o dos tablas, "películas" y "series".
Las consultas serían, en caso de una búsqueda por el usuario tanto pedir una lista de películas o una de series como dos listas, una de cada.
En términos de rendimiento, que consume menos recursos del sistema (con recursos no me refiero a espacio en el HDD, sino en RAM y procesador):
-Consultar una tabla de peliculasyseries en busca de películas o series (es un o exclusivo)
frente a:
-Consultar en una tabla de películas O (exclusivo) en una de series en busca del contenido de su tipo.
En el caso anterior supongo que la segunda, debido a que la tabla es más pequeña; pero en el siguiente caso:
-Consultar una tabla de peliculasyseries en busca de películas y series
frente a:
-Consultar en una tabla de series las series y seguidamente en una tabla de películas las películas.
En ambos casos la búsqueda puede tener diferentes parámetros y tal, pero con resolver esta conslta creo que casi todas las dudas con el diseño básico de la DB estaran contestadas, a falta de que surjan futuras dudas.
En resumen mi duda podria resumnirse en algo como:
"En bases de datos con tablas de más de 200.000 filas, es rentable en términos de rendimiento dividir las tablas según un atributo (en este caso tipo_contenido) a cuyo dominio solo pertenecen 3 o 4 valores (por ej: pelis,series,juegos) en tablas diferentes? Ahorra tiempo la reduccion del número total de elementos a buscar frente al acceso a multiples tablas?)"
O sería mejor utilizar una vista? Que hace MySQL para mantener actualizada una vista; modificarla cada vez que se modifica la tabla origen o "crearse" por cada consulta que el usuario realiza?Es decir, si yo modifico una tabla apuntada por una vista y antes de que nadie más modifique la tabla 20 usuarios acceden a la vista; esta consumirá recursos para actualizarse 20 veces o solo 1?
Pregunta 2: Para almacenar mensajes privados que NO deben desaparecer del outbox del usuario que lo envia en caso de que el usuario que los recibe los elimine se me ocurren 2 cosas:
La peor: Guardar 2 veces el mensage, una en el inbox y otra en el outbox del usuario.
La que según creo es la mejor: Crear 1 sola version del mensage, con sender_id; msg_id y reciever_id. Crear tablas inbox y outbox que contengan msg_id; y a la hora de listar compruebe el out/inbox. Cuando NI el outbox NI el inbox listen un mensage, este podrá (o no, segun intereses) ser eliminado del sistema
necesitas teoria para diseñar una base de datos que sea la solucion optima a tus necesidades