За да отговоря:изглежда текстът е остарял в много СУБД, така че по-добре използвайте или blob, или varchar с висок лимит (и с blob няма да получите никакви проблеми с кодирането, което е голяма неприятност с varchar и текст) .
Също както е посочено в тази тема във форумите на MySQL , твърдите дискове са по-евтини от софтуера, така че е по-добре първо да проектирате софтуера си и да го накарате да работи и едва след това, ако пространството стане проблем, може да искате да оптимизирате този аспект. Така че не се опитвайте да преоптимизирате размера на колоната си твърде рано, по-добре първо задайте размера по-голям (плюс това ще избегне проблеми със сигурността).
Относно различните коментари:Тук е твърде много SQL фанатизъм. Въпреки факта, че много харесвам SQL и релационни модели, те също имат своите клопки.
Съхраняването на сериализирани данни в базата данни както е (като съхранение на JSON или XML форматирани данни) има няколко предимства:
- Можете да имате по-гъвкав формат за вашите данни:добавяне и премахване на полета в движение, промяна на спецификацията на полетата в движение и др...
- По-малко несъответствие на импеданса с обектния модел:съхранявате и извличате данните точно както са във вашата програма, в сравнение с извличането на данните и след това трябва да ги обработвате и конвертирате между структурите на програмните обекти и структурите на вашата релационна база данни .
И има още много други предимства, така че, моля, без фенбойство:релационните бази данни са страхотен инструмент, но нека не изхвърляме другите инструменти, които можем да получим. Повече инструменти, толкова по-добре.
Що се отнася до конкретен пример за употреба, склонен съм да добавя JSON поле в моята база данни, за да съхранявам допълнителни параметри на запис, където колоните (свойствата) на JSON данните никога няма да бъдат ИЗБРАНИ поотделно, а се използват само когато правилният запис вече е избран. В този случай все още мога да разграничавам записите си с релационните колони и когато е избран правилният запис, мога просто да използвам допълнителните параметри за каквато цел искам.
Така че моят съвет да запазите най-доброто от двата света (скорост, сериализируемост и структурна гъвкавост), просто използвайте няколко стандартни релационни колони, които да служат като уникални ключове за разграничаване между вашите редове, и след това използвайте колона blob/varchar, където вашите сериализирани данни ще бъде вмъкнат. Обикновено се изискват само две/три колони за уникален ключ, така че това няма да е сериозен излишък.
Също така може да се интересувате от PostgreSQL, който вече има тип данни JSON, и PostSQL проект за директно обработване на JSON полета точно като релационни колони.
