Здравствуйте, IT, Вы писали:

_>>Хм, что-то не очень понятно (видимо потому что я с Linq не работаю), в особенности чем являются различных идентификаторы не из таблиц (которые не m. и f.). Или может вместо объяснения ты просто покажешь какой sql генерируется из этого запроса? )
IT>Что-то вроде такого:

ОК, теперь понятно. Значит сравниваем:

from m in db.Messages
join f in db.AllowedForumsView(Account.ID) on m.ForumID equals f.ID
where
    ids.Contains(m.ID) &&
    m.BlogMessages.All(bm => bm.BlogID != BlogService.Cache.GetBlogID(db, id))
orderby
    m.Subject
select
    m.ID + ", " + m.Subject;

и

auto m=DB::Messages{};
auto bm=DB::BlogMessages{};
auto f=AllowedForumsView(account_id);
auto q=select(m.ID, m.Subject)
    .from(m.join(f).on(m.ForumID==f.ID))
    .where(
        m.ID.in(value_list(ids))&&
        exists(select(all_of(bm)).from(bm).where(m.BlogID==bm.BlogID&&bm.BlogID!=id)))
    .order_by(m.Subject.asc());

На мой вкус для людей знакомых с SQL второй вариант понятнее. Хотя конечно синтаксис без скобок и точек выглядит проще и яснее, но только если бы он соответствовал SQL. А в первом варианте это совсем не так (мне вот даже понадобилась "консультация" для правильного понимания этого кода).

_>>Ну да, DAL — это правильное решение для сложных проектов и особенно рассчитанных на работу с разными СУБД.
IT>DAL — это анахронизм. Тем более при работе с разными СУБД.

Однако почему-то большинство веб-движков (форумы, галереи, чаты и т.п.), работающих с разными СУБД, как раз по такому принципу и построены. )

_>>В базе null конечно же может быть и для работы с ним там в библиотечке есть все необходимые средства (и соответствующий предикат условий и проверка результатов запросов). Автору даже предлагали сделать возврат значений для не "not null" колонок через std::optional (аналог Nullable<T> из C#), но он предпочёл обойтись проверочной функций (видимо из соображений эффективности).
IT>Понятно. Т.е. без широко обсуждаемых кастылей не обошлось.

Эмм, что? )