Ya no necesitas indagar más en otras webs ya que estás al sitio adecuado, tenemos la solución que buscas y sin complicarte.
Solución:
Para empezar, el título de la Pregunta actual que se refiere a “almacenar datos como string en lugar de columnas” es un poco confuso. Cuando se habla de almacenar datos como cadenas en lugar de otra cosa, eso generalmente se refiere a serializar todo en un string formato en lugar de un tipo de datos adecuado/fuerte (p. ej. INT o DATETIME). Pero si pregunta sobre el almacenamiento de datos como valores múltiples en un solo campo en lugar de filas separadas, eso es un poco diferente. Y para ser justos, aunque la concatenación de valores se hace más fácilmente con cadenas, también se puede hacer con INT y BINARY también tipos, ya sea enmascarando bits o reservando de manera similar ciertas posiciones para que tengan diferentes significados. Dado que la segunda interpretación es sobre lo que realmente se pregunta, según el texto de la Pregunta, abordemos eso.
En una palabra: No. Si está almacenando puntos de datos reales, solo traerá dolor (en términos de código y rendimiento), ya que es una complicación innecesaria. Si es un valor que solo se almacenará como una sola unidad, se actualizará como una sola unidad y nunca se desarmará dentro de la base de datos, entonces eso podría estar bien, ya que es más o menos análogo a almacenar una imagen o PDF. De lo contrario, cualquier intento de analizar los datos invalidará el uso de cualquier índice (por ejemplo, el uso de LIKE '%something%'o CHARINDEXo PATINDEXo SUBSTRINGetc).
Si necesita almacenar valores separados en un solo campo de una sola fila, existen medios más apropiados para hacerlo: XML o JSON. Estos son formatos analizables (XML / JSON) y XML incluso se puede indexar. Pero lo ideal sería que estos datos se almacenaran en campos debidamente escritos para que puedan ser realmente útiles.
Y no olvide que el propósito de un RDBMS es almacenar datos para que puedan recuperarse y manipulado de la manera más eficiente posible, dentro de las limitaciones impuestas por ser compatible con ACID. Recuperar valores concatenados ya es bastante malo debido a la necesidad de analizar primero los valores, y eso no es indexable. Pero manipular a menudo significa reemplazar todo el blob solo para actualizar una parte (suponiendo que no exista un patrón para usar con un REPLACE función). El tipo de datos XML al menos permite XML DML para actualizaciones simples, aunque todavía no son tan rápidas como una simple actualización de datos modelados correctamente.
Además, dado un escenario como el que se muestra en la Pregunta anterior, al concatenar todos los StateCodes juntos, no podría aplicar una clave externa (en ninguna dirección) a esos valores.
¿Y si los requisitos comerciales cambian con el tiempo y necesita realizar un seguimiento de las propiedades adicionales de estos elementos? En términos de “estados”, ¿qué pasa con las capitales, la población, el orden de clasificación o cualquier otra cosa? Almacenado correctamente como filas, puede agregar más columnas para propiedades adicionales. Claro, puede tener múltiples niveles de datos analizables, como |StateCode,Capital,Population pero con suerte cualquiera puede ver el problema creciendo exponencialmente fuera de control. Por supuesto, este problema en particular se trata con bastante facilidad con los formatos XML y JSON, y ese es su valor, como se mencionó anteriormente. Pero aún necesitarías un muy buena razón para usar cualquiera de ellos como un medio inicial de modelado, ya que ninguno será tan eficiente como usar campos discretos en filas separadas.
|StateCode,Capital,Populate|...
De hecho, he usado algo así para un propósito muy limitado. Creamos una tabla de encabezados para los archivos de salida. Fueron construidos específicamente y en su mayoría eran solo los encabezados de las columnas, pero no del todo. Así que los datos se veían algo así como
OutputType OutputHeader
PersonalData Name|Address|City|State|Zip
JobInfo Name|JobName|JobTitle
Esencialmente, parecía que era una lista delimitada. Y en cierto modo lo era. Pero para nuestros propósitos fue un solo largo string.
Ese es el truco aquí. Si usted nunca planee analizar la lista, entonces vale la pena guardar la lista. Sin embargo, si necesita o incluso necesita analizar la lista, vale la pena el espacio y el tiempo adicionales para dividirla y guardarla en filas separadas.
Sección de Reseñas y Valoraciones
Tienes la opción de añadir valor a nuestro contenido contribuyendo tu veteranía en las críticas.