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

[metaclass]

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

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

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

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

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

Comments

[veter-r-r.livejournal.com]

И вот же что характерно.
Для говнопроектов, которые может и свет никогда не увидят, выбираются всякие взрослые технологии, вроде Java-фреймворков, в которых каждая аббревиатура расшифровывается другими аббревиатурами и Оракл в максимальной конфигурации, а в это время американские геи в гараже за неделю клепают на пхп и mysql сервис, который взрывает интернет и получают миллиард.
И где справедливость?

[fas-tm.livejournal.com]

>>Но вот где граница...
Граница находиться примерно в точке(+/- вагон), где производство(берем существующий инструмент и хреначим) превращается в исследования(а давайте возьмем вот эту хреновину, допишем вот тут и тут и будет нам профит).
Иначе я не могу представить вменяемого заказчика который отдаст вам деньги чтобы вы сделали из него бета-тестера.
Лучше плохие стандарты чем свои (утрирую, но доля правды есть)

[plumqqz.livejournal.com]

Нормальная СУБД нам нужна в том случае, если нас интересуют принципы ACID. Если они нам все вместе не то, чтобы до фонаря, но не очень тревожат - она нам не нужна.
Другой вопрос, что под СУБД обычно еще и писать просто сильно удобнее, чем все ручками-с.

Но вот где граница
Граница - когда данных слишком много и/или нужна высокая надежность. Для небольших задач (что такое "небольшая задача" - вопрос отдельный) постгрес - великолепнейшая вещь. Чем больше с ним колупаюсь, тем больше он мне нравится.

[alll]

> Но вот где граница - ... - непонятно.

В утешение могу сказать, что "где граница" определить крайне сложно в подавляющем большинстве случаев, какие ни возьми. Замечательная история про "с какого числа начинается куча" из детского мультика - она как раз про это. По этой причине выбор технологий для проектов, чьи ТТХ находятся в районе границы, всегда выглядит волюнтаризмом. И по этой же причине в волюнтаризме нет ничего страшного при таком раскладе. :)

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

[w00dy.livejournal.com]

Мы, например, для свое проекта решение обосновывали наличием опыта, достаточностью технологии и стоимстью (потому что хотим взлететь за свои). Брать что-то потому что это круто считаю верхом идиотизма.

[alex-radko.livejournal.com]

неократно сталкивался с подобными ситуациями только в приложении железа... В одних мега-проектах и собственный канал связи, и непонятно какой процессор, и все это работает на первый взгляд непонятно на каких заклинаниях... В других говнопроектах - за бешенные бабки куплена devepmentboard с софтом и т.п. и на соплях привинчен необходимый функционал, который занимает 1% ресурсов...

Одной из причин, как удалось выяснить - так было проще. Примерно как у нас - надо просто внешний АЦП с софтом. Не вопрос, сделали. Получилось нечто со спичечный коробок размером. - Нет, так нельзя: чтобы оправдать запрошенные деньги, размеры должны быть не меньше чемодана.

Уже можно суммировать

[a-sure.livejournal.com]

Поскольку звучало ентерпрайз и бухгалтерия, то вот ребе Вам мои 5 коп:

Нашей софтине больше 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 писал, что ему посчастливилось поработать с гуру постгреса - я искренне рад за него. Но закладываться на существование ОДНОГО спеца по базовой технологии не стал бы ни за что. А до "заборов", на которым можно почитать много и всяког, что по ораклу, что по постгресу их достаточно. Что указали на факапы - наверное, здорово. Но для меня это больше похоже на изначальное недостаточное знание используемой технологии.