Для хранения людей в MySQL (или любой БД) - несколько таблиц или только одна?

Question

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

Возможно, я перешел за рамки объектно-ориентированного мышления.но теперь я смотрю на создание одной таблицы «Person», которая содержит всех людей, с флагами / подтаблицами, «расширяющими» эту модель, и добавляющими атрибуты на основе ролей в таблицы соединений по мере необходимости.Если мы скажем 250 000 человек (на MySQL и ISAM), это так сильно повлияет на производительность, что будущие администраторы баз данных будут проклинать меня вечно?Наш самый распространенный поиск - по комбинациям имя / фамилия.

Например, такие компании, как Salesforce, представляют собой клиентов / потенциальных клиентов / сотрудников в единой централизованной таблице с вложенными представлениями (если не хватает лучшего термина) илиони разделены на разные таблицы?

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

Answer 1

Стол «один человек» - это самый гибкий, эффективный и безотказный подход.

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

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

create person_type (
   person_id int unsigned,
   person_type_id int unsigned,
   date_started datetime,
   date_ended datetime,
   [ ... ]
)

(Разумеется, вы захотите добавить индексы и внешние ключи. Person_id - это таблица FK для «person»; поля, чтобы вы могли установить, когда кто-то был для вас.)

Answer 2

Поскольку у вас есть много разных «типов» людей, для того, чтобы иметь нормализованный дизайн с надлежащими ограничениями внешнего ключа, лучше использовать шаблон супертип / подтип. Одна таблица Person (с общими для всех атрибутов) и множество таблиц подтипов (Employee, Contractor, Customer и т. Д.), Все в соотношении 1: 1 с основной таблицей Person и с необходимыми данными для каждого человека.

Проверьте этот ответ @Branko для примера: Многие ко многим, но получены из нескольких таблиц

Answer 3

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

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

Это действительно зависит от того, как вы хотите, чтобы слои выглядели и какие компоненты будут получать доступ к каким слоям и как.

Кроме того, я думаю, вы захотите вернуться к выбору MyISAM вместо InnoDB.

Answer 4

Теоретически было бы возможно быть клиентом для компании, в которой вы работаете.

Но если это не так, то вы могли бы хранить людей в разных таблицах в зависимости от ихРоль.

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

И затем иметь столбец для каждой роли (сотрудник, клиент и т. Д.)

Answer 5

250.000 записей для базы данных не очень много. Если вы правильно настроите свои индексы, у вас никогда не возникнет проблем с этим.

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

Этот подход звучит очень хорошо для меня