Size: a a a

Архитектура ИТ-решений

2021 April 27

GK

Gennadiy Kruglov in Архитектура ИТ-решений
С моей точки зрения, MySQL выбирают тогда, когда опыта в базах нет. В том числе, когда слово репликация не известно (на этапе выбора).

Часто MySQL идёт из коробки с PHP-стеком

Для остального есть Postgre

Если много денег (ярды) и решение действительно большое (десятки и сотни тыров и/или тысячи таблиц), то Оракл - хороший выбор. Всё же Оракл - лидер (де-факто)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Немаловажный фактор при выборе. И да, нужно развивать open source.
источник

S

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Зависит от подходов/бизнес-моделей. Их нужно менять. Разработчики подтянутся

Точнее рынок нужно менять, бизнес-модели подтчнутся
источник

S

Sergey in Архитектура ИТ-решений
не, тут уже к образованию.  Если поглядеть по многим вопросам, то видно что с базой у людей уже плохо. А при таком подходе и запросы тормозить будут и архитектуру не построишь.... В общем, со школы начинать надо :)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Всё это не имеет значения до тех пор, пока самые лёгкие деньги делаются на железе
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
Мне кажется в 90-99% решений при нормальном проектировании можно менять субд на ходу, причём довольно в широких пределах. Оставшиеся крохи реально тяжелых историй зачастую уже давно привязаны к конкретному стеку либо стек выбирается на основе имеющегося ресурса в разработке
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Главный фактор выбора СУБД - это долговременный стабильный SLA от вендора. Когда он тебя не бросит в трудную минуту. У оракл - этот показатель можно назвать эталонным. Аналогичную историю они предоставляют для майсиквел кластера - который является стандартом для всяких хайлоад числогрызок типа билингов платёжек и прочих молотилок.
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
Стабильный вендорлок, ога
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
От ПГ - есть Enterprise DB которая обеспечивает сравнимый SLA
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Ну это да, если клиент экслюзивный (много денег тратит)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Если говорить конструктивно, то конечно использование Оракла может снять ряд болей. Но решение действительно должно быть с большим бюджетом.

При этом, да, вендор лок и санкционные риски
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
при выборе разрабов не спрашивают ))))
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
иногда кстати спрашивают, архитекторов)
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
да , но тут же в TCO косты разработки минимум
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
С моей точки зрения, если нет возможности тратить сотни миллионов деревянных на СУБД + железо под неё, то Оракл лучше не рассматривать в качестве альтернативы
источник

F

Fagor in Архитектура ИТ-решений
сейчас железо дешевле, так что наверное лучше железом? Все равно ЖЦ модели предприятия очень низкий обычно, за 5 лет никто не заглядывает.
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
поэтому лёгший сервис из за апдейта субд - может быть сильно дороже
источник

S

Sergey in Архитектура ИТ-решений
если программист условно пишет 5 вложенных циклов, то железо бессильно
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
рукожопых программистов нужно отсекать статическими анализаторами)))
источник