Разработка SQL - последствия создания нескольких экземпляров одного и того же сотрудника с разными атрибутами - PullRequest
0 голосов
/ 05 февраля 2012

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

Я хотел создать уникальные экземпляры персонала и просто связать их с точками, в которых они работают, чтобы их данные были единообразными по всей базе данных. Однако мой коллега хочет разрешить каждому отделу создавать своих сотрудников. Следствием такого подхода является то, что Джон Смит может быть сотрудником на выходе A, Джонатаном Смитом на выходе B и J Смитом на выходе C (поскольку каждое отделение может вводить почти все, что они хотят). Кроме того, у каждого сотрудника есть набор навыков и услуг, связанных с ними, которые также не будут одинаковыми в разных торговых точках.

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

Ответы [ 3 ]

1 голос
/ 05 февраля 2012

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

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

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

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

1 голос
/ 05 февраля 2012

В дополнение к полезным ответам (которые фактически отвечают на вопрос), вот некоторая полезная информация:

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

РЕДАКТИРОВАТЬ : номера социального страхования США гарантированно будут уникальными и не будут использоваться повторно.Смотрите Q20 здесь: http://www.ssa.gov/history/hfaq.html

РЕДАКТИРОВАТЬ: Нет, они не!D'о!Спасибо Митчу Уиту за эту ссылку: http://www.dailyfinance.com/2010/08/12/your-social-security-number-may-not-be-unique-to-you/ Я полагаю, что задача невозможна, так как нет реального способа решения проблемы ...

0 голосов
/ 05 февраля 2012

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...