Здравствуйте, alex_public, Вы писали:
_>Кстати, давно хотел спросить. А если нам понадобится обеспечивать сохранения в БД состояния (естественно не со всеми полями — всякие там дескрипторы и т.п. не нужны) некого уже существующего (скажем наследника тяжёлого библиотечного класса) сложного класса, то это вызовет какие-то сложности или же тоже без проблем?
Не вызовет. Ты этот вопрос, помнится, уже задавал.
НС>>С того что лишние поля будут выбираться без надобности. _>Ты всерьёз считаешь, что если запросить одну строку из БД целиком, то это будет ощутимо медленнее, чем запросить эту же строку без пары столбцов? )
Всерьез считаю. Про index includes, к примеру, слышал? Так вот, они работают только при ограничении проекции. Я уж не говорю о том, что в таблицах могут быть вполне объемные блобы.
_>В реальных задачах чаще всего надо или всю строку или одно поле из неё.
Моя практика подобного не подтверждает. Моя практика говорит, что для таблицы, у которой колонок больше трех почти никогда не нужно выбирать все поля.
НС>>На цель, извини, не тянет. Цель любого продуктва — удовлетворять требованиям. Заказчик такого требования не выставляет. Так что это уже твои экзерсисы. Поэтому попробуй их обосновать, а не выдавай за аксиому. _>Согласен, но здесь подразумевалось что это цель для "правильной архитектуры" (которая опять же нафиг не нужна заказчику).
Еще раз. Чтобы отличить правильную архитектуру от неправильной нужен критерий. Критерий этот должен быть осмысленным, приводящим к конкретным бенефитам, а не чьей то голой хотелкой.
_>>>- родное (через свои типы) API к хранилищу НС>>Что такое "родное API" и чем оно лучше неродного? _>Я же указал в скобках — работает через те же типы данных, что и само приложение.
Ниче не понял. IQueryable, если что, он на самом деле IQueryable<T> в котором Т вполне себе родной.
_> И лучше оно удобством.
Докажи.
_>>>- программистам в остальной части приложения не надо знать тонкости работы хранилища — этим может заниматься один спец. по нему НС>>IQueryable обеспечивает тоже самое. _>Как минимум надо понимать всякие там join'ы, подзапросы и т.п.
Это надо в любом случае понимать, если ты хочешь получить эффективное решение.
_> Не говоря уже о том, что для некоторых БД некоторые типы запросов могут оказываться неэффективными.
Например?
_>>>- при необходимости можно легко сменить тип хранилища. НС>>IQueryable обеспечивает тоже самое. _>Только в рамках реляционных СУБД.
Не обязательно. Но я вот опять вижу витание в облаках. Тут тебе объясняют что даже смена одной РСУБД на другую — редчайшее явление, а уж замена РСУБД на нереляционное хранилище — это что то из области струнных теорий.
_> Или быть может linq2db может помочь сохранить данные в MongoDB? )
