Тук имате няколко въпроса, така че ще ги разгледам отделно:
Трябва да съхраня няколко избрани елементи в едно поле в база данни
Моето общо правило е:недей. Това е нещо, което освен изисква втора таблица (или трета) с външен ключ. Разбира се, сега може да изглежда по-лесно, но какво ще стане, ако се появи случай на употреба, когато всъщност трябва да потърсите тези елементи поотделно? Това също означава, че имате повече опции за мързеливо създаване на инстанции и имате по-последователно изживяване в множество рамки/езици. Освен това е по-малко вероятно да имате проблеми с изчакването на връзката (30 000 знака са много).
Споменахте, че обмисляте да използвате ENUM. Фиксирани ли са тези стойности? Познавате ли ги предварително? Ако е така, това би била моята структура:
Основна таблица (това, което имате сега):
<предварителен код>| ID първичен_ключ последователност| -- други колони тук.Таблица с елементи:
<предварителен код>| ID първичен_ключ последователност| описание VARCHAR(30) УНИКАЛНОТаблица на картата:
<предварителен код>| base_id bigint| items_id bigintТаблицата на картата ще има външни ключове, така че base_id се преобразува в основната таблица, а items_id ще се съпостави с таблицата с елементи.
И ако искате лесен начин да извлечете това от DB, тогава създайте изглед, който извършва обединяванията. Можете дори да създадете правила за вмъкване и актуализиране, така че на практика да работите само с една таблица.
Какъв формат да използвам за съхранение на данните?
Ако трябва да направите нещо подобно, защо просто не използвате очертан низ от символи? Ще отнеме по-малко процесорна мощност от CSV, XML или JSON и ще бъде по-кратък.
Какъв тип колона трябва да използвам за съхранение на данните?
Лично аз бих използвал TEXT . Не звучи така, сякаш бихте спечелили много, като направите това BLOB и TEXT , според моя опит, е по-лесно за четене, ако използвате някаква форма на IDE.
