![[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, покупаем страшный софт за бешеные бабки и считаем что мы круты" - непонятно. Исключая, конечно, момент откатов за софт, тогда второй случай безальтернативен.
no subject
Для говнопроектов, которые может и свет никогда не увидят, выбираются всякие взрослые технологии, вроде Java-фреймворков, в которых каждая аббревиатура расшифровывается другими аббревиатурами и Оракл в максимальной конфигурации, а в это время американские геи в гараже за неделю клепают на пхп и mysql сервис, который взрывает интернет и получают миллиард.
И где справедливость?
no subject
И интернет-проекты, как это не смешно, настолько простые и тупые, по сравнению хотя бы с налоговым учетом, например, что неудивительно что их за неделю на mysql и php делают.
no subject
Те же интернет-проекты. Только с огромными бюджетами. И где-то после двух-трех циклов разработки, когда уже пару человеко-лет вложено и вот-вот продукт должен стать похож на работающий заказчик говорит "ладно, пока отложим". И больше про него никто не вспоминает.
А всякая внутренняя автоматизация рано или поздно продается SAP-у со всеми вытекающими. И там гиков действительно нет. Там с обеих сторон только менеджеры.
no subject
no subject
1. Доводилось ли Вам автоматизировать Настоящий Кровавый Энтерпрайз, а не эту вашу белорусскую песочницу?
2. Лично Вы получали, передавали, или являлись свидетелем передачи "отмытого бабла" и "откатов"?
3. Если ответ на оба пункта выше - "нет", то сидите и не отсвечивайте, пожалуйста.
no subject
1. система учёта мексов и прочих маргиналов для нью-йоркской муниципалки со всеми вытекающими рассчётками сойдёт за чуть-чуть кровоточащий энтерпрайзик? ;] ну не то что бы единолично писал, так, говнокодил в сторонке, но всё же.
2. довелось, как раз оракель-в-полной-комплектации. ещё из первых рук слышал про сап, из результатов видел уютный домик в пределах мкада в минске :) но тут насколько правда судить не берусь.
вот возьмём кстати ваш газпром (или как там его). ну вот не поверю что контора, ведущая один из трёх источников дохода рашки (а шо - газ, нефть, лес - чем ещё рашка зарабатывает) ведёт дела чэсна, без откатов :)
no subject
no subject
no subject
2. OeBS вообще странная система. на ней стоит клеймо Связьинвеста, а там воруют-с.
и это. сравнения с газпромом/и железкой не канают. там требуется немножко другой результат, нежели повышение эффективности управления через автоматизацию. вон ЖыДы купили сорок (!) мейнфреймов, а они у них тупо стоят третий год. зато освоено.
no subject
no subject
Для меня кровавый ентерпрайз начинается с постановки вопроса когда за остановку системы поставят раком и система через себя желательно так или иначе или учитывает/считает много баблоса, или же управляет технологией, которая этот баблос производит в виде продукции. Но так или иначе все критическое в плане надежности.
no subject
По всем признакам - ФСК, т.е. транспорт электроэнергии.
Плюс у него в записках есть еще примеры - тот же транспорт газа.
no subject
Более интересует нижний порог :)
no subject
Так пойдет?
no subject
Кровавый или нет?
no subject
А кровавее - это управление технологическим процессом на производстве, когда мы вообще физически конвеер не имеем право остановить, убытки сразу по 10k$ в минуту будут или выше.
no subject
no subject
no subject
Насчет энтерпрайза - "со свечкой не стоял", но у людей с крупным ентерпрайзом нихера не работает, а они используют 1С или заказывают софт у нас. Не знаю, откаты там или просто тупицы экономят деньги на внедрении, но результат налицо.
no subject
Называется "антропный принцип". Те, у кого всё просто работает, молчат и никуда не обращаются.
На МАЗе в некоторых финансовых отделах работает Оракл (возможно, с моими программами :) ). На бел.бирже он есть.
From: udpn
(Anonymous) 2009-12-03 04:56 pm (UTC)(link)no subject
что касается энтерпрайза. я помимо нас, могу назвать еще с десяток энтерпрайзов, годовой оборот каждого из которых больше чем ВВП Беларуси, где основная платформа автоматизации - SAP, и все прекрасно работает.
а почему иногда проекты, несмотря на солидные вложения, "не работают" - здесь разгадку нужно искать у бизнеса. то есть, у заказчиков. я неоднократно наблюдал за судьбой некоторых систем. автоматизировали-автоматизировали, а тут бац! и сменились бизнес-приоритеты. или автоматизируемые функции передали от одного бизнес-подразделения другому. а у другого бизнес-подразделения свое видение и свои системы. это неизбежные издержки в гиганских конторах.
no subject
Да вот нифига. в США венчурные капиталисты просто вкладывают 10 раз по миллиону в стартапы, 9 раз теряют деньги, а 1 раз получают взрыв интернета и суммарный плюс. Я сам наблюдал невыстреливший такой стартап с очень близкого расстояния — к концу денег продукт был всё ещё УГ, ну они и самораспустились, у инвестора претензий нет (таковы условия игры), люди вовсе не на феррари ездят (из стратапа), просто пару лет получали нормальную в отрасли ЗП и при этом делали то, что им было интересно.
Понты, понты