Разработка базы данных компании-сотрудника

Я пытаюсь создать базу данных SQL 2005 с таблицей данных компании и таблицей данных Employee. Каждая компания должна иметь Employee 1, Employee 2 и т. Д. Я понимаю, что у каждой записи Employee будет ПК как их EmployeeID, так и их CompanyID, но я не для жизни меня определил лучший способ сделать это?Разработка базы данных компании-сотрудника

Любые идеи?

Позвольте мне пояснить мне это немного

Каждая компания может иметь свой собственный персонал # 1, # 2, и т.д. Скажем, у меня есть хранимая процедура, которая возвращает конкретного сотрудника, передавая в ИО компании и запрошенный идентификатор сотрудника.

exec dbo.GetEmployee @CompanyID = 1, @EmployeeID = 45

Имея в виду, что компания 1 может иметь сотрудник 1 и 2 Компания может иметь различный Employee 1, как я могу это сделать? Как я могу получить дополнительный первичный ключ для сотрудников, уникальных для каждой компании?

источник

2009-04-01 Dan Appleyard

Можете ли вы объяснить, почему вы не можете просто иметь одну серию номеров сотрудников во всех компаниях? Это упростит ситуацию, и добавленная сложность окажется ненужной. – JohnFx

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

Комментарий Часть 2: Я хочу, чтобы каждый новый аукцион начинался с участника №1 и выше. Если это не так, то может быть, что у нового аукциона есть участники торгов, начинающиеся с 1 000 000. –

Простой ответ: вы не можете.

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

Однако вы не можете иметь приращение идентификатора сотрудника автоматически, а во вставке вам нужно обернуть его в транзакции и сделать что-то вроде

insert @companyID, max(employeeID)+1 from employees where [email protected] into employee

источник

2009-04-01 23:48:10 blowdart

Да, я боялся, что мне придется что-то делать с MAX(). Спасибо, удар. –

Лучше ответить, что НЕ ДОЛЖЕН. Это плохой дизайн, который в конечном итоге вас укусит. – JohnFx

Я согласен с JohnFx. Пожалуйста, не делайте этого в производственном приложении, вы создаете основу для будущих проблем. –

Похоже, что там где-то есть иностранный ключ. Это взаимоотношение между Employee и Company: 1: многие, предполагая, что Сотрудник может работать только для одной Компании за раз. У Employee и Company будет PK, а у Employee будет FK, который ссылается на PK компании.

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

источник

2009-04-01 23:16:17 duffymo

Если ваш вопрос моделирования данных вопрос: с

Если сотрудники могут работать только для одной компании, то вы могли бы иметь CompanyID просто внешний ключ ссылки в таблице Employee, и EmployeeID быть чем-то уникальным для любого (например, SSID).

Если сотрудники могут работать более чем в одной компании, то у вас есть отношения «многие ко многим», для которых потребуется третья таблица, названная «CompanyEmployee», состоящая из CompanyID и EmployeeID.

Это поможет?

ИЛИ, ваш вопрос просто:

«Как сделать соединение первичного ключа в SQL Server»?

источник

2009-04-01 23:20:58 Jamo

+1 для объяснения многих ко многим. – duffymo

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

Если «SSID» означает идентификатор социального обеспечения, я бы посоветовал вам избежать этого. Лучше пойти с суррогатом, сгенерированным ключом. Множество законов, запрещающих использование социального обеспечения # для такого рода вещей. – duffymo

У меня была бы табличка с названием Company Company с основным идентификатором CompanyID, а затем у меня была бы таблица с именем Employee с столбцом первичного ключа EmployeeID и столбцом Foreign Key CompanyID. Конечно, у вас были бы EmployeeName и CompanyName и любые другие соответствующие столбцы для каждой таблицы.

источник

2009-04-01 23:39:06

Основываясь на вашем комментарии к Jamo, вам нужны два идентификатора сотрудника. Тот, который уникален для работодателя и тот, который уникален во всей базе данных. Затем у вас есть следующие таблицы:

Employees 
E_ID NUMBER(9) NOT NULL 
E_NAME 
E_SSID 
etc. 

Companies 
C_ID NUMBER(9) NOT NULL 
C_NAME 
etc. 

Employment 
CE_ID NUMBER(9) NOT NULL 
C_ID NUMBER(9) NOT NULL FOREIGN KEY (Companies.C_ID) 
E_ID NUMBER(9) NOT NULL FOREIGN KEY (Employees.E_ID) 
LOCAL_E_ID NUMBER(9) NOT NULL

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

источник

2009-04-01 23:45:50 jmucchiello

Спасибо, Джо. у вас есть лучшее решение. Назначение LOCAL_E_ID - главная проблема, с которой я имею прямо сейчас ... –

Возможно, вам нужен триггер включения в этот столбец, который выполняет операцию select max (local_e_id) +1 из занятости, где c_id =: new_c_id или что-то в этом роде. Мой синтаксис mssql триггера является ржавым. – jmucchiello

Короткого ответа, что вы, вероятно, ложное дерева ,

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

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

источник

2009-04-01 23:52:03 JohnFx

Разработка базы данных компании-сотрудника

ответ

Смежные вопросы