ORM против SQL XML, очень простой средний уровень

Question

Я знаю, это довольно острый вопрос. Но в любом случае я хотел бы услышать мнение тех, кто в Stackoverflow. Учитывая, что поддержка XML довольно хороша в SQL Server 2005/2008, и нет необходимости беспокоиться о независимости базы данных, зачем нужен Linq-to-SQL, Entity Framework, NHibernate и тому подобное, что довольно сложно и неудобно в сложных случаях , если с помощью POCO, XmlSerializer и хранимых процедур, которые обрабатывают XML, можно достичь гораздо менее сложного среднего уровня? Для справки см. Ссылку: http://weblogs.asp.net/jezell/archive/2007/04/13/who-needs-orm-i-ve-got-sql-2005.aspx

Answer 1

"Менее сложный средний уровень" - это то, что меня беспокоит ... смысл ORM в том, чтобы гарантировать, что большая часть сложности относится к вашей реальной области (будь то обработка заказов, чтение каналов или что-то еще),Эта сложность должна уйти куда-нибудь .И последнее место, где вы хотите, чтобы эта сложность находилось в БД - ваш минимум масштабируемый товар (вы обычно масштабируете сервер БД до (что дорого), где- как вы масштабируете серверы приложений из (гораздо дешевле).

Может быть случай использования баз данных документов вместо реляционных баз данных, но СУБД никуда не денутся. Как правило, Я бы предложил: ограничить использование вами xml в БД разумным количеством.Это может быть очень эффективным инструментом, но будьте осторожны, вы не создаете внутреннюю платформу.Реляционная база данных (от любого поставщика) является исключительной в своей работе со сложной индексацией, ACID, ссылочной целостностью и т. Д. ... используйте эту мощь.

Answer 2

Может быть сложно работать со столбцами XmlSerialization и XML в базах данных, но я уверен, что вы можете заставить его работать.Вам все равно придется преодолеть стандартные проблемы ORM, такие как циклические ссылки.Запросы SQL могут быть довольно неуклюжими в отношении столбцов базы данных XML.

Я бы сказал, что не сложные ORM являются сложными в расширенных случаях использования, а объектно-реляционное несоответствие является сложным в расширенных случаях использования.Я не понимаю, как XML и хранимые результаты действительно лучше подходят для этих расширенных вариантов использования.

XML не является реляционным или объектно-ориентированным по своей природе, и вы добавляете дополнительное несоответствие в смесь.