Рекомендации по поиску таблиц: таблицы БД... или перечисления
Если мы должны хранить имеющиеся вакансии в компании (например, менеджер, руководитель группы и т. Д.). Каковы лучшие методы для его хранения? У меня есть два мнения с комментариями... "конечно, приветствую ваше"
- Сохранение его в виде таблицы БД с идентификаторами столбцов и именами, и работа с ней с помощью запросов и объединений.
- Храните его как Enum и забудьте о таблице БД.
На мой взгляд, я выберу первое решение, если у меня есть изменяющиеся предметы. Так что я не буду жестко кодировать эти опции как Enum.
Я могу выбрать решение Enum, если не сомневаюсь, что данные не изменятся (например, Пол: Мужской, Женский).
ПРИМЕЧАНИЕ: я пишу код на английском языке, и культура интерфейса может быть арабской. Если я буду работать с Enum Solution, я буду жестко кодировать строки, основанные на культуре, в уровне представления, это нормально с точки зрения лучших практик!!!!
Я хотел бы узнать ваше мнение, и если мои мысли соответствуют тому, что наиболее рекомендуется "Best Practices"??
9 ответов
Обычно перечисление следует использовать только в том случае, если имеется четкий набор элементов, которые не будут меняться, например, основные цвета или названия континентов. В противном случае таблицы поиска с соответствующим образом реализованными внешними ключами всегда являются лучшим вариантом.
Возможна вариация опции таблицы поиска, когда у вас может быть большое количество таблиц поиска для простых отношений идентификатор / значение. Пара домен / таблица поиска может значительно сократить это количество требуемых таблиц, хотя и с некоторой дополнительной сложностью кодирования. В этом случае у вас будет доменная таблица
DomainID int идентичность Домен varchar(255)
и таблица ключ / значение
DomainID int ID внутри личности Значение varchar(255)
Следовательно, в таблицу Домена добавляется строка, соответствующая каждой таблице поиска, которую вы в противном случае использовали бы, и все пары (ключ-домен)/ значение добавляются в таблицу значений. Помимо упрощения структуры базы данных, этот подход также обладает тем преимуществом, что в коде приложения можно динамически создавать "справочные таблицы", что в некоторых приложениях может быть чрезвычайно полезным.
Вариант 1: Хранить ее в виде таблицы БД с идентификаторами и именами столбцов и обрабатывать ее с помощью запросов и объединений - это минимум того, что вы должны сделать.
Из " Пять простых ошибок проектирования баз данных, которых вы должны избегать":
Хотя разработчикам иногда отдают предпочтение целостности, поддерживаемой приложениями, остается верным, что СУБД все еще должна быть централизованным средством обеспечения целостности.
Рекомендуется применять вашу базу данных так, как будто она ничего не знает о пользовательском интерфейсе. То есть база данных должна обеспечивать соблюдение всех правил, касающихся данных; в этом случае база данных должна указывать, какие значения являются подходящими. Чтобы перечислить, какие значения являются подходящими, таблица поиска для каждого типа значения поиска обычно является подходящим способом. Много раз приложения приходят и уходят, но база данных остается и используется повторно.
Если вы хотите применить перечисления в приложении, вы, безусловно, можете это сделать, но что бы вы ни делали, убедитесь, что база данных выполняет свою функцию базы данных и поддерживает целостность данных. Если это неприятно, пройдите через проблему; вы закладываете основу. В " Проектировании базы данных и Пизанской башне" автор подчеркивает, почему правильное создание основы в базе данных так важно.
Надеюсь, это поможет.
Я всегда использую опцию базы данных, так как она имеет несколько преимуществ, одним из основных из которых является то, что вы можете изменять имена / описания элементов в списках поиска без необходимости изменения какого-либо кода. Согласитесь также с наличием одной таблицы, а не множества маленьких таблиц. Таким образом, вы кодируете одну подпрограмму для извлечения значений из базы данных, что сокращает затраты на обслуживание. Наличие единой рутины означает, что вы можете вкладывать больше усилий в ее выполнение.
В дополнение к ответу Кручана, приведенному выше, вы можете использовать одну таблицу, если у вас есть отношения родитель-ребенок, где строки без родителей описывают домен. Все записи, принадлежащие домену, имеют строку домена в качестве родителя.
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
Я склоняюсь к варианту базы данных, поскольку это позволяет легко запрашивать значимые данные (то есть имена, а не идентификаторы).
Если я абсолютно уверен, что значения не изменятся, я перечислю их в приложении, а также это облегчит разработку, когда вам не нужно запоминать идентификатор элемента, а также сделает код более читабельным.
Этот подход позволяет мне выбрать, включать ли таблицу поиска в запросы или нет. Например, я бы включил его в запрос отчета, где я хочу отобразить значение поиска, но не могу включить его при загрузке данных в мое приложение, если вместо этого я могу вывести его из перечисления.
Очевидно, что если значения могут быть изменены, или перечисление изменений может оказаться невозможным.
Только вы можете судить о влиянии культуры пользовательского интерфейса, я на 100% уверен в культуре моих пользователей, так что не стоит слишком беспокоиться об этом:).
Это единственное, что вы планируете включить в список работодателей?
Если да, поместите его в файл и покончите с этим.
БД отличные, но если вам нужен простой ключ-значение, они излишни. Они дают вам много вещей. Но они также делают много вещей за кулисами, это еще одна вещь, которую вам нужно поддерживать... если вы можете обойтись без одного файла с 20 строками, разделенными табуляцией, идите с простотой.
Если у вас есть много вещей, требующих такого рода поисков, или если вы считаете, что вам может понадобиться обновить их, пока клиент пытается их прочитать, или если вы захотите сделать перекрестные ссылки на вещи позже - тогда перейдите к БД.
Поиски, Поиски, Поиски (вставьте видео танца обезьяны здесь)
Моя личная "лучшая практика" - иметь все в базе данных. Позиции в компании, безусловно, таблица соответствия.
То же самое касается переводов, что может быть немного сложнее, но, как правило, определение представления, объединяющее таблицу с таблицей перевода, является хорошим началом.
Кроме того, если Position является только значением типа int, а ваше приложение одноязычное, вы можете добавлять названия позиций непосредственно в базу данных.
Я склонен почти всегда ставить подобные вещи в стол. Если это нужно много, я его кеширую. Если мне понадобится программно сослаться на некоторые из них, я создам перечисление, в котором его значения установлены на значение ключа элемента поиска.
Например, суррогатный первичный ключ (обычно так, чтобы мой уровень доступа к данным мог без труда добавить / обновить его), поле для значения элемента, плюс "кандидат" (кандидат в кавычках, поскольку он не требуется, поэтому он либо уникален или ноль). Таким образом, я могу использовать перечисление в кавычках для ссылки на конкретные / важные элементы в таблице, но при этом могу позволить конечным пользователям добавлять новые элементы. Специфика используемой модели данных действительно зависит от ваших предпочтений (некоторые люди могут кричать на меня прямо сейчас за то, что я не просто использую поле "кандидат" в качестве истинного первичного ключа).
Я вообще предпочитаю оба. Я использую таблицы в слое dal, так как они могут использоваться для таких инструментов, как tableau, для отчетов, SQL-запросов и других целей.
Я использую перечисления во внешнем интерфейсе и на бизнес-уровне, потому что с ними легко разрабатывать, и вам не нужно получать список от dal, а также вы не должны помнить значения из таблицы.
C# автоматически конвертирует перечисления в соответствующий идентификатор для вас, если список совпадает в таблице и перечислении.
В MVC вы можете использовать раскрывающийся список с перечислениями как @Html.EnumDropdownListFor() в представлении, чтобы вам не приходилось нажимать на саму базу данных для раскрывающихся списков.
Если вы можете синхронизировать их, я не думаю, что есть большая причина, чтобы не иметь и то, и другое. Когда я разрабатывал некоторую функциональность конечного автомата с хранилищем БД, мне было намного проще иметь перечисление доступных состояний объекта в моей IDE.
Некоторое время назад я написал небольшую надстройку EnumGenerator для Visual Studio, которая создает фрагмент кода Enumeration в C# из столбцов ID и DESC планшета DB, который вы выбираете прямо в IDE. Я не выпустил его, потому что это был первый раз, когда я работал с VS Addins, и это было довольно нелепо, но держу пари, что кто-то, имеющий опыт создания дополнений / кода, мог бы взять эту идею и работать с ней.