Първо, наистина не искате да правите това. Една колона в RDBMS е предназначена да бъде атомарна, тъй като съдържа една и само една информация. Опитът за съхраняване на повече от една част от данните в колона е нарушение на първата нормална форма.
Ако абсолютно трябва да го направите, тогава трябва да преобразувате данните във форма, която може да се съхранява като единичен елемент от данни, обикновено низ. Можете да използвате механизма serialize() на PHP, анализ на XML (ако данните са дървовидна структура на документа), json_encode() и т.н.
Но как да правите заявки за такива данни ефективно? Отговорът е, че не можете.
Освен това, ако някой друг поеме проекта ви на по-късна дата, наистина ще го дразните, защото сериализираните данни в база данни са ужасни за работа. Знам, защото съм наследил такива проекти.
Споменах ли, че наистина не искате да правите това? Трябва да преосмислите своя дизайн, така че да може по-лесно да се съхранява по отношение на атомни редове. Използвайте друга таблица за тези данни например и използвайте външни ключове, за да ги свържете с основния запис. Те се наричат релационни бази данни с причина.
АКТУАЛИЗАЦИЯ :Бях попитан за изискванията за съхранение на данни, като дали един ред би бил по-евтин от гледна точка на съхранение. Отговорът е, че в типичните случаи не, не е, а в случаите, когато отговорът е да, цената, която плащате за него, не си струва да бъде платена.
Ако използвате зависима таблица с 2 колони (1 колона за външния ключ на записа, към който пробата принадлежи, една за единична проба), тогава всяка колона ще изисква в най-лошия случай 16 байта (8 байта за колона с longint ключ, 8 байта за число с плаваща запетая с двойна точност). За 100 записа това са 1600 байта (игнорирайки натоварването на db).
За сериализиран низ съхранявате в най-добрия случай 1 байт на знак в низа. Не можете да знаете колко дълъг ще бъде низът, но ако приемем 100 проби с всички съхранени данни по някакво измислено съвпадение, всички попадащи между 10000.00 и 99999.99, като винаги има само 2 цифри след десетичната запетая, тогава вие гледам отново 8 байта на проба. В този случай всичко, което сте спестили, е излишъкът от външните ключове, така че необходимото количество памет излиза 800 байта.
Това, разбира се, се основава на много предположения, като например кодирането на знаци винаги да е 1 байт на знак, низовете, които съставляват пробите, никога да не са по-дълги от 8 знака и т.н.
Но, разбира се, има и режийни разходи от какъвто и да е механизъм, който използвате за сериализиране на данните. Абсолютно най-простият метод, CSV, означава добавяне на запетая между всяка проба. Това добавя n-1 байта към съхранения низ. Така че горният пример сега ще бъде 899 байта и това е с най-простата схема за кодиране. JSON, XML, дори PHP сериализациите добавят повече главни знаци от това и скоро ще имате низове, които са много по-дълги от 1600 байта. И всичко това е с предположението за кодиране на знаци от 1 байт.
Ако трябва да индексирате примерите, изискванията за данни ще нараснат още по-непропорционално спрямо низовете, тъй като индексът на низ е много по-скъп от гледна точка на съхранение, отколкото би бил индексът на колона с плаваща запетая.
И разбира се, ако вашите проби започнат да добавят повече цифри, съхранението на данни се увеличава още повече. 39281.3392810 няма да може да се съхранява в 8 байта като низ, дори в най-добрия случай.
И ако данните са сериализирани, базата данни не може да манипулира. Не можете да сортирате извадките, да правите каквито и да било математически операции върху тях, базата данни дори не знае, че са числа!
Ако трябва да бъда честен обаче, съхранението е абсурдно евтино в наши дни, можете да закупите няколко TB устройства за малки суми. Наистина ли съхранението е толкова критично? Освен ако нямате стотици милиони записи, тогава се съмнявам, че е така.
Може да искате да разгледате книга, наречена SQL Antipatterns
