Как обрабатывать поле «Тип» в БД и приложении?

Question

Необходимо реализовать ведение журнала, сообщения планируется хранить в БД в виде таблицы «log».Среди других полей каждое сообщение будет иметь поле «статус»: 0 - успешно, 1 - неверные данные, 2 - неправильный пользователь, 3 - что угодно, 4 - и т. Д ...

Простая идея - сохранитьПоле «Status» в виде столбца «int» в той же таблице ... Чтобы поместить данные в таблицу, будет создано специальное перечисление, что-то вроде этого (например, давайте используем C # .NET, но любой язык тоже будет работать):

enum LogStatusEnum
{
    Successful=0,
    WrongData=1,
    WrongUser=2,
}
void main()
{
    LogStatusEnum status = LogStatusEnum.Successful;
    int statusValue = (int)status;
    string query = "INSERT INTO log (Status, ...) VALUES ("+statusValue+",...)";
}

Существует также другой подход: создать дополнительную таблицу, что-то вроде «log_status» с полями «StatusId» (int, autoincrement), «StatusCode» (varchar), «StatusDescription» (varchar), которая будет содержатьотдельная запись для каждого поля состояния (с внешним ключом, примененным к обеим таблицам).В этом случае перед добавлением данных в таблицу «log» необходимо заранее получить идентификатор для требуемого «кода» с запросом:

query = "SELECT Id FROM LogStatus WHERE StatusCode='"+GetStatusCode(status)+"'";

, и этот (полученный) идентификатор будет использоваться для заполнения таблицы «log».

В обоих случаях необходимо синхронизировать как сторону БД, так и сторону приложения.Но, с моей точки зрения, 2-й подход немного лучше:

1. более безопасен: вам нужно быть уверенным, что ваш «статус» действительно присутствует в БД, прежде чем добавлять данные, у вас будет ограничение(неправильный статус не будет добавлен).
2. больше управляемых данными (мне трудно сказать, почему это лучше, но я заполняю это).

В порядкеЧтобы получить эти льготы, вам нужно заплатить: выполните запрос в БД, чтобы получить идентификатор статуса по коду состояния.

Считаете ли вы целесообразным внедрение второго подхода?Или 1-й тоже подойдет?Видите ли вы какие-либо другие плюсы второго подхода или минусы первого?

Любые мысли приветствуются.

Заранее спасибо.

Answer 1

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

Если вы делаете много вставок, вам не нужно каждый раз запрашивать идентификатор статуса, а кэшировать его.

Answer 2

Я бы определил коды состояния в базе данных, и я хотел бы, чтобы хотя поле int было в порядке, Char (4) было бы лучше, так как коды будут удобочитаемыми для человека - и - вам следует также укажите описание;

• "OK__", "Операция произошла, как и планировалось" *
• "WUSR", "Неправильный пользователь"
• "WDAT", "Неверные данные "

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

Сделайте описания максимально полезными.Из памяти, в MS SQL Char (4) использует тот же объем пространства, что и int - так что вы не используете дополнительное пространство, используя char.

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

Если вы собираетесь жестко кодировать коды состояния в приложении, я бы предложил, чтобы люди могли получить доступ к кодам безнеобходимость просмотра исходного кода;Документация может ее сократить, но несинхронизировать легко - вам нужен какой-то вызываемый интерфейс (UI, веб-сервис и т. д.), который может легко вызвать любой (например, администратор / администратор БД). Атрибуты являются хорошим способом сделать это.

Для общего ознакомления (или предварительно созданной реализации) я очень настоятельно рекомендую взглянуть на MS Enterprise Libraries ,сюда входит блок ведения журнала, а также репозиторий базы данных.

Answer 3

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

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