Актуализирано на 4 юни 2017 г.
Като се има предвид, че този въпрос/отговор придобиха известна популярност, реших, че си струва да се актуализира.
Когато този въпрос беше първоначално публикуван, MySQL нямаше поддръжка за типове данни JSON и поддръжката в PostgreSQL беше в начален стадий. От 5.7 MySQL вече поддържа тип данни JSON (в двоичен формат за съхранение) и PostgreSQL JSONB е узрял значително. И двата продукта предоставят ефективни типове JSON, които могат да съхраняват произволни документи, включително поддръжка за индексиране на специфични ключове на JSON обекта.
Въпреки това, аз все още поддържам първоначалното си твърдение, че предпочитанията ви по подразбиране, когато използвате релационна база данни, трябва да са колона на стойност. Релационните бази данни все още се изграждат въз основа на предположението, че данните в тях ще бъдат доста добре нормализирани. Инструментът за планиране на заявки има по-добра информация за оптимизация, когато разглежда колони, отколкото когато разглежда ключове в JSON документ. Външни ключове могат да се създават между колони (но не и между ключове в JSON документи). Важно:ако по-голямата част от вашата схема е достатъчно нестабилна, за да оправдае използването на JSON, може да искате поне да помислите дали релационната база данни е правилният избор.
Въпреки това, малко приложения са идеално релационни или документно-ориентирани. Повечето приложения имат някаква комбинация от двете. Ето няколко примера, където аз лично открих JSON полезен в релационна база данни:
-
Когато съхранявате имейл адреси и телефонни номера за контакт, където съхраняването им като стойности в JSON масив е много по-лесно за управление, отколкото множество отделни таблици
-
Запазване на произволни потребителски предпочитания ключ/стойност (където стойността може да бъде булева, текстова или числова и не искате да имате отделни колони за различни типове данни)
-
Съхранение на конфигурационни данни, които нямат дефинирана схема (ако изграждате Zapier или IFTTT и трябва да съхранявате конфигурационни данни за всяка интеграция)
Сигурен съм, че има и други, но това са само няколко бързи примера.
Оригинален отговор
Ако наистина искате да можете да добавяте толкова полета, колкото искате, без ограничение (различно от ограничение за произволен размер на документа), помислете за NoSQL решение като MongoDB.
За релационни бази данни:използвайте една колона на стойност. Поставянето на JSON blob в колона прави практически невъзможно заявката (и болезнено бавно, когато действително намерите заявка, която работи).
Релационните бази данни се възползват от типовете данни при индексиране и са предназначени да бъдат внедрени с нормализиран структура.
Като странична забележка:това не означава, че никога не трябва да съхранявате JSON в релационна база данни. Ако добавяте истински метаданни или ако вашият JSON описва информация, която не е необходимо да се отправя запитвания и се използва само за показване, може да е излишно да създадете отделна колона за всички точки от данни.
