Сразу говорю опыт работы тока с ORACLE и отсюда вопрос. после 2 недель разбора разбора POSTGRES и FIREBIRD понял, что обе не особо подходят, в одной нет временных таблиц и пакетов в другой ещё хуже.
Какая СУБД из желательно бесплатных удовлетворяет требованиям:
1. constraint foreign,primary.
2. Триггера на таблицы
3. надёжная защита информации (имеется ввиду не зная пароль нельзя посмотреть и на дискете не унести)
4. исполняемые хранимые процедуры.
5. временные таблицы (которые не надо создавать в каждой сессии)
6. использование функций в sql операторах
7. транзакционность
8. простая установка СУБД.
9. желательно бесплатная СУБД ну или не высокая цена в пределах 300$
*** Желательно
Нормальный внутренний язык например PLsql а не TSQL меня сильно напрягают собачки перед.
переменные пакетов или решение аналогичное этому. ну привык я уже к ним.

Система относительно сложная с количеством форм ввода >100 данных не много ~300 строк в день.
Наличие аналитических функций приветсвуется.

Q: почему не ORACLE?
A: Ну очень тяжелый инсталятор. и просит админа.

Если уж совсем просто сказать, то нужен оракл без всяких навортов типа спатиал и партишен.

Senya_LА чем Вас Firebird не устроил и какому из списка требований он не удовлетворяет?
В FB мне не понравилось отсутствие документации. потому как сводить доку в список отличий ну как то не очень красиво.
А временных таблиц я там не нашол.
Пакеты желательны для организации вычислений, расчётов. по причине того что система имеет очень много процедур и очень длинные транзакции.
Расчёт календарного плана есть не что иное как 15000 строк pl\sql кода, в котором в большом количестве используются переменные пакеты. и это одна из десятка процедур для расчётов.
Временные таблицы используются для ввода набора данныз 50-150 строк.
Так что для каждой работы свой инструмент.
Relic Hunter
Проблема поставить? Я тебе за $200 установлю удаленно. Только CD в трей вкинь, плиз

Ну забыл сказать, что ещё сделай удалённое соединение. обеспечь связь и прочее прочее. Проще системник в Токио свозить и обратно.
Проблем купить ORACLE нет никаких, но оракл очень тяжелый. если FB занимает 5 Мб то оракл 11G весит 1.7GB. плюс палитика компании при устанвки ПО USER должен нажать на кнопку согласен 2 раза, и ни какие варианты установки ему не предлогаются.

pkarklinавтора не TSQL меня сильно напрягают собачки перед
А в почтовом адресе по средине не напрягают?!

открывая скрипт на T-sql я кроме этих собачек больше ничего не вижу. И меня это раздражает. Приходится напрягать мозги что бы отделять мух от котлет. а на фига мне оно надо. когда в процедуре используется 80 различных переменных и весь экран в собачках это скажем так жуткое зрелище.

Oracle XE был в основе, но потом решили посматреть в сторону FB и PG. на тот случай если будет проще с минимальной потерей функционала.
И как оказалось при всём богатстве выбора альтернативы нет.
Хотя стоит заметить, что FB очень даже хороший инструмент, но какой то он не законченный,такое отношение к документации не в одни ворота не лезет. Я так и не смог найти как создать временную таблицу, хотя сделал это по аналогии с Oracle, и даже получилось. Но все таки хотелось бы иметь нормальный PDF в котором расписаны все функции и операторы которые доступны разработчику.
Всем спасибо можно закрывать топик.

Yo.!не понял, а что в XE то не нравится ? 200мб дистр ? в теории есть еще EnterpriseDB, продвинутый вариант постгрес в котором почти pl/sql и такими же ограничениями, что и oracle xe. но имхо разбиратся будете много дольше чем кодить ...
Ну почему то Oracle довольно тяжёлый, и всё таки была надежда, что конкуренты не дремлют, и догоняют семимильными шагами, оказалось как всегда.

Самый большой + ORACLE XE по сравнению со всеми и без припятсвенный рост хоть в высоту хоть в ширину. в конечном итоге перевесил всё

Dimitry Sibiryakov
ORA-600в конечном итоге перевесил всё

Это было несложно при начальных условиях: "Любая СУБД, которая выглядит
как Оракул и работает как Оракул"...

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

Я знаю и умею использовать и temp table и context variable и package variable. но все это требует дополнительных услий.
если темп табле то соответсвенно надо писать лишние скелеты в место обыного сравнения и джойны в запросах. контекстные переменые тоже не намного проще.
А то что это RDBMS и все должно хранится в таблицах так я не спорю. пусть СУБД хранит где хочет и сама напрягается а не меня напрягает. пакетные переменные? да частично решают проблему, но лишь частично, иногда(95% всех использований) приходится писать дополнителные функции.
На счёт экспорта это пусть голова у производителей СУБД болит.
Кстати пакетные переменные это одна из причин по которой Я вынужден использовать ORACLE а не другие СУБД.

hvladFirebird 2.1 :
1) схем нет
2) rdb$get_context\rdb$set_context - те самые переменные
3) trigger after connect
4) стандартные global temporary table, думаю точно такие же как в оракле

Мнение менять не надо, оставайтесь на Оракле
В оракле не стараюсь не использовать контекст варибле по той причине, что интерпритатор не проверяет названия переменных. и в конечном итоге приходится делать кучу функций для чтения и записи.
И действительно FB очень симпатична, но документация это катострофа.
Я так и не смог найти в доке временные таблицы контекстные варианты тоже не нашол.
Но после 3 дней знакомства очень лестные чувства.

stopor
А объясните, плиз, что не сложилось с PostgreSQL?
Только лишь отсутствие _глобальных_ временных таблиц (которые ИМХО гадость)?

Ну гадость это или нет - вопрос спорный.
Нормальный диалог выбора из ассортимента накидали в табличку 50-100 строк и сделали обычный селект из БД объединяя данные из временных и перманентных таблиц, точнее сказать там уже сделано представление в котором всё объединено автоматически. нажали на кнопочку и процедура выполнила необходимые действия. сформировался новый объект. с выбранным набором реквизитов.
выполнился коммит и данные автоматом почистились. готов к формированию следующего объекта.