¿Por qué crear tablas en tiempo de ejecución (código detrás) es malo?

Question

Se sugiere evitar crear dinámicamente la tabla de la base de datos (o, en tiempo de ejecución), diciendo que es una mala práctica y será difícil de mantener.

No veo el motivo, y no veo la diferencia entre crear una tabla y cualquier otra consulta/instrucción SQL como SELECT o INSERT. Escribí aplicaciones que crean, eliminan y modifican bases de datos y tablas en tiempo de ejecución, y hasta ahora no veo ningún problema de rendimiento.

¿Alguien puede explicar los inconvenientes de crear bases de datos y tablas en tiempo de ejecución?

Answer 1

Las tablas son entidades mucho más complejas que las filas y la creación de tablas de administración es mucho más compleja que una inserción que debe cumplir con un modelo existente, la tabla. Es cierto que una declaración de creación de tabla es una operación SQL estándar, pero depende de crearlas dinámicamente huellas de malas decisiones de diseño.

Ahora, si solo crea uno o dos y eso es todo, o una base de datos completa dinámicamente, o desde un script una vez, eso podría estar bien. Pero si usted depende de tener que crear más y más tablas para manejar sus datos, también necesitará unirse cada vez más y consultar más y más. Un problema muy serio que encontré con una aplicación que hizo uso de la creación de tablas dinámicas es que una sola consulta de SQL Server solo puede incluir 255 tablas. Es una restricción incorporada. (Y eso es SQL Server, no CE.) Solo tomó unas pocas semanas en producción para alcanzar este límite, lo que resultó en una aplicación que no funcionaba.

Y si llega a editar las tablas, p. agregar/soltar columnas, entonces su dolor de cabeza de mantenimiento empeora aún más. También está la cuestión de vincular sus datos de DB a la lógica de su aplicación. Otro problema es actualizar las bases de datos de producción. Esto realmente sería un desafío si un DB hubiera estado creciendo con objetos dinámicamente y de repente necesitara actualizar el modelo.

Cuando necesite almacenar datos de una manera tan dinámica, la práctica estándar es hacer uso de EAV models. Tiene tablas fijas y sus datos se agregan dinámicamente como filas para que su esquema no tenga que cambiar. Hay inconvenientes, por supuesto, pero generalmente se piensa que es una mejor práctica.

Answer 2

Deberá ser un poco más claro sobre lo que quiere decir con "crear tablas".

Una razón para no permitir que la aplicación controle la creación y eliminación de tablas es que esta es una tarea que debe ser manejada solo por un administrador. No desea que los usuarios normales tengan la capacidad de eliminar tablas completas.

Las tablas temporales son una historia diferente, y puede que necesite crear tablas temporales como parte de sus consultas, pero la estructura básica de la base de datos debe ser administrada solo por alguien con los derechos para hacerlo.

Answer 3

KMC,

Recuerde los siguientes puntos

1. ¿Qué pasa si desea agregar o eliminar una columna, que muchos necesitan para cambiar el código y compilarlo AGIAN
2. ¿y si la base de datos cambios de ubicación
3. Los desarrolladores que no son muy buenos en la base de datos pueden realizar cambios, si crea el esquema en el servidor, los DBA pueden encargarse de ello.
4. Si tiene algún problema de rendimiento, puede ser difícil depurarlo.

Answer 4

veces, la creación de tablas de forma dinámica no es la mejor (inyección SQL de Google) opción de seguridad-sabia, y que sería mejor utilizar procedimientos almacenados y tienen sus operaciones de inserción o actualización ocurrir a nivel de base de datos mediante la ejecución de los procedimientos almacenados en codigo.