Каковы принципы и преимущества "модели партии"?

Question

«Модель вечеринки» - это «шаблон» для проектирования реляционных баз данных. По крайней мере, часть этого включает в себя поиск сходства между многими объектами, такими как Заказчик, Сотрудник, Партнер и т. Д., И включение этого в более «абстрактные» таблицы базы данных.

Я бы хотел узнать ваши мысли о следующем:

1. Каковы основные принципы и движущие силы партийной модели?
2. Что он предписывает вам делать с вашей моделью данных? (Мои данные выше довольно высокого уровня и, возможно, в некоторых отношениях некорректны. Я работал над проектом, который использовал его, но я работал с отдельной командой, занимающейся другими вопросами).
3. Что заставило вас испытать к этому ваш опыт? Вы использовали это, и если так, сделаете ли вы это снова? Какие были плюсы и минусы?
4. Модель вечеринки ограничивала ваш выбор ОРМ? Например, вам пришлось исключить определенные ORM, потому что они не учитывали достаточный «уровень абстракции» между вашими объектами домена и вашей физической моделью данных?

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

Спасибо.

Answer 1

1. Каковы основные принципы и движущие силы, стоящие за партией модель

В той степени, в которой я его использовал, в основном речь идет о повторном использовании кода и гибкости. Мы уже использовали его в модели guest / user / admin, и это, безусловно, доказывает свою ценность, когда вам нужно переместить пользователя из одной группы в другую. Распространите это на то, чтобы организации и компании были представлены под пользователями, и это действительно обеспечивает форму абстракции, которая не особенно присуща SQL.

2. Что он предписывает вам делать с вашей моделью данных? (Мой бит выше довольно высокий уровень и вполне возможно неправильно в некоторых отношениях. Я был на проект, который использовал это, но я был работа с отдельной командой, ориентированной по другим вопросам).

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

3. Что заставило вас испытать к этому ваш опыт? Вы использовали это, и если Итак, вы бы сделали это снова? Что были плюсы и минусы?

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

4. Модель вечеринки ограничивала ваш выбор ОРМ? Например, ты должны устранить определенные ORM, потому что они не позволили достаточно "слой абстракции" между вашим доменные объекты и ваши физические данные модель

Это область, в которой я, по общему признанию, немного слаб, но я обнаружил, что использование представлений и зеркальной абстракции на уровне приложений не сделало это слишком большой проблемой. Настоящей проблемой для меня всегда было «где часть данных X живет», когда я хочу читать источник данных напрямую (это также не всегда интуитивно понятно для новых разработчиков системы).

Answer 2

Идея сторонних моделей (так называемая схема сущностей) состоит в том, чтобы определить базу данных, которая использует некоторые преимущества масштабируемости баз данных без схемы. Модель стороны делает это, определяя свои сущности как записи типа стороны, в отличие от одной таблицы на сущность. Результатом является чрезвычайно нормализованная база данных с очень небольшим количеством таблиц и очень небольшим знанием о семантическом значении данных, которые она хранит. Все эти знания распространяются на доступ к данным в коде. Обновления базы данных с использованием модели party минимальны, так как схема никогда не меняется. Это по сути прославленная структура модели данных пары ключ-значение с некоторыми причудливыми именами и парой дополнительных атрибутов.

Плюсы:

• Отличная горизонтальная масштабируемость. Как только ваши 5-6 таблиц определены в вашей модели сущностей, вы можете пойти на пляж и потягивать маргариту. Вы можете виртуально масштабировать эту базу данных настолько, насколько вам нужно, с минимальными усилиями.
• База данных поддерживает любую структуру данных, которую вы ей добавляете. Вы также можете изменять структуры данных и определения сторон / организаций на лету, не затрагивая ваше приложение. Это очень очень мощно.
• Вы можете смоделировать любой произвольный объект данных, добавляя записи, не меняя схему. Это означает, что вы можете попрощаться со скриптами миграции схемы.
• Это рай для программистов, так как код, который они пишут, будет определять действительные сущности, которые они используют в коде, и нет сопоставлений между объектами и таблицами или чем-то подобным. Вы можете думать о таблице Party как о базовом объекте вашего фреймворка (System.Object for .NET)

Минусы:

• Модели партий / сущностей никогда не работают хорошо с ORM, поэтому забудьте об использовании EF или NHibernate для извлечения семантически значимых сущностей из вашей базы данных сущностей.
• Много соединений. Проблемы настройки производительности. Это «против» относится к практикам, которые вы используете для определения своих сущностей, но можно с уверенностью сказать, что вы будете выполнять гораздо больше тех изнурительных запросов, которые ночью принесут вам кошмары.
• Сложнее потреблять. Разработчикам и специалистам по БД, незнакомым с вашим бизнесом, будет сложнее привыкнуть к объектам, представленным этими моделями. Поскольку все абстрактно, нет никакой диаграммы или визуализации, которую вы можете построить поверх своей базы данных, чтобы объяснить, что хранится кому-то еще.
• Потребуются тяжелые модели доступа к данным или механизмы бизнес-правил. По сути, вам нужно понять, какого черта вы хотите получить от своей базы данных в какой-то момент, и ваша модель базы данных не поможет вам в этот раз.

Если вы рассматриваете схему стороны или сущности в реляционной базе данных, вам, вероятно, следует взглянуть на другие решения, такие как хранилище данных NoSql, BigTable или KV Stores. Есть несколько отличных продуктов с массовым развертыванием и поддержкой, таких как MongoDB, DynamoDB и Cassandra, которые стали инициаторами этого движения.

Answer 3

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

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

Это ни к чему не обязывает. И это не останавливает вас ни от чего (я имею в виду любую ошибку). Тот, кто определяет вашу собственную информационную модель - это вы.

У всех сторон много общего. Дело в том, что у них есть имя и тому подобное (мы называли эти "сигнализаторами"). Дело в том, что у них есть основное / основное местоположение, называемое «адресами». Тот факт, что все они, в некотором смысле, вовлечены в контракты бизнеса.

Answer 4

как простой разговор из моего понимания: партийное моделирование дает гибкость и требует больше усилий (например, T-sql join и ...) для реализации.
Я также хочу отметить, что «использование моделирования партии (сериализация / обобщение) дает вам возможность иметь FK-отношение к другим таблицам». Например: представьте себе пользователей разных типов (admin, user, ...), которые обобщены в таблицу User, и вы можете иметь UserID в таблице Authorization.

Answer 5

Это обширная тема, я бы порекомендовал прочитать Книга ресурсов модели данных Том 3 - Универсальные шаблоны для моделирования данных . Автор Len Silverston и Paul Agnew.

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

Существует множество способов моделирования партийных отношений и ролей со всеми их преимуществами и недостатками. Вопрос, который был принят в качестве ответа, охватывает только один случай «партийной модели».

Например, во многих подходах такие понятия, как «Сотрудник», «Руководитель проекта» и т. Д., Являются ролями , которые партия может сыграть в определенном контексте. Я постараюсь дать вам лучшую разбивку, как только вернусь домой.

Answer 6

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