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

Ответ 1

Я использую 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.

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

XML в SQL Server 2005? Лучше, чем JSON в Varchar?

Ответ 7

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

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

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