¿Debo usar tablas planas o una base de datos normalizada?

Tengo una aplicación web en la que estoy trabajando actualmente que utiliza una base de datos MySQL para el back-end, y necesito saber qué es mejor para mi situación antes de continuar.¿Debo usar tablas planas o una base de datos normalizada?

En pocas palabras, en esta aplicación los usuarios podrán construir sus propios formularios con cualquier número de campos (deciden) y ahora lo tengo todo almacenado en un par de tablas vinculadas por claves externas. Un amigo mío sugiere que para mantener las cosas "fáciles/rápidas" debería convertir el formulario de cada usuario en una tabla plana para que la consulta de los datos se mantenga rápidamente (en caso de un gran crecimiento).

¿Debería mantener la base de datos normalizada con todo agrupado en tablas relacionales con claves externas (índices, etc.) o debería construir tablas planas para cada nueva forma que crea un usuario?

Obviamente, algunos aspectos positivos de la creación de tablas planas son la separación de datos (seguridad) y se reducirán las velocidades de consultas. Pero en serio, ¿cuánto ganaré con esto? Realmente no quiero 10000 tablas y estar cayendo, alterando y agregando todo el tiempo, pero si será mejor que lo haré ... solo necesito algo de entrada.

Gracias

Fuente

2010-12-01 The Virtual Machinist

Normalizar hasta que duela. :) – shamazing

No es una respuesta real ... pero siempre puedes usar Wikipedia como guía. Aquí está el esquema de la base de datos de Wikipedia: http://commons.wikimedia.org/wiki/File:Mediawiki-database-schema.png – Dragontamer5788

@shamazing y luego se desnormaliza hasta que funciona. 80)) – Keng

Regla de oro. Es más fácil pasar de normalizado a desnormalizado que a la inversa.

Comience con un nivel razonable de normalización de bases de datos (por razonable quiero decir legible, fácil de mantener y eficiente pero no optimizado prematuramente), luego si tiene problemas de rendimiento a medida que crece, tiene la opción de buscar formas de desnormalización puede aumentar el rendimiento.

Fuente

2010-12-01 19:05:37

Coincidentemente, estaba leyendo este http://stackoverflow.com/questions/4301089/when-to-denormalize-a-database-design – Sathya

Bob Palmer, excelente respuesta. –

Gracias, Bob. Has hecho un buen punto. Apreciado enormemente. –

La alteración del esquema durante el tiempo de ejecución rara vez es una buena idea. Lo que quiere considerar es el modelo EAV (Entidad-Valor-Atributo).

Wikipedia tiene some very good info sobre los pros y contras, así como los detalles de implementación. EAV debe evitarse cuando sea posible, pero para situaciones como la suya con un número desconocido de columnas para cada formulario, EAV está considerando.

Fuente

2010-12-01 19:06:12 RedFilter

Nunca había oído hablar de EAV, pero parece ser similar a la solución que propuse anteriormente utilizando una tabla con pares clave/valor. ¿Mi solución propuesta es similar a la solución EAV que sugirió? Solo tengo curiosidad porque me gustaría obtener más información sobre el modelado de EAV. –

@Matt: sí, eso es exactamente correcto. En su caso, E = form_id, A = clave, V = valor. Existen versiones modificadas en las que tiene columnas de valores adicionales para diferentes tipos de datos, por lo que puede ganar eficiencia con índices y agregación, etc., pero esto también agrega complejidad a las consultas. – RedFilter

gracias por la información! –

Mantenga sus datos normalizados. El sistema se mantendrá rápido siempre que tenga una indexación adecuada.

Si realmente quieres ir rápido, cambia el esquema a una de las bases de datos de valores clave como bigDB/couchDB, etc. Eso está totalmente desnormalizado y es muy rápido.

Fuente

2010-12-01 19:06:35

... en esta aplicación los usuarios serán capaces de construir sus propias formas con cualquier número de campos ...

Ay! Entonces, ¿cómo podría posiblemente hacer algún tipo de normalización cuando los usuarios son, en esencia, tomar las decisiones de la base de datos para usted.

Creo que o bien necesitas gestionarlo paso a paso o dejar volar a tu monstruosa bandera y simplemente seguir comprando hardware para seguir el ritmo que obtendrás cuando los usuarios realmente comiencen a entrar ... .Comenzar en punto, mira lo que sucede cuando los usuarios comienzan a entender cómo crear nuevas formas y vistas en SharePoint ... CRIKY !! ¡¡Habla sobre el alcance arrastrándose !!

Fuente

2010-12-01 19:11:18 Keng

Defina claramente qué campos/entradas pueden crear. Limite la cantidad de personalizaciones que pueden hacer. El alcance está definido para el proyecto y no debe cambiar a menos que lo haga. Gracias por tu contribución. –

@Steve B. Puede considerar un palet de campos universales que pueden agregar que están normalizados. Por ejemplo: ID de empleado que va al emp_table para que las personas no vuelvan a crear la rueda. – Keng

Tengo una lista fija de 15 o más entradas que un usuario podría usar en un formulario, esto puede crecer pero es suficiente para hacer casi cualquier cosa que necesiten, se almacenan en una tabla estática y se vinculan por id a formularios de usuario . –

La forma en que iba a manejar esto es usar una mesa extensible normalizada, "propiedad", como a continuación:

Table: FormProperty 
id: pk 
form_id: fk(Form) 
key: varchar(128) 
value: varchar(2048)

Lo anterior es sólo un ejemplo, pero yo he utilizado este patrón en muchos casos , y tiende a funcionar bastante bien. El único "truco" real es que necesita serializar el valor como una cadena/varchar y luego deserializarlo a lo que sea necesario, por lo que hay una pequeña responsabilidad adicional en el cliente.

Fuente

2010-12-01 19:18:40

Para crear un formulario de inicio de sesión, por ejemplo, podría: insertar en FormProperty (form_id, key, value) valores (1, 'email', ''); insertar en FormProperty (form_id, key, value) values (1, 'password', ' contraseña'); –

Como alternativa al json/xml del ejemplo anterior, puede crear tablas adicionales para las propiedades del campo y vincularlas mediante claves externas. –

Mantenga sus datos normalizados. Si indexa correctamente, no encontrará problemas de rendimiento durante mucho tiempo.

En cuanto a la seguridad: El enfoque plano requerirá que escriba muchas tablas de creación/soltar, alterar declaraciones de tabla, es decir, mucho más código y muchos más puntos de falla.

La única razón para tener archivos sin formato sería cuando los usuarios se pueden conectar directamente a la base de datos (aún puede optar por la seguridad a nivel de fila). Pero en ese caso, usted está realmente reimplementar una variante de phpmyadmin

Fuente

2010-12-01 19:20:17 Martin

+1 muy buena respuesta.Martin, ¿qué hacer cuando los problemas de rendimiento comienzan a aparecer después de tanto tiempo? Nunca he trabajado con tantos datos/tráfico, por lo que no estoy seguro de cuál es el siguiente paso –

a) Los índices son * muy * rápidos: busca valores en 100 mio. la tabla de filas en general no presenta problema, siempre que las columnas relevantes estén indexadas. Entonces, realmente hay mucho margen de maniobra antes de llegar a problemas de rendimiento. b) Puede * particionar * tablas por rango, por ejemplo, crear una partición por cada 1000 ID de usuario. Sus consultas afectarán principalmente a un único ID de usuario y, por lo tanto, a una única partición, por lo que debería ampliarse casi linealmente. – Martin

== normalizados búsquedas rápidas, más fáciles de mantener índices, las operaciones de inserción más lentas (en múltiples filas)

desnormalizado == inserciones rápidas, esto se utiliza ususally cuando hay muchas inserciones (depósitos de datos que recopilan y registran datos cronológicos)

Fuente

2010-12-01 19:50:20 dexter

¿Debo usar tablas planas o una base de datos normalizada?

Respuesta

Cuestiones relacionadas