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

J>Да это все понятно. Но опять же опустимся с небес на землю. Вот есть какая-то сложная операция, не влезающая в SQL. Например — поиск хорошего ресторана, до которого по трассе от заданой точки не дальше 5 км. Такой запрос не ляжет на LINQ.
Почему?

J>Мы можем заюзать его для извлечения минимума нужных данных, например можно вынуть все перекрестки и рестораны в квадрате 10x10 км — этого нам должно хватить. И потом — уточнить это все дело уже в коде.
А можно в студию пример вот этого "уточнить в коде"? Чтобы я проникся невозможностью свести дело к линку? Это раз.
J> Там нам не нужно будет плясять с бубнами, заставляя SQL-сервер решать эту задачу, заодно и снимем с него вычислительную нагрузку.
И там нам точно понадобятся какие-то датаконтексты с change tracking и identity map?
Или всё-таки хватит обычных иммутабельных объектов, иногда с именованными классами?

J>Я хочу показать, что на простых примерах — да, select в LINQ решает простые проблемы от корки до корки и это клёво. А чуть дальше — и всё, приехали. И это — только запросы.
Ну так никто и не требует передавать в сервер прямо всё. Вона, вставил где надо AsEnumerable — и велкам ту Linq2Objects.
Тут давеча ray tracer на линке пробегал — а ты "рестораны... перекрёстки..."

J> Сценарии обработки информации могут быть намного сложнее.


J>Да понятно что размазывание состояния не бывает бесплатным. Речь о том, что без него далеко не всегда можно обойтись.
Таких случаев значительно меньше, чем обратных.
J>А порой оно, создавая, конечно, свои проблемы, решает другие: масштабирируемость например может увеличить.
Да ну? Пока что я видел строго обратное явление: стейтлесс системы значительно сложнее масштабировать. В большинстве тривиальных случаев обработка "отсоединенных данных" приводит тупо к тому, что сиквел сервер по-прежнему делает тот же объем работы (в конце концов, у него главное — стоимость I/O, на его фоне закормить современный CPU задачка нетривиальная), но плюс к этому еще и сервер приложений нагревает воздух. А если сервер приложений случился стейтлес, тогда начинаются еще более интересные сценарии — банальный раунд робин не пойдет, нужно делать балансировку с client affinity, а она небесплатна; или таскать разделяемый кэш, что тоже небесплатно и так далее и так веселее. В итоге вместо линейного по затратам масштабирования получаем какой-то экспоненциальный рост стоимости решения.

J>Кстати про аналогию между оптимистической и пессимистической блокировкой. Есть таки принципиальная разница. Например Вася и Дима открыли форму редактирования чего-то там. В пессимистическом варианте мы заблокируем полученые данные до того, как они оба эту форму не закроют. В оптимистическом — мы не дадим потом им сохранить изменения. Но далеко не факт, что они захотят что-то сохранять.
Я в курсе

Автор: Sinclair
Дата: 27.08.02

разницы пессимистики и оптимистики.

Здравствуйте, Jakobz, Вы писали:
J>Linq2Sql демонстрирует отображение Linq в SQL, а не C# в SQL. Нет никаких сомнений что можно также завернуть и update-ы. Сомнения есть в том, что так можно завернуть решение диф. уравнений или поиск пути на графе.
И насколько часто в задачах, связанных с СУБД, нужно заворачивать решение дифуров?
С поиском пути шансов встретиться больше; но всё же мне кажется, что для него один хрен датаконтекст мало полезен.

J>Так или иначе для решения сложных задач тебе придется вытаскивать данные на уровень приложения.
Это похоже на мантру. Мне вот почему-то кажется, что скорее для "сложных" задач придется втаскивать хранимки на CLR в SQL Server.

J>И да, и нет. Быстрее считать на хранимках, но теряем масштабируемость. Выгодно выгрузить данные и сразу отпустить блокировки, но можно наворотить себе проблем при записи данных назад.
То-то и оно. От того, что ты не удерживаешь объект "лок" (каждый из которых весит около 80 байт), факт наличия блокировки никуда не девается.

J>Ну они не совсем выбрасываются. Они просто проходят тяжкий путь через веб-запросы и пользовательский браузер.
Совсем-совсем. Откуда в пользовательском браузере возьмутся объекты класса Customer?

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

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

G>Такой запрос написать можно (в MS SQL 2008), и я уверен что работать оно будет побыстрее, чем наколеночная реализация в клиетском коде.

На SQL написать можно, если припрет ускорить. А можно ли это написать на LINQ?

J>>Я хочу показать, что на простых примерах — да, select в LINQ решает простые проблемы от корки до корки и это клёво. А чуть дальше — и всё, приехали. И это — только запросы. Сценарии обработки информации могут быть намного сложнее.
G>Нынешний SQL вроде как полн по тьюрингу, значит на нем все написать можно.
G>Другое дело что средств языка SQL для борьбы со сложностью не хватает.

Brainfuck тоже полон по Тьюрингу.

G>Да ну?
G>stateless улучшает масштабируемость, но никак не размазанность состояния.

Размазанность состояния не сама по себе улучшает. Просто если мы жертвуем "атомарностью" состояния, мы получаем много всяких других плюшек.

G>Даже если рассматривать пользователей, то оба могут открыть форму на чтение, но пока один правит (считаем что данные общие), другой не может увидеть ни актуальные данные, ни поменять что-то сам.
Ну да. Один открыл по глупости, другой ждет.

Кстати в MsSQL есть snapshot isolation level, который про оптимистическую конкуренцию как раз. А в тех же oraсle и firebird-е вообще весь принцип на multiversion concurency control-е. Так что даже внутри БД состояние вполне себе "размазывается" для повышения параллелизма.

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

S>И насколько часто в задачах, связанных с СУБД, нужно заворачивать решение дифуров?
S>С поиском пути шансов встретиться больше; но всё же мне кажется, что для него один хрен датаконтекст мало полезен.
Мы вроде как уже не про DataContext, а про то — вытаскивать ли что-то на клиента, или обходиться LINQ-to-SQL и гипотетическим Linq-to-CRUD?

J>>Так или иначе для решения сложных задач тебе придется вытаскивать данные на уровень приложения.
S>Это похоже на мантру. Мне вот почему-то кажется, что скорее для "сложных" задач придется втаскивать хранимки на CLR в SQL Server.
Например вызовы каких-нибудь сторонних веб-сервисов для получения доп. данных — тоже на SQL-сервер пойдут?

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

J>>Да это все понятно. Но опять же опустимся с небес на землю. Вот есть какая-то сложная операция, не влезающая в SQL. Например — поиск хорошего ресторана, до которого по трассе от заданой точки не дальше 5 км. Такой запрос не ляжет на LINQ.
S>Почему?

А ты напиши. Меня вот гложут сомнения что это будет по-человечески выглядеть. Например: таблицы crossroads (id, x, y) и roads (firstCrossRoadId, secondCrossRoadId), найти кратчайший путь от одного перекрестка до другого.

S>И там нам точно понадобятся какие-то датаконтексты с change tracking и identity map?
S>Или всё-таки хватит обычных иммутабельных объектов, иногда с именованными классами?
Я вообще не про это пример приводил, если что.

J>>Я хочу показать, что на простых примерах — да, select в LINQ решает простые проблемы от корки до корки и это клёво. А чуть дальше — и всё, приехали. И это — только запросы.
S>Ну так никто и не требует передавать в сервер прямо всё. Вона, вставил где надо AsEnumerable — и велкам ту Linq2Objects.
S>Тут давеча ray tracer на линке пробегал — а ты "рестораны... перекрёстки..."

Это уже извраты. Хочется свежей функциональщины — есть для этого специальные языки.

J>> Сценарии обработки информации могут быть намного сложнее.
S>

S>Да ну? Пока что я видел строго обратное явление: стейтлесс системы значительно сложнее масштабировать. В большинстве тривиальных случаев обработка "отсоединенных данных" приводит тупо к тому, что сиквел сервер по-прежнему делает тот же объем работы (в конце концов, у него главное — стоимость I/O, на его фоне закормить современный CPU задачка нетривиальная), но плюс к этому еще и сервер приложений нагревает воздух. А если сервер приложений случился стейтлес, тогда начинаются еще более интересные сценарии — банальный раунд робин не пойдет, нужно делать балансировку с client affinity, а она небесплатна; или таскать разделяемый кэш, что тоже небесплатно и так далее и так веселее. В итоге вместо линейного по затратам масштабирования получаем какой-то экспоненциальный рост стоимости решения.

А SQL-сервера, видимо, можно бесплатно в любом количестве расставлять с линейной масштабируемостью?

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

J>А ты напиши. Меня вот гложут сомнения что это будет по-человечески выглядеть. Например: таблицы crossroads (id, x, y) и roads (firstCrossRoadId, secondCrossRoadId), найти кратчайший путь от одного перекрестка до другого.
Ну, как только ты приведешь код, который делает это "на C#" — так я сразу же перепишу его на linq

J>Я вообще не про это пример приводил, если что.
Э, нет. Я всю цепочку рассуждений вижу и помню.
Ты считаешь, что change tracking нужен потому, что это лучший способ отслеживать изменения в объектах в памяти.
А изменения в объектах — потому, что мы подняли объекты в память.
А подняли объекты мы потому, что это лучшее, что можно поднять в память из базы.
А в память — потому, что в сервере трудно обрабатывать.

Видишь, как длинно? Сейчас ты мне пытаешься обосновать последний (то есть первый) шаг в этой цепочке: нужду тащить данные в C#. Ну, так я не против — только примеры, которые ты приводишь недостаточно убедительны для дальнейших шагов. То есть ок, вот мы взяли запрос, отмапили его в некоторые объекты анонимного класса, и навернули над ними некоторую строго императивную обработку. Для всего этого Linq прекрасно подходит.

Но вот что дальше — вот это вопрос. Тебе сейчас кажется, что и изменения тебе будет удобнее вносить прямо в объекты. А мне вот кажется, что удобнее будет по частям строить "запрос на модификацию" — пусть построение этого запроса будет головоломно сложным, зато потом на сервер он уедет единым батчем.

J>Это уже извраты. Хочется свежей функциональщины — есть для этого специальные языки.
Это не извраты. Это всего лишь привычка выполнять декомпозицию задачи определенным способом. Вон, глянь в блоге Липперта как он решает задачку из игры Эрудит — найти все 8-буквенные слова из словаря, которые можно построить из заданных 6ти букв. Спорим, что твоя первая идея алгоритма не будет выражена в линке

J>А SQL-сервера, видимо, можно бесплатно в любом количестве расставлять с линейной масштабируемостью?
Ну, пока что ты не продемонстрировал никаких способов снижения нагрузки на SQL Server. Поэтому именно он по-прежнему остается лимитирующим фактором в отсоединенной модели; а сервера приложений только воздух греют.

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

J>Мы вроде как уже не про DataContext, а про то — вытаскивать ли что-то на клиента, или обходиться LINQ-to-SQL и гипотетическим Linq-to-CRUD?
Я не против вытаскивать на клиента полезную часть данных.
Я против вытаскивания "целого кастомера" для того, чтобы прибавить ему к полю "карма" пять баллов.
Потому что потом нужно будет срочно побежать в базу со всеми его полями — проверять, не опрокинулась ли оптимистичная блокировка. А то мало ли, может быть эта карма была выдана на основе фотографии — мы же не знаем, на какие именно данные смотрел код.


S>>Это похоже на мантру. Мне вот почему-то кажется, что скорее для "сложных" задач придется втаскивать хранимки на CLR в SQL Server.
J>Например вызовы каких-нибудь сторонних веб-сервисов для получения доп. данных — тоже на SQL-сервер пойдут?
А они тут при чем? Сбегал в сервисы — подготовил батч — отправил батч.

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

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

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

G>>Такой запрос написать можно (в MS SQL 2008), и я уверен что работать оно будет побыстрее, чем наколеночная реализация в клиетском коде.

J>На SQL написать можно, если припрет ускорить. А можно ли это написать на LINQ?
Ускорить как? Хинтами — нет, вряд ли в Linq будут database-specific средства. Вынести в процедуру — спокойно, иногда даже без изменений клиентского кода.
Ускорение работы обычно строится на правильной расстановке индексов и построении условий чтобы индексы работали, а также нужна правильная проекция.

Я на Linq писал такие запросы, которые сам бы никогда ручками в SQL не написал.

J>>>Я хочу показать, что на простых примерах — да, select в LINQ решает простые проблемы от корки до корки и это клёво. А чуть дальше — и всё, приехали. И это — только запросы. Сценарии обработки информации могут быть намного сложнее.
G>>Нынешний SQL вроде как полн по тьюрингу, значит на нем все написать можно.
G>>Другое дело что средств языка SQL для борьбы со сложностью не хватает.
J>Brainfuck тоже полон по Тьюрингу.
И на нем тоже можно сделать все. Только не пишут именно по причине слабости языка. Вот c SQL такая же история.

G>>Да ну?
G>>stateless улучшает масштабируемость, но никак не размазанность состояния.
J>Размазанность состояния не сама по себе улучшает. Просто если мы жертвуем "атомарностью" состояния, мы получаем много всяких других плюшек.
Как раз жертва атомарностью — помещение состояния еще куда-то кроме БД.

G>>Даже если рассматривать пользователей, то оба могут открыть форму на чтение, но пока один правит (считаем что данные общие), другой не может увидеть ни актуальные данные, ни поменять что-то сам.
J>Ну да. Один открыл по глупости, другой ждет.
У меня был случай когда я банально не мог сделать коммит в SVN в течение часа. Пытаюсь закоммитить, мне говорит что надо поапдейтиться, апдейчусь, собираю проект, пытаюсь закоммитить, а кто-то уже успел до меня... и по-кругу.
Оптимистичная блокировка помогает только при слабой нагрузке и большом времени удержания.
Когда работаем с данными, обрабатывая один HTTP запрос к примеру, то оптимистичная блокировка нафиг не нужна, лучше использовать пессимистичную блокировку в БД.

J>Кстати в MsSQL есть snapshot isolation level, который про оптимистическую конкуренцию как раз. А в тех же oraсle и firebird-е вообще весь принцип на multiversion concurency control-е. Так что даже внутри БД состояние вполне себе "размазывается" для повышения параллелизма.
Пробовали snapshot пускать под высокой нагрузкой? Поддержание снапшота дороже чем блокировок, при этом все проблемы перекладываются на клинтов СУБД.

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

S>Да ну? Пока что я видел строго обратное явление: стейтлесс системы значительно сложнее масштабировать. В большинстве тривиальных случаев обработка "отсоединенных данных" приводит тупо к тому, что сиквел сервер по-прежнему делает тот же объем работы (в конце концов, у него главное — стоимость I/O, на его фоне закормить современный CPU задачка нетривиальная), но плюс к этому еще и сервер приложений нагревает воздух. А если сервер приложений случился стейтлес, тогда начинаются еще более интересные сценарии — банальный раунд робин не пойдет, нужно делать балансировку с client affinity, а она небесплатна; или таскать разделяемый кэш, что тоже небесплатно и так далее и так веселее. В итоге вместо линейного по затратам масштабирования получаем какой-то экспоненциальный рост стоимости решения.

Выделенное — наверное имелось ввиду стейтфул.

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

J>Да, если у тебя есть детерменированная операция, db = f(db) — ты можешь ее записать в одной транзакции, и это будет правильно. Тебе ничего не нужно "отсоединять", мэппить в объекты, select-ить из базы чтобы сделать update и заниматься прочей чепухой.

Именно. И именно этого нет в linq. Зато в linq есть DataContext который противоречит подходу предполагающему использовать DML-запросы.

J>И вот именно эти задачи решает Linq to sql. Замечу — это не какой-то волшебный инструмент, который принес реляционную алгебру в ООП (как мне показалось именно этого хотел от него VladD2).

Где я такое говорил?

J>Еще в Linq to sql есть DataContext, с которого начался спор. Эта штука частично решает/упрощает некоторые задачи и, в общем, могла бы "быть попроще". Но, на мой взгляд, сильного оверхеда она не приносит, а удобства у нее есть. Например, она сглаживает проблему с identity. И сама запоминает какие объекты менялись, чтобы потом нам не вспоминать что апдейтить. Я не вижу в этих удобствах ничего плохого. В любом случае от этих удобств никто не запрещает отказываться — на то ReadOnly и прочии фичи.

Ёлы, палы. Ну, сколько можно объяснять? DataContext и технология кэширования которая за ним стоит — это тупиковый подход. Он мешает использованию DML-подхода.

DML-подход не мешает написанию простенького фрэймворка который бы позволял бы сохранять изменения данных производимые путем изменения свойств объектов хранящих эти данных. Для этого всего лишь нужно сгенерировать код аналогичный тому что генерирует linq-овский генератор кода. Но сама запись должна осуществляться без кэширования и в рамках текущей транзакции (явной или не явной созданной по средствам менеджера распределенных транзакций — это не важно).

Тогда мы сможет написать код вроде:

var query = from c in customers where c.ID = 123 select c;
var customer = query.First();

customer.Name = "New name";
customer.Phones.Add("(495) 123-45-67");

using (var tran = BD.BeginTran())
  tran.SaveObjects(customer);
// или как-то так:
// BD.SaveInNewTran(customer)

То есть очень похоже на то что происходит с DataContext.
Но при этом на не нужно отслеживать идентичность объектов, производить кэширование изменений (а значит и синхронизацию кэша) и т.п.
Все что нам нужно — это иметь объект который хранит идентификатор записи в БД, исходные данные изменяемые в через объект и изменения. Этого достаточно чтобы сформировать SQL-запрос который запишет изменения в БД.

При этом мы будем иметь возможность изменить все что нам угодно с помощью отдельных, встроенных в язык типизированных запросов.

J>Почему я тут так подробно это расписываю? Потому что разговор ушел куда-то в полный астрал. Мы уже, вон, до Хаскеля дошли. Непонятно где Немерле только отстало

Дык это ты его уводишь. Тебе уже несколько человек обяснили, что они имеют в виду, а ты выслушиваешь их и гнешь свою линию.

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

G>>Там где необходимо "отсоединение" там контексты Linq2SQL, EF, сессии NHibernate тоже не справляются и надо "отсоедиенный" набор данных поддерживать руками.
J>Вполне справляются. Автоматически они это не делают, но лучше уж так, чем никак.

Это если исходить, что весь код должен написать кто-то за тебя.
А если предположить, что код может быть написан и тобой в том числе, то совершенно реальной становится перспектива создать свой фрэймворк записи основанный на DML-запросах и не использующий идеологии датаконтекста.

J>Еще раз:
J>- identity tracking. Позволяет имитировать отсутствие identity у объектов внутри контекста. Позволяет дозапрашивать данные и не думать о том, что у нас могут появиться два разных объекта с одним и тем же.

Задолбал. Тебе уже 100 раз повторили, что запрашивать данные и так можно. А записывать их можно и без контекста с трекингами.

J>- change tracking. Позволяет не писать на каждый чих db.НеЗабудьПроапдейтитьПотом(myObject).

А зачем такой бред писать? Если объект один, то на потом его откдадывать не надо. А если у нас массовые изменения, то у нас просто не будет объектов. Будет просто список изменений.

J>Оба два — для удобства.
J>Оба — не обязательно юзать, они отключаются

У тебя мозг уже работает только в условиях одной парадигмы. Объяснить тебе что-то невозможно, так как ты просто не хочешь воспринять наличие другой парадигмы.

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

J>>- change tracking. Позволяет не писать на каждый чих db.НеЗабудьПроапдейтитьПотом(myObject).

VD>А зачем такой бред писать? Если объект один, то на потом его откдадывать не надо. А если у нас массовые изменения, то у нас просто не будет объектов. Будет просто список изменений.

А можно где-нибудь посмотреть на пример такого фреймворка? Или почитать?

J>>Оба два — для удобства.
J>>Оба — не обязательно юзать, они отключаются

VD>У тебя мозг уже работает только в условиях одной парадигмы. Объяснить тебе что-то невозможно, так как ты просто не хочешь воспринять наличие другой парадигмы.

Ну, тут есть другие люди, они читают. Я вот пока не до конца понял, как это будет работать

Здравствуйте, gandjustas, Вы писали:
G>Выделенное — наверное имелось ввиду стейтфул.
Совершенно верно. Спать не реже одного раза в 24 часа — крайне полезная практика.

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

S>Всё как раз наоборот: проблемы производительности и блокировок — вторая натура "отсоединенной модели".

Ага. Только не "отсоединенной модели", а модели с датаконтекстами, идентити трекингами и т.п.
А "отсоединенная модель" — это датасеты которые отлично совместимы с DML-подходом.
В ней датасет — это структура данных позволяющая перетащить данные куда надо, изменить их там скопом, а потом отослать на сервер где вполне примитивным алгоритмом эти изменения превращаются в набор DML-вызовов.

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

G>>>Там где необходимо "отсоединение" там контексты Linq2SQL, EF, сессии NHibernate тоже не справляются и надо "отсоедиенный" набор данных VD>Задолбал. Тебе уже 100 раз повторили, что запрашивать данные и так можно. А записывать их можно и без контекста с трекингами.

Я не тебе отвечал вообще-то и тебя не задалбывал. Задаете вопрос зачем identity tracking, я отвечаю.
Записывать можно и без контекста и без трекинга. А можно — с контекстом и трекингом.

J>>- change tracking. Позволяет не писать на каждый чих db.НеЗабудьПроапдейтитьПотом(myObject).

VD>А зачем такой бред писать? Если объект один, то на потом его откдадывать не надо. А если у нас массовые изменения, то у нас просто не будет объектов. Будет просто список изменений.

J>>Оба два — для удобства.
J>>Оба — не обязательно юзать, они отключаются

VD>У тебя мозг уже работает только в условиях одной парадигмы. Объяснить тебе что-то невозможно, так как ты просто не хочешь воспринять наличие другой парадигмы.

Нет. Просто у меня мозг работает ближе к практике. Я понимаю что вы хотите. Но мне непонятны детали. Давай поговорим про конкретику:
1. как должно выглядеть в коде то, о котором вы говорите? Возьмем, например, update. Видимо там должно быть выражение, которое поставить в where и какой-то набор выражений про то, что сделать со столбцами. При чем для каждого выражения для каждого столбца должен быть доступ к контексту всей строки. Приведи хоть примерчик в псевдокоде. И как быть с update из другого select-а?
2. очевидно что программу из одних select-ов и update-ов не напишешь. Между ними данные должны попадать в код и как-то обрабатываться. Например у нас есть три колонки a, b и c. Нам нужно сделать какие-то вычисления и положить результат в колонки d и e. Предположим что для этого задействуется большое количество C#-кода. И что переписать это в форме запроса в базу нельзя — например d и e запрашиваются у стороннего веб-сервиса.
Как это все будет выглядеть? Отдельно будут объекты с полями a, b и c, полученые из базы и отдельно — объекты с d и e для сохранения, так? Анонимные типы нельзя передавать между методами, поэтому про них забываем. Получается что для каждой нужной комбинации полей строки придется создавать свой объект?
3. как быть, если в update что-то сложнее, чем встроеные в sql функции? Что должен сделать LINQ, если он не может выполнить на БД какой-нибудь гиперболический косинус? Тащить все в код, там перефигачивать и заливать назад?

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

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

S>>Я не понимаю — неужели Linq2Sql недостаточно убедительно демонстрирует отображение C# в полноценный SQL с блэкджеком и шлюхами?
S>>Никакого сомнения нет в том, что всё это возможно (с некоторыми нюансами).

J>Linq2Sql демонстрирует отображение Linq в SQL, а не C# в SQL.

Linq даже переводится как "запросы интегрированные в язык". Linq — это теперь часть C# и Жлабэйскика.
Так что начинай свыкаться с этой мыслью.

J>Нет никаких сомнений что можно также завернуть и update-ы.

Вообще-то есть. Linq — это встроенный ДСЛ. В Шарпе и Васике нет средств встаивания ДСЛ-ей пользователями.
Просто мощности этих языков недостаточно чтобы встроить поддержку таких ДСЛ-ей универсальными средствами. Но есть Хаскель и Немерле которые это сделать позволяют.
Так что сначала мы увидим поддержку в этих языках, и в виде ДСЛ-я основанного на ФВП (т.е. без поддержки синтаксиса) в Шарпе и Васике. А потом такую поддержку добавят и в эти языки (если к тому времени в них не добавят макросы с помощью которых можно будет сделать это универсально).

J>Сомнения есть в том, что так можно завернуть решение диф. уравнений или поиск пути на графе. Так или иначе для решения сложных задач тебе придется вытаскивать данные на уровень приложения.

У тебя каша в голове. Ты смешиваешь алгоритмы и DSL-и. Алгоритмы не требуют наличия DSL-ей. Возможно для некоторых алгоритмов задачи проще описывать в виде некоторых ДСЛ-ей, но пареллелей между алгоритмами и DSL-ями это провести не дает.

Тот же поиск пути в графе выражается функцией принимающей граф, и два его узла.

Но есть множество задач решение которых резко упростилось, если бы их можно было описать в виде ДСЛ-я и реализовать некий механизм интерпретации ДСЛ-я или генерации по нему кода на универсальном языке. Но это уже другой разговор.

J>И да, и нет. Быстрее считать на хранимках, но теряем масштабируемость. Выгодно выгрузить данные и сразу отпустить блокировки, но можно наворотить себе проблем при записи данных назад.

Каааша. Ужасная каша в голове. Заучил какие-то догмы и оперируешь ими.

J>Ну это так везде. Чем выше абстракция — тем больнее с нее падать

Неееааа!
Тут ты ошибашся. Просто для обработки данных в БД не нужно использовать неподходящую для этого абстракцию — полноценные объекты. Для этого лучше использовать функциональный подход адаптированный к императивной сущности БД — DML-операторы. И лучше если они будут статически типизированными как linq.

ФП как раз идеален для обработки наборов данных. Линг отлично демонстрирует, что приемы ФП позволяют стереть границу межу языком программирования и СУБД, но пока что только для чтения данных.

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

J>>Linq2Sql демонстрирует отображение Linq в SQL, а не C# в SQL.

VD>Linq даже переводится как "запросы интегрированные в язык". Linq — это теперь часть C# и Жлабэйскика.
VD>Так что начинай свыкаться с этой мыслью.

Linq — это часть, подмножество C#.

VD>Каааша. Ужасная каша в голове. Заучил какие-то догмы и оперируешь ими.

А мне вот кажется что ты слишком далеко в астрал залез. Я там ниже про конкретику написал — давай там продолжим разговор.

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

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

S>>Всё как раз наоборот: проблемы производительности и блокировок — вторая натура "отсоединенной модели".

VD>Ага. Только не "отсоединенной модели", а модели с датаконтекстами, идентити трекингами и т.п.
VD>А "отсоединенная модель" — это датасеты которые отлично совместимы с DML-подходом.
VD>В ней датасет — это структура данных позволяющая перетащить данные куда надо, изменить их там скопом, а потом отослать на сервер где вполне примитивным алгоритмом эти изменения превращаются в набор DML-вызовов.

Я че-то перестал понимать.
Если в датасете поменять (названия) таблицы на списки сущностей, строки на объекты, то получится тоже самое что и в контексте.

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

S>>Тут давеча ray tracer на линке пробегал — а ты "рестораны... перекрёстки..."

J>Это уже извраты. Хочется свежей функциональщины — есть для этого специальные языки.

Дык линк — это и есть функциональщина завернутая для индусов в обертку под холом... тфу ты, под SQL .

linq — это набор стандартных функций ФП расширенный сортировкой и групировкой.
Все нужно, чтобы на нем можно было вычислить все что угодно — это добавить рекурсию. Тогда это будет полный по Тьюрингу язык.

SQL же после появления CTE стал полным по Тьюрингу без каких либо оговорок. На нем теперь черта лысого можно расчитать, не то что какие-то там пути.

Я и в до CTE-шные времена одним запросом считал оборотную ведомость по предприятию.

Так что мощи SQL более чем достаточно для любых применений. Но нужно уметь писать функционально.

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

J> Почему дизайн с person1 == person2 — не нормален?

Потому что предполагает, что человек в любом месте программы имеет одинаковое представление. В то время как в реальности в одном месте программы от человека нужно только ФИО, в другом — только адрес, в третьем — вся доступная информация о человеке, включая явки, пароли и адрес любовницы. Поэтому сравнивать представления человека не имеет смысла, нужно сравнивать идентификаторы.