![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Границы применимости решений
Вот тут и тут идут практически идентичные срачи на тему "Зачем юзать (дорогую, энтерпрайзную, сложную) технологию А, если можно воспользоваться (простой, дешевой, десктопно-наколенной) технологией Б?".
А я, честно говоря, совсем уже потерял нить рассуждений, и не могу толком ответить на этот вопрос. Т.е. для меня вещи типа "бухгалтерию на dbf файлах в 2009 году не делают" и "mysql не является базой подходящей для систем со сложными расчетами и высокой нагрузкой" являются как бы самоочевидными, поэтому поиском аргументов на эту тему я себя никогда не утруждал.
Ну вот всегда, когда сталкивался с решениями на основе dbf (клариона, фокспро, клиппера, access, итд) - всегда очевидно, что разработчикиблядь говно тупые уроды ебаные троечники по которым агрогородки плачут отстали от современных технологий, неважно по какой причине, соотвественно, они не способны принимать участие в современных разработках, у них нет для этого мыслительных категорий.
То же самое mysql, который в старых версиях, насколько я помню, вообще толком никакой логики на стороне сервера не содержал и транзакции умел только с одним типом хранилища. Для меня самоочевидно, что транзакции - это благо. И самоочевидно, зачем нужны вещи типа Software Transactional Memory и зачем нужны проверки целостности на стороне БД. Но большому количеству разработчиков это просто непонятно - я уже писал когда-то про попавшуюся под руки базу, в которой FK не было вообще.
С другой стороны - у меня в проекте Firebird молотит данные сотнями записей в секунду на обычном железе, с одновременными массовыми перерасчетами, и ничего. Хотя как бэ и СУБД тоже из разряда тех, на которые тупые линуксоиды наезжают в стиле "это же говно, потому что я так считаю".
И вот получается, что границы применимости решений (в данном случае СУБД) становятся совершенно непонятными. Очевидно, что при желании все недостатки отдельной СУБД можно обойти в программном коде. В экстремальных случаях это получится полное повторение функционала, уже существующего в другой СУБД, и это не всегда плохо - некоторые вещи настолько сделаны чрезмерно сложно и методом постепенного добавления фич, что переписывание с нуля их только улучшит.
Но вот где граница - "берем Postgresql, программиста и линуксоида на обслуживание" vs "покупаем Oracle, покупаем DBA, покупаем страшный софт за бешеные бабки и считаем что мы круты" - непонятно. Исключая, конечно, момент откатов за софт, тогда второй случай безальтернативен.
А я, честно говоря, совсем уже потерял нить рассуждений, и не могу толком ответить на этот вопрос. Т.е. для меня вещи типа "бухгалтерию на dbf файлах в 2009 году не делают" и "mysql не является базой подходящей для систем со сложными расчетами и высокой нагрузкой" являются как бы самоочевидными, поэтому поиском аргументов на эту тему я себя никогда не утруждал.
Ну вот всегда, когда сталкивался с решениями на основе dbf (клариона, фокспро, клиппера, access, итд) - всегда очевидно, что разработчики
То же самое mysql, который в старых версиях, насколько я помню, вообще толком никакой логики на стороне сервера не содержал и транзакции умел только с одним типом хранилища. Для меня самоочевидно, что транзакции - это благо. И самоочевидно, зачем нужны вещи типа Software Transactional Memory и зачем нужны проверки целостности на стороне БД. Но большому количеству разработчиков это просто непонятно - я уже писал когда-то про попавшуюся под руки базу, в которой FK не было вообще.
С другой стороны - у меня в проекте Firebird молотит данные сотнями записей в секунду на обычном железе, с одновременными массовыми перерасчетами, и ничего. Хотя как бэ и СУБД тоже из разряда тех, на которые тупые линуксоиды наезжают в стиле "это же говно, потому что я так считаю".
И вот получается, что границы применимости решений (в данном случае СУБД) становятся совершенно непонятными. Очевидно, что при желании все недостатки отдельной СУБД можно обойти в программном коде. В экстремальных случаях это получится полное повторение функционала, уже существующего в другой СУБД, и это не всегда плохо - некоторые вещи настолько сделаны чрезмерно сложно и методом постепенного добавления фич, что переписывание с нуля их только улучшит.
Но вот где граница - "берем Postgresql, программиста и линуксоида на обслуживание" vs "покупаем Oracle, покупаем DBA, покупаем страшный софт за бешеные бабки и считаем что мы круты" - непонятно. Исключая, конечно, момент откатов за софт, тогда второй случай безальтернативен.
Уже можно суммировать
Нашей софтине больше 14 лет, начиналось на досе со своей, с кластерным хранением, СУБД. Последние лет 7 - только ОРАКЛ, они успели поебайца с MSSQL еще когда он страницами лочил - ясен пень, был выкинут. В те годы (до 2000) я чутка успел поработать манагером по Ораклу в одной немаленькой интеграторской конторе, и помню, что купленных лицензий было не так чтобы много. Но ОРАКЛ особо не обижался. Сейчас - рассматриваем EnterpriseDB как альтернативу, потому что на перелопачивание PL|SQL кода нужно 5 человеколет и их нет.
Используемые у нас плоскости сечения сферического коня:
0)мой стандартный вопрос рассуждателям про "серверное железо и ОРАКЛ - понты\дорого\откат и ваще - ну упало, переставим и из ночного дампа поднимем":
Хорошо, упало оно у вас днем 4 числа. Реакция главбуха? Ваши действия?
Поясню - они 5го числа выдают з\п. Где на 500, где на 1000+, где и на 5000+ чел.
Если решение железо+софт+люди позволяет успеть посчитать и выдать людям з\п без седых висков, сорваных нервов и кучи бабла - значит, оно вполне адекватно.
1) язык разработки - у нас их два, дельфа и жаба. Дельфисты неплохо знают SQL и PL\SQL (не, чудес тоже было - но всё же), стараются логику держать на сервере, а данные - секционировать. Отмечу, что этот код з\п на препредприятии в 5000 чел (3хсменка) считает лет 5.
Жабисты верят в Hibernate и что_там_еще, в то что они могу независеть от базы и это можно будет масштабировать. У них за спиной пока только управленческий документооборот, работающий второй год на контору с 7 филиалами по Поволжью. Для хранения метаданных FIrebird, сами "документы" - в FS (ext3 альбо NTFS).
2) Специфика наша такова, что пока нам приходится саппортить то, что мы написали, самим. Поэтому выбирается то, по чему у нас есть вменяемые спецы (т.е. больше двух).
Обычно они есть по тому, что используется давно и себя зарекомендовало.
Тут ребе theiced писал, что ему посчастливилось поработать с гуру постгреса - я искренне рад за него. Но закладываться на существование ОДНОГО спеца по базовой технологии не стал бы ни за что. А до "заборов", на которым можно почитать много и всяког, что по ораклу, что по постгресу их достаточно. Что указали на факапы - наверное, здорово. Но для меня это больше похоже на изначальное недостаточное знание используемой технологии.
Re: Уже можно суммировать
По постгре существует сравнимое кол-во спецов. Просто по ораклю существует гиганццкая армия ваннаби дба тушканов. Вы жеж не будете на похапэ пейсать по вот такой же причине?
Re: Уже можно суммировать
Чтобы я сказал, как лечить Оракель в приведенной ситуации, Вы сначала докажите (memtest'у после 24часов работы я верю), что к вас не глючит ПАМЯТЬ, диски, в б\п нет выкипевших кондюков. Да, и ОРАКЛ тоже хотя бы с предпоследним патчем.
Где взять патч - на металинке. Как попасть - купить. Нет денег на ОРАКЛ? Вы же не пытаетесь ездить на авто, купить который у Вас нет денег?
И я вообще не пишу.
Re: Уже можно суммировать
по ораклю - это лет 5-6 назад было. железо полностью меняли, ничего не помогало. раз в 3-4 недели стабильный хуяк. оракель был легальный есессно. саппорт оракля ничего ответить не смог, я с ним месяца три общался. так оно и жило пока не мигрировали на постгре ;)