Границы применимости решений

[metaclass]

Вот тут и тут идут практически идентичные срачи на тему "Зачем юзать (дорогую, энтерпрайзную, сложную) технологию А, если можно воспользоваться (простой, дешевой, десктопно-наколенной) технологией Б?".

А я, честно говоря, совсем уже потерял нить рассуждений, и не могу толком ответить на этот вопрос. Т.е. для меня вещи типа "бухгалтерию на dbf файлах в 2009 году не делают" и "mysql не является базой подходящей для систем со сложными расчетами и высокой нагрузкой" являются как бы самоочевидными, поэтому поиском аргументов на эту тему я себя никогда не утруждал.

Ну вот всегда, когда сталкивался с решениями на основе dbf (клариона, фокспро, клиппера, access, итд) - всегда очевидно, что разработчики блядь говно тупые уроды ебаные троечники по которым агрогородки плачут отстали от современных технологий, неважно по какой причине, соотвественно, они не способны принимать участие в современных разработках, у них нет для этого мыслительных категорий.
То же самое mysql, который в старых версиях, насколько я помню, вообще толком никакой логики на стороне сервера не содержал и транзакции умел только с одним типом хранилища. Для меня самоочевидно, что транзакции - это благо. И самоочевидно, зачем нужны вещи типа Software Transactional Memory и зачем нужны проверки целостности на стороне БД. Но большому количеству разработчиков это просто непонятно - я уже писал когда-то про попавшуюся под руки базу, в которой FK не было вообще.

С другой стороны - у меня в проекте Firebird молотит данные сотнями записей в секунду на обычном железе, с одновременными массовыми перерасчетами, и ничего. Хотя как бэ и СУБД тоже из разряда тех, на которые тупые линуксоиды наезжают в стиле "это же говно, потому что я так считаю".

И вот получается, что границы применимости решений (в данном случае СУБД) становятся совершенно непонятными. Очевидно, что при желании все недостатки отдельной СУБД можно обойти в программном коде. В экстремальных случаях это получится полное повторение функционала, уже существующего в другой СУБД, и это не всегда плохо - некоторые вещи настолько сделаны чрезмерно сложно и методом постепенного добавления фич, что переписывание с нуля их только улучшит.
Но вот где граница - "берем Postgresql, программиста и линуксоида на обслуживание" vs "покупаем Oracle, покупаем DBA, покупаем страшный софт за бешеные бабки и считаем что мы круты" - непонятно. Исключая, конечно, момент откатов за софт, тогда второй случай безальтернативен.

Comments

[fas-tm.livejournal.com]

Не не не.. мы не живем в своем мире. Адекватно относимся ко всем технологиям.
А фэйлы случаются ВЕЗДЕ. И чаще всего от незнания нюансов выбранной технологии и попытки изобрести велосипед. А иногда и тупо от человеческой глупости.
И костыли тоже пишем, да, а куда же без них, если нет выбора :)

[veter-r-r.livejournal.com]

Так дело ж не в адекватности. А в том, что тот же MySQL уже триста лет как поддерживает все то, в чем его обвиняют. Но те, кто ушел с него лет семь назад из-за отсутствия триггеров, к примеру, так и будут рассказывать, что это недосубд, развиваемая тремя пьяными любителями и даже триггеры она не умеет.
Просто потому что они не следят за продуктом, с которым не работают. Даже если он давно уже принадлежит корпорации Sun и поддерживает и триггеры и транзакции и черта в ступе.

Причем это не только с СУБД такая беда, но и с любым продуктом. Если что-то не понравилось давным давно, то чтобы поменять стереотип в голове на этот счет, много сил понадобится.

[fas-tm.livejournal.com]

+1 Согласен. Хорошо что не вышло тупого холливара :)

[spacediver.livejournal.com]

+1

мысль первична.

[theiced.livejournal.com]

про недосубд тока ораклисты говорят. это вообще специфическая каста долбоёбов.

[veter-r-r.livejournal.com]

Я видел сколько они получают ТАМ. Они таки имеют право считать всех остальных низшей кастой. :))

[theiced.livejournal.com]

высококвалифицированные постгрешники получают больше чем высококвалифицированные ораклисты. вопросы? :)

[a-sure.livejournal.com]

Да, я как раз тот, который 7 лет назад выбрал постгрес, а не мускуль.

И что, от того, что мускуль научился триггерам, целостности и т.д. - мне бросаться переделывать код? Мне делать больше нечего? Или отказываться от наработанных опыта\навыков\кода? А стоит ли оно?

А до саней это была MySQL AB, если ребе забыл. Теперь корпорация SUN принадлежит ОРАКЛ. Да и фиг бы с ней, даже если оракл решит задушить мускуль в пользу 10ХЕ - народ отфоркается и потащит дальше. Дело же не в этом!

Стереотип состоит из двух "половинок" - 1) я вот это попробовал и оно (было) говном (не подошло под задачу) 2)я уже имею успешный опыт решения задач с альтернативным продуктом

Просто вторую часть осознают единицы. Но они обычно вполне адекватны и в высказываниях. Это люде, ребе, просто люди.

[madeveloper.livejournal.com]

Че-то тогда как-то странно... С оракла я слез 7 лет назад, и эти годы занимался и Firebird и MySQL и MSSQL. И постоянно не находил в них чего-то привычного и удобного. Хотя MSSQL значительно подрос, к нему меньше всего вопросов...

[kurilka.livejournal.com]

Корпорации Oracle почти уже :)