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

Question

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

Есть идеи?

Позвольте мне немного уточнить это

В каждой компании может быть свой сотрудник № 1, № 2 и т. Д. Скажем, у меня есть хранимая процедура, которая возвращает конкретного сотрудника путем передачи идентификатора компании и запрошенного идентификатора сотрудника.

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

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

Answer 1

На основании вашего комментария к 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 является уникальным для компании. Вам нужно будет создать какой-то триггер для создания этого числа.

Answer 2

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

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

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

Это поможет?

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

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

Answer 3

Короткий ответ: вы, вероятно, лаете не на то дерево.

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

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

Answer 4

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

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

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

insert @companyID, max(employeeID)+1 from employees where companyID=@companyID into employee

Answer 5

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

Answer 6

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

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