Así que esto es más una cuestión de diseño.

Tengo una clave primaria (dicen que el ID del usuario), y tengo toneladas de información asociada con el usuario.

Debo tener varias tablas se dividen en categorías de acuerdo a la información, o debería tener sólo una tabla con muchas columnas?

La forma en que solía hacer era tener varias tablas, por así decir, una tabla para la aplicación de uso de datos, una tabla para la información de perfil, una tabla para la parte final de tokens, etc. para mantener las cosas en busca organizado.

Recientemente, uno me dijo que es mejor que no hacerlo de esa manera y tener una tabla con muchas columnas está bien. La cosa es que todas las columnas tienen la misma clave primaria.

Soy bastante nuevo para diseño de base de datos por lo que el enfoque es mejor y cuáles son los pros y los contras?

¿Cuál es la forma convencional de hacerlo?

  • Para mayor claridad, me corrigen si estoy equivocado, pero creo que el «varias tablas» puede ser entendido como enlace/asociativa de la tabla: en.wikipedia.org/wiki/Associative_entity
  • Es esta base de datos necesarios para fines analíticos o de funcionamiento/de procesamiento de transacciones?
InformationsquelleAutor Xavier_Ex | 2012-03-19

8 Comentarios

  1. 102

    Cualquier momento la información es uno-a-uno (cada usuario tiene un nombre de usuario y contraseña), entonces es probablemente mejor para tener una mesa, ya que reduce el número de combinaciones de la base de datos se necesita hacer para recuperar los resultados. Creo que algunas bases de datos tienen un límite en el número de columnas por tabla, pero yo no me preocuparía por eso, en casos normales, y siempre se puede dividir más tarde si es necesario.

    Si los datos es uno-a-muchos (cada usuario tiene miles de filas de la información de uso), entonces se debería dividir en tablas separadas para reducir la duplicación de los datos (datos duplicados desechos espacio de almacenamiento, espacio de caché, y hace que la base de datos más difícil de mantener).

    Usted puede encontrar el artículo de la Wikipedia en la normalización de la base de datos interesante, ya que explica las razones de ello en profundidad:

    De la base de datos la normalización es el proceso de organización de los campos y las tablas de una base de datos relacional para minimizar la redundancia y la dependencia. La normalización generalmente implica la división de las tablas de gran tamaño en otros más pequeños (y menos redundante) tablas y definir las relaciones entre ellos. El objetivo es aislar los datos para que las adiciones, eliminaciones y modificaciones de un campo puede ser hecho en una sola tabla y, a continuación, se propaga por el resto de la base de datos a través de las relaciones definidas.

    La desnormalización también es algo a tener en cuenta, ya que hay casos donde la repetición de los datos es mejor (ya que reduce la cantidad de trabajo de la base de datos debe hacer cuando la lectura de los datos). Me gustaría recomendar encarecidamente hacer que sus datos como normalizada posible que para empezar, y sólo denormalize si eres consciente de los problemas de rendimiento en consultas específicas.

    • Gracias por tu respuesta, así que después de leerlo creo que lo que me estaba hablando era el uno-a-uno la información de la situación, cuando un usuario tiene muchos, uno-a-uno columnas.
    • Sí, si sólo hay una columna por cada usuario, a continuación, sólo una enorme tabla de usuarios será más fácil trabajar con (y mucho más fácil para el motor de base de datos para optimizar).
    • Tu post editado proporciona más información útil! Tengo una nueva inquietud de que si algunas de las columnas se actualiza con frecuencia, debo poner los en mesas separadas? Por ejemplo, la fecha de nacimiento de un usuario no se actualiza nunca, pero la parte final token puede ser invalidado después de un período de tiempo y se requieren actualizaciones frecuentes. Sería mejor si yo separado en las tablas de esta manera a mejorar el rendimiento? Ahora voy a ir a leer acerca de la wiki que usted ha mencionado 🙂
    • Yo no lo recomendaría. Usted obtener un rendimiento significativamente mejor cuando usted puede mirar todos los datos que necesita en una tabla (véase la desnormalización del artículo). Las combinaciones son caros debido a que (1) se requiere buscar datos en múltiples lugares, que pueden implica busca en un disco giratorio, (2) por lo general requieren de varios índices y algún tipo de combinación, y (3) hacen que la planificación de la consulta más difícil, que no sólo lleva su tiempo, pero también aumenta las posibilidades de que el optimizador de consultas conseguir algo mal (y mal optimizado consultas pueden ser realmente lento).
    • Básicamente, mi recomendación es hacer que tus datos como «normal» posible ahora, si usted encuentra cualquier consultas son lentos, hacer lo que usted necesita hacer para conseguir sus objetivos de rendimiento (este es el mismo consejo que daría para cualquier tipo de optimización).
    • Hmmmm estoy de acuerdo con tus puntos, pero no del todo en el primero, sin embargo, incluso si me almacenar toda la información en una tabla, la búsqueda de datos todavía podría exigir a girar el disco, los datos podrían no estar físicamente en un lugar al que prácticamente son.
    • Recientemente me encontré con el mismo problema, debido a que MySQL tablas InnoDB es relativamente pequeña límite de longitud (~8000 bytes). En mi tabla del problema (datos de muy larga formas de seguro, más de 100 columnas) tenemos varias columnas varchar, todos UTF8. Así, fácilmente nos llenó el ~8000 bytes límite y tiene «error 139 de motor de almacenamiento» todo el tiempo. Así que tuvimos que dividir la tabla. (Hemos probado con el nuevo Barracuda formato y funcionó sin dividir, pero nuestros servidores del cliente, siendo el uso de MySQL 5.0).
    • Básicamente, me siento igual, todo depende de los casos de uso. Como si el caso de uso es siempre para obtener el perfil de datos por separado y back-end-tokens por separado. Entonces uno debe ir para las distintas tablas, en lugar de la carga enorme de datos en la memoria. Pero si el caso de uso es para obtener los datos de perfil y back-end de fichas de datos y algunos otros datos, a continuación, una consulta es mejor que varias consultas. Por lo que depende totalmente de los casos de uso.
    • Estoy diciendo que usted debe tener varias tablas, no lo que usted debe hacer varias consultas. Esto es lo que UNIRSE es para.

  2. 12

    Una mesa grande es a menudo una mala elección. Tablas relacionadas son lo relacional de la base de datos se han diseñado para trabajar con. Si usted índice correctamente y saber cómo escribir rendimiento de las consultas, que se va a realizar el bien.

    Cuando las tablas obtener demasiadas columnas, entonces usted puede tener problemas con el tamaño real de la página que la base de datos es el almacenamiento de la información. El registro puede llegar a ser demasiado grande para la página, en la que usted puede no ser capaz de crear o actualizar un registro específico, que hace que los usuarios infeliz o se puede (en SQL Server al menos) se permitió a algunos de desbordamiento para determinados tipos de datos (con un conjunto de reglas que usted necesita para buscar si usted está haciendo esto), pero si muchos registros se desborde el tamaño de página puede crear tremedous problemas de rendimiento. Ahora, ¿cómo MYSQL maneja las páginas y si usted tiene un problema cuando el potencial del tamaño de la página se vuelve demasiado grande, es algo que tendría que buscar en la documentación de la base de datos.

    • Ah voces diferentes! Que siempre está muy bien. Gracias por la información! Me aseguraré de que soy consciente de que cuando hago mis tablas… pero yo no sabía que tendría que ser conscientes de que la baja de nivel de materias originalmente.
  3. 4

    Tengo un buen ejemplo. Demasiado base de datos Normalizado con el siguiente conjunto de relaciones:

    people -> rel_p2staff -> staff

    y

    people -> rel_p2prosp -> prospects

    Donde la gente tiene nombres y detalles de las personas, el personal tiene el personal de registro de detalles, perspectivas acaba de perspectivas de detalles, y la rel tablas relación de tablas con claves externas de las personas de vinculación de personal y perspectivas.

    Este tipo de diseño se realiza para toda la base de datos.

    Ahora a consulta de este conjunto de relaciones es un multi-mesa de unirse a cada tiempo, a veces de 8 y más tabla de unión. Ha estado trabajando muy bien hasta mediados de este año, cuando comenzó a ponerse muy lento ahora que hemos pasado 40000 registros de las personas.

    De indización y de todas las bajas que cuelgan frutas se habían utilizado hasta el año pasado, todas las consultas se han optimizado a la perfección. Este es el final del camino para el particular normalizado de diseño y de gestión aprobado un reconstruida de toda la aplicación que depende de él, así como la reestructuración de la base de datos, en un plazo de 6 meses. $$$$ Ouch.

    La solución es tener una relación directa para people -> staff y people -> prospect

    • Estaría interesado en saber cómo la reconstrucción fue? Fue que empezaste a diseñar algo similar a la única tabla de herencia donde había una type ser un staff o un prospect?
    • Fui con relación directa con la gente -> el personal y las personas -> perspectiva, funciona de maravilla, fácil de usar, rápido para consulta.
  4. 4

    Llegó a través de este, y como alguien que solía usar MySQL mucho, y luego cambió a Postgres recientemente, una de las grandes ventajas es que se pueden agregar objetos JSON a un campo de Postgres.

    Así que si usted está en esta situación, usted no tiene que necesariamente tenga que decidir entre una gran tabla con muchas columnas y división, sino que puede combinar columnas en objetos JSON para reducir que, por ejemplo, en lugar de con domicilio en 5 columnas, sólo puede ser uno. También se puede consultar en el objeto demasiado.

    • lo que acerca de él de rendimiento cuando se utiliza un objeto json, mientras que la consulta?
    • el rendimiento está muy bien para las aplicaciones que he usado. No he hecho mi propio benchmarking en él, pero esto podría ser de utilidad para usted: arangodb.com/2018/02/…
  5. 3

    hágase estas preguntas, si pones todo en una tabla, usted tiene varias filas para ese usuario? Si tiene que actualizar un usuario desea mantener una pista de auditoría? El usuario puede tener más de una instancia de un elemento de datos? (como número de teléfono, por ejemplo) usted tiene un caso donde es posible que desee añadir un elemento o conjunto de elementos de la tarde?
    si la respuesta es que sí, entonces lo más probable es que quiere tener hijo tablas con relaciones de clave externa.

    Pros de padre/hijo tablas es la integridad de los datos, el rendimiento a través de índices (sí, usted puede hacerlo en una tabla plana también) y de la OMI más fácil de mantener si se necesita añadir un campo más tarde, especialmente si va a ser un campo obligatorio.

    Contras de diseño es más difícil, las consultas se convierten en un poco más complejo

    Pero, hay muchos casos donde una gran mesa plana y será apropiado para que usted tiene que mirar a su situación para decidir.

    • Gracias por recordármelo! Así que en mi caso me fue de sólo considerar el caso en el que cada usuario no puede tener más de una fila de modo que todos los campos de información son uno-a-uno. Asimismo, el usuario no puede tener más de una instancia de un mismo elemento, como creo en el concepto de un elemento no puede existir en más de un lugar. A la tercera pregunta, sí, yo podría agregar más elementos a la tabla, pero que no se rompa con los requisitos que he mencionado anteriormente. Creo que el padre/hijo de la tabla es bueno cuando quiero asociar varias filas a un usuario, pero en este caso, mi preocupación es que un usuario tiene muchos, uno-a-uno columnas.
    • incluso si todos los elementos son en la actualidad uno a uno, que no obviar la necesidad o el deseo de tener padre/hijo tablas de la OMI. Manteniendo un registro de los datos modificados, es de un solo uso. carga diferida de los objetos es otro. mientras que hay ventajas en una sola estructura de la tabla hay beneficios para padres e hijos diseños así (aunque he visto que la gente vaya a los extremos con estas así).
  6. 1

    Ya estoy hecho de hacer algún tipo de diseño de base de datos. para mí, esto depende de la dificultad del sistema de gestión de bases de datos; sí es cierto que para tener los datos en un único lugar, pero es realmente difícil de hacer consultas con demasiado base de datos normalizado, con un montón de registro. Simplemente combine los dos esquemas; el uso de una enorme mesa, si usted siente que usted va a tener una enorme registros que son difíciles de mantener como facebook,gmail,etc. y el uso de tabla diferente para un conjunto de récord para el sistema simple… bueno esta es solo mi opinión .. espero que podrían ayudar.. solo hacerlo..se puede hacer… 🙂

    • «el uso de una enorme mesa si vas a tener una enorme records..» Pero Facebook, Google no almacena los datos de usuario en una sola tabla, se separó de ellos como muchas tablas.
  7. 0

    La forma convencional de hacer esto sería el uso de diferentes tablas como en un esquema en estrella o copo de nieve esquema. Howeevr, me gustaría base de esta estrategia de dos vertientes. Yo creo en la teoría de que los datos sólo deben existir en un solo lugar, no para el esquema que he mencionado que iba a funcionar bien. Sin embargo, también creo que para los motores de creación de informes y suites de BI, un enfoque en columnas sería muy beneficioso porque es más de apoyo de las necesidades de generación de informes. Columnas de enfoques como los que infobright.org tienen enormes mejoras en el rendimiento y la compresión que hace que el uso de ambos enfoques increíblemente útil. Una gran cantidad de empresas están comenzando a darse cuenta de que sólo tiene una arquitectura de base de datos en la organización no es de apoyo de la gama completa de sus necesidades. Un montón de empresas que están implementando el concepto de tener más de una base de datos achitecture.

    • Gracias por la información, pero lo siento, no entiendo muy bien tu respuesta… voy a hacer una búsqueda en los dos esquemas que se menciona por primera vez…
  8. -3

    creo que tener una sola tabla es más eficaz, pero usted debe asegurarse de que la tabla está organizada de una manera que muestra la relación,tendencia, así como la diferencia en las variables de la misma fila.
    por ejemplo, si la tabla se muestra la edad y las calificaciones de los estudiantes debe arange la mesa en una manera que gracias goleador es bien diferenciado con el menor y goleador de la diferencia en la edad de los estudiantes es aún.

Dejar respuesta

Please enter your comment!
Please enter your name here