и снова [orm] для [cl]

Хочеться ORM

Зачем? Для обработки - что может быть «няшнее» SQL (если мы о RDBS). Для гуя - из нескольких виденных мною экземпляров БД-шных гуев (в т.ч. Дельфи, 1С, прочие «бухпроги», результат работы Оракловского дизайнера, и т.д. и т.п.) наиболее «логичным» с т.з. пользователя мне показался табличный гуй мелкософтовского Access-а (хотя там шаг в сторону - лучше я сам повешусь), но «снаружи» там ОРМ-ом и не пахло, подозреваю что и внутри - тоже (по крайней мере до 2000-го включительно).

Единственное для чего могу допустить оправданность ORM-а - 3-звенки и прочие подобные извращения: прокидывать через слой события и обработку данных может быть ещё большим извращением. Хотя это довольно специфический класс задач.

3-звенки и прочие подобные извращения

Сам ты извращенец.

ну согласись - в каждой дырке 3-х звенка не нужна. Спорить на тему «stored procedure vs. middle tier» за пределами 3-х физически раздельных уровней не собираюсь.

в каждой дырке 3-х звенка не нужна

«каждой дыркой» я не занимаюсь, но да, во всяких CAD-системах обычно не нужна (хотя, тоже разные бывают).

«stored procedure vs. middle tier»

Бизнес-логика должна быть в бизнес-слоё. Размещать бизнес-логику в БД - подход архаичный и по нынешним временам совершенно извращённый.

Elephant: я правильно понял что он только с беркли дб работает

Нет еще с postmodern и clsql:) И в экспериментальном режиме чем-то неsql-ным.

CLSQL: отличный ORM,

«прекрасный снаружи, корявый внури» - насколько я помню консит, сортировка на клиенте вместо сервера, некоторые непринципиальные заморочки с передачей функций.

Пугают сообщения на lisper.ru о «перманетных проблемах» с этой либой.

А те у которых работает скромно молчат. Он для небольших объемов вполне себе работает, для больших сильно неидеален.

Бизнес-логика должна быть в бизнес-слоё.

Логично! Осталось провести границу между бизнес-логикой и ключами/индексами/счётчиками/SQL/DML/фильтрацией/агрегированием/вставкой/удалением - всем тем, именно чем и должна заниматься БД и только БД.

Граница очень простая - БД должна обеспечивать хранение и выборку данных, всё.

т.е. бизнес-слой не должен заниматься хранением и выборкой? Сиречь не должен озадачиваться консистенцией, равно как и фильтрацией/агрегированием - это же «выборка», не?

Сиречь не должен озадачиваться консистенцией, равно как и
фильтрацией/агрегированием - это же «выборка»

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

2 archimag А целостность? А возможность подкрутить скорость выполнения?

Размещать бизнес-логику в БД - подход архаичный и по нынешним временам совершенно извращённый.

Почему архаичный и извращенный?

2 s9gf4ult. Чесс гря я бы вообще задумался о целесообразности применения ОРМ. Основные причины:

• ORM не дает сильно бОльшей абстракции над базенкой. Все равно, рано или поздно ты задумаешься над всеми этими индексами, ограничениями и т.д. Все равно тебе придется, рано или поздно, ковырять быстродействие. И ORM все равно не отвязывает тебя от таблиц и полей.
• От накладных расходов, связанных с СУБД-шкой ты, частично, уйдешь. Но придешь к накладным расходам, связанным с ORM-мом.
• Хорошо подумай, так ли тебе важна переносимость между СУБД? У каждой СУБД есть свои фишки, которые позволяют выжать из нее максимум. А так ты хочешь приравнять Oracle к какому-нибудь SQLLite. Кроме того, ты по-любому, завязан на СУБД-шку, привязка к которой сильнее привязки к ОС. А так ты вводишь еще одну сильную зависимость.
• Подумай, что легче сопровождать? SQL он один, а ORM-ов много. И их форма записи особо от SQL не отличается. Сегодня в моде один ORM, завтра другой. Вероятность устаревания твоего ORM-а намного выше, чем вероятность устаревания СУБД-шки. Зоопарк ORM-ов разводить будешь?
  
• Не надо исключать и возможность переноса существующего кода. SQL перенести будет намного проще.

• ORM не дает сильно бОльшей абстракции

  Таки не верно. Индексы, форейн кеи описываются непосредственно в классах, не нужно DDL описывающий базу, не нужно писать связывающий код, который будет разбирать результаты запросов. Выброрки по джоинам, update значений в таблицах по результату select (выбираешь список объектов из базы, потом эти объекты меняешь и сохраняешь снова в базе, объекты сами помнят в какой таблице и в каких полях нужно запомнить значения) работают с объектами (экземплярами клссов) которые сами контролируют свое содержимое. Это все есть ORM
• Накладные расходы с ORM ? не слышал.
• Тут не известно, проект какбы фэнтэзийный и нагрузка на базу будет ли большой тоже не ясно на данной стадии.
• Ну дак библиотека открытая, всегда можно форкнуть, если что - то не понравится.
• Если логика приложения не будет отличаться в реализации на другом ЯП. Да и SQL так то тоже не совсем «чистый» он генерится из sexp-ов (как в Postmodern) или самодельными макросами.

Индексы, форейн кеи описываются непосредственно в классах

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

не нужно писать связывающий код, который будет разбирать результаты запросов

В известных мне ORM получение и обработка результатов как-то не особо сложнее, чем из обычного запроса. И модификация тоже. Хотя кода несколько больше, но вполне приемлемо. Хотя да, объем вносимых изменений при помощи ORM таки меньше.

Накладные расходы с ORM ? не слышал.

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

проект какбы фэнтэзийный и нагрузка на базу будет ли большой тоже не ясно на данной стадии.

Я уже понял, что фентезийный. Из ТЗ. А теперь подумай, что записей может быть хотя бы тыщь триста. И неоптимальность запроса сразу вылезет. На разных СУБД это по-разному решаться может. Особо критично это в вебе, где юзер ждать не будет.

Ну дак библиотека открытая, всегда можно форкнуть, если что - то не понравится.

И много ты нафоркал? А сопровождать и развивать форк ты тоже будешь? И платить тебе за его поддержку тоже будут? И ты так классно разбираешься в предметной области твоей либы, чтоб ковырять ее потроха?

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

Реализация всегда будет отличаться. И пойдут твои наработки в никуда.

Да и SQL так то тоже не совсем «чистый» он генерится

Чесс гря если SQL полностью генерится это как-то не классно. Я понимаю уточнения для запроса или сортировка, а полностью неее... Полностью разве что запросы модификации - они, как правило, намного проще выборок.

Тут именно проблема, что этот уровень абстракции недостаточно высокий, чтобы обеспечить качественный скачек уменьшения издержек разработки и сопровождения при использовании реляционных СУБД. Мое мнение, что ORM это затычка для недостаточно выразительных языков, помноженная на неудобство генерирования SQL. С этим и надо, в первую очередь бороться, а не пытаться натянуть жопу на глаз реляционные данные на объектную модель.

А целостность?

Целость необходима для обеспечения хранения. Это не бизнес-логика.

А возможность подкрутить скорость выполнения?

Это оптимизация. Вынос какой-то части в бизнес-логики в базу возможен в целях оптимизации. Но любая оптимизация обычно порождает проблемы с поддержкой код и его развитием.

При этом, возможности масштабирования железа, на котором крутится СУБД, всегда ограниченны и не сравнимы с возможностями по масштабирования серверов-приллжоний.

Почему архаичный

Потому что уже давно придумали SOA.

и извращенный?

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

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

А как же различные модули, позволяющие писать процедуры к, например, PostgreSQL на всяких там питонах и прочем, вплоть до Си, если не ошибаюсь?

А как же различные модули, позволяющие писать процедуры к, например,
PostgreSQL на всяких там питонах и прочем, вплоть до Си, если не
ошибаюсь?

Да, у меня тут как раз под одному проекту большой массив кода на PL/Python. Лучшая демонстрация того, что «настоящие SQL программисты на любом языке будут писать как на SQL». Впрочем, тот же PL/Python всё равно имеет очень ограниченные возможности по повторному использованию кода и писать на нём нормально довольно затруднительно. Хотя это и лучше, чем другой код по этому же проекту, где реализован один алгоритм на чистом PL/pgSQL - 6 000 строк кода, которые никто уже давно понять не может.

Целость необходима для обеспечения хранения.

Проверка на валидность это бизнес-логика или можно оставить на уровне СУБД?

Вынос какой-то части в бизнес-логики в базу возможен в целях оптимизации.

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

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

В теории - да, на практике всяко бывает.

SOA

Это нужно далеко не везде.

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

Это больше вопрос аккуратности разработчика, не?

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

Здесь согласен.

Это больше вопрос аккуратности разработчика, не?

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

Здесь согласен.

В смысле, что я ненавижу писать хранимки.

Проверка на валидность это бизнес-логика или
можно оставить на уровне СУБД?

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

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

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

SOA

Это нужно далеко не везде.

Это не вопрос нужности, это вопрос общего подхода к проектированию.

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

Такой подход не масштабируется эффективным образом на сколько-нибудь большую команду разработчиков.

Проверка валидности данных должны быть на стороне СУБД, ибо это важно для сохранности данных.

А если не для сохранности данных? Например, проверка значения или установка значения по умолчанию и т.д.? Т.е. это таки кошерно делать на стороне СУБД?

Поэтому, хорошо оформлять весь SQL-код в виде хранимок

Согласен. Или, по ситуации, вьюшек.

Такой подход не масштабируется эффективным образом на сколько-нибудь

большую команду разработчиков.
Не скажу, т.к. в больших командах не работал.

В общем посмотрел я на clsql, вот что не понял: в соответствии с документашкой http://clsql.b9.com/manual/csql-rel.html мы должны делать вот так:

(def-view-class employee ()
  ((name :type (string 20))
   (company
    :accessor employee-company
    :db-kind :join
    :db-info (:join-class company
              :home-key companyid
              :foreign-key companyid
              :set nil))
   (president
    :reader president
	:db-kind :join
	:db-info (:join-class employee
		      :home-key presidentid
              :foreign-key emplid
              :set nil))
   (manager
    :accessor employee-manager
	:db-kind :join
	:db-info (:join-class employee
	          :home-key managerid
              :foreign-key emplid
              :set nil))))

(def-view-class company()
  ((name :type (string 20))
   (employees
	:reader company-employees
	:db-kind :join
	:db-info (:join-class employee
		      :home-key companyid
		      :foreign-key companyid
              :set t))))

и после создания таблиц у нас должны появится форейн кеи в таблицах. При включенном start-sql-recording наблюдаю что создается в базе

(mapcar #'clsql:create-view-from-class '(something::company something::employee))

;; 2012-01-24T19:04:46 127.0.0.1/test/test => CREATE TABLE COMPANY (NAME CHAR(20))
;; 2012-01-24T19:04:46 127.0.0.1/test/test => CREATE TABLE EMPLOYEE (NAME CHAR(20))

проверка значения

Если это важно для хранения.

установка значения по умолчанию

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

Итоги подведем.
Т.Е. хранимки и прочая начинка СУБД-шек хоть и не идеальна далеко, но полезна, так?
И использование этой начинки, хоть и архаично и некошерно, но таки, в некоторых случаях практично (процент зависит много от чего). Так?

Т.Е. хранимки и прочая начинка СУБД-шек хоть и не идеальна далеко,
но полезна, так?
хоть и архаично и некошерно, но таки, в некоторых случаях практично

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

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

навороченные хранимки для извлечения данных - кошерно или не? Если чо, я сам такого терпеть не могу.

а использование этих инструментов для реализации бизнес-логики.

Может это и архаично, но, временами, это наиболее практично. ИМХО

а что, для этого вашего лиспа за 25 лет не осилили собраться и придумать стандарт для работы с базами и для orm?
джависты с их jdbc четвертой (кросс БД) и jpa второй редакций смотрят на вас...

навороченные хранимки для извлечения данных - кошерно или не?

Опять неправильная постановка вопроса :) Это просто вопрос рациональной декомпозиции. Бизнес-логика должна быть в отдельном слое. С точки зрения этого слоя не важно насколько сложной является конкретная хранимка. Логика хранения данных может быть довольно сложной, унаследованной от предыдущих систем, зависимой от каких-то внешних факторов или других систем. Хранимка как раз может обеспечивать эффективное отделение бизнес-логики от логики хранения.

Кстати, я потому и ORM не люблю, ибо ORM хочет что бы я в бизнес-слое прописал какие-то детали логики хранения.

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

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

джависты .. смотрят на вас...

Да они на всё так смотрят, не зависимо от каких-либо факторов. Поэтому не аргумент. Кстати, все остальные смотрят на джавистов так же ;)

Опять неправильная постановка вопроса :)

Хранимки, триггеры и т.д. и есть отдельный слой, хотя и хранящийся в СУБД. Просто больно неуклюже, оно порой, выглядит. Я об этом.
И не вполне понятно, что вы подразумеваете под «логикой хранения» и бизнес-слоем.

Я не пишу хранимки

Везет. У меня есть унаследованные, на 5-7 экранов. Понять, что выражено посредством SQL бывает очень непросто при таких раскладах.

И не вполне понятно, что вы подразумеваете под «логикой хранения»
и бизнес-слоем.

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

Везет. У меня есть унаследованные, на 5-7 экранов.

Везение тут не при чём :) Унаследованного кода в базе полно, просто я не пишу хранимки (и не хочу), для этого есть специальные люди (как я сказал выше).

а что, для этого вашего лиспа за 25 лет не осилили собраться и придумать стандарт для работы с базами и для orm?

джависты с их jdbc четвертой (кросс БД) и jpa второй редакций смотрят на вас...

Нормальные языки не являются анально огороженными, поэтому протащить что-то в стандарт ради костного интереса одной стороны невозможно. Common Lisp - это достояние человечества, а не одной проприетарной конторы.

Ну так то парень не о том говорил.

А вообще состояние библиотек в CL меня сильно батхертит. Такой рантайм с таким продуманным стандартом и таким языком, а сообщество крайне не практично и мало. Бибилиотеки которые действительно можно использовать развивают еденицы, еще меньше делают на них документацию.

CLSQL таки гавно, да.

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

Ну и корпорации деньгами язык не двигают, но это, вероятно, следствие из первого пункта.

Двигали когда-то.
Это все отголоски AI-winter, на самом деле.

А для решения обычных задач лисп вполне ОК. Лучше всякого хлама типа питона или C#. Тут проблема исключительно в малом количестве библиотек и маленьком коммьюнити, что в основном, является следствием вышесказанного про корпорации.

lovesan

А это не правда ли случайно, что гуголь где - то собирается использвоать CL ? я такое где то на лоре вычитывал.

В общем, мы говорили об одном и том же, просто разными словами. Путаница вышла на уровне терминологии.

костного интереса одной стороны
одной проприетарной конторы.

не разобрались - так не говорите.
http://jcp.org/en/jsr/results?id=3544 вот пример голосования за стандарт jdbc 4.0
Apache Software Foundation Yes
BEA Systems Yes
Borland Software Corporation No Vote
Fujitsu Limited Yes
Google Inc. No Vote
Hewlett-Packard Yes
IBM Yes
Intel Corp. Yes
Lea, Doug No Vote
Nortel Yes
Oracle No Vote
RedHat Yes
SAP AG Yes
SAS Institute Inc. Yes
Suleiman, Hani Yes
Sun Microsystems, Inc. Yes

И да, 7 джава вообще то уже не огороженная.

А это не правда ли случайно, что гуголь где - то собирается использвоать CL ? я такое где то на лоре вычитывал.

Отвалили кучу бабок ITA за лисповый движок поиска авиабилетов. По последним слухам от засланцев морду гуголь таки с лиспа переписал, а движок не трогает.

не разобрались - так не говорите.

jdbc - не язык.

И да, 7 джава вообще то уже не огороженная.

Ну да, один раз - не пи...ас. И всякие iced tea на ровном месте росли.

а кто говорит о языке? я говорю о стандартах. Между прочим на коре джава тоже есть стандарт - хоть обимплементируйся.

а кто говорит о языке? я говорю о стандартах.

Ну ты же заикался о CL, а это стандарт языка.

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

Между прочим на коре джава тоже есть стандарт - хоть обимплементируйся.

Только влияния на стандарт до недавнего времени у людей с улицы было нуль.

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

в результате чего появилась смесь бульдога с носорогом, да :)

в результате чего появилась смесь бульдога с носорогом, да :)

В результате получился мощный и сбалансированный язык. Ляпы есть, но не слишком страшные.

Вопрос к знатокам, для CL есть что-то похожее на Korma? Я использовал однажды в Clojure, понравился опыт.

Для CL - не знаю, вроде нет. Для Java - есть! Называется iBATIS. И в несколько раз круче сабжа.