Tabla MySQL con campos TEXT y BLOB

[Irwin Rodriguez]

Saludos colegas,

Alguien ha trabajado con tablas MySQL de muchos campos y ademas con campos TEXT y/o BLOB?

Estoy migrando una base de datos de DBF a MySQL y me encuentro con tablas que tienen separadas las imagenes y observaciones de la tabla principal. Supongo que era porque en ese entonces era por temas de rendimiento y velocidad ya que es de un sistema hecho en FOX 2.0.

Pero ahora la cosa ha cambiado y pienso que tener esos campos juntos en una sola tabla en teoria no deberia de afectar mucho en el rendimento o si? Es conveniente dejar esos campos en tablas separadas o es mejor unirlos de una vez? No afectará en temas de busquedas ni de indexado?

Gracias...!

--

DISTRIBUIDORA IRSESU, C.A

J-29947174-7
Irwin Rodríguez - Director

Analista Programador - Freelance
+584125210679

Barquisimeto - Venezuela
Desarrollos online dentro y fuera del país

[Antonio Meza]

Hola!!

En lo personal uso los campos Text y Blob por separado, no tengo a la mano el articulo donde explican porque es mejor, pero tiene que ver con rendimiento y ahí recuerdo que explicaba el o los detalles, incluso si un campos text o blob no tiene nada es mejor que sea NULL, a ver si lo encuentro.

saludos

Antonio Meza

[mpulla]

Hola Irwin.

Teniendo en cuenta la defracmentacion de las paginas de datos lo tendría en tablas separadas.

Saludos.

Mauricio

[Víctor Hugo Espínola Domínguez]

Otra ventaja de la tabla separada es que con ese esquema es fácil implementar más de una imagen por cada PK del maestro.

Saludos,

Víctor.

Lambaré - Paraguay.

[Irwin Rodriguez]

Entiendo, me parece que es mejor dejarlos separados entonces. De hecho tengo un cliente que tiene campos BLOB y  LONGTEXT con 200 mil registros y a veces en las consultas le demora bastante en responder, y eso que cuenta con indices. Creo que mejor me voy por la opcion de dejarlas separadas.

Saludos!

[mapner]

En mi caso uso firebird pero mi estrategia es usar una tabla genérica llamada Blobs que permite ser referenciada por cualquier otra tabla maestra con una FK compuesta: TablaMaestra, pkTablaMaestra, nombreCampoBlob
Da más flexibilidad en muchos sentidos. Una buena sugerencia con BD y blobs es no hacer consultas masivas de registros qur incluyan estos campos dado que a primera instancia no se sabe cuantos bytes pesa el contenido y que consecuencia puede tener en el rendimiento de la red (LAN o WAN). Lo mejor es ubicar el registro en cuestión en la tabla maestra y luego hacer un lectura de sus campos blobs por separado. (Lazy Loading)
Saludos

[Esteban H]

Será este el artículo q mencionas Antonio?

 

https://firebird21.wordpress.com/2015/10/16/consultas-a-tablas-que-tienen-columnas-de-tipo-blob/

 

Saludos.

 

Esteban.

[Antonio Meza]

Es parecido, ya que el otro habla sobre Mysql con campos Null, pero lo encontré gracias a la referencia de Walter Ojeda, es decir gracias a su comentario investigue que hacia Mysql en esos casos y no hay mucha información, encuentras mucho que ocupan mas espacio los null que otro valor, pero haciendo pruebas con mysql note que era mejor usar Null y el articulo que leei,

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Nosotros implementamos tablas mysql con los text dentro de las tablas (algunos text con cerca de 2MB) y no tenemos problemas de desempeño (las demoras son emergentes de que buscamos por fulltext, con varias condiciones lógicas y por ende la respuesta da alguna demora lógica y aceptable).

Las imágenes, se apuntan por separado (archivos en disco, no en blobs) fundamentalmente porque el sistema es web, y entonces, por corriente ajax normal, devolvemos el texto a mostrar, y por carga propia (estándar) del html, este se encarga de subir las imágenes al navegador, apuntadas desde el html anterior.

Si las imágenes estuvieran en blob, el proceso sería un poco más complicado y un poco más lento.

La desnormalización que implica poner los archivos blobs en tablas separadas es un anti-patrón de diseño que cae dentro lo que justifica aplicar dicho anti-patrón.

Por si no me entendieron. Es correcto tener las imágenes en tablas separadas del conjunto de datos principal. E importante tener las imágenes en la bd, porque así, cuando se hace el BK de la BD, se hace el BK de las imágenes.

Más de uno perdió las imágenes por tenerlas solamente en archivos comunes de disco.

Un anti patrón de diseño es algo que en principio es un diseño inapropiado o incorrecto, pero que bajo ciertas circunstancias (Y en el caso de las imágenes, lo es) es una solución apropiada.

Saludos: Miguel

Larga Vida y Prosperidad

Que la Fuerza los acompañe

[Antonio Meza]

El guardar la ruta del archivo de imagen en la base de datos o guardar físicamente el archivo en la base de datos ya es necesidad de cada Proyecto, por lo que no existe un estándar si no necesidades, lo mas correcto y practico es almacenarlos en la base de datos lo que te da movilidad y seguridad de la información, en el caso de SqlServer pues cuenta con un Motor para resolver parte de este problema y no tener físicamente los archivos contenidos en la base de datos y al respaldar se los lleva, pero no todos usamos sqlserver jejeje

Imaginen el caso de tener un servidor Web, donde accesas a las imágenes, pero las tienes en archivos separados de la base de datos, para las paginas web no existirá ningun problema, pero que pasa si desarrollas una aplicación de escritorio y tienes que accesar a esas imágenes? como vas a resolver el problema de traerte las imágenes? si estas están en carpetas dentro del servidor web, a demás que si no proteges bien la carpeta donde están las imágenes en el servidor web cualquier usuario podrá hacer uso de esas imágenes poniendo la ruta en el navegador.

Teniendo las imágenes en la base de datos ya tienes protegido las mismas y puedes fácilmente enviarlas al programa de escritorio, mas aun que pasa si decides separar el servidor web de la base de datos?? que es lo mas correcto, es decir tienes Server01 donde esta solamente la parte web y tienes otro servidor para la base de datos Data01 y capetas de imágenes, como le enviaras las imágenes al servidor web??? 

La realidad es que siempre sera mejor guardar las imágenes en la base de datos y en Base64 que ocuparan mas espacio pero serán transportables a donde sea sin problema alguno y seguridad adicional.

La desnormalización que implica poner los archivos blobs en tablas separadas es un anti-patrón de diseño que cae dentro lo que justifica aplicar dicho anti-patrón.

No concuerdo con tu comentario Miguel, el separar los campos en varias tablas no tienen nada que ver con anti-patrón de diseño, simplemente es algo que se aplica justamente en la normalizaciíon, y se le llaman particiones verticales, lo que te permite separar cierta información que no sera recurrente de la que si, esto al motor de base de datos le es mas sencillo buscar información que el tener todo junto, 

El particionamiento vertical divide una tabla en varias tablas que contienen menos columnas. Los dos tipos de particionamiento vertical son la normalización y la división de filas:

• La normalización es el proceso estándar de bases de datos que consiste en quitar columnas redundantes de una tabla y colocarlas en tablas secundarias vinculadas a la tabla principal mediante relaciones de clave principal y clave externa.

• La división de filas divide verticalmente la tabla original en tablas con menos columnas. Cada fila lógica de una tabla dividida coincide con la misma fila lógica en las demás tablas, según se identifica en la columna UNIQUE KEY que es idéntica en todas las tablas con particiones. Por ejemplo, al combinar la fila con el Id. 712 de cada tabla dividida se vuelve a crear la fila original.

Al Igual que las particiones horizontales, el particionamiento vertical permite a las consultas recorrer menos datos. De ese modo se aumenta el rendimiento de las consultas. Por ejemplo, una tabla que contenga siete columnas de las cuales generalmente sólo se hace referencia a las cuatro primeras, puede beneficiarse de la división de las tres últimas columnas en una tabla independiente.

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Si pongo las imágenes en una tabla separada, puede crear una relación muchos a muchos de manera tal que un ítem que tenga una imagen, pueda compartirla con cualquier otro ítem que tenga la misma imagen.

Poner las imágenes por separado, tal como indiqué es un anti-patrón, o sea que prima facie es incorrecto, pero bajo ciertas circunstancias (limitaciones en el SGBD, p.e., que se ponga lento, o limitaciones en el tamaño de la tabla o de la bd), el anti-patrón es de aplicación.

Por ejemplo, en fox, una tabla tiene un límite de 2 Gb, y los archivos también tienen ese límite de tamaño, entonces las imagenes podrían "rebasar" la capacidad de almacenamiento.

Y no entiendo que me criticas, porque justamente en el segundo párrafo del texto que cut&paste, justifica la separación de las tablas.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe.

[Antonio Meza]

Miguel, hablas de desnormalizacion y anti-patrones de diseño, es decir dices que separar los campos Blobs en tablas es desnormalizacion y es un anti-patron, cosa que como indique no estoy de acuerdo con lo que comentas y en el texto que anexe explica que el separar los campos de una tabla no tiene nada que ver con desnormalizacion.

Si tienes una fuente donde explique a detalle tu punto porque dices que separar los campos de una tabla es desnormalizacion seria valioso!!

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Cuando se hablo sobre el uso o no de indices pk autoincrementales, pase una bibliografía donde habla de anti-patrones y cuales son las situaciones donde amerita usarlos. Además tienes a Silverschatz (o algo así), Date, y unos cuantos autores más (hay bibliografía de profesores de creo que Carlos III de España muy buenos).

A la tarde, cuando esté en casa te paso algo de lo que he visto.

Pero podes ver en http://labda.inf.uc3m.es/publications.php que hay para hacer dulce (;-D

Creo que el leí es:

Dolores Cuadra, Elena Castro, Ana Iglesias, Paloma Martínez, Francisco Javier Calle, César de Pablo-Sánchez, Harith Aljumaily, Lourdes Moreno, (2007). Desarrollo de Bases de Datos: Casos Prácticos Desde el Análisis a la Implementación, ESPAÑA, October, 2007, Ra-Ma, ISBN: 9788478978359, pp: 569.

Es más, algunos expertos (con fundamentos que van más allá de lo que estamos comentando ahora) indican que si está bien normalizado no pueden existir relaciones 1 a 1 en una BD (que sería el caso de la particion vertical).

A mi entender, cualquier bd debe ser normalizada al menos hasta 3FN como también comentaron en este foro. Si luego se aplica Boyce-Codd, 4FN y siguientes dependerá mucho de los requerimientos de cada sistema. Cuando haces particionado vertical, en principio sería un anti-patrón, pero que circunstancialmente puede ser apropiado.

Por ejemplo, en VFP, cuando usas un campo memo o blob, estás haciendo un particionado físico, los datos de longitud fija están en el dbf, los de longitud variable en el FPT.

Y eso es apropiado, porque simplifica y optimiza el acceso a los datos de tamaño fijo (por eso siempre decimos que no usen el SELECT *.

Que quede claro, usar un anti-patrón no está mal, lo que es necesario es justificarlo apropiadamente.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, pero ahorren, que sacaron los subsidios

[Antonio Meza]

Hola Miguel, en lo personal me gusta citar el detalle de lo que hablo, pero bueno no todos somos iguales jajaja citar nombres pues no me lleva rápido a ver ejemplo sobre lo que hablas en fin gracias por la información.

Encontré una diapositiva que habla sobre antipatron de diseño de base de datos relacionales y ya entiendo porque odias a los autoincrementables jajajaj porque según esto es un antipatron, a demás separar los campos de las tablas también es un antipatron, entonces si todo es antipatron para que se esmeraron en las normalizacion jajajaj en fin mi lógica sin títulos, doctorados ni maestrías me sigue diciendo que no todo lo que brilla es oro!!!! por lo tanto algunas cuestiones mencionadas en los antipatrones se contradicen, es decir en una parte dicen que no y entro parte dicen que si jajajajaj

http://datosintensos.blogspot.mx/2012/07/sql-de-manera-efectiva-los-antipatrones.html

saludos

Antnoio Meza

[Carlos Miguel FARIAS]

La opinión de las diapositivas es una opinión de cuartas, en links previos, cuando se trato el tema de AI, pase un libro sobre el tema de anti-patrones y cuando es válido utilizarlos (un libro, no 14 diapositivas, que no están mal, pero son de cuartas).

Y además, evidentemente, lees mal, porque yo no odio los autoincrementales, y si lees post míos en este foro de hace varios años atrás, indico que los uso (usaba, usaré) mucho, lo que indique últimamente, es que no siempre es lo mas conveniente y su uso debe analizarse en función de las especificaciones y requerimientos del sistema y no como "AI para todos y todas".

Entonces pareciera que buscas disentir de lo que digo, cuando no veo causal para ello.

Mi aporte es que ahora, en lugar de AI, estoy trabajando con claves calculadas, que tienen la ventaja de darme datos de auditoria, a la par de que me permiten juntar datos de diferentes BD sin posibilidad de conflictos, manteniendo una clave numérica única para la entidad.

Y la clave calculada (al menos el algoritmo que estoy usando), es más rápido que el AI, porque el cálculo se puede llevar al cliente (o hacerse en el servidor, A = A), pero no requiere gestión de ISOLATION como en el caso de los AI.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, estoy totalmente en desacuerdo en disentir ;-D

[Antonio Meza]

Si tu lo dices así sera!!! para evitar disentir!! jajajaj

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Lo que las diapositivas son de cuartas, fue una chanza por el nombre del autor (lo leiste?)