Имеются документы с набором информационных полей (информационные карточки), и происходит движение этих документов. В процессе движения производятся действия типа: "отправить письмо в организацию х", "получить ответ от организации y".
К действиям прикрепляются файлы(сканы ,доки, pdf) и хранятся.
И имеются статусы документа: Поступил, Уточнение данных, Принят в обработку, Завершен. В процессе пребывания документа в рамках одного статуса может производится несколько разновидностей действий. Для определенного статуса доступны определенные действия. Нужно реализовать полтора десятка действий.
Чтобы документ можно было перевести в следующий статус нужно совершить набор обязательных действий - отправить письма в ряд организаций и получить от них ответ.
Имеется таблица документов (информационных карточек) которые двигаются, каждому присвоен id. Таблица действий статусов связана с таблицей документов по id.
Фактически в таблицу действий статусов заносятся последовательно все действия со ссылкой на id документа.
Перевод в другой статус тоже является действием. Есть действия которые статус не меняют, а есть такие которые меняют.

Как лучше организовать связь между главной таблицей документов и таблицами статусов , действий?
Можно ли (и нужно ли) хранить действия и статусы в одной таблице?

Еще что смущает сами события и статусы занесены в таблицы в формате текстовых данных на кирилице типа - "Уточнение данных (исходящее)", а не в виде переменных, это не ошибочно, можно так делать?
Или нужно сначала объявить переменные для всех действий в отдельной таблице и подставлять их?
Столбец id в таблице действий это id связанного документа из главной таблицы, а не id действия. Сами id действий не реализованы имеет ли смысл их реализация?

"id""datetime_in""event_what""status_doc""event_docs""user""7""30.11.2011 0:00""Уточнение данных (исходящее)""Уточнение данных""C:\events\Уточнение данных.rtf""Администратор""97""27.11.2011 0:00""Отправлен запрос в организацию 1""Принят в обработку""C:\events\Заявление.doc""Администратор""7""14.12.2011 0:00""Уточнение данных (входящее)""Уточнение данных""C:\events\док3.jpg""Оператор""7""18.12.2011 0:00""Отправлен запрос в организацию 2""Принят в обработку""C:\events\док3.jpg""Оператор""7""11.12.2011 0:00""Завершение""Завершен""Администратор"


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

"Покажи все документы у которых имеется событие "Отправлен запрос в организацию 1" , но отсутствует действие "Получен ответ от организации 1".
"Покажи все документы у которых имеется событие "Отправлен запрос" (куда либо) , но отсутствует действие "Получен ответ
Покажи все документы по которым не отправлены письма в организации 1 и 2.
Для данного документа покажи в какие обязательные организации по нему не отправлены письма.
Для данного документа покажи из каких организаций не получен ответ.
Покажи все дерево переписки по данному документу во временной последовательности.
Покажи все документы в статусе x
В журнале документов в строке данного документа покажи количество исходящих писем в Организацию1 и количество входящих писем от Организации 1.

Может быть нужно все раздробить на переменные типа "Отправлен запрос (исходящее)"- out, "Получен ответ (входящее)" - in
и организации Org_1 , Org_2 итд, но есть еще действия со сменой статуса не являющиеся входящми или исходящими и не связанные с организациями.

SERG1257 1 засунуть прямо в документ и обновлять после действий. Теряется история обновлений статуса.
Я тоже думал чтобы засунуть статусы прямо в документ, так статус будет хранится 1 раз в главной таблице, а так он будет дублироваться в специальном поле впустую в каждом действии, слишком много лишних данных. История обновления статуса не теряется, поскольку само обновление статуса это тоже действие.
SERG1257 3 совместить действия и статусы (как у вас). Это выгодно, если статусы не меняются сами по себе (без действий) А в чем именно выгода? Если такое дублирование данных в поле статус само по себе не критично и это нормальная практика, то я бы оставил.

SERG1257 Длинное сообщение типа "Отправлен запрос в организацию 2" можно разбить на постоянную "Отправлен запрос" и переменную часть "организацию 2". Постоянную часть нормализовать (заменить длинное текстовое сообщение коротким числовым action_id) переменную часть оставить как есть. Скорее всего стоит ввести поле id_Организации
Это нужно будет вводить справочники-таблицы организаций и действий, где те будут привязаны к id ?

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

sergrx Имеет ли значение порядок предприятий которым пересылается документ?
В рамках одного этапа-статуса порядок значения не имеет это параллельные потоки действий.
sergrx Количество предприятий одно и то же?
Количество организаций одно и то же, заранее определенное по схеме работы, но возможно добавление новых организаций.
sergrx Если нет, то от чего зависит, как их узнать? Какие части в б.д. предоставляют эти данные?
Раньше название организаций засовывали прямо в наименование действий, но сейчас выше по тексту предложили, сделать переменной, поэтому наверное понадобится таблица-справочник для них.
sergrx Существует такой "абстрактный документ" и его версии. (т.е ты отсылаешь, его исправляют и возвращают уже другую версию) Сам документ никуда не отсылаю, это информационная карточка, он накапливает данные по ходу движения как снежный ком.
sergrx Как понять что действия успешно завершено?
Например если действий только два, то документ может отсылаться несколько раз (исходящий), а то что он появился во входящиих означает, что это действие над ним закончено?
(или его снова нужно проверить, согласиться с новой версией или нет)
Что делать если действие завершилось не с тем результатом, который бы служил сигналом перехода к следующему действию?
Теперь как понять что Этап закончен? (по количеству завершенных действий или если действия выполняются в последовательности, то по успешному завершению последнего действия)
Нужно отправить письма в x организаций, получить подтверждение об их получении, затем получить ответ. После получения ответа сотрудник по контексту принимает решение о необходимости продолжения переписки или ее завершении.
Если ответ не получен в течении срока x принимается решение о завершении переписки с формулировкой "ответ не получен".
Когда по всем организациям это завершено, сотрудником принимается решение о смене статуса, переходе на следующий этап.

sergrx т.ВерсииДокументов(абстрактный док ID, сами данные)
А как реализовать ревизии документов, общая таблица и там содержатся все варианты документа с одинаковым id , но разными датами ревизий? Там нужно держать данные из всех полей или только те которые поменялись в данной ревизии относительно предыдущей? В нашем случае ревизии нам могут быть нужны только на случай если кто то из сотрудников что то случайно удалит в процессе редактирования или занесет ни то не туда.
sergrx т.ПодДействия(Действия ID, НомерВПоследователностиДействий) Я тоже думал про поддействия.
Не хотелось бы вводить ПОДдействия, чтоб не нагромождать. Хотелось бы держать все действия на одном уровне иерархичности, но с помощью prent_id (как предложили выше) делать их подчиненными к другим действиям. Например после первого действия Отправить запрос в организацию 1, следуют еще получить подтверждение о прочтении и получить ответ, сделать их ссылающимися по parent_id на первы родительский документ.
Спасибо, ваши вопросы навели на мысли и заставили прояснить кое что для себя.

SERG1257 Этот способ организации деревьев имеет свои недостатки. Ваша СУБД может неподдерживать рекурсивный SQL. Посмотрите на статью Деревья в SQL
Сейчас используем MySQL, она не поддерживает рекурсивные запросы, есть рекурсивная функция на PHP, но у нас десктопный клиент и он разрабатывается не на PHP. Здесь затык.
А как называется метод создания иерархии, когда дерево реализуется с помощью разрядов в id:
id title1 категория11 субкатегория111 подсубкатегория

Только если реализовать отдельные таблицы для действий и поддействий, как предлагал выше sergrx :

sergrx т.Действия
т.ПодДействия(Действия ID, НомерВПоследователностиДействий)
или это что то другое типа:
Действия idПоддействия номер1 11 21 32 12 22 3

А почему тогда нельзя таким методом действия и поддействия в одну таблицу засунуть?