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

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 # для перечисления. В противном случае кто-то просто тратит время на жесткое кодирование всех записей, предполагая, что значения вряд ли изменятся . Для числовых значений в перечислении они жестко закодированы на основе столбца ID в соответствующей таблице поиска в базе данных, если она существует, или просто закодированы на основе записи, начинающейся с 1.

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

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

У меня следующие вопросы:

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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