ведение идентификаторов в базе данных, которые соответствуют перечислениям клиентского программного обеспечения

Question

Допустим, у меня есть таблица в базе данных SQL Server 2000 с именем TransactionType:

CREATE TABLE [dbo].[TransactionType](
    [ID] [int] NOT NULL,
    [Description] [varchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
 CONSTRAINT [PK_TransactionType] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
) ON [PRIMARY]
) ON [PRIMARY]

Затем у меня есть таблица транзакций со столбцом TransactionTypeID, отключенным от столбца ID таблицы TransactionType.

Мое клиентское приложение .net отвечает за вставку записей транзакций и указание типа транзакции. Моей первой мыслью было определение перечисления, приведение перечисления к целому числу и передача этого значения в базу данных. Проблема заключается в том, что потенциально кто-то может зайти в базу данных и изменить один из идентификаторов в таблице TransactionType, делая идентификаторы в базе данных не синхронизированными с идентификаторами в перечислении клиентских приложений.

Итак, после моего многословного объяснения у меня возникает вопрос: существуют ли другие шаблоны / методы проектирования, которые другие используют для борьбы с этой проблемой?

Answer 1

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

ID  | Name
------------
GRN | Green
PURP| Purple
YELL| Yellow
RED | Red

Теперь у вас есть идентификатор, который, если вы отображаете без объединения, очень удобен для человека, и если вам нужно более точное / подробное значение «Имя», вы можете присоединиться к нему или получить его. Очевидно, что когда вы просматриваете родительскую запись (скажем, это фрукт), вам не нужно выполнять соединение. Кроме того, нет веских причин для изменения идентификатора

ID | Name   | Color
-----------------
 1 | Banana | YELL
 2 | Apple  | RED
 3 | Cherry | RED

Имейте в виду, что эту систему не следует использовать, если вы планируете добавлять много дочерних типов, но если у вас будет только дюжина, это может быть хорошим способом. Это также не очень хорошая идея, если вы планируете иметь много «фруктов», потому что CHAR / VARCHAR не эффективный способ ГДЕ ваших данных. Но для 99% баз данных этот метод подойдет.