Рекомендации по поиску таблиц: таблицы БД ... или перечисления

Question

Если нам нужно сохранить имеющиеся вакансии в компании (т. Е. Менеджер, руководитель группы и т. Д.). Каковы лучшие методы для его хранения? У меня есть два мнения с комментариями ... "конечно, приветствую ваше"

1. Сохранение ее в виде таблицы БД с идентификаторами и именами столбцов, а также обработка с помощью запросов и объединений.
2. Сохраните его как Enum и забудьте о таблице БД.

На мой взгляд, я выберу первое решение, если у меня есть изменяющиеся элементы. Так что я не буду жестко кодировать эти параметры как Enum.
Я могу выбрать решение Enum, если не сомневаюсь, что данные не изменятся (например, Пол: Мужской, Женский).

ПРИМЕЧАНИЕ: Я пишу код на английском языке, и культура интерфейса может быть арабской. Если я буду работать с Enum Solution, я буду жестко кодировать строки, основанные на культуре, в уровне представления, это нормально с точки зрения лучших практик !!!!

Я хотел бы узнать ваше мнение, и если мои мысли соответствуют тому, что наиболее рекомендуется "Best Practices" ??

Answer 1

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

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

DomainID int identity
Domain   varchar(255)

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

DomainID int
ID       int identity
Value    varchar(255)

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

Answer 2

Вариант 1: Хранить ее в виде таблицы БД с идентификаторами и именами столбцов и обрабатывать ее с помощью запросов и объединений - это минимум, который вам следует сделать.

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Если да, поместите его в файл и покончите с этим.

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

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

Answer 6

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

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

Answer 7

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

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

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

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

Answer 8

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

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

C # автоматически преобразует перечисления в соответствующие идентификаторы для вас, если список совпадает в таблице и перечислении.

В MVC вы можете использовать выпадающий список с перечислениями как @ Html.EnumDropdownListFor () в представлении, чтобы вам не приходилось нажимать на саму базу данных для выпадающих меню.

Answer 9

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

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