Я работаю с базами уже далеко не первый год.. Разные были..

InterBase/Firebird – нравится. UDF, более близкий к чистому ЯМД синтаксис (когда в цикле можно работать с переменными.. что как правило, например в M$ можно только на уровне курсоров, что в вьюшках не допустимо у M$). Просто, удобно.. «Минус» - автоинкримент.. конечно это мелочь, но досадная мелочь, как и интеграция с Windows, хотя, есть сторонние драйвера, но они часто привязаны к версиям и платные. Ну и поля – дата, время, метка времени – отлично, да и много «плюсов» в целом. Плохо что с репликациями никак :( Ну и остального, присущего промышленным СУБД в области администрирования и сопровождения тоже нет – это плохо.

SQL M$ - отличная штука, но напарываешься постоянно на грабли.. Вообще, это не та СУБД, которая должна использоваться в промышленности, офис – да, но не более.. Хотя, в целом, для бизнес задач очень даже неплохо, но повторяю – бухгалтерия, точнее склад… При неправильной настройки сервера, работа с датами может превратиться в кошмар.

Oracle – ну что сказать.. я не гуру в этой СУБД, а посему, моё мнение – только мнение моё :) Ощущение, что эта СУБД идет взади Firebird в области программирования (PL/SQL).. По синтаксису схожи (ну а как, из одной конюшни.. (имею ввиду InterBase) ).
Программирование – отлично, типы данных – нормально. Тот же недостаток с автоинкриментом, хотя, в 11 версии приблизились по синтаксису к Firebird, но триггера так и остались.. :( О.. точно – триггера – это пожалуй один из огромных «плюсов» в отличии от SQL M$.
Но все прелести Oracle теряются когда речь заходит о инсталляции, сопровождении этой СУБД – тут уж поистине, оракловый админ должен реально получать много денег.. Ибо знать он должен не мало.. Да, возможностей много, уж и не знаю, насколько они все необходимы, т.к. часто можно сделать одни и те же операции разными способами – такое ощущение, что ресурсы Oracle нужны не для ведения БД, а для собственных нужд СУБД.. Очень все запутано, а справка – УЖАС, на металинк чужой не зайдет.. То, что можно поставить локально – извращение полное! Попробуйте, разрабатывая БД, вдруг «вспомнить» что-то, например синтаксис оператора или функцию.. Пока вы найдете это в справке – уж забудете что искали (контекстной справки нет, точнее, она вас кидает на oracle.com).
Требования к железу – монстрообразные (не верти, что у вас нормально будет работать экземпляр на 1 гиге памяти). В общем, да, весьма продвинутая СУБД (и дорогая), но роняется запросто – пример, выполните
INSERT INTO EMPLOYEES AS SELECT * FROM EMPLOYEES
В цикле.. вы однозначно уроните БД.. На самом деле – очень много таких косяков (как например, известный баг, который пылиться уже несколько лет – когда вы не можете поднять архивный лог при откате / восстановлении пока не назначите кодировку AMERICAN, т.е. по сути не можете поднять БД).. Да, конечно, это все компетенция админа, повторяю – в этом случае админ должен быть весьма грамотным. Вообщем, хорошая СУБД.. но сложновата в плане экплуатации..
Конечно, на просторах РФ еще долго будут юзать экземпляры Oracle не платя не копейки.. Только, тут надо четко осознавать – а для каких целей этот монстр нужен? Так ли он необходим? И оправданы ли затраты на железо и сопровождение этой СУБД.. Да и.. это старейшая СУБД, у которой до сих пор косяки лезут и лезут.. (я уж молчу о WEB интерфейсе)

MySQL – до 5-й версии, практически не воспринимал серьезно.. Да, были свои плюсы, но не в моей области (АСУ ТП).. Но начиная с 5-й версии, взгляд весьма изменился.
Пожалуй, я бы уже поставил MySQL впереди Firebird/Interbase по скорости, удобству и возможностям. Надежность? Ну.. надежность тут без притензий.

Остались не затронутыми постгрес и DB2 – с первой я плотно не работал, но судя по возможностям – их много, только вот опять же, не в моей области.. Это своеобразная СУБД, и далеко не всем необходима..
А с DB2 просто не работал.

А в целом – моё мнение, использовать СУБД и держать БД на Windows – это верх извращения.. Только Linux/Unix

Gluk (Kazan)
Бгг. Сам пробовал ? (напоминаю, это не IB)
Не ну если конечно заполнение таблспейса считать за "роняется", тада канеша ...
Кстати, insert из той-же таблицы без всяких AS прекрасно работает

Тэорэтики :)

Ну.. это «вчерашний» пример.. :) когда продвинутый программист умудрился рекурсивный цикл в своей таблице сделать.. Да, конечно было переполнение табличного пространства, и конечно это решилось — но суть не в этом, а в том, что во первых, экземпляр благополучно был выведен из строя, во вторых — откат потребовал времени и прочих телодвижений.
И не надо утверждать, что типа «крутой админ это выправит за пол секунды».. Я сказал — что нужен админ... :) Во вторых, «я не гуру в этой СУБД» - это значит, я обычный сертифицированный разработчик.. :) так что, тоже «Рыдалъ» :) когда восстанавливал..


IgorK stells2SQL M$ - отличная штука, но напарываешься постоянно на грабли..
Ну хоть-бы для приличия уточнили - какие, может Вы просто не умеете их готовить ?
Про автоинкремент - повеселило, оказывается это самая нужная фича в СУБД.

Нет, не самая важная, и в стандарте это не выделено :) Но кто поспорит, что сама БД — ничто, коль нет клиентских мест.. Во вторых, далеко не всегда есть PK естественные, часто нужны суррогатные или искуственные.. тут уж без автоинкрементного не обойтись..
Ну вот и сложите это вместе — разработку клиента и логику БД.. Это не определяющий фактор, только замечание.. :)

А в целом, это моё ИМХО, я так и указал :)

Bogdanov Andrey
А что такое с экземпляром случилось? Что значит "вышел из строя"? Я вот сейчас на своем домашнем компе такое попробовал - ну выдало ошибку, после чего спокойно табличку Truncate'ом очистил и никаких "выходов из строя".

Уточню..
Человек запустил запрос.. через сколько то понял что его запрос – косяк.. Работал под виндой и ничего лучшего не придумал, как тупо нажать ресет.. Вот, в собственно в этом траблы..
Любая другая СУБД, из мне знакомых, в этих случаях продолжала бы работать, т.к. просто состояние осталось бы на последней точке фиксации..
Конечно это большой плюс, что можно четко регулировать как дисковое пространство для пользователя, так и иные ресурсы (память, время процессора и т.д.) причем динамически – это действительно у других не встречал.. Разговор как раз не о заполнении табличного пространства, и не о падании, т.к. само падение тут не в остановке сервера, а в невозможности его старта нормального.
Но факт остается фактом…


PS: И нечего насмехаться над бедным усталым человеком

Да.. уточню.. отдельно для «гуру».. :)
В отличие того же интербейса, при «грамотных» настройках в Оракле, действительно можно создать ситуацию, когда из-за одного юзверя, ляжет весь сервер – это опять к моему утверждению, что для Oracle нужен грамотный админ.. ну, или хотя бы грамотно поставить сервер, слишком много возможностей – а в той ситуации (по памяти уж не воспроизведу настройки) косяки как раз и возникли из-за таких «грамотных» настроек..
Так что, наверно осторожней надо быть в «слезах».. Пути юзверя неисповедимы, впрочем как и софта.. ::)

Приятно радует и не удивлен сплоченности любителей Oracle :)
Священные войны вечны по определению – но это не тот случай, я не говорю что плохо или хорошо..
Gluk (Kazan)
P.S. Между Oracle и FB ну ничо общего, если аргументированно меня в этом разубедишь, сильно удивлюся
1. Многоверсионность
2. Теневые копии
3. Синтаксис (не в виде классических «SELECT» а сама организация – PSQL PL/SQL)
4. UDF
5. поля типа "массив"
6. каскадные триггеры
7. фильтры полей типа blob
8. сигнализаторы событий
9. двухфазное подтверждение транзакций
10. генераторов уникальных чисел
11. Джим Старки :) [GDS Rdb/VMS Oracle RDB ISC]
Если вы работали с обоими серверами, то явно заметили «до боли знакомые вещи»..:)
А вообще, я высказал своё ИМХО, которое сводится к следующему:
Oracle отдаленно похожа на InterBase, но намного круче, настолько, что нужен админ, и весьма грамотный.
Как следствие, если админ не грамотный, или просто пользователь сам управляет, то в отличие от того же InterBase, «сломать» можно намного проще – ибо инструментов гораздо больше.
Справка – да большая, но настолько запутанная.. да и контекстная закрыта (только для зарегистрированных).. Это, на мой взгляд бооольшой минус..


Bogdanov Andrey
Значит траблы не в Oracle, а в том, что "Человек ничего лучшего не придумал, как тупо нажать ресет". Есть еще один хороший способ любую базу "положить" - тяжелой кувалдой по винчестеру долбануть. Ну а вообще даже после ресет Oracle превосходно поднимается. Но вот если операционка файловую систему не спасла, то...

Не буду спорить, но ни разу не наблюдал такого с FireBird.. Хотя «ресетилось» и не раз (W2k/NTFS).. Может просто везло.

PS: млин, да ктож спорит то, что Oracle это монстр и с Firebird не сравнить, никто и не пытается сравнивать. Или, вы однозначно утверждаете, что Oracle это такое коробочно-настольное решение, которое запросто может юзать любой желающий? В этом не соглашусь никогда. Этот инструмент на то и стоит дорого, дабы вдумчиво принимать решение по его использованию..

PPS: я бы не выбирал брендов.. Гораздо правильней, считаю, выбирать конкретный продукт под конкретные задачи.. А то, посмотрите на севера – там буквально на каждом шагу стоит Oracle, порой для 1-2 пользователей.. ужас.. Наверно, если бы платили, то думали бы а не «Только Oracle – это круто»…

Yo.! stells2это опять к моему утверждению, что для Oracle нужен грамотный админ..
ораклу достаточно не подпускать к физическому серверу людей с заторможеным развитием, убивающих ФС ребутами. чего проще - пойти в EM и кильнуть там сессию ? в любой субд ...

ЗЫ. если бы ФС выжила оракл бы штатно поднялся и в бэкграунде просто откатил бы ту транзакцию.
Искренне улыбнуло, спасибо.