В MS SQL можно ли делиться семенем идентификации между таблицами? Например, я могу иметь 2 таблицы:MS SQL-идентификатор семени среди таблиц
Таблица: peopleâ
таблицы: PeopleB
Я хотел бы для PeopleA.id и PeopleB.id всегда иметь уникальные значения между собой. То есть Я хочу, чтобы у них было одно и то же семя Identity.
Примечание: Я не хочу слышать о разбиении таблиц, пожалуйста, только о том, можно ли разделить семя через таблицы.
Нет, но я думаю, вы могли бы создать IDENTITY (1, 2) на одном столе и IDENTITY (2, 2) на другом. Однако это не очень надежный дизайн.
Не могли бы вы обратиться к своим сущностям как «A1», «A2», ... если они поступают из таблиц A и «B1», «B2» и т. Д. ... если они поступают из TableB? Тогда невозможно получить дубликаты. Очевидно, вам фактически не нужно хранить A и B в базе данных, как это подразумевается.
Я думаю, когда вы имеют дизайн с таблицами, такими как PeopleA и PeopleB, которым нужно разделить уникальный столбец идентичности, что выполнение этой четной вещи идентичности не будет выдумывать дизайн больше, чем это уже –
Нет, в SQL Server нет ничего, чтобы сделать это.
Очевидно, что существуют обходные пути, такие как использование отношения FK к таблице, которая имеет единую идентификационную информацию и имеющую некоторые причудливые ограничения или триггеры.
Оригинальный ответ
Нет, вы не можете, и если вы хотите сделать это, ваш дизайн почти конечно, недостатки.
Когда я написал это в 2010 году, это было правдой. Однако на данный момент SQL Server теперь имеет последовательности, которые могут делать то, что хочет сделать OP. Хотя это может и не помочь ОП (который, безусловно, давно решил свою проблему), это может помочь кому-то еще сделать то же самое. Я все еще думаю, что желание сделать это обычно является признаком недостатка дизайна, но теперь это возможно из коробки.
+1 ROFL! Думаю, когда-нибудь каждый достигнет своего терпения, столкнувшись с такими вопросами! ;-) –
@Cade Roux: Иногда есть веские причины –
@Net Citizen Конечно, и в этих случаях вам нужно предоставить больше информации о ваших требованиях и движущих силах. –
No.
Но я работал над проектами, в которых использовалась аналогичная концепция. В моем случае у нас был стол под названием [MasterIdentity], который имел одну колонку [Id] (семя идентичности). Ни одна другая таблица в базе данных не имела столбцов с семенем идентификации, и когда Identities требовалось, чтобы функция/хранимая процедура была вызвана, чтобы вставить значение в таблицу [MasterIdentity] и вернуть семя.
Если вам это действительно нужно, создайте третью таблицу PeopleMaster, где существует идентификатор (1,1), чтобы две другие таблицы имели только int FKs для этого значения. Вставьте в PeopleMaster, а затем в PeopleA или PeopleB.
Я бы действительно подумал, что это плохой дизайн. Создайте одну таблицу с флагом PeopleType («A» или «B») и включите все общие столбцы и при необходимости создайте дочерние таблицы (для любых разных столбцов между PeopleA и PeopleB)
Не знаете, какой у вас дизайн, но иногда полезно использовать модель наследования типа, где у вас есть базовая таблица, а затем к югу таблицы с существенно различными атрибутами, например:
Person
------
PersonID <-- PK, autoincrement
FirstName
LastName
Address1
...
Employee
--------
PersonID <-- PK (not autoincrement), FK to Person
JobRoleID
StartDate
Photo
...
Associate
---------
PersonID <-- PK (not autoincrement), FK to Person
AssociateBranchID
EngagementTypeID
...
в этом случае вы вставили бы базовые значения для лица, а затем используйте полученный результат PersonID для вставки в таблицу Employee или Associate.
Я не знаю, возможно ли, что вы спросите, но похоже, что лучше было бы служить как одна таблица, так и код типа, чтобы отличать людей, которые являются a или b ... –
Я должен согласиться с О, МОЙ БОГ. Если таблицы имеют идентичную структуру, то они действительно должны быть только одной таблицей. Читайте о нормализации базы данных. –
Причина заключается в эффективном снижении всей таблицы. Мой фактический сценарий - это не имена людей. –