Сохранить данные в формате XML в БД по сравнению с сохранением нескольких строк данных

Question

Я проектирую свою базу данных и хотел узнать, как лучше всего решить эту проблему.У меня есть вкладки на странице, которая выглядит следующим образом:

Tab1
--SubTab1
----Data1
--SubTab1
--SubTab1
Tab2
--SubTab1
--SubTab1
--SubTab1
Tab3
--SubTab1
--SubTab1
--SubTab1

Я могу поместить эту информацию в базу данных, которая будет храниться в несколько строк, как это

TypeID---------------Name
1--------------------Tab
2--------------------Data


ObjectID----------Parent-------------TypeID
1-----------------0------------------1
2-----------------0------------------1
3-----------------0------------------1
4-----------------1------------------1

Или я могу простопоместите это в базу данных следующим образом:

<root>
     <tab name="MyTab">
          <tab name="MySubTab">
               <data>1234567890</data>
          </tab>
     </tab>
</root>

Если я извлекаю только XML из базы данных, мне не нужно выбирать несколько строк, мне просто нужно выбрать одну строку, а затем проанализировать XML в классе, а затемпередать эти данные в контроллер.Я просто хотел бы знать, если это хорошая идея?Буду ли я ошибаться, если мой сайт будет расширяться в будущем?Будет ли это делать больше обслуживания по мере того, как сайт станет больше и захочет больше возможностей?

Answer 1

XML трудно запрашивать с использованием SQL. Если вы думаете, что вам никогда не понадобится запрашивать данные, вы можете использовать XML. Я бы, вероятно, сохранил данные в несколько строк для будущей гибкости.

Answer 2

Если вы используете SQL Server, я бы просто использовал ierarchyid .Хотя это возможно сделать с XML в TSQL, есть несколько предостережений с ним.Прежде всего, возвращение упорядоченного XML обратно - отстой , потому что TSQL (2008) неправильно / полностью не поддерживает position().Требуется несколько грязное соединение со столбцом indexer.(Это неприменимо, если вы читаете весь XML-блоб назад, но это звучит как головная боль при ручном разборе на стороне клиента).

hiearchyid позволяет этим уровням бытьлегко сохраняется, оставляет базу данных в более нормализованном формате (СУБД предназначены для эффективной работы над многими столбцами, просто убедитесь, что у них правильные индексы), и в целом с ними должно быть гораздо проще работать -- особенноесли вы не готовы погрузиться в землю SPROC: -)

hiearchyid представляет отношения между родителями и детьми, а также упорядочение братьев и сестер (это может привести в порядок модель);он основан на глубокой модели, которая хорошо подходит для таких задач, как эта.

Кроме того, использование XML, скорее всего, ничего не спасет (IIRC, [типизированный] XML фактически превращается во что-то вроде внутренней настройки столбца).Это (XML) гораздо лучше, если нужно, просто использовать как формат сообщения «in / out» (или «документ»).

Happy SQL'ing.

Answer 3

Если вы подумываете о том, хранить ли XML в базе данных, самое время спросить себя, нужно ли вообще хранить эти данные в базе данных.

Как насчет хранения этих данных в статическом XML-файле?Это жизнеспособный вариант?Почему и почему нет?

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

Это масштабируемый, обслуживаемый и эффективный способ решения этой проблемы для данных, которые меняются не часто.

Аналогичным образомЧтобы добиться того же, нужно, чтобы серверная технология, такая как ASP.net или PHP, генерировала для вас XML из таблиц базы данных, а затем использовала кэширование вывода с длительным сроком действия, чтобы убедиться, что процесс генерации выполняется не часто.*

Как общее практическое правило, обычно не рекомендуется хранить непримитивные или сложные данные в поле базы данных.

Answer 4

Может быть, я неправильно понял, но, похоже, вы решаете, сохранять ли данные как XML или сохранять их в таблицах, а затем запрашивать их, используя xml, чтобы вернуть их. Если это так:

Проще запрашивать и обрабатывать больше изменений: Лучше сохранить данные в таблицы и запросить их позже, если у вас будет много изменений, и они будут расти с высокой скоростью. Вы получаете больше вариантов для сложных запросов.

Быстрее, если данные не растут или не меняются так сильно: Если данные не будут меняться так часто, и нет опасности их большого роста, тогда вы можете просто использовать XML, чтобы сохранить их Синтаксис уже и он будет иметь меньше производительности. Этот метод означает, что у вас меньше гибкости в запросе нужных данных.

Answer 5

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