Я разрабатываю генератор форм и задаюсь вопросом, будет ли плохое mojo хранить JSON в базе данных SQL?
Я хочу, чтобы моя база данных и таблицы были простыми, поэтому я собирался иметь
`pKey, formTitle, formJSON`
на таблице, а затем сохраните
{["firstName":{"required":"true","type":"text"},"lastName":{"required":"true","type":"text"}}
в форме JSON.
Приветствуется любой ввод.
Я использую JSON экстенсивно в своей CMS (на которой размещается около 110 сайтов), и я нахожу скорость доступа к данным очень быстро. Я был удивлен, что ухудшения скорости не было. Каждый объект в CMS (страница, макет, список, тема и т.д.) Имеет столбец NVARCHAR (MAX), называемый JSONConfiguration. Мой инструмент ORM знает, как искать этот столбец и восстанавливать его как объект, если это необходимо. Или, в зависимости от ситуации, я просто передам ее клиенту для обработки jQuery или Ext JS.
Что касается удобочитаемости/ремонтопригодности моего кода, вы можете сказать, что он улучшен, потому что теперь у меня есть классы, которые представляют множество объектов JSON, хранящихся в БД.
Я использовал JSON.net для всей сериализации/десериализации. http://james.newtonking.com/default.aspx
Я также использую один запрос для возврата meta-JSON с фактическими данными. Как и в случае с Ext JS, у меня есть запросы, которые возвращают как структуру объекта Ext JS, так и данные, которые будут нужны объекту. Это сокращает одно сообщение назад /SQL в оба конца.
Я также был удивлен тем, насколько быстрым был код для анализа списка объектов JSON и сопоставления их с объектом DataTable, который затем передал GridView.
Единственный недостаток, который я видел в использовании JSON, - это индексирование. Если у вас есть свойство JSON, вам необходимо выполнить поиск, тогда вы должны сохранить его как отдельный столбец.
Есть JSON DB, который может лучше настроить ваши потребности: CouchDB, MongoDB и Cassandra.
Отличный способ создания базы данных объектов с сервера sql. Я делаю это для всех объектов конфигурации и всего остального, для которых не требуется никаких конкретных запросов. расширяя ваш объект - легко, просто создайте новое свойство в своем классе и init со значением по умолчанию. Вам больше не нужна собственность? Просто удалите его в классе. Легкое развертывание, простота обновления. Не подходит для всех объектов, но если вы извлекаете какую-либо опору, которую вам нужно индексировать, продолжайте ее использовать. Очень современный способ использования SQL-сервера.
Он будет медленнее, чем форма, определенная в коде, но один дополнительный запрос не должен причинять вам много вреда. (Просто не давайте 1 дополнительный запрос стать 10 дополнительными запросами!)
Изменить: если вы выбираете строку formTitle вместо pKey (я бы, потому что тогда ваш код будет более читабельным), поместите индекс на formTitle
Мы использовали модифицированную версию XML для той цели, которую вы указали в течение семи или восьми лет, и она отлично работает. Наши потребности в форме клиентов настолько разнообразны, что мы никогда не сможем справиться с табличным/колоночным подходом. Мы слишком далеко по XML-дороге, чтобы меняться очень легко, но я думаю, что JSON будет работать и, возможно, лучше.
Отчетность не представляет проблемы с несколькими хорошими функциями синтаксического анализа, и я бы бросил вызов любому, чтобы найти существенную разницу в производительности между нашей отчетностью/аналитикой и решением таблицы/столбца для этой потребности.
Вы можете использовать SisoDb для этого. http://sisodb.com
Я думаю, что это не оптимальная идея хранить данные объекта в строке в SQL. Вы должны сделать преобразование вне SQL, чтобы разобрать его. Это представляет проблему с производительностью, и вы теряете рычаги использования SQL-данных для синтаксического анализа данных. Лучшим способом было бы хранить JSON в качестве типа данных XML в SQL. Таким образом, вы убиваете двух зайцев одним камнем: вам не нужно создавать дерьмовую нагрузку таблиц и по-прежнему получать все собственные запросы SQL.
Я бы не рекомендовал его.
Если вы когда-либо захотите делать какие-либо отчеты или запросы на основе этих значений в будущем, это сделает вашу жизнь намного сложнее, чем наличие нескольких дополнительных таблиц/столбцов.
Почему вы избегаете создания новых таблиц? Я говорю, если ваше приложение требует от них идти вперед и добавлять их в... Кроме того, если кто-то должен пройти через ваш код /db позже, им, вероятно, будет сложнее выяснить, что вы делали (в зависимости от того, у вас есть).