¿Es bueno almacenar cadenas largas en una base de datos?

Question

Necesito almacenar cadenas largas en una base de datos. la cadena puede tener 5 o 6 oraciones de largo. ¿Crees que esta es una buena estrategia de diseño? o debería almacenar una identificación para esa cadena y luego crear una relación con otra tabla que contenga la ubicación del archivo que almacena la cadena. ¿podría dar ventajas y desventajas de ambos?

las cadenas han sido preprocesadas y almacenadas en la base de datos. cualquier modificación leería toda la cadena y la reemplazaría por completo. para que pueda suponer que la cadena es indivisible.

Answer 1

Debería estar bien almacenar la cadena en la base de datos. Si almacena un puntero de archivo en su lugar, eso significa que debe hacer E / S de archivo cada vez que quiera leer la cadena. Unas pocas oraciones no son terriblemente largas y siempre puedes usar un campo de datos de texto largo si es necesario. Obviamente su base de datos será un poco más grande porque tiene el texto, pero está bien. Sin duda, es una mejor alternativa que tener que almacenar los archivos.

Answer 2

Las cadenas que mencionas no son del todo largas.

Cuando se refirió a " long " cadenas, estaba pensando en 32kB y superiores - algunas oraciones son < 1kb - eso no es nada hoy.

Tu truco, almacenar un Id hace las cosas más lentas ya que tienes que hacer un acceso indirecto.

Lo único que recomendaría, cuando se necesita un rendimiento máximo, debe seleccionar solo las columnas que necesita (omita SELECT *), por lo que omita la columna de texto, cuando no sea necesario, ya que el transporte de la cadena desde el servidor a la aplicación cuesta más tiempo. Es una buena práctica, no tocar columnas no necesarias (especialmente cuando pueden contener muchos datos).

Answer 3

La única razón por la que crearía una tabla separada es si esas cadenas largas serán las mismas para muchos registros. De lo contrario, es solo una complicación adicional que probablemente no proporcionará ningún reembolso.

Answer 4

¡Cinco o seis oraciones no son nada para un DBMS moderno! Almacene el texto directamente en la base de datos.

(La otra técnica que mencionó: almacenar una referencia a otra tabla que tiene una referencia a un archivo externo que contiene el texto, sería mucho más engorrosa de usar y tendría un rendimiento mucho peor).

Answer 5

La respuesta realmente depende del volumen de cadenas que tiene la intención de almacenar, y qué base de datos tiene la intención de utilizar para almacenarlo. Si no está almacenando muchas cadenas, puede considerar almacenarlas en un archivo XML o de recursos, y cargarlas en su aplicación por adelantado. Sin embargo, si tiene muchos datos de cadena, probablemente será mejor que lea la cadena en el sentido de la memoria cuando la necesite, en lugar de arriesgarse a leer una cadena en la memoria que no termina usando.

Answer 6

La base de datos en sí no tiene ningún problema real con el almacenamiento de cadenas largas. Se aplican algunas restricciones (como el límite de tamaño de registro de 8k en SQL Server), pero incluso así podría almacenar texto de longitud arbitraria en una base de datos, ya que todas las correctas admiten tipos de datos BLOB / TEXT prácticamente sin límite superior.

Cinco a seis oraciones no son realmente largas. Si están juntos y están destinados a ser recuperados y manipulados en su conjunto, puede continuar y almacenarlos en un campo de tipo de datos CHAR de dimensiones apropiadas.

La pregunta de si separarlos y adjuntarles una ID surge solo si su aplicación / modelo de datos se beneficia directamente de este enfoque, es decir, en realidad son cosas separadas. En su caso, parece que no hay razón para hacerlo.

Answer 7

Todos han mencionado el rendimiento, pero nadie ha planteado la otra razón principal por la que almacenar punteros en los archivos del sistema operativo es una mala idea: copia de seguridad y recuperación. Si todo está en la base de datos, entonces tenemos un mecanismo único para hacer una copia de seguridad de los datos y un mecanismo único para la recuperación. Mientras que con los archivos en el sistema operativo tenemos dos mecanismos de respaldo diferentes, probablemente con dos granularidades diferentes, y la recuperación se convierte en una pesadilla de sincronización.

Hay algunos casos en los que esto no se aplica, como los almacenes de datos, que tienen transacciones muy poco frecuentes y, por lo tanto, pueden sobrevivir sin rehacer o sin registros de transacciones.

Answer 8

Excepto en casos especiales, dejaría el campo donde está.

La única otra opción sería colocar las cadenas en una tabla diferente (colocando las cadenas reales allí) ... ponerlas en archivos separados matará su rendimiento.