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

K>Сейчас существуют и всегда существовали разные версии SQL Server (как и других СУБД), от Express до Enterprise. Если не нужны фичи последней, то зачем за неё платить? Выбираем более дешёвую, с меньшими возможностями. Если добавить API, специально разработанный для эффективного взаимодействия с linq-провайдером, при этом выкинув ставшие ненужными другие возможности, то и на такую версию найдутся потребители.
Любая дополнительная гибкость на практике оборачивается геморроем в развёртывании. Т.е. там, где раньше нам достаточно было указать на нужный нам edition, теперь надо предоставлять простыню со списком депендов.
Особенно здорово, когда при апгрейде нашего приложения требования повышаются — т.е. просто запустить апгрейд недостаточно, надо попросить додеплоить недостающие фичи в сервер.
С учётом того, что в промышленной эксплуатации задачи на апгрейд и задачи на деплой делают разные команды с разными правами, это выглядит как хорошее такое усложнение.

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

_>>Я согласен. Linq, как пример лёгкой ORM
НС>linq это вообще не ORM.

Естественно речь про linq2db. Но т.к. мой собеседник использовал просто слово linq, то и я стал сокращать — нам обоим было вполне понятно.

_>>2. У linq не всё в порядке с эффективностью.
НС>

Самое забавное, что данная фраза верна в любой интерпретации. Т.к. проблемы с эффективностью есть как у linq2db, так и у просто linq. )))

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

_>>Кстати, а mysql тогда как там живёт? )
НС>Мне постоянно кажется, что мои ответы ты читаешь через строчку. Хреново он там живет.

Я говорю не про быстродействие, а про кастомизацию запросов. Ты же сказал, что там всё работает благодаря схожести sqlite и postresql. Однако у Trac'a заявлена ещё и поддержка mysql...

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

_>>А слышал о применение там sql? )))
S>Нет. Потому что с точки зрения SQL, все эти "обработки экспериментальных данных" малоинтересны. Ну надо сделать свёртку двух рядов, по терабайту каждый. И что? Это примитивный алгоритм, который ещё и хорошо параллелится, а при сбое его всегда можно перезапустить заново.

Вот вот. ) Только нет никакой "точки зрения SQL", а есть только точка зрения создателей подобных систем (кстати стоят многие миллионы), которым как раз вообще не интересен sql. Ну и кстати там не свёртка двух больших рядов, а совсем другая схема. Упрощённо, мы имеем там некую решётку (n-мерный массив), в узлах которой задан набор величин. Решётка естественно не маленькая. И имеем некую функцию (обычно довольно сложную), которая преобразует всю решётку (применяясь к узлу). Соответственно нам надо преобразовать решётку огромное число раз, сохраняя каждое состояние.

Но тут главное не это, а твоя фраза "И приводит к дичайшим тормозам, как только объём этой кунсткамеры перестаёт помещаться в RAM.". Как видно имеется очень много таких вот быстрых и эффективных систем, без всякой связи с реляционными моделями. Кстати, результатами одной из таких систем ты ежедневно пользуешься)))

_>>При работе с большими графами следует вообще отказаться от реляционных БД.
S>Если вам нужны гарантии восстановления после сбоев и ACID, то альтернативы RDBMS у вас нет.

С каких это пор транзакции являются прерогативой реляционной модели?

S>И работают они на отлично — особенно если отказаться от наркомании типа "давайте засосём в память все остатки по складам, залочим их, побегаем по ним курсорами, а потом скинем обратно пачку апдейтов", которую навяливают традиционные ORM конструкты.Вы, для смеху, поинтересуйтесь результатами тестов TPC-C. Там ни один хибернейт и в топ-100 не попадёт.

А я и не сторонник таких штук. )

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

MA>Ради интереса посмотрите Closure Table — там небольшой геморрой со вставкой, но все поддеревья можно выбирать одним запросом (без рекурсии).
MA>http://karwin.blogspot.co.uk/2010/03/rendering-trees-with-closure-tables.html

Ааа ну тут уже две таблицы используется и join. Хотя конечно вторая целиком в индексе сидит, так что по идее должно быть быстро. Но всё равно не то, хотя и получше вариантов с одной таблицей. Собственно более менее приемлемое (подходит для многих вариантов простых графов) решение известно и даже существует на практике: http://www.postgresql.org/docs/9.4/static/ltree.html. Только вот приложение, использующее его, будет жёстко привязано к одной СУБД. Ну и опять же подходит это не для всех графов, хотя возможности таких СУБД как MongoDB в принципе покрывает (в области работы с иерархиями, не вообще — с автоматическим шардингом у всех реляционных БД дела плохи). А для более сложных случаев лучше брать специальные СУБД, типа Neo4j.

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

_>Это зависит от уровня абстракции ORM. Если мы имеем тяжёлую ORM (в которой весь код имеет вид db.persist(obj); ), то т.к. она полностью скрывает весь вид запросов внутри себя, то в принципе можно всю зависимость от вида СУБД там и оставить (с другой стороны такие ORM не особо эффективны сами по себе, вне зависимости от переносимости). Если же мы имеет дело с лёгкой ORM (где активно используется sql синтаксис), то уже можно очень легко наткнуться в прикладном коде на особенности конкретных СУБД.

Я же говорю, это всё дело техники. В linq2db есть как Insert(obj), так и Insert(() => new MyTable { Field1 = ... }) и ещё некоторые перегрузки, которые в точности повторяют действия программиста.

_>1. Т.к. это лёгкая ORM, то всё же можно в прикладном коде наткнуться на разную обработку запросов разными СУБД.

Эта проблема по шкале важности из 10-ти баллов набирает где-то 0.5, а подавляющее число разработчиков о ней вообще ничего не знают.

_>2. У linq не всё в порядке с эффективностью. Уже в смысле накладных расходов, а не особенностей sql. Что собственно и обсуждалось в данной теме.

За всё нужно платить. У генерации SQL по Expression Tree есть три проблемы:

1. Анализ и разбор ET.
2. Генерация параметрозависмого SQL.
3. Мапинг результата.

С первым всё просто. Проанализированное дерево нужно кешировать. Дальше стоит лишь вопрос эффективности кеша и функции сравнения. Судя по тестам на ormeter.org эти накладные расходы могут составлять не более 25-30% по сравнению с CompiledQuery на самых примитивных запросах, где время работы самого сервера минимально. При усложнении запроса это время нивелируется и на фоне самого запроса становится малозаметным. Т.е. правило простое. Для примитивных, быстрых, массированных запросов используется CompiledQuery, для сложных можно такой фигнеё не страдать. У них другая проблема — мапинг, но о ней позже.

Со вторым тоже всё понятно. В зависимости от параметров запроса SQL может быть разным. Например, сравнение поля с параметром запроса выглядит на C# как field == p, но SQL нужно генерировать разный, в зависимости от того имеет ли p значение или он null. Генерировать универсальную помоечку — скорее всего убить план запроса, так что лучше потратиться на клиенте. Таким образом генератор должен отличать параметрозависимые запросы от непараметрозависимых и кешировать или нет сгенерированный SQL.

С мапингом проблемы возникают лишь для запросов, в которых присутствуют десятки колонок и запрашиваются десятки/сотни тысяч+ записей. В этом случае в рамках одного запроса обрабатываются миллионы значений и неэффективный маппинг может серьёзно тормозить. В случае linq2db (кстати, когда я говорю linq, то не имею ввиду конкретно linq2db (это я про твоё предыдущее сообщение)) этой проблеме уделялось приоритетное внимание и проблема успешно решена. Маппинг работает чуть медленнее параноидального рукописного, а если учесть, что параноей, в виде использования индексов вместо имён полей, страдают не многие, то зачастую и быстрее рукописного за счёт тех же индексов и кеширования.

IT>>Про главное и самое могучее преимущество linq перед плоским SQL — type-safety, я вообще молчу.
_>Конечно. Но в этой теме опять же показывали, что возможна статическая типизация sql запросов без накладных расходов.

Мы это уже проходили много раз. Это не статическая типизация. Это — жертвоприношение. В жертву приносится буквально всё: простота кода, читабельность, гибкость, расширяемость. Остаётся только типизация, причём весьма условная. Как с условным сроком. Вроде как на свободе, но к участковому каждую неделю нужно ходить отмечаться. Делать на этом какие-то простые вещи, например, для демонстрации возможностей ещё как-то можно. Но заставить кого-то это использовать в реальных проектах можно только либо взяв в заложники семью, либо надо быть изобретателем этого самого гениального изобретения. Шаг вправо, шаг влево — расстрел, прыжок на месте — провокация. Использовать клиентские выражения в этом коде нельзя, т.е. проекции пролетают мимо. Способ добавить свои SQL функции отсутствует. Как мне, например, в запросе вернуть поле, предварительно сделав ему RTrim? В коде куча синтаксического шума. Да и при использоавнии цепочек вызовов методов нужно знать меру. Одно дело методы уровня SQL CLAUSE, а другое выпиливать с помощью них expressions and conditions. Модель данных — ужос! ужос! ужос! и мама, роди меня обратно. Это же рассадник копипейстных багов. Да и с самой типизацией как я уже сказал не всё в порядке. Затолкать в запрос таблицу, ему не принадлежащую, вовсе не проблема. Да и, как я понял, помножить строку на дату, тоже не вопрос.

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

На самом деле единственной альтернативой linq может стать compile-time кодогенерация. Желательно с возможностью синтаксического расширения языка. Команда в бозе почившего Немерле, как раз занималась подобным проектом — Нитрой. Но, к сожалению, как я понял, парни поднялись в облака и улетели в далёкие дали. Где они теперь витают никто не знает. Так что в текущем десятилетии мы вряд ли получим в этом плане что-то лучшее, чем linq.

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

IT>С мапингом проблемы возникают лишь для запросов, в которых присутствуют десятки колонок и запрашиваются десятки/сотни тысяч+ записей. В этом случае в рамках одного запроса обрабатываются миллионы значений и неэффективный маппинг может серьёзно тормозить. В случае linq2db (кстати, когда я говорю linq, то не имею ввиду конкретно linq2db (это я про твоё предыдущее сообщение)) этой проблеме уделялось приоритетное внимание и проблема успешно решена. Маппинг работает чуть медленнее параноидального рукописного

Выше по теме заявлялось что для мэппига в linq2db генерируется код настолько быстрый, насколько позволяет платформа. Так ли это?

IT>На самом деле единственной альтернативой linq может стать compile-time кодогенерация.

Это возможно в D, Nemerle и C++ (менее удобно чем в первых двух, но всё же возможно).

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

EP>Выше по теме заявлялось что для мэппига в linq2db генерируется код настолько быстрый, насколько позволяет платформа. Так ли это?

Надеюсь. Обычно накладные расходы на маппинг происходят из-за бесконечного вызова вспомогательных методов и боксинга. В linq2db маппинг задаётся в виде выражений Expression Tree. Когда строится код для создания проекции, то эти ET раскрываются и в них параметр IDataReader заменяется на текущий DataReader и таким образом проекция собирается в кучу. С конвертацией типов дело обстоит примерно также. В результате для

from t in db.Person
select p

будет сгенерирован код создания проекции

new Person
{
    ID        = rd.GetInt(0),
    FirstName = rd.GetString(1),
    LastName  = rd.GetString(2),
}

т.е. так же как если бы он писался в параноидальном варианте.

IT>>На самом деле единственной альтернативой linq может стать compile-time кодогенерация.

EP>Это возможно в D, Nemerle и C++ (менее удобно чем в первых двух, но всё же возможно).

На счёт D не знаю. В D можно синтаксис расширять? В Nemerle может и можно, но кривой API компилятора превратит это занятие в личную драму жизни. В C++, насколько мне известно, тоже пока синтаксис нельзя расширять. А без этого мы получим только решения, изувеченные цепочками вызовов методов, которые мы здесь уже видели. Кстати, не самое плохое решение, но порочна сама идея.

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

_>Но тут главное не это, а твоя фраза "И приводит к дичайшим тормозам, как только объём этой кунсткамеры перестаёт помещаться в RAM.". Как видно имеется очень много таких вот быстрых и эффективных систем, без всякой связи с реляционными моделями. Кстати, результатами одной из таких систем ты ежедневно пользуешься)))
Ну, не то что бы "очень много". Готов поспорить, что реляционных баз данных эксплуатируется на три-четыре десятичных порядка больше, чем систем обработки экспериментальных данных.

_>С каких это пор транзакции являются прерогативой реляционной модели?
С тех пор, как для неё разработали необходимые механизмы. По факту, нормального ACID больше нигде нет. Теория применима к чему угодно, а вот на практике получить сразу все четыре буквы получается мало у кого. И у RDBMS-то не всегда получается — вон оракл знаменит своим "serializable, который не serializable". А большинство NoSQL решений вообще никаких транзакций не поддерживают, кроме атомарного обновления значения для одного ключа — и то, через global lock, т.е. нету никакой concurrency.

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

IT>В результате для
IT>

IT>from t in db.Person
IT>select p
IT>

IT>будет сгенерирован код создания проекции
IT>[...]
IT>т.е. так же как если бы он писался в параноидальном варианте.

А как он будет сгенерирован? Есть какое-то встроенное средство типа "скомилируй это ET" чтобы убрать лишние лямбды?
Я изначально подумал что речь идёт об ручном IL emit. Но что-то связанное с emit нашёл только в pull request#53.

IT>>>На самом деле единственной альтернативой linq может стать compile-time кодогенерация.
EP>>Это возможно в D, Nemerle и C++ (менее удобно чем в первых двух, но всё же возможно).
IT>На счёт D не знаю. В D можно синтаксис расширять?

Именно расширять вряд ли, зато есть compile-time reflection, мощная перегрузка операторов, обработка строк во время компиляции и подобие макросов.
Например EDSL можно построить внутри строки с каким угодно синтаксисом. Хотя большой минус этого варианта в том, что поддержки IDE из коробки не будет.
Другой вариант — построить EDSL поверх перегрузки операторов.

IT>В Nemerle может и можно, но кривой API компилятора превратит это занятие в личную драму жизни.

Насколько я помню из презентации, там это должно быть как-то совсем просто — то есть задаём грамматические правила для нового синтаксиса и пишем соответствующий макро-обработчик. Хотя лично не пробовал.
Ещё помню там тоже была поддержка compile-time обработки строк (даже как-то интегрировалась в IDE).

IT>В C++, насколько мне известно, тоже пока синтаксис нельзя расширять. А без этого мы получим только решения, изувеченные цепочками вызовов методов, которые мы здесь уже видели. Кстати, не самое плохое решение, но порочна сама идея.

Да, синтаксис нельзя расширять, но за счёт перегрузки операторов, шаблонов и макросов — варьировать синтаксис EDSL можно в очень широких границах — для языка запросов этого более чем достаточно.

Плюс имеется возможность создать EDSL на строках. Например можно получить синтаксис LINQ'а:

auto products = QUERY(db,
R"(
        from p in Product
        where p.ProductID == 5
        select p.Name;
)");
for(const auto &p : products)
    cout << p.Name << endl;

Правда это как из пушки по воробьям.

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

_>>1. Т.к. это лёгкая ORM, то всё же можно в прикладном коде наткнуться на разную обработку запросов разными СУБД.
IT>Эта проблема по шкале важности из 10-ти баллов набирает где-то 0.5, а подавляющее число разработчиков о ней вообще ничего не знают.

Ну однако некоторые участники дискуссии в данной темке уделили этому вопросу большое внимание. )

_>>2. У linq не всё в порядке с эффективностью. Уже в смысле накладных расходов, а не особенностей sql. Что собственно и обсуждалось в данной теме.
IT>За всё нужно платить. У генерации SQL по Expression Tree есть три проблемы:
IT>1. Анализ и разбор ET.
IT>2. Генерация параметрозависмого SQL.
IT>3. Мапинг результата.

Лично мне для анализа вопроса эффективности (в контексте конкретного запроса и конкретной БД) надо знать две легко измеряемые величины:
1. Разницу (в микросекундах) между временем обработки запроса на linq и временем обработки запроса на базе голой sql строки.
2. Среднее время (в микросекундах) обработки подобного запроса в нашей БД.

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

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

_>>Конечно. Но в этой теме опять же показывали, что возможна статическая типизация sql запросов без накладных расходов.
IT>Мы это уже проходили много раз. Это не статическая типизация. Это — жертвоприношение. В жертву приносится буквально всё: простота кода, читабельность, гибкость, расширяемость. Остаётся только типизация, причём весьма условная. Как с условным сроком. Вроде как на свободе, но к участковому каждую неделю нужно ходить отмечаться. Делать на этом какие-то простые вещи, например, для демонстрации возможностей ещё как-то можно. Но заставить кого-то это использовать в реальных проектах можно только либо взяв в заложники семью, либо надо быть изобретателем этого самого гениального изобретения. Шаг вправо, шаг влево — расстрел, прыжок на месте — провокация. Использовать клиентские выражения в этом коде нельзя, т.е. проекции пролетают мимо. Способ добавить свои SQL функции отсутствует. Как мне, например, в запросе вернуть поле, предварительно сделав ему RTrim? В коде куча синтаксического шума. Да и при использоавнии цепочек вызовов методов нужно знать меру. Одно дело методы уровня SQL CLAUSE, а другое выпиливать с помощью них expressions and conditions. Модель данных — ужос! ужос! ужос! и мама, роди меня обратно. Это же рассадник копипейстных багов. Да и с самой типизацией как я уже сказал не всё в порядке. Затолкать в запрос таблицу, ему не принадлежащую, вовсе не проблема. Да и, как я понял, помножить строку на дату, тоже не вопрос.

Ммм, я не очень понял к чему конкретно относилась данная критика.

IT>На самом деле единственной альтернативой linq может стать compile-time кодогенерация. Желательно с возможностью синтаксического расширения языка. Команда в бозе почившего Немерле, как раз занималась подобным проектом — Нитрой. Но, к сожалению, как я понял, парни поднялись в облака и улетели в далёкие дали. Где они теперь витают никто не знает. Так что в текущем десятилетии мы вряд ли получим в этом плане что-то лучшее, чем linq.

Так о том собственно и была речь. К примеру упоминаемая тут sqlpp11 как раз занимается генерацией во время компиляции. Конечно программирование на шаблонах C++ не особо удобно и требует много лишнего для реализации вроде бы очевидных вещей, но это касается только написания самой библиотеки, а не её использования.

P.S. Спасибо за интересный экскурс в предыдущем сообщение (я его пропустил в своём ответе, но тем не менее с большим интересом ознакомился). Снова появилась польза от участия в данной дискуссии.

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

IT>На счёт D не знаю. В D можно синтаксис расширять?

На D можно сделать такое http://vibed.org/templates/diet (там нет никаких внешних препроцессоров, если что, собирается просто компилятором D), так что написать там вариант для SQL вообще не вопрос.

Кстати, кроме C++, D и Nemerle, есть ещё Rust с его макросами. И там я видел вот такие https://github.com/sfackler/rust-postgres-macros любопытные решения. Хотя это немного о другом речь (не про ORM), но тоже очень интересно в контексте статических проверок...

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

_>На D можно сделать такое http://vibed.org/templates/diet (там нет никаких внешних препроцессоров, если что, собирается просто компилятором D)

Там видимо код D во время компиляции читает эти внешние файлы?

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

_>И там я видел вот такие https://github.com/sfackler/rust-postgres-macros любопытные решения. Хотя это немного о другом речь (не про ORM), но тоже очень интересно в контексте статических проверок...

А тут, судя по всему, создаётся плагин к компилятору (а-ля Nemerle):

#[plugin_registrar]
#[doc(hidden)]
pub fn registrar(reg: &mut Registry) {
    reg.register_macro("sql", expand_sql);
    reg.register_macro("execute", expand_execute);
    unsafe { ffi::init_parser() }
}

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

S>Ну, не то что бы "очень много". Готов поспорить, что реляционных баз данных эксплуатируется на три-четыре десятичных порядка больше, чем систем обработки экспериментальных данных.

А причём тут количество инсталляций? ) Ты утверждал, что если работать с большими объёмами данных (не помещающимся в оперативную память) без реляционной модели, то получатся "дичайшие тормоза". А на практике видно, что когда нам требуется реальное быстродействие (в таком моделирование суперкомпьютеры задействуют если что) на таких объёмах, то про реляционную модель мы даже и не вспоминаем.

_>>С каких это пор транзакции являются прерогативой реляционной модели?
S>С тех пор, как для неё разработали необходимые механизмы. По факту, нормального ACID больше нигде нет. Теория применима к чему угодно, а вот на практике получить сразу все четыре буквы получается мало у кого. И у RDBMS-то не всегда получается — вон оракл знаменит своим "serializable, который не serializable". А большинство NoSQL решений вообще никаких транзакций не поддерживают, кроме атомарного обновления значения для одного ключа — и то, через global lock, т.е. нету никакой concurrency.

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

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

EP>Там видимо код D во время компиляции читает эти внешние файлы?

Ну да, такой вот http://vibed.org/api/vibe.http.server/render функцией.

Здравствуйте, alex_public, Вы писали:
_>А причём тут количество инсталляций? ) Ты утверждал, что если работать с большими объёмами данных (не помещающимся в оперативную память) без реляционной модели, то получатся "дичайшие тормоза".
Вы, наверное, неверно поняли, что значит "работать". Под "работой" понимается OLTP — внесение изменений в данные, при этом источников изменений много, и есть требования к согласованности данных. Вы приводите примеры read-only операций, для которых разработаны целые классы альтернативных методик, даже если исходные данные представлены в реляционном виде.

А для классики вроде резервирования авиабилетов, ERP, те же форумы и прочего ничего лучше RDBMS пока не придумали.


_>Ну т.е. речь идёт не о какой-то технической привязки надёжности именно к реляционной модели, а просто о том, что исторически сложилась ситуация, в которой данные техники были изначально реализованы именно в реляционных БД. Т.е. ничего не мешает разработать СУБД с аналогичными параметрами по надёжности, но без всякого sql.
Во-первых, речь не только о надёжности, а обо всём ACID. Во-вторых, теоретически, конечно же, ничего не мешает разработать СУБД с поддержкой ACID на основе альтернативной модели.
Однако на практике у нас нет никакой теории про то, каким образом сериализовывать операции в такой СУБД.

_>Собственно это уже давно происходит. Более того, какая-нибудь там Cassandra при правильной установке будет намного устойчивее к сбоям, чем обычные sql базы.

Cassandra does not use RDBMS ACID transactions with rollback or locking mechanisms

Увы. В кассандре расслабленная трактовка consistency и нет никакой изоляции за пределы одной строки. При таких упрощениях durability получить совсем нетрудно.

S>Во-первых, речь не только о надёжности, а обо всём ACID. Во-вторых, теоретически, конечно же, ничего не мешает разработать СУБД с поддержкой ACID на основе альтернативной модели.

Ну, есть например Erlang'овская Mnesia. Она, по сути, — key-value storage, но с ACID. (старое быстрое введение)

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

S>Вы, наверное, неверно поняли, что значит "работать". Под "работой" понимается OLTP — внесение изменений в данные, при этом источников изменений много, и есть требования к согласованности данных. Вы приводите примеры read-only операций, для которых разработаны целые классы альтернативных методик, даже если исходные данные представлены в реляционном виде.

1. А кто это сказал, что мы тут под работой понимаем OLTP? )
2. Я же вроде как ясно описал процесс моделирования — там совсем не read-only операции. Единственно что они производятся ровно одним "пользователем", но при этом параллельно на многих узлах.

S>А для классики вроде резервирования авиабилетов, ERP, те же форумы и прочего ничего лучше RDBMS пока не придумали.

Не факт. Для форумов возможно есть смысл посмотреть на СУБД оптимизированные под графы. А для ERP очень удобной (в первую очередь благодаря работе с json документами) может быть MongoDB, хотя PostreSQL вроде как тоже уже научился этому. Про авиабилеты ничего не скажу, т.к. не знаю специфики.

Собственно преобладание именно реляционных СУБД (и кстати такой ммм особенной, как mysql) обосновано в основном историческими причинами, а не фундаментальными основаниями.

S>Во-первых, речь не только о надёжности, а обо всём ACID. Во-вторых, теоретически, конечно же, ничего не мешает разработать СУБД с поддержкой ACID на основе альтернативной модели.

Вот вот.

S>Однако на практике у нас нет никакой теории про то, каким образом сериализовывать операции в такой СУБД.

Какой ещё теории? ) Скажем для доступа к массиву данных тебе нужна специальная теория? )

_>>Собственно это уже давно происходит. Более того, какая-нибудь там Cassandra при правильной установке будет намного устойчивее к сбоям, чем обычные sql базы.
S>
S>

S>Cassandra does not use RDBMS ACID transactions with rollback or locking mechanisms

S>Увы. В кассандре расслабленная трактовка consistency и нет никакой изоляции за пределы одной строки. При таких упрощениях durability получить совсем нетрудно.

А я и не говорил, что это сложно. Но главное же достигнутый результат.

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

EP>А как он будет сгенерирован? Есть какое-то встроенное средство типа "скомилируй это ET" чтобы убрать лишние лямбды?

Есть встроенное в linq2db:

[Test]
public void ExpressionConvertTest()
{
    Expression<Func<IDataReader,int,int>> readerToInt = (rd,idx) => rd.GetInt32(idx);

    var p = Expression.Parameter(typeof(IDataReader), "rd");

    var idReadExpression = readerToInt.Body.Transform(e =>
    {
        if (e == readerToInt.Parameters[0]) return p;
        if (e == readerToInt.Parameters[1]) return Expression.Constant(0);
        return e;
    });

    var l = Expression.Lambda<Func<IDataReader,ConvertTest>>(
        Expression.MemberInit(
            Expression.New(typeof(ConvertTest)),
            Expression.Bind(MemberHelper.MemberOf<ConvertTest>(t => t.ID), idReadExpression)),
        p);

    var convertReader = l.Compile();

    // Don't call it.
    //var obj = convertReader(null);
}

В результате сгенерированная лямбда будет выглядеть так:

rd => new ConvertTest() { ID = rd.GetInt32(0) }

EP>Я изначально подумал что речь идёт об ручном IL emit. Но что-то связанное с emit нашёл только в pull request#53.

emit использовался в bltoolkit. В linq2db он изничтожен на корню.