Tiene un par de preguntas aquí, así que las abordaré por separado:
Necesito almacenar una cantidad de elementos seleccionados en un campo en una base de datos
Mi regla general es:no. Esto es algo que casi requiere una segunda tabla (o tercera) con una clave foránea. Claro, puede parecer más fácil ahora, pero ¿qué sucede si surge el caso de uso en el que necesita consultar esos elementos individualmente? También significa que tiene más opciones para la creación de instancias diferidas y tiene una experiencia más consistente en múltiples marcos/lenguajes. Además, es menos probable que tenga problemas de tiempo de espera de conexión (30 000 caracteres es mucho).
Mencionaste que estabas pensando en usar ENUM. ¿Estos valores son fijos? ¿Los conoces de antemano? Si es así, esta sería mi estructura:
Tabla base (lo que tienes ahora):
| id primary_key sequence
| -- other columns here.
Tabla de artículos:
| id primary_key sequence
| descript VARCHAR(30) UNIQUE
Tabla de mapas:
| base_id bigint
| items_id bigint
La tabla de mapas tendría claves foráneas, por lo que base_id se asigna a la tabla base y items_id se asignaría a la tabla de elementos.
Y si desea una manera fácil de recuperar esto de una base de datos, cree una vista que haga las uniones. Incluso puede crear reglas de inserción y actualización para que prácticamente solo esté tratando con una tabla.
¿Qué formato debo usar para almacenar los datos?
Si tiene que hacer algo como esto, ¿por qué no usar una cadena de caracteres delineada? Requerirá menos potencia de procesamiento que un CSV, XML o JSON, y será más breve.
¿Qué tipo de columna debo usar para almacenar los datos?
Personalmente, usaría TEXT . No parece que ganes mucho haciendo de esto un BLOB y TEXT , según mi experiencia, es más fácil de leer si usa algún tipo de IDE.
