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

[metaclass]

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

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

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

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

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

Comments

[veter-r-r.livejournal.com]

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

[metaclass.livejournal.com]

А проекты с жабой и ораклом света никогда не видят - это в 99% случаев внутренняя автоматизация, бухгалтерия, биллинги, управленческий учет - то что гикам неинтересно, и к чему их не подпускают, во избежание.
И интернет-проекты, как это не смешно, настолько простые и тупые, по сравнению хотя бы с налоговым учетом, например, что неудивительно что их за неделю на mysql и php делают.

[veter-r-r.livejournal.com]

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

А всякая внутренняя автоматизация рано или поздно продается SAP-у со всеми вытекающими. И там гиков действительно нет. Там с обеих сторон только менеджеры.

[metaclass.livejournal.com]

Там, где "отложим" это народ банально бабло отмывает. Я не совсем понимаю механизм, все таки нужно хоть какой-то продукт поиметь в итоге, но изначально задача - отмыть бабло "оттуда".

Понты, понты

[a-sure.livejournal.com]

Говнопроекты такого типа - это почесывание ЧСВ, обычно с ними все понятно после 10 минут разговора с главным архи-тектором. По красноглазости.

[fas-tm.livejournal.com]

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

[metaclass.livejournal.com]

Смешно то, что крупные заказчики с которыми я работал, согласны быть бета-тестерами. Потому что иначе они отдают в 10-100 раз большие деньги сразу, получают условно "работающий" продукт, потом оказывается что его все равно нужно допиливать под требования заказчика, а допилить или невозможно или стоит еще непонятно каких денег.

[fas-tm.livejournal.com]

Тут конечно нужно учитывать нишу применения. Везде свои мухи.
Но на вопрос клиента: "А почему вы вместо, например, бесплатного MySQL/Postgre, юзаете MSSQL", я ответил, что если вы хотите получать такой ответ техподдержки "... эээ, это не наша бага, поройтесь в рассылках MySQL", то мы вам можем устроить. Плюс специфика данного софта - возможность выгружать данные в другие базы. Мы конечно можем наклепать сервисы выгрузки но боюсь это будет дороже чем купить MSSQL.

Искать границы/серебрянные пули/золотое сечение итд... бесполезно. Вменяемость разработчика не измеряется баллами или манной. Выбор той или иной технологии - это тупо опыт и уверенность в своих силах и команде.

[veter-r-r.livejournal.com]

Можно, конечно, устроить холивар на тему, чем копание в рассылках MySQL отличается от копания в рассылках MSSQL.. но не хочется. :)
Поэтому я спрошу, а почему не Оракл? :)

[plumqqz.livejournal.com]

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

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

[metaclass.livejournal.com]

Не, если ACID нас не интересует - мы такие задачи не рассматриваем, пусть ими кто-нибудь другой занимается, у кого нервы покрепче для ответов по телефону на вопросы "а почему у нас тут данные друг другу противоречат" %)

Постгрес надо бы глянуть да, а то у меня объективной информации для сравнения с Firebird нет, а линуксоиды возмущаются что я Firebird использую :)

[plumqqz.livejournal.com]

Не, если ACID нас не интересует - мы такие задачи не рассматриваем, пусть ими кто-нибудь другой занимается, у кого нервы покрепче для ответов по телефону на вопросы "а почему у нас тут данные друг другу противоречат" %)


На самом деле есть прорва задач, где точность "тютелька-в-тютельку" не так уж важна. Ну пролюбили мы учет ста хитов из многих миллионов - ну и хрен с ним, например.

Постгрес надо бы глянуть да, а то у меня объективной информации для сравнения с Firebird нет, а линуксоиды возмущаются что я Firebird использую :)

Ой, только не слушайте фанатиков.

[theiced.livejournal.com]

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

Ну честно - немного практики и он и для "больших задач" будет не менее великолепнейшей вещью. Понимаете - из него вши и тараканы при каждом чихе не вываливаются, всё работает так как написано в ОХУЕННОЙ документации (кто то видел доку лучше чем офф дока по постгре?). Я вообще знаю только одну ситуация где _я_ буду использовать не постгре - когда нужна ембедед база, ну не умеет он (пока?) этого. Да - я заинвэстил ощутимое кол-во времени в изучение, да мне повезло работать с реальными монстрами на проекте с неебическим кол-вом данных. Да - я буду стоить дороже чем аналогичный спец по ораклю, но постгре у меня будет работать как минимум не хуже оракля.

[inhate.livejournal.com]

Слуш, а как там сделать аналог (mysql'ного) SHOW GRANTS FOR username; не прибегая к магическим самописным процедурам?

[plumqqz.livejournal.com]

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

[theiced.livejournal.com]

вы конфиг чуть-чуть менять пробовали? :)

[spacediver.livejournal.com]

Меня в постгресе возбуждает (увы, пока издалека) возможность ембеддить в сервер свои модули на чем попало. Оно вообще зачем-нибудь полезно? :) На первый взгляд, туда можно вкачать бизнес-логику и получить толстый сервер, хорошо интегрированный с СУБД. Профит ли?..

В чем сила постгреса? ;)

[vp.livejournal.com]

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

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

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

[theiced.livejournal.com]

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

По постгре существует сравнимое кол-во спецов. Просто по ораклю существует гиганццкая армия ваннаби дба тушканов. Вы жеж не будете на похапэ пейсать по вот такой же причине?

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

[a-sure.livejournal.com]

Ну, ваши перлы про биллинг я посмотрел. Смеялсо, а как же. Ваша, ребе, беда - Вы все видите только с позиций ойтишнега. Вам трижды пытались объяснить, что есть до бениной мамы секурных ограничений, несоблюдение которых стоит ОЧЕНЬ дорого, но Вы как-то их не хотели заметить.

Чтобы я сказал, как лечить Оракель в приведенной ситуации, Вы сначала докажите (memtest'у после 24часов работы я верю), что к вас не глючит ПАМЯТЬ, диски, в б\п нет выкипевших кондюков. Да, и ОРАКЛ тоже хотя бы с предпоследним патчем.

Где взять патч - на металинке. Как попасть - купить. Нет денег на ОРАКЛ? Вы же не пытаетесь ездить на авто, купить который у Вас нет денег?

И я вообще не пишу.

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

[theiced.livejournal.com]

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

по ораклю - это лет 5-6 назад было. железо полностью меняли, ничего не помогало. раз в 3-4 недели стабильный хуяк. оракель был легальный есессно. саппорт оракля ничего ответить не смог, я с ним месяца три общался. так оно и жило пока не мигрировали на постгре ;)