«Мастер» ассоциативный стол? - PullRequest
9 голосов
/ 27 ноября 2010

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

В этой модели обычно существует несколько ассоциативных таблиц, например, client_contact, contract_addr, contact_phone, contact_email, service_provider, service_consumer и т. Д.

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

Мне пришло в голову: почему бы не иметь единственную "главную" ассоциативную таблицу, содержащую все ассоциации?Требуется, чтобы эта главная таблица имела «тип связи» в дополнение к двум PK, и чтобы все PK были одного типа (целые, GUID и т. Д.).

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

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

Будем благодарны за любые ссылки, которые вы можете предоставить.

Ответы [ 3 ]

1 голос
/ 30 ноября 2010

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

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

0 голосов
/ 17 июня 2013

Это можно решить с помощью абстракции и наследования таблиц.

Индивидуальный клиент, клиент организации, поставщик услуг - все Стороны, которые играют роли.

Адрес электронной почты, номер телефона, веб-адрес и физический адрес - все адреса.

0 голосов
/ 05 декабря 2010

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

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

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

В-четвертых, вероятный прирост производительности обусловлен предположением, что индекс имеет логарифмическое поведение, и отмечением, что 5log (N) больше, чем log (5N), поэтому лучше использовать один большой индекс, чем 5 меньших,Тем не менее, добавление столбца типа собирается уменьшить это преимущество.Я не совсем уверен, как проанализировать, полностью ли это исключит или просто уменьшит его.

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

Мне было бы интересно посмотреть, какие результаты вы получите, но я был бы удивлен, если есть выигрыш в производительности.

...