Desarrollo y diseño

Rendimiento de base de datos

EnZo
EnZo #1 Mar '07

Estoy diseñando el diagrama E-R pero me han surgido un par de dudas.

Supongamos que tengo 3 areas: Informatica, Musica, Deportes. En las 3 los usuarios pueden comentar articulos.

Que es mejor? Hacer tres tablas para cada area, o una sola tabla para todas con un campo que diferencie el area. Que seria mas eficiente?

Y la otra duda:
Los usuarios se registran y ahora mismo la informacion de los usuarios la clasifico en 3 clases.

  • Informacion de cuenta (user, pass, mail, ip...)
  • Informacion personal (nombre, edad, provincia...)
  • Estadisticas (comentarios hechos, logins...)

Es mejor clasificar esa informacion en tres tablas, o todo en uno.
Lo digo porque ahora mismo son 30 campos de informacion, y no se que seria mas apropiado para cuando se vayan a hacer las consultas.

Gracias de antemano, y un saludo.

SeiYa
SeiYa #2 Mar '07

Sobre lo primero, es mejor tener 1 tabla y diferenciarlas por un campo, ya que además puedes hacer mucho más óptimo y reutilizable los scripts de comentar noticias y todo eso.

Sobre los registros, imagínate.

Se registran 1 millón de usuarios. ¿Qué es mejor? una tabla con 1 millón de registros o 3 tablas con 1 millón de registros cada 1.

Además, si tu tienes 30 campos, con que en la select indiques solamente los campos que quieres (nunca el select *) vas que chutas.

Un saludo :P

EnZo
EnZo #3 Mar '07

Ok, ahora yo te lo planteo de esta manera. Las estadisticas de usuario se estan modificando continuamente. Y se hacen muchas consultas en comparacion con la informacion personal.
Tal y como tu lo planteas ahorras en espacio fisico, pero en rendimiento? Es decir se supone que cuantos menos campos que comparar la consulta sera mas rapida no?

Y con los comentarios igual. Como lo planteas ahorras en codigo a la hora de programar. Pero rendimiento?
Si tengo 100.000 comentarios al dividirlo en 3 tablas se kedarian en 33.000, si hago una consulta a la tabla de 33.000 sera mas rapido si lo hago a una de 100.000 no?

Que opina(is)s?

Soltrac
Soltrac #4 Mar '07 MV Wizard

Sobre la primera parte, si todas las areas son iguales (es decir, tienen los mismos campos), lo mejor es hacer una columna de area. La razón la explica bien #2, es más reutilizable realizar un código que separe por areas que hacer 3 códigos diferentes. Además, imagina que quieres agregar más areas...no tendrías que modificar apenas el código.

Caso aparte sería que las áreas fueran diferentes, es decir, que por ejemplo, en música quisieras guardar ciertos campos y en informática otros, por lo que sería imposible hacerlo de esta manera.

Sobre la segunda parte, prefiero 100 veces la opción de todo en la misma tabla. Piensa que cuando quieras sacar todos los datos de las personas son 3 consultas! en vez de 1...además de que ocupas más espacio en disco.

Sobre lo que dices de dividirlo en 33.000....no va a durar exactamente 3 veces menos. Tu vas a indexar la tabla por el campo id, por lo que el tamaño de la tabla no va a importar tanto. Échale un vistazo como funcionan las indexaciones en bases de datos y verás la verdadera magia de las bb.dd. relacionales :D

Eso si, indexar = menos tiempo de búsqueda, pero más tiempo al añadir y actualizar, pero como nunca vas a actualizar el ID de la persona por ser clave primaria, te merece la pena y bastante.

En conclusión al tochazo y resumen para vagos, en mi opinión, a la primera parte de tu pregunta, utiliza solo 1 tabla y a la segunda parte también 1 sola tabla.

IS4kO
IS4kO #5 Mar '07

Efectivamente Enzo, lo suyo es diversificar la información, sin que llegue a resultar redundante, para que puedas realizar consultas específicas dependiendo del dato al cual quieras acceder.

En el caso que comentas, lo suyo sería:

  • Una tabla de áreas con: id_area, nombre_area..
  • Otra para comentarios: id_comentario, id_area, id_usuario,....
  • Resto de Tablas: Usuarios, etc...

Un error que solemos comenter, es que creemos que por tenerlo todo en una misma tabla la eficiencia será mayor, pero no es así... os invito a que hagais pruebas de rendimiento, a poder ser con TOAD sobre oracle

No cabe duda que es mucho más facil tenerlo todo en una misma tabla, a la hora de realizar las consultas etc... pero para tener un sistema de información bien distribuido, la primera máxima es diversificar sin redundar.

Un ejemplo facilillo:

Usando un sistema "distribuido", nuestra tabla áreas puede tener por ejemplo 10 registros

Si en la misma tabla areas metiéramos los comentarios, dicha tabla tendría para cada id_area cientos de registros.... por lo que posteriormente el acceso a la misma sería menos eficiente...

De todas formas, estos temas de rendimiento suelen tenerse en cuenta cuando pasamos de 99K registros por tabla, aunque siempre depende del servidor y de como queramos hacer bien nuestro trabajo.

Soltrac
Soltrac #6 Mar '07 MV Wizard

#5 lo que dices es totalmente válido, es más, por el ejemplo que estás dando, estás dejando todas las tablas en 2ª/3ª forma normal, totalmente adecuado para una bb.dd. relacional, pero....si lees bien lo que pide #1, no es lo que él pregunta.

IS4kO
IS4kO #7 Mar '07

#6 No se, he releido el post y creo que lo que necesita es exactamente eso (#5) de hecho, cuando te haces todo un modelo de datos con sus diagramas E-R se supone que es pq tendrás un esquema relacional de tablas..

Enzo plantea 2 preguntas a las que las doy la misma respuesta:

1º Comenta si es mejor hacer una tabla para cada área y yo le respondo que lo suyo es hacerse una tabla con todas las áreas, otra para comentarios etc...

2º Pregunta sobre un esquema parecido al de las áreas pero para usuarios, la respuesta sería la misma.

  • Tabla de cuenta: id_cuenta, id_personal, id_estadisticas, pass, user
  • Tabla personal: id_personal, id_cuenta, id_estadisticas, nombre, edad..
  • Tabla Estadísticas: id_estadistica, id_cuenta,...

Si no es el significado del post, perdón por el rollo.. :)

Un saludo

Soltrac
Soltrac #8 Mar '07 MV Wizard

#6

Por lo que yo entiendo...en la primera parte pregunta si debe hacer esto:

1era opción

Tabla comentarios_informatica
Tabla comentarios_musica
Tabla comentarios_deporte

2ª opción

Tabla comentarios, con una columna idArea (evidentemente relacionada con una tabla de areas como comentas tú), para diferenciar los comentarios de cada área.

En la segunda pregunta, dice si conviene hacer:

1ª opción

Tabla usuario_informacion
Tabla usuario_personal
Tabla usuario_estadisticas , todas compartiendo el mismo id_usuario

ó

2ª opción

Tabla usuario, donde estén todos los campos de información, personal y estadísticas.

En ambos casos, por lo que he expuesto en #4, he recomendado usar la 2ª opción.

Al menos, yo lo he entendido así jejeje, que por cierto, lo que has puesto en #7 se parece mas a lo que yo digo, aunque en la segunda parte defiendes la primera opción :P, cosa q yo no comparto por lo que he dicho :)

IS4kO
IS4kO #9 Mar '07

1era opción



Tabla comentarios_informatica
Tabla comentarios_musica
Tabla comentarios_deporte

En esta Opcion estas probocando una redundancia de datos... ya que tienes tres tablas para las mismas columnas (aunque luego puedas meter alguno nuevo para cada tabla)

2ª opción

Veo que aquí estamos de acuerdo :D

1ª opción

Tabla usuario_informacion
Tabla usuario_personal
Tabla usuario_estadisticas , todas compartiendo el mismo id_usuario

Este sería el mismo caso de la pregunta anterior, en el cual estamos de acuerdo :) diversificamos la información en distintas tablas, si quisieramos sacar las estadisticas de un usuario determinado consultariamos directamente sobre usuario_estadisticas.

2ª opción

Tabla usuario, donde estén todos los campos de información, personal y estadísticas.

Piensa en que por cada login que hagas tendrías que guardar un registro en la tabla usuario. Visto esto, si después quisieras sacar las estadisticas, para un solo usuario tendrías cientos de registros, con practicamente los mismos datos diferenciadas por el login..

Soltrac
Soltrac #10 Mar '07 MV Wizard

#9 es q yo entiendo por logins...el nº de logins como contador, no los diferentes logins

Evidentemente, si queremos guardar cada login que se hacen, con su fecha, etc..habría que separar la tabla, ya que duplicaríamos los demás valores de nombre, apellidos, bla bla bla bla y nos cargaríamos el principio de las formas normales :P.

¿Llegamos a estar de acuerdo entonces?

IS4kO
IS4kO #11 Mar '07

EEEEEse es el el tema, si quiere registro de logins (momento en el cual te conectas a la aplicación), para después poder elaborar tus estadísticas en condiciones.... debes separarlo/distribuirlo :) for example: veces que se ha conectado entre ayer y hoy, o a qué lugares se conecta la gente de esta hora a esta hora...

Llegamos al consenso yujuuu ;)

EnZo
EnZo #12 Mar '07

Conclusion: en ambos casos es mejor unificar tablas no?

Gracias a los dos. :D

IS4kO
IS4kO #13 Mar '07

Noooo!!!!!!!!!!

En ambos casos, lo mejor es distribuirlas :)

Usuarios habituales

  • IS4kO
  • EnZo
  • Soltrac
  • SeiYa