Хорошо ли хранить статические данные в db - C #?

Question

У меня есть эта проблема, и я не знаю, какое решение лучше для нее.

У меня есть таблица с именем Employees, и есть столбец с именем LastWork, в этом столбце должны быть только пользовательские значения, которые я выбираю, например:

value 1
value 2

, и я хочу, чтобы пользователь выбрал значение из элемента управления ComboBox, поэтому у меня есть 2 идеи для него, но я не знаю, что лучше для него.

A -добавьте эти значения в Combobox как строку в свойстве Items и сохраните их как строку в БД.

B - создайте отдельную таблицу в моей базе данных с именем, например, «LastWork» с 2 столбцами «LastWorkID», «LastWorkName» и вставьтемои значения в нем, а затем я могу добавить контроль источника привязки, и я могу использовать связанные с данными элементы, чтобы сохранить идентификатор как целое число в моей главной таблице и показать LastWorkName для пользователей.

Я предпочитаю использовать метод Bпотому что в некоторых формах у меня есть элемент управления DataGridView с правами на редактирование, и я хочу отобразить в нем Combobox вместо Textbox для выбора из этих пользовательских значений.

Я надеюсь,Вы поняли мои вопросы.

Answer 1

Обычно нормализация данных - это хорошая вещь, поэтому я бы тоже остановился на вашем варианте B.

Имея отдельную таблицу и отношение к ней внешнего ключа, вы можете обеспечить целостность данных;легко получить список всех доступных (не только всех выбранных) опций;иметь единственное место, в котором можно изменить текст опции (например, что если кто-то решит назвать его «значение один» вместо «значение 1»?);и т. д. и т. п.

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

Answer 2

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

Answer 3

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

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