Компания против дилеммы ID сотрудника

Question

В моей базе данных SQL есть две таблицы:

Компания:

• ID (автоинкремент)
• имя
• адрес
• ...

Сотрудники:

• ID (автоинкремент)
• company_id
• internal_id
• имя
• 1028 * фамилия *

Проблема в том, что я хотел бы иметь идентификатор сотрудника (internal_id), относящийся к компании , к которой они принадлежат. Я получил эту дилемму, потому что я действительно искал, что было бы самым чистым способом реализовать это.

Один из вариантов - просто выбрать SELECT MAX (internal_id) ОТ сотрудников WHERE company_id = X, но проблема заключается в том, что, если мне удастся удалить последнего сотрудника, следующий будет создан с идентификатором следующий.

Есть идеи или предложения?

PD: Причина, по которой я хочу сделать это, заключается в том, что я не хочу, чтобы пользователь из компании X создавал сотрудника, например ID = 2000, тогда как последний сотрудник, созданный в его компании, был, скажем, 1532. Обычно это происходит в системе, в которой Компании Y и Z также создают сотрудников в одной системе. Я хочу, чтобы этот идентификатор не использовался в качестве постороннего ключа, а имел его для внутреннего использования (даже для документов или отчетов).

PD2: в этом случае сотрудникам никогда не придется менять компанию

Answer 1

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

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

Answer 2

Создать отдельную таблицу:

CREATE TABLE t_identity (company INT NOT NULL PRIMARY KEY, id INT NOT NULL)

и выпуск:

INSERT
INTO    t_identity (@company, 1)
ON DUPLICATE KEY UPDATE
SET     id = id + 1

перед вставкой нового сотрудника.

Answer 3

Здесь много вопросов о создании «бизнес» идентификаторов или номеров, которые не связаны с первичными ключами.

В вашем случае я бы создал столбец в таблице компаний "NextEmployeeID". Затем при создании нового сотрудника просто извлекайте значение и увеличивайте его.

Теперь я оставляю вам решать, что случится, если сотрудник сменит компанию. : -)

Answer 4

Я бы лучше создал 3 столбца для 3 переменных и позволил бы Администратору изменять значения в базе данных! 1. КОРОТКИЙ КОД КОМПАНИИ (companyCode, т.е. COMP) 2. КОРОТКИЙ КОДЕКС ОТДЕЛА КОМПАНИИ (код депо, т. Е. DEP) 3. ЗНАЧЕНИЕ СЧЕТА НАЧИНАЮЩЕЙ КОМПАНИИ (то есть 00000) Теперь при добавлении нового сотрудника я бы присоединялся ко всем переменным, каждый раз увеличивал и обновлял compVal ++! (т.е. COMP-DEP-0001) или Мы также можем добавить дату () с идентификатором сотрудника

Answer 5

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

Answer 6

Почему бы не использовать GUID для своих внутренних_идей? Таким образом, вы всегда можете просто вставлять, не опасаясь столкновения ID.

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

Answer 7

Если вы собираетесь использовать идентификатор сотрудника в качестве fk, вы действительно хотите удалить его и всю его работу в БД? Сделайте поле статуса в сотруднике и установите его «А» или «Я» неактивным. Код EmployeeID лучше всего подходит, если он остается уникальным во всех компаниях, так что пусть это будет автоинкремент. Никогда не позволяйте пользователям видеть идентификаторы, пусть они видят только имена.

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

Answer 8

Вы никогда не должны удалять строки из реляционной базы данных. Вы должны уволить этого сотрудника (IE, Set Employee.ActiveFlag = 0)

Так что, если у вас есть internal_id (int) и вы выполняете (SELECT MAX (internal_Id) +1 FROM сотрудников WHERE Company_Id = [parameterCompanyID]), то это будет работать нормально.