Хранить JSON в базе данных msSQL?

Question

Я занимаюсь разработкой генератора форм и задаюсь вопросом, будет ли плохим моджо хранить JSON в базе данных SQL?

Я хочу, чтобы моя база данных и таблицы были простыми, поэтому у меня будет

`pKey, formTitle, formJSON`

на столе, а затем хранить

{["firstName":{"required":"true","type":"text"},"lastName":{"required":"true","type":"text"}}

в форме JSON.

Любой вклад приветствуется.

Answer 1

Я широко использую JSON в своей CMS (на которой размещено около 110 сайтов) и считаю скорость доступа к данным очень высокой. Я был удивлен, что не было больше ухудшения скорости. Каждый объект в CMS (страница, макет, список, тема и т. Д.) Имеет столбец NVARCHAR (MAX) с именем JSONConfiguration. Мой инструмент ORM знает, что нужно искать этот столбец и при необходимости восстанавливать его как объект. Или, в зависимости от ситуации, я просто передам его клиенту для обработки jQuery или Ext JS.

Что касается читабельности / удобства сопровождения моего кода, вы можете сказать, что он улучшен, потому что у меня теперь есть классы, которые представляют множество объектов JSON, хранящихся в БД.

Я использовал JSON.net для всей сериализации / десериализации. https://www.newtonsoft.com/json

Я также использую один запрос для возврата мета-JSON с фактическими данными. Как и в случае с Ext JS, у меня есть запросы, которые возвращают как структуру Ext JS-объекта, так и данные, которые ему понадобятся. Это исключает один ответ / SQL туда и обратно.

Я также был удивлен, насколько быстро код анализировал список объектов JSON и отображал их в объект DataTable, который я затем передавал в GridView.

Единственный недостаток использования JSON, который я видел, - это индексирование. Если у вас есть свойство JSON, которое вам нужно искать, то вы должны сохранить его как отдельный столбец.

Существуют JSON DB, которые могут лучше удовлетворить ваши потребности: CouchDB, MongoDB и Cassandra.

Answer 2

Отличный способ сделать объектную базу данных с сервера SQL. Я делаю это для всех объектов конфигурации и всего остального, которое не требует каких-либо особых запросов. Расширение вашего объекта - легко, просто создайте новое свойство в вашем классе и инициализируйте со значением по умолчанию. Вам больше не нужна недвижимость? Просто удалите его в классе. Легко выкатить, легко обновить. Подходит не для всех объектов, но если вы извлекаете какую-либо подпорку, на которую нужно индексировать - продолжайте использовать ее. Очень современный способ использования сервера sql.

Answer 3

Мы использовали модифицированную версию XML именно для той цели, которую вы описываете в течение семи или восьми лет, и она прекрасно работает. Формы потребностей наших клиентов настолько разнообразны, что мы никогда не поспеваем за подходом «таблица / столбец». Мы слишком далеко продвинулись по пути XML, чтобы измениться очень легко, но я думаю, что JSON также сработает и, возможно, станет лучше.

Создание отчетов - не проблема с парой хороших функций синтаксического анализа, и я бы никому не посоветовал найти существенную разницу в производительности между нашими отчетами / аналитикой и решением для таблицы / столбца, удовлетворяющим эту потребность.

Answer 4

Это будет медленнее, чем определение формы в коде, но один дополнительный запрос не должен причинить вам большого вреда. (Только не позволяйте 1 дополнительному запросу стать 10 дополнительными запросами!)

Редактировать: если вы выбираете строку с помощью formTitle вместо pKey (я бы, потому что тогда ваш код будет более читабельным), поместите индекс на formTitle

Answer 5

Вы должны быть в состоянии использовать SisoDb для этого. http://sisodb.com

Answer 6

Я думаю, что не оптимальная идея хранить данные объекта в строке в SQL.Вы должны выполнить преобразование вне SQL, чтобы разобрать его.Это создает проблему с производительностью, и вы теряете рычаги использования возможности анализа собственных данных SQL.Лучшим способом было бы хранить JSON как тип данных XML в SQL.Таким образом, вы убиваете двух зайцев одним выстрелом: вам не нужно создавать дерьмовую загрузку таблиц и при этом получать все собственные преимущества запросов SQL.Лучше, чем JSON в Varchar?

Answer 7

Я бы не рекомендовал это.

Если вы когда-нибудь захотите сделать какой-либо отчет или запрос на основе этих значений в будущем, это сделает вашу жизнь намного сложнее, чем наличие нескольких дополнительных таблиц / столбцов.

Почему вы избегаете создавать новые столы?Я говорю, если ваше приложение требует, чтобы они продолжали и добавляли их ... Также, если кто-то должен будет просмотреть ваш код / ​​db позже, им, вероятно, будет сложнее выяснить, что вы делаете (в зависимости от того, какого родадокументация у вас есть).