ОИ
Size: a a a
2021 July 06
2021 July 07
V
Да, помню такое в банке. Даже нас спрашивали, что мы хотим)
V
Но СА там никаких не было, был БА, стремящийся в архитекты, ему это поручили и он всех опрашивал. Вообще в банке проще, что поручили то и делаешь, без всяких железобетонных границ между функциями.
ГП
С ним всё нормально. Просто если компания является партнёром Oracle, то перед архитектором или кем бы то ни было вопрос выбора СУБД уже не стоит.
С MS SQL немного другая ситуация: там СУБД является частью всей инфраструктуры разработки. Но вопрос выбора у партнёров Microsoft из-за этого тоже обычно не поднимается.
С MS SQL немного другая ситуация: там СУБД является частью всей инфраструктуры разработки. Но вопрос выбора у партнёров Microsoft из-за этого тоже обычно не поднимается.
ГП
Из моей практики: пытались зайти в один банк с продуктом, написанном на стеке Microsoft (MS SQL, C# и т. п.) А у банка всё работает на Oracle. Админы сертифицированы, поддержка, в общем вся команда IT. Пришлось в итоге для них переделывать всё под Oracle.
S
Ну во первых компании разные бывают. Во вторых независимо от степени партнёрства с вендорами имеет смысл разработку начинать на той СУБД, которую лучше знаешь, есть спецы ( естественно с учётом требований заказчика). Универсальных специалистов очень мало, чтобы на чем угодно писал - mssql, oracle или postgresql.
ГП
Раньше, если не выходить за рамки стандартного SQL, можно было адаптироваться под что угодно. :) Надеюсь, это всё ещё так.
ГП
А я не говорю, что это плохо. Это просто иллюстрация тезиса, что выбор СУБД – это часто не техническое решение. С точки зрения разработки оно «политическое» (а на самом деле экономическое).
S
Вот это пожалуйста рассказывайте только начинающим разработчикам 😉 если начинаешь разработку универсального решения с хранением в любой СУБД, значит не будешь использовать каких то специфических вещей, которые есть в каждом. Там даже синтаксис SQL разный везде, в oracle есть аналитические запросы, которые не будут нигде больше работать (это только маленький пример)
V
Еще точнее, смотря где будет решаться) в банках это всегда прежде всего вопрос экономический, плюс вопрос того, что уже есть в наличии. Никто не будет принимать решение исходя из того, что могут и любят айтишники, скорее, новых наберут.
DC
Еще про импортозамещение нужно помнить.
RT
На мой взгляд это и правильно.
СА должны уметь выявлять и фиксировать требования.
Иначе решение непонятно какую задачу решает, есть де-факто какое-то описание, но почему оно так сделано - найти невозможно.
У нас БА это история в основном про просчет финмоделей проектов
СА должны уметь выявлять и фиксировать требования.
Иначе решение непонятно какую задачу решает, есть де-факто какое-то описание, но почему оно так сделано - найти невозможно.
У нас БА это история в основном про просчет финмоделей проектов
ОИ
Но у вас же не фиксируются бизнес-требования и цели?
Помню, что как раз на вопрос "почему?" всегда было сложно найти ответ в документации.
Чистые системные аналитики, которые при необходимости проводят разведку в области БА, но не оставляют артефактов.
БА же порождает артефакты БА, поддерживают их актуальность, структурированность.
Или уже удалось переломить ситуацию?
Помню, что как раз на вопрос "почему?" всегда было сложно найти ответ в документации.
Чистые системные аналитики, которые при необходимости проводят разведку в области БА, но не оставляют артефактов.
БА же порождает артефакты БА, поддерживают их актуальность, структурированность.
Или уже удалось переломить ситуацию?
RT
Я помню даже момент когда вопрос "а почему" вообще вызывал бурю негодования)
Но это все в прошлом.
Но это все в прошлом.
ОИ
О, поздравляю))