Многие многим отношения
Обычно проверка числа сделана с регулярными выражениями. Этот код определит, является ли что-то числовым, а также проверка на неопределенные переменные относительно не бросают предупреждения:
sub is_integer {
defined $_[0] && $_[0] =~ /^[+-]?\d+$/;
}
sub is_float {
defined $_[0] && $_[0] =~ /^[+-]?\d+(\.\d+)?$/;
}
Вот некоторый материал чтения, на который необходимо посмотреть.
3 ответа
Несмотря на ваши опасения, лучший дизайн БД - это именно то, что вы описали. Другими словами, имейте таблицу сопоставления ManagerCustomerMapping .
Всегда начинайте с 3NF и изменяйте тогда и только тогда, когда есть реальные проблемы с производительностью, которые нельзя решить другими способами.
Если ваш бизнес такой большой, как кажется (со 100 миллионами клиентов), дисковое хранилище не должно быть проблемой, а правильное индексирование таблицы сопоставления должно смягчить любые проблемы с производительностью.
И да, если каждый клиент сопоставляется с двумя разными менеджеров, у вас будет 200 миллионов записей. Это не проблема. В магазинах, в которых я работаю (DB2 на System z), речь идет о таблице среднего размера.
Прелесть SQL в том, что вы можете в большинстве случаев заменить СУБД, если она не работает достаточно хорошо.
Двести миллионов строк из двух столбцов идентификаторов не будут обременительными для средней базы данных, и это лучший способ, особенно , если существует вероятность того, что клиент не будет назначен менеджеру (или наоборот). Любое другое решение, которое пытается поместить идентификатор клиента в таблицу менеджеров (или идентификатор менеджера в таблицу клиентов), в этом случае приведет к потере места.
Ваши цифры весьма интригуют. Сколько клиентов может знать менеджер по работе с клиентами - 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 будет отражать продажи каждого элемента, по общему признанию, большая таблица, но вы бы не вам вообще нужно сопоставлять клиентов с менеджерами, просто выполните поиск в таблице фактов и найдите последнего продавца, который контактировал с клиентом. Почему-то я думаю, что это может быть ближе к бизнес-модели.
Если не секрет, что это за бизнес по отслеживанию базы данных?
Подожди. Вы утверждаете, что ВСЕМ клиентам может быть назначен менеджер? Менеджер может отвечать за сто миллионов клиентов? Честно говоря, это звучит так, будто там что-то не так.
Если у вас простые отношения менеджер <-> с клиентами, как описано, то описанный вами дизайн (таблица связывания «многие-ко-многим») верен. Но если вы действительно хотите иметь возможность связать ВСЕХ клиентов с несколькими менеджерами, я предполагаю, что существует иерархия менеджеров, о которой вы нам не сказали, то есть менеджер может управлять другими менеджерами, которые могут управлять другими менеджерами, которые затем управляют клиентами (с возможностью дополнительных уровней и прямым управлением клиентами, смешанным с управлением менеджерами на любом уровне).