Microsoft SQL Server 2005/2008: XML по сравнению с текстом/типом данных varchar
просто перетащите таблицу в визуальный редактор дважды. Второй экземпляр таблицы автоматически переименовывается в «_1».
SELECT Contacts.EmpID, Contacts_1.EmpID AS reportsTo
FROM Contacts INNER JOIN Contacts AS Contacts_1 ON Contacts.SupervisorID=
Contacts_1.EmpID;
3 ответа
Мое быстрое расследование показывает что MS SQL 2005 (Express Edition)
2005 Microsoft SQL Server - 9.00.3073.00 (Intel X86) 5 августа 2008 12:31:12 Copyright (c) 1988-2005 Microsoft Corporation Express Edition на Windows NT 6.0 (создают 6000:)
снабдите XML служебными приблизительно 70% (возможный для более быстрой обработки/парсинга).
Мои данные перед преобразованием: rows=160320, reserved=178576 КБ, data=178184 КБ, index_size=272 КБ, unused=120 КБ
Мои данные после преобразования: rows=160320, reserved=309702 КБ, data=307216 КБ, index_size=1672 КБ, unused=184 КБ
Таким образом, это не имеет никакого смысла сохранить данные XML в типе данных XML, если Вы не планируете использование технология XML на стороне базы данных.
При хранении xml во введенном столбце xml данные не будут храниться как простой текст, как в nvarchar случае, это будет сохранено в своего рода проанализированном дереве данных, которое в свою очередь будет меньшим, чем непроанализированная xml версия. Это не только уменьшает размер базы данных, но и дает Вам другие преимущества, как проверка, легкое управление и т.д. (даже при том, что Вы не используете ни одного из них, тем не менее, они там для будущего использования).
С другой стороны, сервер должен будет проанализировать данные по вставке, которая, вероятно, замедлит Вашу базу данных - необходимо принять решение скорости по сравнению с размером.
Править:
Лично, я думаю, что данные в базе данных должны храниться как xml только, когда это имеет структуру, которую трудно реализовать в реляционной модели, например, разметках, описания стиля и т.д. Обычно это означает, что не будет большого количества данных, и скорость не является проблемой, таким образом добавил xml опции, как способность к подтверждению правильности данных и управлению (также, наконец, что не менее важно, способность нажать на значение в студии управления и видеть отформатированный xml - я действительно люблю ту функцию!), перевесьте затраты.
У меня нет прямого опыта в хранении большого объема xml в базе данных, и я не сделал бы этого, если бы у меня была опция, так как это почти всегда медленнее, что реляционная модель, но если бы это имело бы место, я рекомендовал бы представить обе опции и выбрать между размером и скоростью, которые лучше всего удовлетворяют Вашим потребностям.
Я широко использую xml для связи с портативными устройствами и использую XQuery почти во всех моих хранимых процессах для извлечения только тех данных из XML, которые мне нужны. Работает ОТЛИЧНО !! Я просто беспокоюсь о месте для хранения, потому что всего с сотней тысяч записей или около того размер БД составляет от 1 до 2 ГБ. Мы ожидаем запуска миллионов записей, хранящихся для ведения журналов и использования клиентами ... так что это будет вызывать беспокойство, пока я не увижу, что он на самом деле собирается делать с точки зрения использования пространства.