От многих до многих

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

  • У одного менеджера может быть несколько клиентов.
  • Один клиент может отображаться несколькими менеджерами.

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

3 ответа

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

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

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

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

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

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


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

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

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

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


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

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 будет отображать продажи каждого элемента, правда, большой таблицы, но вам не нужно будет вообще сопоставлять клиентов с менеджерами, просто искать таблицу фактов и находить последнего продавца, который имел контакт с клиентом. Как-то я думаю, что это может быть ближе к бизнес-модели. Если это не секрет, какой бизнес это отслеживание базы данных?

licensed under cc by-sa 3.0 with attribution.