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

C>Нет, тут сложнее. SQL — изначально основывался на операциях с множествами, у которых главная фича в том, что они могут быть хорошо оптимизированы. И они по своему дизайну не Turing-complete. О том как бы лучше расширить SQL написан не один десяток диссертаций

После появления CTE они стали Тюринг-полными. Так что ты не прав.

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

C>>Нет, тут сложнее. SQL — изначально основывался на операциях с множествами, у которых главная фича в том, что они могут быть хорошо оптимизированы.
WH>И что мешает функциональному языку проводить операции над множествами?
Необходимость ограничиваться только ими, чтобы оптимизатор мог эффективно работать.

C>>И они по своему дизайну не Turing-complete.
WH>А всякие там TSQL очень даже Turing-complete. При этом еще и императивные в доску.
Ну это уже извращение, не спорю. С CTE и сам SQL тоже полон, но CTE можно игнорировать, как ещё одно кривое расширение.

C>>Тупые методы "взять и всю базу в память загрузить, а потом map-reduce'у скормить" неинтересны.
WH>А императивненько ползать курсором по таблице значит интересно?
Нет. Я про такие "расширения" и не говорю.

WH>А не иметь нормальных средств декомпозиции запросов тоже интересно?
Нет. Но если пытаться что-то придумать на мотив SQL, то сильно лучше тоже что-то не получается. Понятно, что кое-что можно улучшить — в явном виде представлять отношения, к примеру. Но сама суть SQL по дизайну сделана ограниченной.

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

C>>Нет, тут сложнее. SQL — изначально основывался на операциях с множествами, у которых главная фича в том, что они могут быть хорошо оптимизированы. И они по своему дизайну не Turing-complete. О том как бы лучше расширить SQL написан не один десяток диссертаций
VD>После появления CTE они стали Тюринг-полными. Так что ты не прав.
Я их игнорирую

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

C>>>И они по своему дизайну не Turing-complete.
WH>>А всякие там TSQL очень даже Turing-complete. При этом еще и императивные в доску.
C>Ну это уже извращение, не спорю. С CTE и сам SQL тоже полон, но CTE можно игнорировать, как ещё одно кривое расширение.

CTE отличная вещь — не надо его игнорировать. И на каком основании эта часть стандарта SQL стала вдруг кривым расширением?

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

VD>Вы что гордитесь, что не знаете и не используете SQL?

Меня радует возможность не менять ДАО при изменении свойств бизнес-объектов.

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

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

OA>>Хотелось бы более детальной информации об рисках, связанных с использованием NHibernate в таком проекте как rsdn.

VD>У нас просто не хватит денег на железо. На РСДН используется только прямая работа с SQL и BL-Toolkit.
VD>NHibernate-у к ним и на пушечный выстрел не подойти.
Господа, теперь я понял почему вы так хвалите свое боло... ой BL-Toolkit. Без обид, но как минимум не скромно хаять темы пришедшие из ява. Генерики тоже из ява пришли
Или может Мартин Фаулер по вашему необразован?
гыг, что еще сказать

Здравствуйте, Аноним, Вы писали:

А>Господа, теперь я понял почему вы так хвалите свое боло... ой BL-Toolkit. Без обид, но как минимум не скромно хаять темы пришедшие из ява. Генерики тоже из ява пришли
А>Или может Мартин Фаулер по вашему необразован?
http://en.wikipedia.org/wiki/Generic_programming

А>гыг, что еще сказать
А ничего и не надо больше

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

S>Здравствуйте, Аноним, Вы писали:

А>>Господа, теперь я понял почему вы так хвалите свое боло... ой BL-Toolkit. Без обид, но как минимум не скромно хаять темы пришедшие из ява. Генерики тоже из ява пришли
А>>Или может Мартин Фаулер по вашему необразован?
S>http://en.wikipedia.org/wiki/Generic_programming

А>>гыг, что еще сказать
S>А ничего и не надо больше
, виноват, на эмоциях выдал непроверенную инфу.
Обидно слышать что мои проекты щас живут и где то там у них есть угроза, потому что на гибернейте.
Но по сути — зачем тогда BL-Toolkit если я и так могу все дао на SQL переписать?
Есть два вида водителей: одни просто ездят и для решения повседневных задач им коробка-автомат приемлемо, другим только механика — чтобы на светофорах не обижали.

Здравствуйте, Аноним, Вы писали:

А>>>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

VD>>Вы что гордитесь, что не знаете и не используете SQL?

А>Меня радует возможность не менять ДАО при изменении свойств бизнес-объектов.

Я разве об этом спрашивал?

Здравствуйте, Аноним, Вы писали:


А>…Без обид, но как минимум не скромно хаять темы пришедшие из ява. Генерики тоже из ява пришли

Вслед за сборщиком мусора что ли пришли?

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

VD>Здравствуйте, Аноним, Вы писали:

А>>>>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

VD>>>Вы что гордитесь, что не знаете и не используете SQL?

А>>Меня радует возможность не менять ДАО при изменении свойств бизнес-объектов.

VD>Я разве об этом спрашивал?
Отвечаю на Ваш вопрос:
я использую SQL там где NHibernate не уместен.
несколько лет назад я сопровождал ОДБ под ораклом — там ОРМ не уместна, только SQL — и его я там накушался до отвращения — горжусь этим.

Здравствуйте, Аноним, Вы писали:

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

Пока у них нет по 400 параллельных запросов, как это постоянно происходит на РСДН, им ничего не угражает.

А вообще, да, согласен. Слышать то, что ты используешь не эффективное и неразумно спроектированное решение всегда неприятно. Раньше я тоже наверно обиделся бы, если услышал бы такое. А сейчас я бы предпочел для начала разобраться в сути вопроса. Оказывается, что не все представления которые мы имеем верны.

А>Но по сути — зачем тогда BL-Toolkit если я и так могу все дао на SQL переписать?

Он тебе не нужен если ты конечно не хочешь писать более масштабируемые проекты меньшими силами. Ну, и соответственно, нужен если хочешь.

А>Есть два вида водителей: одни просто ездят и для решения повседневных задач им коробка-автомат приемлемо, другим только механика — чтобы на светофорах не обижали.

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

В прочем все аналогии пригодны только для образного объяснения.

Здравствуйте, Аноним, Вы писали:

А>Господа, теперь я понял почему вы так хвалите свое боло... ой BL-Toolkit. Без обид, но как минимум не скромно хаять темы пришедшие из ява.

Я к BL-Toolkit не имею никакого отношения.

А>Генерики тоже из ява пришли

О как? А ничего что дженерики в CLI (в специальном открытом проекте созданном автором F#) появились на пару лет раньше чем аналогичное предложение для явы?
Дженерики пришли из мира функционального программирования где они поддерживались начиная с 70-х годов. Кроме того, конечно, большое влияние на них оказали шаблоны С++.
Дженерики же явы являются весьма поверхностным решением. Короче, курите источники.
http://en.wikipedia.org/wiki/Generic_programming#Generics_in_Java

А>Или может Мартин Фаулер по вашему необразован?
А>гыг, что еще сказать

А что Фаулер писал, что BL-Toolkit — это плохо?
Гы-гы. Что еще сказать на такую логику?

Как мне взять вот это
http://rsdn.ru/projects/rfd/rfd_dev.rar
вижу страницу с "Server Error in Application "RSDN.RU""

Здравствуйте, Аноним, Вы писали:

А>Как мне взять вот это
А>http://rsdn.ru/projects/rfd/rfd_dev.rar
А>вижу страницу с "Server Error in Application "RSDN.RU""

http://www.bltoolkit.net/download.htm

Здравствуйте, Аноним, Вы писали:

А>Отвечаю на Ваш вопрос:
А>я использую SQL там где NHibernate не уместен.
А>несколько лет назад я сопровождал ОДБ под ораклом — там ОРМ не уместна, только SQL — и его я там накушался до отвращения — горжусь этим.

Получается, что ты используешь и NHibernate и SQL. А можно было бы использовать один LINQ. При этом и скорость была бы лучше, и код более высокоуровневым был бы.

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



VD>Получается, что ты используешь и NHibernate и SQL. А можно было бы использовать один LINQ. При этом и скорость была бы лучше, и код более высокоуровневым был бы.
Не так. У гибернейта есть язык запросов, зачастую мне его хватает заглаза. Разве что груповое изменение типа UPDATE ... WHERE

Здравствуйте, Аноним, Вы писали:

А>Не так. У гибернейта есть язык запросов, зачастую мне его хватает заглаза.

Только он динамически типизированный и не очень хорошо ложиться на РСБУД. Вот и приходится тебе писать что-то на SQL-диалекте конкретной СУБД.

А>Разве что груповое изменение типа UPDATE ... WHERE

Вот именно! А это очень не маловажный момент. Для производительности он чуть ли не главный. А как только ты полез делать UPDATE-ты вручную, так сразу нарываешься на конфликт идеологией гибернэйта (его кэша).

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Не так. У гибернейта есть язык запросов, зачастую мне его хватает заглаза.

VD>Только он динамически типизированный и не очень хорошо ложиться на РСБУД. Вот и приходится тебе писать что-то на SQL-диалекте конкретной СУБД.

А>>Разве что груповое изменение типа UPDATE ... WHERE

VD>Вот именно! А это очень не маловажный момент. Для производительности он чуть ли не главный. А как только ты полез делать UPDATE-ты вручную, так сразу нарываешься на конфликт идеологией гибернэйта (его кэша).

Мне не доводилось писать бизнеслогику где бы требовались груповые изменения. В основном объект туда, объект сюда

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


VD>А вообще, да, согласен. Слышать то, что ты используешь не эффективное и неразумно спроектированное решение всегда неприятно. Раньше я тоже наверно обиделся бы, если услышал бы такое. А сейчас я бы предпочел для начала разобраться в сути вопроса. Оказывается, что не все представления которые мы имеем верны.

А можно по-подробнее на ету тему.

В чём принципиальная разница в использовании BLToolkit, NHibernete и FE?
Какое решение выбрать?
К сожалении при всём уважении к BLToolkit (результаты тестов видел, впечатляет) использовать его нет возможности поскольку к сожалению не мы ето определяем.