Как стать автором
Обновить

Комментарии 6

Сдаётся мне что такой подход к моделированию данных применим только при отсутствии необходимости держать серьёзную нагрузку — там на первое место выходит оптимальная укладка данных на горячих путях с учётом требований к их консистентности, в итоге всё сходится к циклическому процессу "conceptual modelling -> app workflow analysis -> query modelling".

Да, речь идёт в основном про различного рода бизнес-приложения - либо для внутренних пользователей организации, либо для иного ограниченного круга лица. Максимум речь шла о десятках тысяч конкурентных пользователей (на систему в целом) - и такой процесс моделирования данных был эффективен.

Есть речь идет о более высоких нагрузках - вероятно процесс должен как-то видоизмениться. Но как именно - из-за отсутствия собственного практического опыта предметно обсудить затрудняюсь.

Если коллеги из 1С случайно прочитают этот пост, прошу их уточнить в комментариях - есть у них такая сущность как "логическая модель данных приложения" или нет.

1С - это предметно-ориентированное программирование. Так что модель есть. И она именно логическая. Физическая модель отдана на откуп платформе 1С.

Да, вы всё верно написали. Но у меня был вопрос не про приложения созданные на платформе 1С, а про саму платформу, которая поддерживает разные СУБД.

Приложения на платформе 1С понятно что используют абстракции предоставляемые платформой и далеки от конкретной СУБД.

На моей практике неплохо зарекомендовал себя подход, когда аналитик при разработке логической модели сразу пилит эту модель на "куски" и выделяет в отдельные диаграммы: НСИ, например, рисуем отдельно, управление доступом отдельно, и т.д. "Рисование" ведем в общем инструменте типа EA.

Понятно, что, как правило, решения по "физике" принимаются позже и как правило уже архитектором: сколько и каких будет баз, сколько и каких будет сервисов или будет монолит.

В этом случае, рисование "физики" на последующих этапах упрощается: можно на стадии проектирования делать и монолит и микросервисы, можно разделять по разным базам, можно эти "куски" отдавать в разные команды. При этом, "куски" всегда можно склеить в одну физическую модель БД и сгенерить общий DDL.

Интересная статья, но не хватает примеров для каждого варианта: концептуальной модели данных предметной области, логической модели данных предметной области, логической модели данных приложения, физической модели данных приложения. Если дополните, то статья будет иметь еще большую ценность.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории