вы говорите.
Но.
Есть реальность. В реальности бизнес-требования и требования функциональные могут появляться не сразу при старте проекта и хороший архитектор должен предвидеть появление таких требований.
Условно.
Если вы проектируете некую систему, где есть движение денег со счета на счет - требование о транзакционности подразумевается. А если вы его не подразумеваете - у вас что-то не то с общим видением архитектуры будущей системы.
Даже черт с ними с транзакциями.
Вы должны подразумевать, что после запуска системы вам представят дядю-аналитика и он потребует ему для OLAP дать доступ к данным. Если вы не подумали об этом и не спросили у заказчика системы - косяк.
А теперь представьте себе ситуацию, которую я не раз уже описывал.
С одной стороны бородатый дядя, Oracle DBA и аналитик, который появляется через месяц и говорит - что блять? какая монга? вы че тут наделали? Вот мой условный Pentaho, и мне надо, чтобы в вашей базе были материализованные вьюхи под него в отдельной схеме.
С другой стороны собственник, который смотрит на тимлида-хипстера и говорит «Ну это же не проблема, не так ли?», после чего хипстер начинает обоссываться - он же монгу выбрал. Причем выбрал не потому, что он ее хорошо знает и умеет готовить, а потому что на ночь прочитал на Хабре статью.
Вопрос - кого из них уволит собственник?
> предвидеть появление таких требований Это почти что не реально, увы. Если не обладать сверхспособностями.
> Какая монга? ... Вот мой условный Pentaho Щяс бы код писать сразу под все конкретные инструменты
Обсуждают сегодня