Это очень просто объясняется тем фактом, что это, так сказать, несущая фраза на странице. Вероятно, от нее там строятся все css селекторы, и если ее убрать, то вся верстка распадется
Там же написно что вы начинаете с коробки, соответствующей вашему номеру. То есть вы придете к коробке со своим номером в последнюю очередь перед замыканием цепочки. Поэтому и шанса спастись также не будет
С XML у MS SQL сервера далеко не все гладко. ОРМ если и поддеживают его то не в сильно приятном виде — через xpath, который, к сожалению, далек от мечты
Кеш это хорошая идея, но есть две потенциальных трудности
1) Я писал выше что данные у нас не стльно много источников данных, однако для кеша он все же обновляются достаточно часто, тем самым сбрасывая его
2) нам была необходимость на разных страницах показывать свежие данные с опрееленным фильтром
Получается достаточно серьезная нагрузка на реляционную БД, даже при наличии кеша
У нас использование монги сложилось можно сказать исторически. Кроме того в качестве реляционного хранилища нам было удобнее использовать ms sql.
А так конечно да. Постгрес вполне подходящий инструмент для описанного в статье подхода
У нас навешивается событие на сохранение данных в sql, кроме того у нас не очень много источников данных — около 5-10 редакторов контента плюс фиды из нескольких источников, поэтому данные попадают в монгу практически мгновенно.
С sql у нас фактически работает админка сайта, что гарантирует нам наличие гарантированно достоверного набора данных. После того как данные попадают в sql, они должны как-либо попадать в монгу, это может либо событие на выполнение транзакции sql реальизованное непосредственно в части админки, что к сожалению, не гарантирует того что данные попадут в nosql корректно, либо можно воспользоваться очередью сообщений, например msmq или rabbitmq. Кроме того при такой схеме мы получили пару дополнительных возможностей
1) На случай если что-то пошло сильно не так, нажатием одной кнопки мы можем полностью восстановить данные в nosql
2) В качестве админки сайта можно взять любую бесплатную цмску с удобным интерфейсом управления контентом, не задумываясь о ее производительности, т.к. клиентская часть сайта, находящаяся под наибольшей нагрузкой никак не будет зависеть от производительности этой цмс
Если это страница какой-либо программы или непосредственно статьи то мы из монги вытаскиваем данные по идентификатору, преобразуем дата модель во вью модель и показываем.
Если же у нас на странице показываюся тайлы, как например во втором случае, к монге идет запрос к коллекции тайлов, возвращающий набор разных тайлов с базовым классом BaseTile. Для каждого типа тайлов у нас есть своя вьюха, которая знает какой тип ей нужен и какие данные она должна отображать. Наш проект реализован на aspnet mvc, и для этого нам было досаточно вызывать что-то вроде:
foreach (var tile in Model.Tiles)
{
<text>
@Html.DisplayFor(tile)
</text>
}
1) Я писал выше что данные у нас не стльно много источников данных, однако для кеша он все же обновляются достаточно часто, тем самым сбрасывая его
2) нам была необходимость на разных страницах показывать свежие данные с опрееленным фильтром
Получается достаточно серьезная нагрузка на реляционную БД, даже при наличии кеша
А так конечно да. Постгрес вполне подходящий инструмент для описанного в статье подхода
1) На случай если что-то пошло сильно не так, нажатием одной кнопки мы можем полностью восстановить данные в nosql
2) В качестве админки сайта можно взять любую бесплатную цмску с удобным интерфейсом управления контентом, не задумываясь о ее производительности, т.к. клиентская часть сайта, находящаяся под наибольшей нагрузкой никак не будет зависеть от производительности этой цмс
Если же у нас на странице показываюся тайлы, как например во втором случае, к монге идет запрос к коллекции тайлов, возвращающий набор разных тайлов с базовым классом BaseTile. Для каждого типа тайлов у нас есть своя вьюха, которая знает какой тип ей нужен и какие данные она должна отображать. Наш проект реализован на aspnet mvc, и для этого нам было досаточно вызывать что-то вроде: