Можно ли использовать столбцы XML сервера Sql в качестве замены для реальной базы данных документов (например, Couch или Mongo)?
Если бы мне нужно было создать таблицу с идентификатором PK-указателя и столбцом XML для документа. Каковы будут основные проблемы по сравнению с использованием DB документа?
Сервер Sql поддерживает индексирование по столбцам XML, поэтому запрос не должен быть полностью ужасным?
Я экспериментирую с этим: http://rogeralsing.com/2011/03/02/linq-to-sqlxml-projections/
Скорость запроса "приличная", это ничего, что я использовал бы для масштабирования. Но радость бесплатного хранения схемы, работающая на стандартной инфраструктуре, довольно приятная.
У вас есть несколько вопросов здесь:
Можно ли использовать столбцы XML сервера Sql в качестве замены для реальной базы данных документов (например, Couch или Mongo)? Да, вы можете использовать ее в качестве замены, но нет, вы, вероятно, не будут удовлетворены производительностью, если вы исключительно храните XML и не используете какие-либо реляционные инструменты SQL Server.
Если бы я должен был создать таблицу с идентификатором PK-указателя и столбцом XML для документа. Каковы были бы основные проблемы по сравнению с использованием DB документа? Вкратце, масштабирование. SQL Server не масштабирует этот вид. Вы можете сделать это с помощью репликации, но это больно управлять относительно "реальной" DB документа.
Sql Server поддерживает индексирование по столбцам XML, поэтому запрос не должен быть полностью ужасным? Проблема заключается в том, что индексы SQL Server XML могут занимать в несколько раз больше места для хранения исходных данных. Эти индексы не могут поддерживаться в режиме онлайн (как в дефрагментах), поэтому в процессе обслуживания вы получаете проблемы с блокировкой.
Да, вы можете. Хранение документа внутри столбца XML SqlServer будет работать, и если вы используете стандартную сериализацию XML, которая оставит вас с приличным хранилищем ключей/значений ACID. Кроме того, это позволит вам делать запросы на нем с относительной легкостью, и вы можете объединить результаты с данными, которые вы храните в более реляционном режиме. Мы делаем это, это работает. Если вы храните контент в XML-полях, требования к хранилищу намного ниже, чем использование NTEXT, и запросы на него будут более гибкими и быстрыми.
Что SqlServer вам не подойдет (по сравнению с mongo) - это бесшовный переход на резервную копию реплик - устанавливает автозагрузку монго. Кроме того, атомарные операции, такие как добавление определенного свойства внутри документа, являются трудными (хотя и не невозможными с помощью функции обновления XQuery). Обновления, как правило, быстрее в большинстве баз данных NoSql, потому что они более расслаблены по принципу "данные только безопасны на диске".
Да, это возможно. Что касается того, хорошая ли это идея, это всего лишь мои 2 цента...
До того, как появился тип данных XML, я работал над системой хранения XML в столбце NTEXT - это было не приятно, и чтобы получить реальную пользу из данных, это означало измельчение некоторых этих данных в реляционную форму.
ОК, теперь тип данных XML упрощает запрос блога XML и извлекает определенные значения/индексирует их. Но лично, в общем, я бы этого не сделал. Я не говорю, что никогда не использую XML, поскольку есть сценарии для этого - скорее, если бы все это планировалось, я бы подумал: "Это правильный инструмент для работы". Использование СУБД в качестве базы данных документов заставляет меня чувствовать себя немного неловко. В то время как нечто вроде MongoDB было создано с нуля в качестве базы данных документов.
Честно говоря, я не проводил тестирование производительности при хранении данных в формате XML, поэтому я не могу дать вам представление о том, какая производительность будет выглядеть. Было бы интересно узнать, как это выполняется в масштабе.