¿Por qué no crear y eliminar 'TABLE' cada vez que se insertan datos?

Question

He discutido con mi amigo sobre el esquema DB.

Nuestra aplicación lee un tipo de archivo csv, y luego inserta datos (casi 200 filas) en la tabla. En ocasiones, la aplicación necesita eliminar datos por nombre de archivo.

Por lo tanto, sugiero esquema de la tabla folloing -> [Key], [Texto], [Nombre de archivo]

es capaz de insertar datos con el nombre de archivo, a continuación, elimine los datos de nombre de archivo (eliminar de [TABLA] donde fichero = 'boolaboola').

Pero mi amigo, insiste en "¿Por qué no crear y eliminar 'TABLE' cada vez que se insertan datos?"

Su esquema de la tabla es -> [Key], [Texto]

Su idea es [Cuando la aplicación lee un archivo, la aplicación crea una tabla cuyo nombre es el nombre del archivo. Luego inserte datos en la nueva tabla. Cuando necesitamos eliminar datos por nombre de archivo, simplemente suelte la tabla.]

Aunque nuestra tabla no necesita una clave externa.

No pude estar de acuerdo con esa idea. En mi experiencia, sentí que el esquema DB está mal ... pero no puedo explicar y persuadir a mi amigo.

Por favor, ayúdame. ¿Estoy equivocado? o ¿cómo puedo persuadir a mi amigo?

Answer 1

En general, estoy de acuerdo con usted. Cambiar el esquema de la base de datos en mi humilde opinión debería ser una acción rara, preferiblemente solo cuando el software se actualiza. Sé que esto es muy estricto y 'no-NoSQL', pero esta es una base de datos relacional tradicional después de todo :).

Para una recomendación más específica, sería útil saber cómo piensa utilizar esta información. Almacenarlo en una tabla (tal vez particionado o con un índice en 'nombre de archivo' para el rendimiento, si eso es un problema) es más flexible: le permite hacer fácilmente análisis que abarcan datos de múltiples archivos.

Además, si posteriormente desea utilizar algún tipo de mapeador O/R u otras herramientas, a menudo es útil tener el esquema de la tabla bastante estático.

Answer 2

La eliminación de tablas aumenta el rendimiento porque la tabla no tendrá que volver a indexarse ​​y otros gastos generales del motor de DB; esto mejora mucho el rendimiento en datos de gran tamaño. Sin embargo, la creación de múltiples tablas aumenta la complejidad de su código, ya que tendrá que usar un índice propio para encontrar la tabla correcta en las consultas.

Answer 3

Solo por la perspectiva, un ejemplo del mundo real. No es exactamente una "respuesta", solo una historia :) Decidí publicarlo porque alguien dijo que cambiar el esquema [es decir crear y soltar tablas] debería ser una acción rara ". Sin dar una explicación satisfactoria.

Actualmente estoy trabajando en una gran aplicación para una gran corporación. Consiste en 80% de servidores PL/SQL (Oracle)- lado y 20% GUI del navegador (Javascript, basado en la excelente biblioteca YUI3 de Yahoo). La GUI solo tiene> 140 módulos individuales.

Desafortunadamente, la parte (más grande) del lado del servidor de la aplicación no tiene middleware, está todo escrito en PL/SQL. Eso se debe a que hace años era una aplicación pequeña donde esta arquitectura estaba bien, y nunca se obtienen fondos para escribir una versión "2.0 "(lo que significa comenzar desde cero, descartando el código 1.0). (Sin embargo, dadas las limitaciones, está sorprendentemente bien escrito, aunque muchas funciones PL/SQL exceden las 1000 líneas o incluso más)

Por lo tanto, aunque el middleware de su aplicación web realiza un seguimiento rutinario de las sesiones y los datos de la sesión, todo esto debe hacerse manualmente en PL/SQL, y lo hacemos creando MUCHAS tablas temporales. Hay una gran cantidad de datos para manejar. y en lugar de un caché de middleware, utilizamos tablas para datos de sesión, así como para ciertas funciones. Por ejemplo, cuando el usuario ingresa ciertos "casos de uso" de nivel superior, agregamos (grandes cantidades de datos muy detallados) en tablas temporales, y el usuario se sirve de esas tablas para el resto de su sesión. Esos casos de uso de alto nivel no necesitan los detalles, solo necesitan los agregados.

Entonces, crear y soltar tablas ... bueno, al menos lo hacemos, y funciona bien. No hay razones técnicas generales a favor o en contra, depende de su situación REAL MUNDO. Los puristas pueden quejarse de nuestra falta de un middleware, todo lo que quieren, por ejemplo, en el mundo real, las quejas no logran nada.

Sugiero tratar de ver la imagen más grande. ¿Por qué estás en contra de la creación dinámica de tablas? Son las razones realmente técnicas, entonces defiende tu posición con tanta fuerza (y astucia) como puedas. Sin embargo, con demasiada frecuencia tenemos tecnología. los muchachos son demasiado religiosos y se niegan a reconocerlo (ante nosotros mismos antes que nada).

Cuando te encuentras discutiendo por siempre (con otro "techie") sin que nadie pueda convencer al otro, puede ser un indicador de que el problema no es tan importante, porque simplemente no hay una respuesta obvia y justificable:) Las discusiones religiosas siempre son mucho más largas que las técnicas ;-)

La creación y eliminación dinámicamente de tablas es un caso de uso "legítimo". Cuando los datos se usan solo de forma temporal (en lugar de almacenarse "para siempre") y si se ejecutan consultas solo contra el conjunto de datos en esa temperatura. tabla (si se trata de tablas cruzadas hay un argumento pesado contra la tabla (s) temporal (es)), vaya por ello, si es conveniente en el gran esquema de cosas (su aplicación y escenario general).

PD: Ah, y, por cierto, en términos generales, no hay manera de decir mucho sobre la situación dada aquí, el rendimiento como argumento solo debe entrar en esto si realmente es un problema. Para el 95% de todas las situaciones, no lo es, el mantenimiento es mucho más alto en la lista.