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

Ответ 1

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

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

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

Вы довольно корректны в своем бите выше, хотя для этого требуется более подробная информация. Вы можете представить себе ситуацию, когда предприятие в базе данных (назовите ее Стороной) заключает контракты с другой Стороной, что, в свою очередь, может привести к заключению субподряда. Стороной может быть Сотрудник, Подрядчик или Компания, все подклассы Стороны. По моему мнению, у вас будет таблица Party, а затем более конкретные таблицы для каждого подкласса, которые затем могут быть дополнительно подклассифицированы (Party → Person → Contractor).

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

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

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

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

Ответ 2

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

Плюсы:

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

Минусы:

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

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

Ответ 3

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

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

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

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

Ответ 4

Это обширная тема, я бы рекомендовал прочитать "Книга ресурсов ресурсов модели 3" - "Универсальные шаблоны для моделирования данных" Лен Сильверстона и Пол Агнью.

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

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

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

Ответ 5

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

Ответ 6

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