Проблемы с проектированием схемы базы данных

Question

Разработчики и разработчики баз данных, привет!

Я проектирую схему базы данных для моего проекта.

Проект включает отношения между «Продюсеры» и «Потребители». Но если «Продюсер» может быть как «Пользователь», так и «Организация», тогда «Потребитель» может быть только «Пользователем» (хотя он только сейчас). Если рассмотреть объектную модель моего проекта, она в основном состоит из двух основных интерфейсов - «Производители» и «Потребители». Отношения будут находиться между экземплярами основных классов, которые являются «Организация» и «Пользователь», а более класс «Организация» реализует интерфейс «Продюсер», а «Пользовательский» реализует интерфейсы «Продюсер» и «Конвейер». Например, на определенный период использования моего приложения некоторые пользователи должны иметь возможность продавать товары другим пользователям и иметь возможность покупать товары у кого-либо.

В будущем я планирую интегрировать наиболее востребованные платежные системы к проекту. Скажите, пожалуйста, если у вас есть опыт работы с платежными системами, как это изменит модель и схему базы данных. Нужно ли добавлять объекты «Юридическое лицо» и «Индивидуальный»?

Я разработал ER-диаграмму в соответствии с описанием выше, но имеет несколько недостатков.

Во-первых, нет полное соответствие между ER-описания и описания UML. Нужно ли выделять отдельные таблицы для интерфейсов? Я не знаю. Действительно, в этом случае, согласно описанию ER, можно сказать, что «Продюсер» и «Потребитель» являются суперклассами «Организация» и «Пользователь». Но на самом деле это только интерфейсы.

Во-вторых, мне нужно самое простое проектирование, чтобы обеспечить доступ к хранилищу достаточно гибким, без лишних «JOIN». Может быть, я должен полностью отказаться от реализации интерфейсов? Но я все использую богатство ООП. Можно ли использовать реализации интерфейсов на уровне базы данных? Я знаю, что наследование может быть использовано. Но я не знаю, как эти трюки будут влиять на производительность - из-за всех предыдущих проектов не требовалось использование суперклассов и интерфейсов. Я буду использовать PostgreSQL в качестве реляционной СУБД.

Просьба поделиться своим опытом и реализацией успешных схем баз данных.

UPDATE

Если я буду назначать роли для таблиц «Producer» и «Потребителем», то я должен буду дать им атрибуты, характеризующие сущностей пользователя "и«Организация». С одной стороны, если количество ролей увеличивается, количество атрибутов увеличивается. Этот путь связан с перегрузкой атрибутов таблиц. И некоторые атрибуты для разных ролей будут соответствовать значениям NULL. С другой стороны, один атрибут для одной роли может соответствовать нескольким атрибутам для другой роли. Например, атрибут «имя» для организации «Организация» соответствует атрибутам «firstname», «middlename», «lastname» и «username» для лица «Пользователь». В-третьих, я все еще хочу отделить модели «Продюсер», «Организация», «Пользователь» и «Потребитель» друг от друга.

Answer 1

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

Так в основном у вас есть таблицы, которые зависят от соответствующих классов. Вы можете просто оставить его открытым, как эта зависимость будет реализована. Некоторые языки программирования предоставляют строительные леса для сопоставления друг с другом. Это удобно и экономит много ввода/дизайна. Конечно, это не очень гибко. Поэтому на основе этого вы должны рассмотреть различные варианты. Было бы необходимо внедрить доступ к базам данных внутри классов и заставить их реализовать интерфейс serializer?

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

Или было бы лучше иметь какой-либо механизм затенения, где вы можете подписаться на то, чтобы ваше состояние сохранялось одновременно?

Итак, для того, чтобы получить решение правильный дизайн вы должны думать о том, как объекты и базы данных связаны друг с другом и насколько сильна эта привязка должна быть. К сожалению, нет серебряной пули.