Проектирование значений поиска

Question

Мне интересно, что протокол находится в вашем магазине разработки или проекте для работы со значениями поиска, такими как страны мира или государства в Соединенных Штатах Америки.

Я видел, как это было сделано двумя разными способами: в одном месте я работал, наши поиски были сохранены в таблице базы данных с префиксом «L_» и имели следующие столбцы: id, code, desc, ordersequence. Так, например, для стран мира мы имеем таблицу, как:

CREATE TABLE L_Countries(

    CountryID INT IDENTITY(1,1) PRIMARY KEY, 

    CountryCode VARCHAR(10) NOT NULL, 

    CountryDesc VARCHAR(50) NOT NULL, 

    OrderSequence INT NULL 

) 

Совсем недавно я видел пример, когда поиски выпекают в Перечисление, например:

enum Countries 
{ 

    Croatia = 1, 

    Slovenia = 2, 

    Serbia = 3, 

    // and so on 

} 

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

Аргумент для первого подхода, который, по общему признанию, я пользуюсь тем, что он довольно гибкий, давая возможность использовать коды или полные описания, манипулировать порядком и вносить изменения без перекомпиляции. Хотя возможность генерировать код из них возможна, большим преимуществом является то, что они остаются истинными «поисками», когда их отбрасывают в базу данных. Наконец, способ, которым они могут быть использованы, является гибким: как значения в коллекции Словаря или генерирует элементы ASP.NET ListItems или html combobox с кодом на стороне сервера.

Аргументы, которые я слышал для последнего, это то, что значения не изменятся и что накладные расходы требуют извлечения значений поиска из базы данных, даже если они кэшируются на уровне приложения. Благодаря жесткому кодированию или генерированию Enum они доступны без штрафа за извлечение базы данных.

Мои вопросы заключаются в следующем:

1. Какой вариант имеет смысл для вас, или, если ваш ответ «это зависит,» Вы можете дать сценарий, где жестко закодированные перечислений лучше, чем поиск в базе данных через всю заявку?

2. Есть ли другие способы, которые вы видели, которые являются элегантным решением для работы с поиском? Я работал над приложением, в котором для всех поисков была одна таблица (в ней был столбец «lookupname»). Как ваш альтернативный подход сравнивается с вышеупомянутыми двумя подходами?

Answer 1

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

Если информация статична, но больше, или если никакая ценность или выразительность не будут предложены, сделав ее перечислением, и она не нужна для объединений и т. д., мы храним ее в XML или хеш-таблице и читаем ее по мере необходимости и/или вставляем ресурс.

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

Надеюсь, что поможет

Answer 2

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

Answer 3

Стандарт ISO для кодов стран - 2 или 3 символа. Стандарт ISO для названий стран составляет 40 символов. ISO также определяет числовые идентификаторы для всех стран.

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