Нелояльный, раньше была в основном на сервере БД. Теперь новую в основном пишем на лиспе, а хранимки используем там, где критична скорость.

wadman, на вопрос вы, однако, не ответили. Являются ли процедура частью ПО?

Само то, что в FB можно написать хранимую процедуру без перезапуска сервера, как вы говорите - это проявление родства между SQL серверами и лиспом. alter table = defclass, alter procedure = defun. Потому я в начале темы и привёл аналогию между defclass и alter table (хотя это скорее будет create or alter table). А можно ли сделать alter procedure в программе на C# или Delphi? Вообще говоря, нет.

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

Ну и PSQL - язык, конечно, убогий до слёз. Длина идентификатора недостаточная, пространств имён нет, структур нет. Ничего нет.

Arm79, ну так вы структуру таблиц меняете?

Arm79, а SSDТ внутри себя разве не alter table вызывает, когда вы правите описание таблицы?

Ну вот, наконец-то началось настоящее рубилово. Извините, мне надо поработать. Чуть попозже отвечу

Arm79, вы хотите знать куда я веду или для чего я использую лисп?
Что структура БД может меняться? Я с вами не спорю.

Мне сложно вас понять. Как не спорите, а это что вы раньше писали?
Чисто теоретически оно вам и не нужно ничего про неё знать, так как нет задач, требующих изменение БД на бою.

Что значит нет задач? Мы уже пришли к тому, что не только я, но и вы сначала меняете базу отладочную и потом накатываете изменения на промышленную. Значит, промышленная БД тоже меняется. И меняется она, я надеюсь, вы признаете, с помощью alter table, хотя ваш инструмент позволяет вам об этом не задумываться. Согласны или нет?

wadman, я не считаю свою архитектуру единственно правильной, но она одна из правильных. У нас реализована более-менее обычная трёхзвенка, правда, без ORM и на экзотическом языке сервера приложений.

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

Кроме того, когда вы говорите, что вам не нужно менять код, из этого можно сделать только вывод о том, что ваше приложение очень простое и в нём нет изменчивой бизнес-логики. Из этого опять же не следует, что таковы все приложения.

Нелояльный, я опробовал на практике достаточно много разных подходовв. Моя прошлая система на MS SQL (таблиц около 100, жила и развивалась лет 8 до прекращения бизнеса) была именно такой: вся бизнес-логика на сервере. Я был противником трёхзвенки и кричал на весь мир "вот как надо программировать, никаких трёхзвенок, sql рулит". Я и сейчас высоко ценю SQL - гениальная вещь.

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

Представьте себе такой мысленный эксперимент. Есть у вас ваш Firebird, но когда на сервере FB происходит Exception, появляется окошко "just in time debugging", можно запустить IBE и посмотреть место, где исключение возникло, глянуть переменные, вычислить что-то. Согласитесь, вот так надо бы работать в XXI веке. В FB (во всяком случае по состоянию на 2.5) такого нет, в MS SQL 2000, с которым я последним работал, этого не было. Думаю, и сейчас ещё такого там нет. Хотя если кто положит такую инфу в тапок и кинет в меня - начну копить на MS SQL :)

Вот ради такого удобства мы и перешли на трёхзвенку и теперь такое удобство у нас это есть.

Arm79, ну так и торговля бывает разная. Бывают клиенты со своими требованиями по оформлению документов, бывают хитрые управленческие отчёты, бывает просто очень большой объём данных, при котором производительность 1С не удовлетворяет. Бывают системы премирования менеджеров. Бывают филиалы. Бывает закачка документов из других систем. Бывают системы ранжирования товара. Всё это уникально для каждой организации и никак не покрывается стандартными конфигурациями 1С. И есть меняющееся законодательство, может быть, вы с этим не сталкивались. Если это 1С, то есть какая-то поддержка от вендора, а если это самописная система, то нужно успевать тянуть весь воз уже написанного кода за сменой законов. Мне казалось, это очевидно, поэтому я особо и не отвечал на это :)

По Дельфи - да справилось бы и Дельфи. Вопрос в объёме кода и сложности самого приложения. Чем сложнее приложение, тем больше преимущества лиспа за счёт возможности переопределять функцию на лету. Эти преимущества сказываются в уменьшении времени компиляции и в уменьшении времени на воссоздание ситуации, являющейся предметом изучения. Если ваши приложения компилируются за одну-две секунды, то они, видимо, довольно простые.

По сравнению с Дельфи - лисп надёжнее, т.к. он по работе с объектами больше похож на Java/C#, в нём сложнее промазать мимо памяти, хотя тоже можно. Намного сложнее добиться утечки памяти, или там Access Violation-ов. Соответственно, меньше возни с деструкторами. Это ведь само по себе, наверное, многих заставило перейти с Дельфи на C#. Настраиваемый отладчик. Например, можно сделать, чтобы в одном треде экспешн вызывал отладчик, а в другом возвращал экспешн пользователю, всё это можно программировать, а не мышью накликивать, как в Delphi. Ну и я не представляю себе какой-нибудь Delphi 2007, неделями висящий на промышленном сервере приложений. Он рухнет довольно быстро или всю память съест. А IDE лиспа у нас реально неделями крутится, т.е. все сорсы приложений и отладчик промышленной базы у нас всегда под рукой, если что.

Что ещё? Ну, допустим, хеш-таблицы по любым объектам элементарно строятся. Очень удобна работа с древовидными структурами. Я на Дельфи уже 13-й год потихоньку развиваю библиотеку работы с деревьями, но она до сих пор уступает тому, что в лиспе есть "из коробки".

wadmanизменение структуры бд может принести кучу сюрпризов
А мы умеем с этим справляться, потому что у нас за счёт макросов, которыми мы расширили PSQL, наборы параметров нужных нам хранимых процедур растут вместе со структурой таблицы. Система макросов для PSQL написана на лиспе. Клиентское приложение тоже в большой степени генерируется автоматически из структуры базы - генератор написан на лиспе. Оно заточено так, что редко возникают сообщения типа "field not found" или как там оно - не помню даже его текст, так давно не видел. Бывают и у нас сюрпризы с базой, они неизбежны по природе вещей, но крайне редко.

mayton, мы, в общем-то, готовы делиться нажитым, нам это выгодно. Хотя тут есть проблемы - не всё можно выложить в open source из-за NDA, многое нужно приводить в божеский вид, многое неудобно и т.п. Я говорю "мы", но 90% работы сделал я один, многое доведено до минимально рабочего состояния - мне же платят за решение прикладных задач, а не за развитие платформы. Если будет какой-то интерес, адрес указан в вакансии.