Здравствуйте, Ночной Смотрящий, Вы писали:

_>>В произвольном случае конечно. Однако для конкретной задачи (особенно если в ней нет произвольных деревьев) это становится более реально.
НС>Ну а для конкретного случая и у линка проблем нет.

Кстати, давно хотел спросить. А если нам понадобится обеспечивать сохранения в БД состояния (естественно не со всеми полями — всякие там дескрипторы и т.п. не нужны) некого уже существующего (скажем наследника тяжёлого библиотечного класса) сложного класса, то это вызовет какие-то сложности или же тоже без проблем?

_>>С чего бы это? )
НС>С того что лишние поля будут выбираться без надобности.

Ты всерьёз считаешь, что если запросить одну строку из БД целиком, то это будет ощутимо медленнее, чем запросить эту же строку без пары столбцов? )

_>> Без уточнения конкретной задачи это всё бессмысленный разговор.
НС>Тут все вполне конкретно. В реальных задачах набор полей в основном уникален. Рисовать на каждый случай новый тип — геморой, возвращать недозаполненный тип или безликий кортеж — отличный способ прострелить себе ногу, возвращать все поля — удар по перформансу.

В реальных задачах чаще всего надо или всю строку или одно поле из неё. ) И даже если в каком-то редком случае понадобится именно некий набор полей, то это тоже без проблем и удобно задаётся в API для случая статических запросов.

НС>На цель, извини, не тянет. Цель любого продуктва — удовлетворять требованиям. Заказчик такого требования не выставляет. Так что это уже твои экзерсисы. Поэтому попробуй их обосновать, а не выдавай за аксиому.

Согласен, но здесь подразумевалось что это цель для "правильной архитектуры" (которая опять же нафиг не нужна заказчику).

_>>- родное (через свои типы) API к хранилищу
НС>Что такое "родное API" и чем оно лучше неродного?

Я же указал в скобках — работает через те же типы данных, что и само приложение. И лучше оно удобством.

_>>- программистам в остальной части приложения не надо знать тонкости работы хранилища — этим может заниматься один спец. по нему
НС>IQueryable обеспечивает тоже самое.

Как минимум надо понимать всякие там join'ы, подзапросы и т.п. Не говоря уже о том, что для некоторых БД некоторые типы запросов могут оказываться неэффективными.

_>>- при необходимости можно легко сменить тип хранилища.
НС>IQueryable обеспечивает тоже самое.

Только в рамках реляционных СУБД. Или быть может linq2db может помочь сохранить данные в MongoDB? )