лучшие практики с кодом или таблиц поиска

Question

[UPDATE] Выбранный подход является ниже, в качестве ответа на этот вопрос

Привет,

Я так долго искали вокруг в этой теме, но я не могу найти что я ищу ...

С таблицами кодов я имею в виду: такие вещи, как «maritial status», пол, конкретные юридические или социальные состояния ... В частности, эти типы имеют только установленные свойства, а элементы не являются скоро изменится (но может). Свойства - это идентификатор, имя и описание.

мне интересно, как справиться с этим лучше всего в следующих технологий: (? Несколько таблиц, одна таблица с различными кодовыми ключами ...)

• в базе

• создания классы (возможно, что-то вроде наследования ICode с ICode.Name и ICode.Description)

• создание представления/презентатора для этого: должен быть экран, содержащий все из них, поэтому список типов (пол, maritial положение дел ...), а затем список значений для этого типа с именем & для каждого элемента в списке значений.

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

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

[ВЫПОЛНЕНИЕ]

Хорошо, я получил хороший ответ на CodeToGlory и Ahsteele. Давайте уточним этот вопрос.

Скажите, что мы не говорим о гендерном или брачном статусе, значения которого определенно не изменятся, а о «материале», который имеет имя и описание, но не более того. Например: Социальные статусы, Правовые статусы.

UI: Я хочу только один экран для этого. Listbox with possiblee NameAndDescription Types (я просто позвоню им), listbox с возможными значениями для выбранного типа NameAndDescription, а затем поля Name и Description для выбранного элемента NameAndDescription Type.

Как это можно обрабатывать в представлении & Ведущие? Я нахожу здесь трудность в том, что тогда имена NameAndDescription должны быть извлечены из имени класса?

DB: Что такое pro/cons для нескольких таблиц с одним или несколькими таблицами?

Answer 1

Я решил пойти с этим подходом:

CodeKeyManager mgr = new CodeKeyManager(); 
CodeKey maritalStatuses = mgr.ReadByCodeName(Code.MaritalStatus); 

Где:

• CodeKeyManager может извлечь CodeKeys из БД (CodeKey = MaritalStatus)
• Код класс заполняется константами, возвращающих строки, поэтому Code.MaritalStatus = "maritalStatus".Эти константы сопоставить с таблицей CodeKey> CodeKeyName
• В базе данных у меня есть 2 таблицы:
  • CodeKey с Id, CodeKeyName
  • CodeValue с CodeKeyId, VALUENAME, ЗначениеОписание

DB:

alt text http://lh3.ggpht.com/_cNmigBr3EkA/SeZnmHcgHZI/AAAAAAAAAFU/2OTzmtMNqFw/codetables_1.JPG

Код класса:

public class Code 
{ 
    public const string Gender = "gender"; 
    public const string MaritalStatus = "maritalStatus"; 
} 

Класс CodeKey:

public class CodeKey 
{ 
    public Guid Id { get; set; } 
    public string CodeName { get; set; } 

    public IList<CodeValue> CodeValues { get; set; } 
} 

Класс CodeValue:

public class CodeValue 
{ 
    public Guid Id { get; set; } 

    public CodeKey Code { get; set; } 

    public string Name { get; set; } 
    public string Description { get; set; } 

} 

Я считаю, на сегодняшний день самый простой и сверхвысоком путь:

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

Единственным, что я все еще Рассматриваемый выбрасывая GUID Id и используя строку (NCHAR) коды для удобства использования в бизнес-логике.

Спасибо за ответы! Если есть какие-либо замечания по этому подходу, сделайте это!

Answer 2

Пара вещей здесь:

1. Используйте Перечисления, которые явно ясны и не изменится. Например, MatStatus, Пол и т. Д.

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

Одна таблица, разумеется (для ссылочной целостности и для их доступности для отчетности).

Для классов снова один раз, потому что, если я пишу метод для получения объекта «Пол», я не хочу, чтобы он случайно мог передать ему «MarritalStatus»! Пусть компилятор поможет вам избавиться от ошибки во время выполнения, поэтому его там. Каждый класс может просто наследовать или содержать класс CodeTable или что-то еще, но это просто помощник реализации.

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

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