Как к автоинкрементному непервичному ключу? - SQL Server
CREATE TABLE SupplierQuote
(
supplierQuoteID int identity (3504,2) CONSTRAINT supquoteid_pk PRIMARY KEY,
PONumber int identity (9553,20) NOT NULL
.
.
.
CONSTRAINT ponumber_uq UNIQUE(PONumber)
);
Вышеупомянутое ddl производит ошибку:
Сообщение 2744, Уровень 16, состояние 2, Строка 1 Несколько столбцов идентификационных данных указаны для таблицы 'SupplierQuote'. Только один столбец идентификационных данных на таблицу позволяется.
Как я могу решить его? Я хочу, чтобы PONumber был автоувеличен.
5 ответов
В таблице не может быть более одного столбца идентификаторов. Я думаю, что лучше всего было бы вытащить данные PO в отдельную таблицу, а затем связать их со столбцом FK.
SupplierQuote
-------------
supplierQuoteID (PK/identity)
purchaseOrderID (FK to PurchaseOrder.purchaseOrderID)
otherColumn1
PurchaseOrder
-------------
purchaseOrderID (PK/identity)
otherColumn1
Если SupplierQuoteId и PONumber генерируются при вставке строки, то два столбца «идентичности» будут назначены синхронно (3504 идет с 9553, 3506 идет с 9573, 3508 идет с 9593 и т. д.). Если это предположение верно, то вы, вероятно, можете сделать PONumber вычисляемым столбцом, например:
CREATE TABLE SupplierQuote
(
supplierQuoteID int NOT NULL identity (3504,2) CONSTRAINT supquoteid_pk PRIMARY KEY,
PONumber AS (10 * supplierQuoteID - 25487)
.
.
.
);
Я сделал поставщикQuoteId NOT NULL, что гарантирует, что PONumber также будет НЕ NULL. Точно так же вам больше не нужно уникальное ограничение для PONumber, так как оно всегда будет уникальным. (Можно создавать индексы для вычисляемых столбцов, если они нужны для повышения производительности.)
Если для каждой цитаты поставщика существует только один идентификатор заказа на поставку, то почему бы просто не использовать идентификатор предложения поставщика в качестве идентификатора заказа на поставку?
Если может быть более одного, у вас должна быть отдельная таблица с ограничением внешнего ключа. Вы, конечно, можете использовать каскадное удаление для удаления из этой таблицы, но это может быть опасно, если вы удаляете слишком много записей (вызывая блокировки), или лично я не хотел бы удалять предложение поставщика, если был создан номер заказа на поставку, поскольку это означает, что указанный товар был действительно куплен. Вы не хотите когда-либо уничтожать записи о фактически купленных вещах. Поскольку у вас, вероятно, будет несколько POS (я получил расценки на шесть вещей и сначала купил три из них, а на следующей неделе купил еще две) на расценки, и поскольку вполне вероятно, что вы захотите сохранить конкретную информацию о заказе на покупку, я рекомендую отдельную таблицу. Делать что-либо еще в конечном итоге вызовет у вас проблемы.
Вы не можете решить - вы можете иметь только один IDENTITY столбец на таблицу. Обойти это невозможно, извините.
Единственным "хакерским" решением может быть создание отдельной таблицы, в которой будет только поле INT IDENTITY, и захват самого нового значения из этой вспомогательной таблицы в вашу сущность при вставке (например, с помощью триггера). Не очень красиво, но может сработать.
Думаю, я бы использовал триггер, чтобы заполнить «вторую личность».