От многих до многих отношений

Question

У меня есть клиенты и менеджеры, две таблицы независимо. Таблица моих клиентов имеет почти сто миллионов записей, тогда как таблица менеджеров имеет 100 записей. Теперь я нахожусь в состоянии сопоставить клиентов с менеджером. Правила следующие:

1. Один менеджер может иметь несколько клиентов.
2. Один клиент может отображаться несколькими менеджерами.

Что такое лучший дизайн БД для решения этой проблемы? Создать способный менеджерCustomerMapping - одна из идей. Но я не доволен этим. потому что это привело меня к очень большой таблице. Например. Если Manager1 и Manager2 сопоставляются со всеми клиентами, тогда эта таблица содержит 2 сотни миллионов записей.

Answer 1

Лучший дизайн БД, несмотря на ваши опасения, является именно тем, что вы описали. Другими словами, есть таблица отображения ManagerCustomerMapping.

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

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

И да, если каждый клиент сопоставляет двух разных менеджеров, у вас будет 200 миллионов записей. Это не проблема. В тех магазинах, в которых я работаю (DB2 on System z), речь идет о таблице среднего размера.

Красота SQL заключается в том, что вы можете в основном заменять СУБД, если она не работает достаточно хорошо.

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

Answer 2

Ваши номера довольно интригующие. Сколько клиентов может знать менеджер аккаунта - 100? Сколько у вас менеджеров, 1M? Будет ли продавец лучше описать? Если это так, возможно, вам следует рассмотреть хранилище данных подхода (DW), например Кимбалл звезда будет выглядеть так:

TABLE dimCustomer (KeyCustomer, Name, Address, ...etc) 
TABLE dimSalesPerson (KeySalesPeson, Name, Phone, Area, ...etc) 
TABLE dimProduct (KeyProduct, Description, CatalogPrice, ...etc) 
TABLE dimDate (KeyDate, FullDate, Year, Month, DayOfWeek, IsHoliday, etc...) 
TABLE factSales (KeyCustomer, KeyProduct, KeySalesPerson, KeyDate, Quantity, Ammount, OrderID, ..) 

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

Answer 3

Теперь держись. Вы заявляете, что менеджер может быть назначен всем клиентам? Менеджер может нести ответственность за сто миллионов клиентов? Честно говоря, похоже, что что-то не так.

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

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

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