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

[metaclass]

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

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

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

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

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

Comments

[fas-tm.livejournal.com]

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

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

[veter-r-r.livejournal.com]

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

[fas-tm.livejournal.com]

Я за адекватное применение. Холливаров не получиться.
Oracle не нужен в 90% задач. Зато в тех 10% где он оправдывает себя - он делает это хорошо. По поводу MSSQL vs Postgree vs MySQL. Платформа win-only, зачем скрещивать софт в непотребных позах там где это не нужно ? При этом есть условие, обязательно должен быть нормальный способ выгрузки в MSSQL/Oracle (99% софта в нашей области юзают их, и часто приходиться интегрироваться).
В рассылках MSSQL так же ковырялись, тоже всякое бывало. Принципиально конечно ничем, не отличается, но я не настолько хорош в Postgree чтобы брать на себя ответственность, и иметь бледный вид в случае косяков :)

[theiced.livejournal.com]

>Oracle не нужен в 90% задач. Зато в тех 10% где он оправдывает себя - он делает это хорошо

я в том адовом треде вже писал. оракель нужен ТОЛЬКО в том случае если есть относительно большие (>100GB) объёмы данных и есть только тушкан мега-оракель-дба (ака тупое быдло ничего кроме рутинного обслуживания оракля не умеющая). постгре при больших объёмах всё же требует квалификации, но работает лучше.

Почему лучше:

1. быстрее
2. фичастее (а в оракле нетуть WITH RECURSIVE ня ня ня)
3. предсказуемее
4. можно _быстро_ получить вменяемую поддержку - что платную что на офф канале ирц - там и разработчики тусят и мощные визарды (мне вот в ирц за 15 минут оччччень нетривиальные вещи разжёвывали, брали мои 100меговые дампы и показывали на факапы за час итд - саппорт оракля который может ваш вопрос на пол года отложить тут рядом не срал).

[madeveloper.livejournal.com]

1. Быстрее под какой нагрузкой? На какой технике? Скока пользователей и характер запросов?
2. Нет. Потому что уже давно есть CONNECT BY. Списками фич не советую даже пытаться меряться.
3. Что, и хинты можно руками любые прописывать?
4. Ни разу не приходилось в суппорт обращаться. Зато обучиться можно вполне себе достойно.

[gds.livejournal.com]

4. плохо работаете. У нас стабильно раз в пару месяцев (и вот уже больше пяти лет) возникают вопросы, однако в пустоту, так как саппорта на спижженный оракл не дают (даже левые аккаунты на металинке прикрывают, ироды), открытой информации нет, а гуры разводят руками. В том числе из-за этого думаю смотреть на что-нибудь другое. На постгрес, например. Конечно, не в том проекте уже.

нюню

[a-sure.livejournal.com]

Это мне напоминает историю с моим другом - его начальник пытался учить, как надо обращаться с б\п, считая себя более опытным - как-никак спалил2 штуки! То, что Серж за 10 лет не спалил ни одного, его как-то не убеждало.

Вы хотите сказать, что вопросы у вас НАСТОЛЬКО уникальны, что на них ответа нет даже на sql.ru ??? Пример можно ? (Хоть бы и в ЛС).

А насчет иродов - если у вас из личного авто будут из бака бензин регулярно пиздить, что, замочек не поставите?

Re: нюню

[gds.livejournal.com]

по-моему, у Вас что-то с чувством юмора. Однако мы это проедем, так как ещё чего не хватало. Давайте лучше о хорошем.

вопросы -- например, из недавнего, запрос

select
case when a=0 then 1 else 0 as res1,
case when b>c then 1 else 0 as res2,
case when a=0 and b>c then 1 else 0 as res3
from ...

в некоторых строчках выдавал res1=1, res2=1, res3=0.
Причём стабильно, перегрузка базы не помогала.
Благодаря зоопарку бд мы случайно обнаружили, что вызывает подобное поведение. Но -- зацените всю красоту!

Но это относительно самой базы данных. Радость доставляют также неимоверно кривые oracle forms + reports. Не передать.

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

Re: нюню

[kurilka.livejournal.com]

а что вызывает, если не секрет?

[madeveloper.livejournal.com]

Честно говоря, с Оракла я слез 7 лет назад. На 8.1.7 никаких хлопот небыло. Потом встречи стали эпизодическими ;)

[henu3detb.livejournal.com]

На нынешнем проекте постгрес шуршит на 8 терабайтах, и размер быстро растет. Оракл тоже используется, но только там, где без некоторых его фич просто не смогли обойтись.

[fas-tm.livejournal.com]

Верю. Поэтому дома ковыряю, привыкаю к нему.
Но на комплекс где стоит 100% MSSQL я не буду его ставить.
1. Админов местных надо обучать будет. Если эти лемминги испугаются и оперативно не подымут что то в течение получаса, то за невыход рекламы, на нас через суд повесят пару десятков штук ойро.
2. У нас нет 100Gb баз. 50Gb - да может быть, не больше.
3. У нас нет логики в базе.
4. Не вижу я смысла на Win юзать Postgree, MySQL, Oracle

Это не отменяет того что все остальные DB надо обязательно пощупать и выяснить те самы рамки применимости, о которых вопрошал автор корневого сообщения :)

[theiced.livejournal.com]

4. если у вас виндовз на серверах, то я вам просто сочувствую.

[metaclass.livejournal.com]

В РБ на госконторах виндовса на серверах 90% наверно. Юниксы промышленные - дорого, для линуксов линуксоидов которые бы обслуживали, не найти на ту зарплату и в тех ебенях.

[theiced.livejournal.com]

Ну так делайте дёшево и хреново, кто ж вам мешает ;))

[fas-tm.livejournal.com]

Андрей, спасибо за сочувствие. Но нам честно оно не нужно :)
Виндовый сервер для меня просто инструмент, его требует заказчик и платит деньги, при этом у нас есть отработанный набор инструментов для разработки обкатанные на куче проектов.
Точно так же мы работаем с Linux(для кластерных хранилок StorNext, ExaStore), MacOSX(для NLE станций).
Свои задачи WinServer выполняет. Как только Linux будет иметь инфраструктурные возможности (не просто "это в принципе можно наваять", а будет стандартно это делать) для наших задач и поддержка и сопровождение будет финансово выгодна - вопросов не будет.

[theiced.livejournal.com]

не ну требует заказчик говно - получает говно, вы получаете свои пару копеек, все довольны ;)

[a-sure.livejournal.com]

ребе, а по существу?

Вот работают третий год 5 серверов Вонь2003, Оракл 9.2.0.6.
Я плююсь, конечно, мне до них RDP ходить приходится в соседнюю область. Но проблемы были только с одним - распиздяям одминам моих 3х китайских предупрждений о том, что UPS надо настроить, было мало. Пришлось подключить главбуха.

Остальные 4 проблем за 3 года не вызвали. Может, таки начнем смотреть на задачу в комплексе? Или Вы готовы саппортить пол-россии в одно лицо?

[veter-r-r.livejournal.com]

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

[fas-tm.livejournal.com]

Ничего плохого в этом не вижу, если требуемый функционал и хотелки клиента будут достигнуты в пределах временных рамок проекта и его бюджета :)

[veter-r-r.livejournal.com]

Ну просто потом такой разработчик сам себя убеждает, что его софтина лучше всех прочих софтин и живет с этим убеждением долгие годы. А потом приходит на форум по mysql и разносит там всех, опираясь на убеждения, полученные лет 10 назад. :)
Впрочем, в этом тоже нет ничего плохого. :)

[fas-tm.livejournal.com]

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

[veter-r-r.livejournal.com]

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

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

[fas-tm.livejournal.com]

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

гм...

[a-sure.livejournal.com]

У клиента есть простой выбор:
1) купить (спиздить и потом не жаловаться) ОРАКЛ
2) оплатить на 5 человеколет миграции
3) пойти на йух, или за другим продуктом

Объяснять очередному умнику, начитавшемуся мурзилок, почему ОРАКЛ, никто просто не будет.

Ребе предлагает сделать иначе? Выбрать СУБД, в которой у разработчика (мы ведь тут про ентерпрайз всё ёщё, ага?) нет компетенции?!? И каковы шансы, что оно будет масштабируемо?