Решение схемы MS Access: несколько таблиц или множество нулевых значений?

Question

Я нашел эту ветку, которая несколько помогает моему пониманию, но не отвечает на мой вопрос:

SQL: использование значений NULL и значений по умолчанию

Мой вопрос:Если я создаю схему (в базе данных MS Access), которая предназначена для хранения контактной информации для сотрудников, было бы лучше иметь одну таблицу для телефонных номеров, затем одну таблицу для адресов, а затем еще одну таблицу для адресов электронной почты.ИЛИ было бы лучше иметь одну таблицу, в которой хранятся все эти записи, но могут иметь значения NULL для нескольких полей в более чем половине записей?

Я хотел бы хранить различные элементыадреса улицы в отдельные поля: для адресов: одно поле для номера улицы и названия, одно для города, одно для штата, одно для страны, одно для почтового индекса, а такжеодин для любого другого имени для адреса ("ATTN:" или подобный), и возможно больше; Для телефонных номеров: по существу один для имени и один для номера; Для электронной почты: по существу совпадает с телефоном - имя и номер.Это оставило бы многие значения NULL / Blank в списке для телефонных номеров ... фактически, я бы предположил, что, вероятно, 70% записей будут иметь 5 или более нулевых значений в масштабе от 5000 до 10000 записей.

Я бы хотел иметь возможность отображать их как в отдельных списках, так и в объединенном списке, отфильтрованном и сгруппированном.Любая структура может поддержать это (через предложения JOINS / UNIONS и WHERE).С точки зрения простоты структуры таблицы, один список может показаться очевидным - ОДНА таблица «аккуратнее», чем три или более таблиц.

Ответ, как мне кажется, должен зависеть от эффективности «хранения» потенциально десятков тысяч значений NULL по сравнению с эффективностью индексации различных таблиц и потраченного времени на то, чтобы объединить UNIONс типами данных и созданием различных других методов для объединения данных, которые уже имеют отношение к SOMEWHAT.

Надеюсь, я достаточно ясно изложил свои мысли!Я приветствую ссылки, ответы и комментарии, а также вопросы.

Answer 1

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

Однако, что я обычно вижу, так это желание гибко хранить несколько типов телефонных номеров для каждого человека: дома;Работа;клетка;факс;и т.д. Хранение их в одной таблице (Person_ID, work_phone, home_phone, cell_phone) приводит к хрупкому дизайну.Когда менеджеры говорят вам добавить поле для другого типа телефонного номера, вы вынуждены пересмотреть структуру таблицы, а также запросы, формы и отчеты, которые используют эту таблицу.

Я бы склонился котдельная таблица с отношением один-ко-многим между People и PhoneNumbers --- так, чтобы каждый номер телефона и его тип были отдельной строкой в ​​таблицах PhoneNumbers.Такой дизайн позволяет избежать хрупкости подхода, основанного на едином столе.И это также избавит вас от беспокойства по поводу хранения стольких значений Null - если у человека нет номера телефона, у вас нет номера для этого человека в PhoneNumbers.

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

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

Answer 2

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

Для большинства ваших сотрудников поле Address2 может не понадобиться, но что с того? Я не думаю, что личные адреса электронной почты необходимы, когда кого-то нанимают (будет в CV / Resume и использоваться в процессе собеседования.). 2-3 телефонных номера должны покрывать это.

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