Closed venomjke closed 11 years ago
Забыл один момент:состояния зависят от типа категории, то есть для категории Жилая-Аренда имеем "Сдал", "Не сдал", "Отказались","Другое"; Жилая-Продажа: "Продал","Не продал","Другое". Помимо этого есть еще один момент: если статус "Сдал", то тогда появляется поле "За сколько", ну или что-то типо того, где человек может указать цену, за которую он сдал.
Предлагаю следующее решение с точки зрения БД. Таблица statuses_orders ( статусы заявок) - таблица в которой будем хранить список статусов: сдал, не сдал, продал и.т.р Таблицы orders_statuses - таблица, в которой будем хранить - id заявки, id статуса, note ( комментарий, за сколько сдал, почему не сдал, как продал и.т.п). Поле комментарий необязательное. Дополнительного id, для хранения записи, думаю, что делать не надо, т.к запись о статусе для одной заявки будет всегда уникальной.
Приложение (backend): В момент создания заявки создаем запись о статусе, и изменяем её каждый раз, когда нам понадобится. Приложение (frontend): Тут мы получаем status_order,status_note, и добавляем их в таблицу. В зависимости от status_order меняем заголовок над status_note.
Иначе другая идея: нет смысла хранить указанную таблицу со списком статусов. Приложение может спокойно на основе входных данных выводить необходимые слова. Подумать над тем, чтобы сделать так: каждая заявка изначально имеет статус, например: 0 - подана 1 - принята на обработку 2 - обрабатывается 3 - сдана (или же в зависимости от модуля выводить необходимое слово) и т.д. ... n - ... То есть каждый модуль в зависимости от категории по своему обрабатывает это входное значение. И комментарий будет один общий, который можно изменять в ходе обработки заявки
Если я тебя правильно понял, то ты предлагаешь сделать следующее: добавить в таблицу orders поле status типа, скажем, INT, и в коде определить массив $statuses = array('сдал'=>0x01,'не сдал'=>0x02 ...и.т.д), правильно? Если так, то тогда отпадает необходимость создавать еще одну таблицу, и это круто. С другой стороны теряется целостность, в том плане, что может возникнуть ситуация при которой в поле окажется неправильное значение, однако даже в таких случаях можно выводить ошибку и фиксировать это в коде.
Да, но только для каждого модуля, т.е.
Жилая аренда 0 - сдал 1 - не сдал 2 - отказались 3 - другое + комментарий
Жилая продажа 0 - продал 1 - не продал .... аналогично
Как может попасть ошибка? В принципе каждое значение будет означать одно и то же, только модуль будет по разному их именовать. Тут уже если и будет ошибка, то только при выборе неверного значения
Ок, я еще уточню, какие могут понадобится статусы, а также могут ли они различаться в зависимости от категории, чтобы не получилось так, что Жилая->Аренда имеет значения (0 - 3), а Коммерческая аренда ( 0 - 5 ).
Я еще с ребятами посоветовался, и мы пришли к следующему, 4 много, достаточно 2-ух, то есть: успех и неуспех. И все. + комментарий. ( успешная, завершенная)
Завершение заявки может подразумевать самые разные причины. Начиная от сдал, не сдал, отказались и.т.д. Для того, что бы эти состояния не пришлось вводить вручную в описание, требуется добавить новое поле.