Согласен с автором. Давно назрело четкое разделение данных на отдельные слои программного уровня и пользовательских данных. Концепция заложенная в 1981 года Э. Ф. Коддом реляционных БД на основе которой был сформированы стандарты SQL, хорошо подходит для организации данных внутри базы данных и ПО, но не работы с бизнес-данными.
В SAP S/4 HANA и других ERP мы не встретим объекты типа яблочки или машинок, о которых рассказывают в учебниках. Но даже те объекты, которые там есть задают жесткость процессов, которые регулярно приходится «натягивать» на бизнес.
В части комментариев правильно задаются вопросом, зачем для аналитиков отдельный слой со своей онтологией и метамоделью. Ответ в том, что им требуются другие правила и инструменты работы с данными. Пользовательские данные могут содержать ошибки консистентности, выбросы и многое другое. С ними нужно работать и стандарты SQL плохо для этого подходят со своей жесткостью. Что не мыслимо для БД и приведет к краху приложения, может и должно сохраняться в пользовательских данных.
Второе. Как правильно замечено, управление структурой пользовательских данных занимается бизнес. Точнее, управленец с помощью аналитиков. Модель управления регулярно меняется, и программисты столько же в этом понимают, сколько управленец в программирование. Они сами решают какие данные им нужны. По моему мнению, в хороших системах класса АСУ Предприятия (ERP и др.) должна быть возможность изменения модели без изменения функциональности ПО. И не только модели, но и данных после таких изменений.
Существующие технологии пока только определяются и формируются (понятно это не ORM :). В любом случае это тренд, пусть и не все его принимают.
P.S. Из интересных фактов. В amazon и ряде других буржуйских компаний, на балансе предприятия ставят бизнес-данные отдельно от ПО.
В моделях управления - да. А структура данных, это дело прикладное.
Согласен с автором. Давно назрело четкое разделение данных на отдельные слои программного уровня и пользовательских данных. Концепция заложенная в 1981 года Э. Ф. Коддом реляционных БД на основе которой был сформированы стандарты SQL, хорошо подходит для организации данных внутри базы данных и ПО, но не работы с бизнес-данными.
В SAP S/4 HANA и других ERP мы не встретим объекты типа яблочки или машинок, о которых рассказывают в учебниках. Но даже те объекты, которые там есть задают жесткость процессов, которые регулярно приходится «натягивать» на бизнес.
В части комментариев правильно задаются вопросом, зачем для аналитиков отдельный слой со своей онтологией и метамоделью. Ответ в том, что им требуются другие правила и инструменты работы с данными. Пользовательские данные могут содержать ошибки консистентности, выбросы и многое другое. С ними нужно работать и стандарты SQL плохо для этого подходят со своей жесткостью. Что не мыслимо для БД и приведет к краху приложения, может и должно сохраняться в пользовательских данных.
Второе. Как правильно замечено, управление структурой пользовательских данных занимается бизнес. Точнее, управленец с помощью аналитиков. Модель управления регулярно меняется, и программисты столько же в этом понимают, сколько управленец в программирование. Они сами решают какие данные им нужны. По моему мнению, в хороших системах класса АСУ Предприятия (ERP и др.) должна быть возможность изменения модели без изменения функциональности ПО. И не только модели, но и данных после таких изменений.
Существующие технологии пока только определяются и формируются (понятно это не ORM :). В любом случае это тренд, пусть и не все его принимают.
P.S. Из интересных фактов. В amazon и ряде других буржуйских компаний, на балансе предприятия ставят бизнес-данные отдельно от ПО.