классы моделей в базе данных с моими собственными типами перечислений - PullRequest
0 голосов
/ 04 октября 2009

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

В моем приложении есть перечисления, определяющие несколько разных вещей. Например, GENDER.Male, GENDER.Female. и JOBTYPE.BlueCollar, JOBTYPE.WhiteCollar. и т. д.

У меня есть несколько методов, которые выглядят так: (пример)

FindLifeExpectancy(int age, GENDER gender);
FindDeathRate(int age, JOBTYPE jobType);

Итак, мой вопрос: как вы моделируете перечисления в базе данных? Я не думаю, что лучше всего использовать 0 или 1 в базе данных для хранения JOBTYPE, потому что это было бы бессмысленно для любого, кто на него смотрит. Но если бы вы использовали nvarchar для хранения «BlueCollar», было бы много дублирующих данных.

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

Как это обычно делается?

Спасибо.

Ответы [ 3 ]

1 голос
/ 04 октября 2009

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

Gender
GenderID  Name
1         Male
2         Female

Accounts
AccountID  GenderID  FirstName  LastName
1          1         Andrew     Siemer
2          2         Jessica    Siemer

И в коде я бы определил enum с соответствующим отображением

public enum Gender
{
    Male = 1,
    Female = 2
}

Затем я могу использовать свое перечисление в коде, и когда мне нужно использовать перечисление в запросе LINQ to SQL, я просто получаю его физическое значение, например:

int genderValue = (int)Enum.Parse(typeof(Gender), Gender.Male));

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

0 голосов
/ 04 октября 2009

SQL-эквивалентами 'enums' являются таблицы поиска . Это таблицы с двумя (иногда более) столбцами:

  • код, обычно короткий, числовой или символьный (например, 'R', 'S', 'M' ...)
  • текстовое определение (например: «В отставке», «Студент», «Военный» ...)
  • дополнительные столбцы могут использоваться для хранения определений или альтернативных версий текста, например, короткое сокращение для столбчатых отчетов)

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

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

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

A Конструкция JOIN на уровне SQL - это удобный способ связать справочную таблицу и основную таблицу. Например:

SELECT Name, Dob, M.MaritalStatus
FROM tblCustomers C
LEFT OUTER JOIN tblMaritalLkup M ON C.MStatus = M.Code
WHERE ...
0 голосов
/ 04 октября 2009

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

...