Здравствуйте, Sinclair, Вы писали:
V>>Ну т.е. что ЯОН имеют смысл при работе с бд вы согласны? S>С реляционными БД — нет. Пока что я не вижу никаких аргументов в пользу этого утверждения.
Ну так и речь исходно не про реляционные бд была, а про дсл. Sql лишь как "классический пример" упоминался и не являлся никаким доказательством что ЯОН не нужны при работе с бд, замечу, не указано какой.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, AndrewVK, Вы писали:
K>>1. Я не явлюясь специалистом в данной предметной области. K>>2.1. Я не являюсь специалистом в создании DSL.
AVK>А таких людей вообще — просто считанное количество. That's the problem.
Это да, проблема. Но давай вспомним появление C++. ООП тогда толком не умел применять почти никто. И сейчас, можно сказать, мало кто умеет (я, например, с трудом). Однако это не помешало большинству его применять и получать от этого немалый профит. Ибо остальные средства декомпозиции задач тоже не блещут. В том смысле, что на отдельных задачах могут показать более простой и поддерживаемый код, а могут и не показать.
Язык, который даст возможность быстренько написать DSL если вдруг в нем возникла нужда в любом случае будет лучше такого же языка, который этой возможности не имеет. Обилие появляющихся примеров fluent DSL (которые тоже мало кто умел писать раньше, да и мало кто умеет писать сейчас) говорит о том, что какой-то DSL в системе все равно появится, вопрос только в его качестве и сложности разработки и поддержки. Я лично написал несколько fluent DSL, но это реально похоже на хождение по граблям на ходулях. И вносить правки в такой DSL, с прошествием времени, геморрой еще тот.
Здравствуйте, vdimas, Вы писали:
AVK>>У меня язык строго типизирован и типы параметров обязательны к декларированию. Я ж говорю — это проблема SQL, а не предметной области.
V>Ага, тогда я не правильно понял "компиляцию запроса", я думал, что это есть процедура получения готового SQL.
Готовый sql у нас не может быть заранее получен хотя бы потому что на этапе компиляции неизвестен целевой сервер СУБД. Но WH говорил прежде всего про статический контроль типов, а вот его то как раз в большинстве случаев обеспечить можно.
V>Интересно, а как запрос "ембедится" в исходник? Свой препроцессор C#? Или рядом в другом файле лежит?
У нас — никак. У нас запросы не в C# исходниках в основном, а внутри другого DSL. А те запросы, которые внутри шарпа, те сейчас компилируются только в рантайме.
V>Хотя реальную кастомизацию все-равно не сами клиенты делают, а всякие "партнеры"
Ну вот поэтому в Торнадо кастомизация партнерам доступна в любом объеме, в отличие от 8-ки, кде куча логики была захардкожена в клиенте.
V>, но шаговая доступность для этого и вообще сам сценарий: пришел представитель "партнера" к клиенту и прямо на месте что-то подкрутил — такой сценарий очень даже юзер-френдли.
У нас клиенты обычно покрупнее, такие фокусы не очень усместны. Да и сложность и технологичность продуктов сейчас сильно больше, чем во времена 1С 6, так просто не влезешь.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Вопрос в том, распарсил ли он его согласно стандарту.
Распарсил согласно стандарту.
Так что там с ??
Хочу проверить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
ANS>> INNER JOIN Inventory i
ANS>> ...
ANS>> WHERE
ANS>>
AVK>Этот кусок на C# короче. И там вполне можно через query comprehension переписать.
Во-первых, я написал, что "INNER JOIN" это артефакт и его можно заменить более понятной и простой конструкцией, а там где всякие "больше"/"меньше"/"равно" это у тебя будет и в C#.
Во-вторых, у тебя же не конкурс "впихни как можно больше функционала в меньшее кол-во букв". В примере типичный "лапша-код", из-за того, что если не сделать всё за один проход по циклам, то оно будет тормозить так, что можно будет сказать, что оно не работает. Я так понимаю, что с этим ты и не споришь?
Другое дело, что в отличии от топик стартера, мне не кажется, что DSL в виде языка запросов, в таком приложении это "на раз-два". Но то, что это тяжело — не значит, что навигациооное API лучше всегда.
А какое там API для сторонних приложений?
ANS>>DELETE FROM ... AVK>Ага, а самого то интересного и нет. Как циклы в декларативную форму переделать — догадаться несложно. А вот как последующий алгоритм — вопрос.
Какой такой "последующий алгоритм"? Мне непонятна твоя позиция. Ты согласен, что это "лапша-код"; ты утверждаешь, что это нормальный код, для такого приложения (т.е. бывает и хуже) и лучше нельзя. На выходе получается, что лапша-код это нормально и сделать ничего нельзя. Просто фатализм и безысходность.
Здравствуйте, Sinclair, Вы писали:
ANS>>А, туплю. Тебя смущает, что нет мета-протокола? S>Я не понимаю, что такое мета-протокол.
Аналог meta object protocol (сори, мне слово object тут показалось неуместным). Тебе же нужно запросами манипулировать — там условия дорисовать, там переписать. Не в строках же всё хранить. Плюс система a-la RULE в PostgreSQL для перехвата и переписывания запросов во время выполнения.
ANS>>мне не совсем понятно, как это использовать. Я беру из пула конекшен, фигашу туда сорок кусков запросов и пятьдесят функций для комбинации этих кусков, потом один запрос который из дёргает эти функции и так при каждом запросе? S>Нет, зачем? Вы же не создаёте при каждом запросе все view и stored procedures. S>Вы берёте, фигачите один раз при развёртывании базы в неё нужные вам функции, которые могут вызывать другие функции, а наружу выставляете только простой и понятный набор таблиц/view/функций/хранимых процедур.
Меня терзают смутные сомнения. Вроде как, пол приложения в БД, а половина в сервере приложения это уже пройденный этап.
AVK>Не вижу никакого взрыва. Этот код просто лапочка по сравнению с тем, что местами попадается, скажем, в решарпере Типа нескольких вложенных циклов по графу, на который наложены и неявно учитываются контролируемые только в рантайме ограничения, внутри которых несколько goto, причем в разные точки. Вот это да, взрыв моска. А тут линейная логика. AVK>Ну давай посмотрим: AVK>
AVK>Получаем объект инвентаризации из истории операции инвентаризации
1. Почему у нас явно указан тип? Это важно? (здесь и далее все комментарии — с точки зрения бизнес-логики, а не с точки зрения C# AVK>
AVK>if (invCardObj != null)
AVK>
AVK>Если объект есть
2. У нас он часто отсутствует?
3. Если он отсутствует, то выполняется какая-то сложная логика, или просто "а, ну тогда пропустим тридцать строк"?
4. Я веду к тому, что может имеет смысл свернуть эти явные ветки кода во что-то типа "для всех карточек (которых либо 0 либо 1) выполни XXX", либо перейти от null к исключениям, которые можно удобно проигнорировать где-то внизу кода (типа OnMissingInvCard = Skip). AVK>
AVK>var card = ((IPersistedObject)invCardObj).Master as IInventoryCardBase;
AVK>
AVK>Берем карточку, по которой он инвентаризован
5. Вот эти два даункаста в разных стилях — они точно нужны? Почему нельзя просто invCardObj.Master? AVK>
AVK>if (card is IAccrualAccountingInventoryCard)
AVK> Manager.DeleteObject((IPersistedObject)invCardObj);
AVK>
6. Опять даункаст. В целом, выглядит, как размазанная запись правила, которое в оригинале звучало как "убить все карточки, которые входят в бла-бла-бла". DSL, который бы позволял написать "убить все карточки, которые входят в бла-бла-бла", не отвлекаясь на порядок обхода итераторов, даункасты, и скобочки, был бы крайне уместен. AVK>
AVK>else if (!cardsDeleteSet.Contains(card))
AVK> invCardObj.Inventory = inv;
AVK>
AVK>Иначе проверяем наличие в хешике, который мы чуть раньше заполняли, и если совпало, то в детейле инвентарной карточки заменяем ссылку на справочник инвентаризуемых объектов.
7. Этот хешик — он какую бизнес-сущность отражает? AVK>
AVK>inv.ChangesHistory = null;
AVK>
AVK>Обнуляем историю инвентаризации
Хм. Не вполне очевидно. AVK>
AVK>Удаляем инвентаризационную операцию AVK>Это, собственно, типичная бизнес-логика. Далеко не самая запутанная, уж поверь. И ее то как раз нужно сохранить, это входящее требование. А вот как ее более красиво записать — вопрос.
Отож, про то и обсуждение.
AVK>Где? В DeleteObject даункаст лишний. Даункаст при обращении к Master — технологическая особенность, связанная с распределенностью системы и едиными интерфесами и в клиентском и в серверном коде. Согласен, проблема, но ее не так то легко вылечить. А as/is — это просто проверка дискриминанта, который выражен в виде реализации тех или иных интерфейсов.
С точки зрения C# — понятно. С точки зрения бизнес-логики — нет.
AVK>Переменная модифицируется ровно один раз, при объявлении. Потом меняется содержимое самого хеша, а не переменной. И использование вполне стандартное — запоминаем в цикле обхода, потом запомненное используем для проверки. Такого кода, скажем, внутри System.Enumerable до попы, хотя, вроде как, весьма приличные спецы писали.
Тут дело не в спецах, а в решаемой задаче.
Не то, чтобы у меня было готовое решение для вашей бизнес-логики, просто невооружонным мозгом понять код на шарпе всё же тяжело. Относительнно много мусора и сущностей, которые как бы вне модели собственно бизнеса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Аналог meta object protocol (сори, мне слово object тут показалось неуместным).
Эту аббревиатуру я тоже не знаю. ANS> Тебе же нужно запросами манипулировать — там условия дорисовать, там переписать. Не в строках же всё хранить. Плюс система a-la RULE в PostgreSQL для перехвата и переписывания запросов во время выполнения.
Мне не надо манипулировать запросами. Мне надо иметь средства борьбы со сложностью.
ANS>Меня терзают смутные сомнения. Вроде как, пол приложения в БД, а половина в сервере приложения это уже пройденный этап.
Границы обязанностей двигаются всё время. Вот от толстых клиентов уже почти везде уехали к тонким; так и на серверной стороне то же самое. Зачем подымать мегабайты в память веб-сервера, чтобы "быстро-быстро" их обработать? Пусть RDBMS сама этим занимается. Вы никогда не порвёте по производительности update inventory set amount = amount — @quantity where goodId = @goodID and amount > @quantity никакими ORM. И никаким джаваскриптом вы его тоже не порвёте — ну разве что ценой отказа от персистентности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
AVK>>Получаем объект инвентаризации из истории операции инвентаризации S>1. Почему у нас явно указан тип? Это важно?
Ты имеешь в виду почему не var? Нет, не важно.
AVK>>
AVK>>if (invCardObj != null)
AVK>>
AVK>>Если объект есть S>2. У нас он часто отсутствует?
ХЗ
S>3. Если он отсутствует, то выполняется какая-то сложная логика, или просто "а, ну тогда пропустим тридцать строк"?
Это из исходника видно.
S>4. Я веду к тому, что может имеет смысл свернуть эти явные ветки кода во что-то типа "для всех карточек (которых либо 0 либо 1) выполни XXX", либо перейти от null к исключениям, которые можно удобно проигнорировать где-то внизу кода (типа OnMissingInvCard = Skip).
Возможно
AVK>>Берем карточку, по которой он инвентаризован S>5. Вот эти два даункаста в разных стилях — они точно нужны?
Увы, да.
S> Почему нельзя просто invCardObj.Master?
Потому что сейчас базовый интерфейс, он для серверного и клиентского кода разный, а вот бизнес-интерфейсы универсальны. Технологическая проблема, которую надо устранять. Скорее всего введением еще одного интерфейса, общего для сервера и для клиента. В любом случае DSL тут — из пушки по воробьям.
AVK>>
AVK>>if (card is IAccrualAccountingInventoryCard)
AVK>> Manager.DeleteObject((IPersistedObject)invCardObj);
AVK>>
S>6. Опять даункаст.
Я уже писал — ненужный.
S>DSL, который бы позволял написать "убить все карточки, которые входят в бла-бла-бла", не отвлекаясь на порядок обхода итераторов, даункасты, и скобочки, был бы крайне уместен.
По идее, такое можно и в рамках библиотеки реализовать.
AVK>>Иначе проверяем наличие в хешике, который мы чуть раньше заполняли, и если совпало, то в детейле инвентарной карточки заменяем ссылку на справочник инвентаризуемых объектов. S>7. Этот хешик — он какую бизнес-сущность отражает?
Никакую. Промежуточное накопление результатов, чтобы два раза коллекцию не обходить.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Во-первых, я написал, что "INNER JOIN" это артефакт и его можно заменить более понятной и простой конструкцией
Я так понимаю, что весь топик ты не читал? Потому что я, как бы, в курсе. Но на шарпе все равно будет как минимум не хуже.
ANS>Во-вторых, у тебя же не конкурс "впихни как можно больше функционала в меньшее кол-во букв".
Нет. Меня больше читабельность интересует. Но и с ней никаких преимуществ по сравнению с шарпом нет.
ANS> В примере типичный "лапша-код", из-за того, что если не сделать всё за один проход по циклам, то оно будет тормозить так, что можно будет сказать, что оно не работает.
Нет, тормозить оно особо не будет. Все коллекции на момент прохода уже в памяти и на фоне активной работы с БД накладные расходы на лишний проход в микроскоп не увидишь.
ANS> Я так понимаю, что с этим ты и не споришь?
Я не спорю, я пытаюсь выслушать мнения (отличные от "пример не годится").
ANS>Другое дело, что в отличии от топик стартера, мне не кажется, что DSL в виде языка запросов, в таком приложении это "на раз-два".
DSL в виде языка запросов там уже есть. Но вряд ли он в таком коде что то упростит.
ANS>А какое там API для сторонних приложений?
Каких таких сторонних?
ANS>Какой такой "последующий алгоритм"? Мне непонятна твоя позиция. Ты согласен, что это "лапша-код"; ты утверждаешь, что это нормальный код, для такого приложения (т.е. бывает и хуже) и лучше нельзя. На выходе получается, что лапша-код это нормально и сделать ничего нельзя. Просто фатализм и безысходность.
Какое то у тебя странное восприятие. Код тут приведен не в качестве примера плохого или хорошего, а в качестве примера исходной логики, которую нужно круто записать на DSL. И код специально взят обрабатывающий, а не просто выборки делающий.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Я точно не помню, но там проблемы не с самим оператором. а с его комбинацией с оператором ??. WH>>Какие именно?
AVK>Не помню, а искать лень. В стандарте шарпа описано.
Нет там никаких неоднозначностей и быть не может. Это ведь два разных токена. Соответственно в стандарте тоже ничего по их поводу нет.
Для слабых парсеров может возникгуть проблема в интерпретации оператора "?" (в унарном виде он является частью описания типа), для TDOP — это ни разу не проблема.
Плюс у нас еще есть синтаксические предикаты. То что не решается синтаксисом, решается предикатами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Мне не надо манипулировать запросами. Мне надо иметь средства борьбы со сложностью.
Фраза не несущая конкретики. Может моё решение и плохое, но твоя фраза это пожелание мира во всём мире.
ANS>>Меня терзают смутные сомнения. Вроде как, пол приложения в БД, а половина в сервере приложения это уже пройденный этап. S>Границы обязанностей двигаются всё время. Вот от толстых клиентов уже почти везде уехали к тонким; так и на серверной стороне то же самое. Зачем подымать мегабайты в память веб-сервера, чтобы "быстро-быстро" их обработать? Пусть RDBMS сама этим занимается. Вы никогда не порвёте по производительности update inventory set amount = amount — @quantity where goodId = @goodID and amount > @quantity никакими ORM. И никаким джаваскриптом вы его тоже не порвёте — ну разве что ценой отказа от персистентности.
Не совсем понял какая связь с моим утверждением. Мне кажется естественным и понятным ситуация, когда запрос на апдейт уходит с сервера приложения. Ты же хочешь, чтобы запрос уходил на сервер, там он (пре)процесился и порождался конечный запрос. Мне ситуация когда пользовательская логика размазана между СУБД и приложением кажется ненормальной. Ты же, с одной стороны, говоришь, что происходит четкое разделение обязанностей (я с этим согласен), с другой предлагаешь запихивать в сервер какую-то логику.
. Так вот, просто иногда достаточно что-бы операция просто работала за приемлемое время, а разница в производительности компенсируется удобством. Железо сейчас для текущих операций позволяет.
ЗЫ. Я в вас запутался. AndrewVK привёл пример, когда всё-всё поднимается в память и быстро быстро обрабатывается лапша-кодом, и говорит, что лучше нельзя, а тебе ставит плюсик, когда ты говоришь, что это плохо плохо.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я так понимаю, что весь топик ты не читал? Потому что я, как бы, в курсе. Но на шарпе все равно будет как минимум не хуже.
Тогда тебе будет польза от обсуждения с Sinclair его идей по декомпозиции запросов. Должно получится лучше чем на C#.
AVK>Нет. Меня больше читабельность интересует. Но и с ней никаких преимуществ по сравнению с шарпом нет.
Ок. Но пока получается, что читабельноcть C# кода может и есть, а вот с бизнес-сутью — проблемы. Пример:
var card = ((IPersistedObject)invCardObj).Master as IInventoryCardBase;
if (card is IAccrualAccountingInventoryCard)
Manager.DeleteObject((IPersistedObject)invCardObj);
else if (!cardsDeleteSet.Contains(card))
invCardObj.Inventory = inv;
ANS>> В примере типичный "лапша-код", из-за того, что если не сделать всё за один проход по циклам, то оно будет тормозить так, что можно будет сказать, что оно не работает. AVK>Нет, тормозить оно особо не будет. AVK>Все коллекции на момент прохода уже в памяти
Хм. Вот этот код мне как-бы намекает, что не всё в памяти:
Но тебе виднее, конечно. Если он не лезет в БД, то — ок.
AVK>и на фоне активной работы с БД накладные
Это если всё в ОЗУ влезет.
AVK>расходы на лишний проход в микроскоп не увидишь.
Тогда мне вообще не понятно на какой ляд вводить промежуточные переменные, размазывать и перемешивать между собой реализацию разных бизнес-правил.
AVK>Я не спорю, я пытаюсь выслушать мнения (отличные от "пример не годится").
Пример, как раз годится. Мне кажется, что "внешний DSL" можно легче породить когда есть "внутренний DSL". Но я не уверен, что легко соглашусь с тем, что API из примере это "внутренний DSL".
И, вообще, позволю себе вернутся к мысли, которую пытался выразить завуалировано. Признание проблемы это первый шаг к исцелению. Ты утверждаешь, что лучше нельзя. Как тогда можно сделать лучше, если даже нет попытки найти решение?
ANS>>А какое там API для сторонних приложений? AVK>Каких таких сторонних?
которые в другом процессе/по сети работают и хотят в этой системе операции творить.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>И, вообще, позволю себе вернутся к мысли, которую пытался выразить завуалировано. Признание проблемы это первый шаг к исцелению. Ты утверждаешь, что лучше нельзя.
Я нигде подобного не утверждал.
ANS>>>А какое там API для сторонних приложений? AVK>>Каких таких сторонних?
ANS>которые в другом процессе/по сети работают и хотят в этой системе операции творить.
Свой протокол поверх HTTP.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Фраза не несущая конкретики. Может моё решение и плохое, но твоя фраза это пожелание мира во всём мире.
Я не вижу у вас никакого решения. Я вижу какие-то непонятные мне слова про метаобъектные протоколы.
Моя "идея" решения — в том, чтобы поддерживать в языке средства декомпозиции.
ANS>Не совсем понял какая связь с моим утверждением. Мне кажется естественным и понятным ситуация, когда запрос на апдейт уходит с сервера приложения. Ты же хочешь, чтобы запрос уходил на сервер, там он (пре)процесился и порождался конечный запрос.
Мне кажется, что вы неверно понимаете суть реальной ситуации. Любой запрос сейчас уходит на сервер, препроцессится, и порождается конечный запрос. Я, возможно, сейчас порву какие-то шаблоны, но внутри сервера, помимо наблюдаемых с клиента таблиц, в вышеупомянутом запросе участвуют индексы, блокировки, логи для восстановления и репликации и прочий малоинтересный стафф. Мне не очень важно, сколько там происходит стадий в этом "препроцессинге" — важен конечный результат.
К примеру, когда я делаю select * from something where date > ...., я могу обращаться к view, которое построено поверх других view, и так далее. Это ничему не противоречит и никого не пугает, т.к. стандартизовано.
ANS>Мне ситуация когда пользовательская логика размазана между СУБД и приложением кажется ненормальной. Ты же, с одной стороны, говоришь, что происходит четкое разделение обязанностей (я с этим согласен), с другой предлагаешь запихивать в сервер какую-то логику.
Конечно предлагаю. Потому что логику нужно держать близко к тому месту, где живут данные, с которыми она работает. Ибо таскать данные туда-сюда — дорого. Идея "давайте использовать RDBMS чисто как хранилище данных" — это misconception. Забивание гвоздей при помощи электрического шуруповёрта.
Причём идея эта происходит в основном от отчаяния. Потому что нет способа "нормально" запихать эту логику в сервер.
Ну и понятно, что догика логике рознь. Логика "если вот этот параметр не выбран, то вон те нужно скрыть" прекрасно обработается на клиенте. Логика "найди мне список самых подходящих мест на этот рейс" лучше пусть работает внутри сервера.
ANS>И, я так понял, что ты сразу сомневаешься, в моём предположении, что JS это наше будущее
. Так вот, просто иногда достаточно что-бы операция просто работала за приемлемое время, а разница в производительности компенсируется удобством. Железо сейчас для текущих операций позволяет.
Да я ни в чём не сомневаюсь. Вот, у нас сейчас есть один маленький кусочек приложения, который хранит данные в RDBMS в виде key:json. Пользуясь безлимитностью varchar полей в SQLite. Ну так он и рассчитан на частые неконтролируемые обновления приложения, и логики в нём самом собственно минимум — это, фактически, кэш-прослойка между нами и 3rd-party cервисом.
ANS>ЗЫ. Я в вас запутался. AndrewVK привёл пример, когда всё-всё поднимается в память и быстро быстро обрабатывается лапша-кодом, и говорит, что лучше нельзя, а тебе ставит плюсик, когда ты говоришь, что это плохо плохо.
Вот такие мы разносторонние
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Мне кажется, что вы неверно понимаете суть реальной ситуации. Любой запрос сейчас уходит на сервер, препроцессится, и порождается конечный запрос. Я, возможно, сейчас порву какие-то шаблоны, но внутри сервера, помимо наблюдаемых с клиента таблиц, в вышеупомянутом запросе участвуют индексы, блокировки, логи для восстановления и репликации и прочий малоинтересный стафф. Мне не очень важно, сколько там происходит стадий в этом "препроцессинге" — важен конечный результат. S>К примеру, когда я делаю select * from something where date > ...., я могу обращаться к view, которое построено поверх других view, и так далее. Это ничему не противоречит и никого не пугает, т.к. стандартизовано.
Ну, типа, вау. Но ты действительно не замечаешь разницы между внутренними механизмами сервера и тонами логики которые ты должен залить в сервер и там поддерживать?
ANS>>Мне ситуация когда пользовательская логика размазана между СУБД и приложением кажется ненормальной. Ты же, с одной стороны, говоришь, что происходит четкое разделение обязанностей (я с этим согласен), с другой предлагаешь запихивать в сервер какую-то логику. S>Конечно предлагаю. Потому что логику нужно держать близко к тому месту, где живут данные, с которыми она работает. Ибо таскать данные туда-сюда — дорого. Идея "давайте использовать RDBMS чисто как хранилище данных" — это misconception. Забивание гвоздей при помощи электрического шуруповёрта.
Это попытки нагрузить сервер чем-то кроме выполнения запросов это misconception. От нищеты и попытки на спичках экономить. Но сейчас потихоньку складывается такая ситуация, что там где есть смысл заливать логику в RDBM, там нет смысла пользоваться RDBM, а проще взять какой-то noSql и книжку Крокфорда (единственное, что сейчас мешает это незрелость). А вот там где преимущества RDBM встают в полный рост, там нет смысла логику заливать.
Типа нескольких вложенных циклов по графу, на который наложены и неявно учитываются контролируемые только в рантайме ограничения, внутри которых несколько goto, причем в разные точки. Вот это да, взрыв моска. А тут линейная логика.
