Таблицы / поля базы данных, которые вы всегда используете в своих приложениях-убийцах

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

Например, я всегда включаю таблицу App_Errors для хранения любой информации о неперехваченных исключениях и таблицу App_Audit, в которой хранится вся информация о редактировании.

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

Чтобы придать вопросу немного больше направленности: в настоящее время я сосредоточен на глобально доступных веб-приложениях (подумайте о социальных сетях).

Ta!


web-applications database-design
person Ash    schedule 29.10.2008    source источник

Ответы (9)


arrow_upward
9
arrow_downward

1 Таблица, содержащая номер версии, чтобы приложение могло легко проверить версию схемы.

2 Таблица для хранения произвольных пар переменная/значение, как файл конфигурации, но в базе данных. (Здесь можно указать номер версии....)

person Corey Trager    schedule 29.10.2008
comment
+1 за пункт 2. Я склонен называть это свойствами. Пункт 1 тоже актуален. - person Draemon; 17.12.2008
comment
Я бы добавил, что произвольная таблица var/val работает даже лучше, чем таблица category/var/val. - person jmucchiello; 20.01.2009
comment
У меня есть таблица с именем schema_version. Каждое обновление базы данных вставляет в эту таблицу номер версии, описание и системную дату. - person WW.; 21.01.2009

arrow_upward
6
arrow_downward

Я часто использовал таблицу журнала аудита, чтобы отслеживать, какие данные были изменены и кем.

Вы будете поражены тем, насколько регулярно это приносит огромную пользу.

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

person Galwegian    schedule 29.10.2008
comment
что вы на самом деле помещаете в журнал аудита? Комментарии, созданные приложением, SQL-запросы или что? - person Draemon; 17.12.2008
comment
@Draemon - для большинства систем, над которыми я работал, было достаточно простой записи о том, кто изменил запись, когда было достаточно - другие требовали, чтобы данные были записаны в том виде, в котором они были до изменения, а другие требовали, чтобы основной оператор SQL использовался для быть записаны. - person Galwegian; 17.12.2008

arrow_upward
2
arrow_downward

Каждая таблица, независимо от того, что она делает, всегда начинается с поля "ID", int.

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

Иногда у меня есть таблица настроек/статистики, но не всегда.

person tsilb    schedule 29.10.2008

arrow_upward
1
arrow_downward

Для отчетности таблица чисел (целые числа от 0 до 1Mil) и таблица статических дат (дней за 30 лет).

person StingyJack    schedule 29.10.2008
comment
Я повторю вопрос выше, почему таблица чисел? Также какую цель обеспечивает таблица статических дат - учитывая, что большинство языков программирования и систем отчетности предоставляют множество функций дат... - person Ash; 29.10.2008
comment
Одно использование: для сообщения о пробелах - например. укажите даты за последние 100 дней, когда не было получено ни одного заказа. - person Tony Andrews; 30.10.2008
comment
@Tony - Именно для этого они мне и нужны. Наличие таблицы чисел/дат позволяет выполнять поиск на основе наборов и позволяет избежать курсоров или повторяющейся логики запросов на уровне приложения. - person StingyJack; 07.11.2008
comment
См. stackoverflow.com/questions/ 418318/ - person WW.; 20.01.2009

arrow_upward
0
arrow_downward

Таблица сообщений об ошибках, в которой есть код ошибки, техническое сообщение, пользовательское сообщение, серьезность и столбцы памятки. Серьезность и пользовательское сообщение используются для создания диалогового окна сообщения при возникновении ошибки. Код ошибки и техническое сообщение включаются в журнал ошибок (вместе с IP-адресом клиента, датой, временем и т. д.) при регистрации ошибки.

person Patrick Cuff    schedule 29.10.2008

arrow_upward
0
arrow_downward

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

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

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

person WW.    schedule 20.01.2009

arrow_upward
0
arrow_downward

Я считаю, что всегда удобно включать следующие поля:

  • Неактивный (или видимый/прекращенный/и т. д.)
  • Неактивная причина

Просто упрощает «обратимое удаление» элементов, поэтому целостность данных сохраняется, и вы не теряете эту ценную историческую информацию.

И +1 за таблицу журнала аудита, о которой упоминал Галвегиан.

person Dhaust    schedule 20.01.2009

arrow_upward
0
arrow_downward

Таблица членства. Бесценный.

person BBetances    schedule 20.01.2009

arrow_upward
0
arrow_downward

Любая таблица, содержащая пользовательские данные (в отличие от ваших системных данных), имеет дату создания и дату последнего обновления. Если есть вероятность 1%, вам может понадобиться знать, когда что-то произошло. Это избавит от многих головных болей в будущем. Хотя мне не нравятся триггеры, их использование для поддержки этих двух полей того стоит. Если вы используете настоящие логины базы данных, то created_user и updated_user также будут полезны.

person jmucchiello    schedule 20.01.2009