Рекомендации по работе с базами данных - Статус

Я создаю приложение, в котором объекты имеют статус поиска. Чтобы дать некоторый контекст, давайте рассмотрим следующий пример.Рекомендации по работе с базами данных - Статус

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

Новый - Работа создана, но неназначенную
In Progress - Работа назначается работнику и в ходе
Завершить - Работа готовая к выставлению счетов
Закрыт - - Счет выставлен на обслуживание

Итак, я создаю таблицу состояния со следующими данными:

INT ID
строка Имя

и столбец поиска по таблице заданий

int ID
строка Имя
INT CustomerID
INT StatusID -> выглядит статус-

Таким образом, в реальном мире, скажем, у нас есть следующие требования.

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

Так с этим в виду, мои первые мысли, чтобы создать новый столбец в таблице состояния называется SortOrder или аналогичный и назначить номера ему такие как

Новый - 10
In Progress - 20
Завершена - 30
Закрытая - 40

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

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

источник

2012-03-29 the-a-train

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

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

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

Что мы делаем, это одна таблица состояния и таблица состояния группы компаньонов.

create table status_group (
    id integer primary key not null, 
    alias varchar(20) not null, 
    descr varchar(128) 
) 

create table status (
    id integer primary key not null, 
    status_group_id integer, 
    alias varchar(20) not null, 
    descr varchar(128) 
)

Затем все статусы живут в одном месте, но группируются вместе с наличием миллионных индивидуальных.

источник

2012-03-29 05:01:57

Спасибо за ответ, я не совсем понял. Как это будет использоваться в моем случае? –

Рекомендации по работе с базами данных - Статус

ответ

Смежные вопросы