Таблицы Lookup Таблицы наилучшей практики: Таблицы DB... или Перечисления

Ответ 1

Как правило, вы должны использовать только перечисление, где есть ясный набор элементов, которые не будут меняться. Мужской/Женский - хороший пример, в противном случае таблицы поиска, с соответствующим образом реализованными внешними ключами, всегда являются лучшим вариантом.

Существует возможная вариация в опции таблицы поиска, где у вас потенциально имеется большое количество таблиц поиска для простых отношений id/value. Пара данных домена/поисковой таблицы может значительно уменьшить это количество требуемых таблиц, хотя и с некоторой дополнительной сложностью кодирования. В этом случае у вас будет таблица доменов

DomainID int identity
Domain   varchar(255)

и таблица ключей/значений

DomainID int
ID       int identity
Value    varchar(255)

Следовательно, строка добавляется в таблицу домена, соответствующую каждой таблице поиска, которую вы в противном случае использовали бы, и все пары (ключ-домен)/значение, добавленные в таблицу значений. Помимо упрощения структуры базы данных, этот подход также имеет то преимущество, что "таблицы поиска" могут быть созданы в коде приложения динамически, что в некоторых приложениях может быть чрезвычайно полезным.

Ответ 2

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

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

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

Очевидно, что если значения могут быть изменены или изменения перечислены, возможно, не удастся.

Только вы можете судить о влиянии культуры пользовательского интерфейса, я на 100% уверен в культуре моих пользователей, поэтому не нужно слишком беспокоиться об этом:).

Ответ 3

Вариант 1: сохранение его в качестве таблицы DB с идентификаторами столбцов и именем и обработкой с использованием запросов и объединений - это минимум, который вы должны сделать.

От " Пять простых ошибок проектирования баз данных, которые следует избегать":

Несмотря на то, что разработчики продолжают применять целостность, обеспечиваемую приложением, остается верным, что СУБД все еще должна быть централизованным исполнителем всей целостности.

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

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

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

Ответ 4

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

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

ID           int autonumber -- integer primary key for performance
DomainID     int            -- null for domains
Name         varchar(100)   -- Name of the item
Description  varchar(255)

Итак, например, список валют может содержать:

 ID    DomainID   Name              Description

 100   NULL       ISO Currencies    List of ISO Currency codes
 101   100        BHD               Bahrain Dinar
 102   100        GBP               British Pound
 103   100        EUR               Euro  
 104   100        USD               US Dollar

Ответ 5

Поиск, поиск, поиск (вставьте здесь видео с участием обезьян)

Моя личная "лучшая практика" заключается в том, чтобы иметь все в базе данных. Позиции в компании, безусловно, являются справочной таблицей.

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

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

Ответ 6

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

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

Ответ 7

Единственное, что вы планируете включить в список этих работодателей?

Если да, отбросьте его в файл и сделайте с ним.

БД великолепны, но если вам нужна простая ключевая ценность, они переполнены. Они дают вам много чего. Но они также делают много вещей за кулисами, это еще одна вещь, которую вам нужно поддерживать... если вы можете уйти с одним файлом с 20 линиями с разделителями табуляции, пойдите с простотой.

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

Ответ 8

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

Я написал себе немного EnumGenerator Visual Studio Addin некоторое время назад, которое создает фрагмент кода Enumeration на С# из столбцов ID и DESC таблицы DB, которую вы выбираете справа в среде IDE. Я не выпустил его, потому что это был первый раз, когда я работал с VS Addins, и это было довольно неприятно, но я уверен, что кто-то с опытом добавления/генерации кода может принять идею и запустить ее.