Why everyone hates ...?

Разработка приложений на ЯП Java под СУБД Firebird, как?

Все это связано с желанием все информационные системы пересадить на одну БД. Следовательно просчитывается путь с минимальными затратами.

Иногда дешевле купить дорогую лицензию, чем переводить какие-нибудь замороченные базы на другую БД.

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

Иногда просто мозк е..ут.

Plaintext - наше всё. Базы данных не нужны.

Firebird тупо неудобен: сообщения об ошибках в запросе крайне малоинформативные, плюшек мало типа нормальных вьюх (кстати, там есть вообще оконные функции?)

Пока работал во многих компаниях везде наблюдал что они часто занимаются переездом с базы на базу

Что бы зоопарка не было.

Обоснуйте.

MySQL говно, у него нет нормальных stored procedures, например. По крайней мере несколько лет назад не было. А в MicrosoftSQL кроме всего прочего их можно на нормальном языке писать, на C#

Кстати о них я как-то не спрашивал. Но спасибо раз уж ответили

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

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

Plaintext - наше всё.

Кто вы такие?

Уже пошутить нельзя? :)

Одмины локалхоста :)

У меня уже было два приложения, которые у которых все данные вмещались в пару мегабайт. И поддавались большому количеству чтений. С другой стороны запись производилась раз в 10 мин. Сохранял все в структуру в памяти, потом при каждой записи сбрасывал все на диск в JSON + flush. Чем не plaintext use case?

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

Вот смотри - есть у нас 300 ораклов, на которых мы проданные презервативы считаем. Это конечно круто, но вообще недешево, и если свалить на постгрес, можно сэкономить очень дофига.

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

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

Работал и с ораклом, и дб2... Я не знаю почему так получается, но если проприетарное, то почти наверняка значит громоздкое, переусложненное, сложное в эксплуатации. Вообще это не только к базам относится.

Бывает так, что в наследство досталась база на DB2, но вот специалистов по DB2 в наследстве не было.

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

конкретнее?

Вот смотри - есть у нас 300 ораклов, на которых мы проданные презервативы считаем. Это конечно круто, но вообще недешево, и если свалить на постгрес, можно сэкономить очень дофига.

300 ораклов --- это прямо скажем дофига.

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

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

заманчивая перспектива экономии, да.

это о в организациях такого размера, что похоже цена лицензии для них не аргумент.

ставлю на то, что в «этих» организациях есть тьма _разных_ баз от разного ПО. это самое ПО бывает снимают с поддержки и предлагают другое. оно такое же, но новое, за новые деньги.

вот тебе и переезд.

Чем плох Firebird кроме немодности?

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

но если тебе эта штука подходит по тех.параметрам, то почему нет собственно?

верно. Plaintext рулит, но для особо запущенных случаев json

заманчивая перспектива экономии, да.

Зависит от масштабов и качества того софта, который работает с этими базами. Если этот софт всё равно под переписывание, а ораклов будет положим не 300 а 2000, то уже становится выгодно.

верно. Plaintext рулит, но для особо запущенных случаев json

/me представил себе 2-терабайтный JSON и сполз под стол.

Однажды мне сказали что нужно фид распарсить - несколько гигабайтный JSON. Я уже представил себе SAX парсер, муки и страдания. Оказалось что это несколько ГБ отдельных 3 КБ JSON документов, разделенных окончанием строки. Шикарный формат кстати

Угу, тут не получится. Обычно на другую базу слезают в самом начале, когда этих 300 ораклов нет, но они мерещятся. Вот и решают свалить, пока не поздно.

этот софт всё равно под переписывание

годами отработанная и работающая инфраструктура при смене будет отрабатываться годами и помахивать в тумане плесневелыми плюшками. во радости :)

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

не, серьезно? ваш лукоил, если я не ошибаюсь, этим занимается? :)

Я уже представил себе SAX парсер, муки и страдания.

Дамп текстов википедии (11ГБ) распространяется в xml. Сначала пробовал разные парсеры, в результате выяснил, что нет ничего круче обычных regexp'ов.

Ну, из того, что сразу приходит в голову:

• tempdb в памяти, как следствие - эскалация блокировок. Оракл хранит блокировки прямо в блоках данных, и такой проблемы не возникает
• MSSQL - блокировочник. И несмотря на то, что они давно парят, что сделали там версионность, тяжкое наследие Sybase не дает спокойно вздохнуть. Это значит, что если одна сессия изменит данные, то другая сессия, не сможет эти данные прочитать до тех пор, пока первая не сделает коммит. Оракл же предоставит второй сессии неизмененную версию данных.
• в MSSQL нет сиквенсов. Поле с автоинкрементом небезопасно с точки зрения одновременного использования из нескольких сессий.
• Уродский T-SQL. Например, в этом языке могут порождаться сущности, которые средствами самого языка не могут быть обработаны. Даже SQL/PL в DB2 и то более продвинутый. Оракловый PL/SQL - вообще как благословение божье.
• У Оракла есть RAC. Причем работает оно так, что ты тупо торкаешь пустой блейд в стойку, по PXE туда ставится Шляпа или, там, unbreakable linux, и блейд прямо на ходу включается в RAC и все вертится автоматом.

Это только то, что помню с Oracle 10g. Тут недавно было мероприятие, посвященное запуску двенадцатой версии, там вообще чудеса и космос.

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

RAC

У машин разные IP? Как их указывать на клиенте? Какой тип репликации?

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

MSSQL - блокировочник. И несмотря на то, что они давно парят, что сделали там версионность, тяжкое наследие Sybase не дает спокойно вздохнуть. Это значит, что если одна сессия изменит данные, то другая сессия, не сможет эти данные прочитать до тех пор, пока первая не сделает коммит. Оракл же предоставит второй сессии неизмененную версию данных.

Разве это не просто разные режимы изоляции транзакций? И переключаются они просто опцией

Нет там никакой репликации. К какой ноде отправить клиента решает TNS. Клиент видит один сервис, и его не парит что там за этим сервисом, одна база, RAC или DataGuard.

Смысл RAC в том, что несколько инстансов (у оракла инстанс - это совсем не то, что у MSSQL) работают с одной базой (в смысле, с одним хранилищем).

В том-то и дело, что в оракле ничего переключать не надо. А в MSSQL - да, есть выбор. Либо адская каша из неконсистентных данных в READ UNCOMMITED, либо блокировки. И это не просто опция. Тебе надо прямо в коде на каждый чих переключать уровень изоляции.

В оракле по дефолту READ COMMITED и версионность.

Вот тебе еще киллер-фича. У Оракла есть Flashback. То есть, ты можешь сказать

select * from t_table as of timestamp sysdate - 1;

Про Informix еще забыли. :)

Про Informix еще забыли. :)

Про мертвых либо хорошее, либо ничего. Вот про него и... Ничего :-)

годами отработанная и работающая инфраструктура

Обросший плесенью зомби, правильней сказать.

Мы же оба прекрасно понимаем, что слово Oracle является антизаклинанием призыва дерьмодемона, который превращает в г..но всё окружающее :-)

Вот тебе еще киллер-фича. У Оракла есть Flashback. То есть, ты можешь сказать select * from t_table as of timestamp sysdate - 1; . Получишь данные за час назад.

Ну это еще не факт, что за час, можно и за 10 минут не получить.

Можно и не получить, смотря как флэшбэк настроишь.

Здравствуйте, меня зовут Андрей, и я ораклист. *сочувствующее понимание в зале*

на нормальном языке писать, на C#

Очень толсто