Как управлять изменяемыми пользовательскими таблицами поиска

Question

В нашей базе данных есть таблица, которая очень похожа на стандартную таблицу поиска (ID, Description). Тем не менее, этот конкретный не является статичным, клиент хочет возможность добавлять записи на лету. Некоторые записи, которые будут предварительно заполнены, являются «специальными» в том смысле, что будет код, который проверяет их (различные бизнес-правила).

Обычно я создавал бы таблицу без автоматически увеличивающихся идентификаторов, чтобы быть уверенным в том, что перечисление, которое отражает записи в таблице, всегда совпадает. Тогда нужно просто проверить, совпадает ли идентификатор этого объекта со значением перечисления, которое я проверяю.

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

Если я переключусь на использование столбцов идентификаторов, возникнет проблема с синхронизацией значений enum.

Конечно, я всегда могу сопоставить текстовый атрибут «Описание», но это плохо по очевидным причинам.

Есть ли хороший способ справиться с чем-то вроде этого? Этот вопрос на самом деле не отвечает на него.

Answer 1

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

lkpTable
PK Identity
Description
FK LogicEnum NULL

lkpLogic
PK EnumValue
LogicParamColumns

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

Answer 2

Почему бы просто не использовать две таблицы? Одна таблица содержит ваши значения ENUM, для которых вы кодируете. Другой обрабатывает все настраиваемые пользователем элементы.

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

Мы используем подход GUID psuedo enum, поскольку нам необходимо поддерживать несколько копий одной и той же базы данных, и они могут легко выйти из синхронизации. Гиды помогают в этом отношении.

Answer 3

1) Присвойте своему клиенту диапазон, который больше, чем число значений, которое понадобится вашему приложению, например, 1000000. Добавьте триггер, чтобы принудительно разрешать только новые значения выше этого диапазона.

2) Используйте автоинкремент и создайте свои перечисления из локальной копии базы данных.

Answer 4

Если честно, то пахнет одной заботой, обслуживающей два разных требования.

Я бы разделил его на две таблицы, что-то вроде ApplicationLookups и CustomLookups, и тогда было бы интуитивно понятно обрабатывать их по-разному в коде, а также с точки зрения БД.

Answer 5

Опираясь на ответ Митча:

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

CREATE TABLE dbo.Table_1
(
    ID int NOT NULL IDENTITY (1000000, 1),
    Label nvarchar(50) NOT NULL
)  ON [PRIMARY]
GO

SET IDENTITY_INSERT dbo.Table_1 ON
GO

INSERT INTO dbo.Table_1(ID, Label) VALUES (1, 'First');
INSERT INTO dbo.Table_1(ID, Label) VALUES (2, 'Second');