Креш-тест: многослойная система для крупной финансовой организации

Здравствуйте, Константин.

Запросто, но это будет только мое мнение. Да и вопрос очень абстрактный. В реальном диалоге, я бы ограничился простым «Да, так бывает» и послушал бы дальше :) Но, так как это переписка, смотрите ниже.

Насколько мне известно, ни одна спецификация persistence layer не ограничивает сложность объектов. Так то единственное ограничение, которым следует руководствоваться в данном случае — это физические ограничения используемой RDBMS (например, PostgreSQL поддерживает «всего» 4096 колонок в одной таблице). Так что с точки зрения дизайна, модели с десятками и сотнями свойств — это нормально.

Что касается второй части Вашего вопроса — любая задача специфична для предметной области. Любая. Именно поэтому не существует строгих спецификаций и гарантировано работающих правил создания persistence layer, или SOA, или чего бы то ни было. Вероятно в Вашем случае необходимо сохранять именно такой объем информации именно в такой форме. Это, между прочим, не значит, что заказчик обожает непомерные таблицы, которые очень сложно читать. Уровень представления может очень сильно отличаться от уровня persistence. Это, прежде всего, значит, что заказчик хочет хранить всю эту информацию в одном месте, доступно для редактирования, и просто для резервного копирования.

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

И последнее, что можно с этим сделать. Не зная предметной области, Ваших отношений с заказчиком, степени Вашего влияния на принятие решений, степеней Вашей свободы в изменении архитектуры, кода и дизайна проекта, могу дать только общие советы. Также, я не знаю языка и платформы, на которой Вы работаете, поэтому рекомендации будут опираться на Java + JPA.

1. Попытайтесь проанализировать структуру сущностей. Действительно ли они столь монолитны и неделимы, насколько это реализовано. Все ли эти десятки и сотни полей нужны каждый раз, когда происходит выборка сущности. Если это не так (разумеется, здесь будет сложный разговор с заказчиком) то
1. «лишние» атрибуты имеет смысл разделить на логические группы
2. вынести каждую из групп в отдельную сущность, связанную с основной и помеченной fetch = FetchType.LAZY.
3. таким образом, Вы сможете существенно снизить нагрузку на память и на RDBMS, не потеряв при этом данных, связей и существенно упростив себе жизнь.
2. Если же сущности действительно монолитны и неделимы, то логически сгруппировать поля все равно стоит. Но вместо связных сущностей можно использовать @Embeeded объекты. Этот термин хорошо знаком людям, которые работают с Hibernate, суть такого рефакторинга заключается в том, что большая таблица из RDBMS представляется набором объектов уровня ORM. Физически мы будем иметь единую и неделимую таблицу с огромным количеством полей, логически — иерархию объектов, заполненных данными из этой таблицы.

Из каких-то общих, не специфичных действий, которые можно здесь предпринять — это, пожалуй, два самых эффективных варианта. Любой другой «тюнинг» требует более глубоких знаний системы, ее назначения, вариантов использования и тому подобного.

Резюмируя, могу сказать, что описанная ситуация нормальна. Реализация может быть сделана не самым оптимальным образом, возможно, ее можно улучшить и сделать более читабельной. Но если бизнес-задача решена, то это именно то, зачем вообще разрабатывается ПО. Более того, RDBMS поддерживает большое количество строк и столбцов именно потому, что некоторые задачи требуют именно такой организации данных. Так что все, что можно сделать для улучшения модели — разделить ее логически и, если это необходимо и приемлемо, физически. Насколько сильно, сейчас сказать не могу.

Присылайте свои вопросы через форму — dou.wufoo.com/forms/nnnnn. Ответы — каждый понедельник.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU