Работа с разнородным контентом

LittleDen

Новичок
Работа с разнородным контентом

Приветствую!

Даже затрудняюсь чётко описать свой вопрос, поэтому попытаюсь проиллюстрировать. Сразу говорю -- пример "от балды", первое, что пришло в голову.

Итак, хочется некую систему, которая (например!) ведёт жизненный путь какого-либо оборудования. Например, компьютерного. То есть, для любой железки в организации есть жизненный путь, подобный такому: Планирование-Поиск поставщика-Выписка счёта-Оплата счёта-Прибытие-Установка-Запуск в работу-Перемещение на другой этаж-Ремонт-Ремонт-Ремонт-Списание.

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

Оплата счёта -- это
а) От какого юрлица оплачивается
б) Когда отдан счёт на оплату
в) Когда реально оплачен
г) Когда деньги поступили продавцу
д) Когда товар приехал на склад продавцу
е) Когда товар отгружен нам

Всё это, повторюсь, приведено для примера. Два момента, на которых хотелось бы заострить внимание:
1. Для каждого из этапов список пунктов одинаков (иначе вообще можно повеситься). То есть, для каждой железяки этап "Планирование" проходит через пункты а-в. Будет ли занесена при этом какая-нибудь инфа в них -- дело десятое.
2. Для каждого из этапов список пунктов -- свой. Впрочем, это видно даже на примере.

На сайте всё подобное видится как список железок, ткнув в одну из них и перебирая по "селектам" (или выпадающий список, это непринципиально) соответствующие этапы, мы видим результаты прохождения железки по пунктам конкретного этапа.

Собственно, вопрос: как с этим работать и как хранить?

Мне пока видится некая XML-структура, запиханная в какое-то поле базы данных. Но как, например, сделать такую выборку: посмотреть, насколько активно некий человек участвует в обсуждении по планированию оборудования? Это ведь надо вытащить всю структуру из каждой записи в базе и сделать поиск уже в ней? Или я вообще не в том направлении думаю?

Посоветуйте, пожалуйста, стратегию. В php не новичок, но до сих пор ограничивался задачами попроще. А с XML так вообще ни разу не работал.
 

Beavis

Banned
LittleDen
ну XML пихать в БД точно не нужно... или просто хранить XML-файлы с этим контентом, или как то под это дело спроектировать БД
 

baev

‹°°¬•
Команда форума
Лично я вообще не понял: нафига тут XML?
 

whirlwind

TDD infected, paranoid
Прежде всего нужно разобраться где коровы а где утюги.

Планирование, Оплата счёта -- это состояние. Если я правильно понял, то субъект (единица оборудования) не может находиться сразу в двух состояниях. Если так, то стоит обратиться к событийной модели где каждое событие будет иметь свое место на временной оси. Итого общие атрибуты

Единица оборудования, событие, время события.

По аналогии с
Будет ли занесена при этом какая-нибудь инфа в них -- дело десятое.
ответ - будет ли сопроводительная информация - дело десятое.

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

На примере задачи

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

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

LittleDen

Новичок
Автор оригинала: baev
Лично я вообще не понял: нафига тут XML?
С благодарностью выслушаю более удобный способ хранения интересующих меня структур.

-~{}~ 13.03.08 15:53:

Автор оригинала: whirlwind
Для каждого вида статистики необходимо заводить отдельную таблицу. Это проще, понятнее и быстрее работает.
Статистика тут -- дело последнее. Намного больше интересует способ хранения таких структур.
 

whirlwind

TDD infected, paranoid
> Статистика тут -- дело последнее. Намного больше интересует способ хранения таких структур.

Вы систему для каких целей проектируете для декоративных? Какая разница, каким способом хранится информация, если ее невозможно использовать для анализа? Ну заведите для каждого оборудования отдельный вордовский документ и пишите там что захотите. Будет практически то же самое что "некая XML-структура, запиханная в какое-то поле базы данных" с тем отличием что вордовский документ читается легче. Ни первое ни второе практически нереально использовать для программного анализа.


А если серьезно, составьте список требований, например:

1. Хочу видеть историю "жизненного пути" оборудования
2. Хочу видеть насколько активно человек участвует в обсуждениях
3 ... и т.п.

Это и есть ваши учетные единицы, которые в свою очередь и есть ничто иное как максимально развернутая статистика.

PS. Наверное самым подходящим советом будет рекомендации прочитать литературу по проектированию БД.
 

LittleDen

Новичок
Требование сформулировано в моём первом письме. Ткнул в оборудование и можно посмотреть интересующие стадии: кто планировал (стадия Планирование), у кого покупали и сколько заплатили (стадия Оплата), когда и куда поставили (стадия Эксплуатация) и так далее. Об аналитике действительно пока речи нет, просто удобный способ просмотра.

Вордовские файлы, кстати, тоже вариант, но их по одному открывать муторно :)
 

baev

‹°°¬•
Команда форума
С благодарностью выслушаю более удобный способ хранения интересующих меня структур.
— Вам whirlwind уже ответил: «самым подходящим советом будет рекомендации прочитать литературу по проектированию БД».

Вообще, всё просто: заводите таблицы под каждую «стадию» и таблицы-«справочники» для понятий, которыми эти стадии характеризуются. Плюс таблица с переченем оборудования.

Для Планирования будет примерно так:
1. Появляется задача «организовать утилизацию бумажных документов в бухгалтерии». Записываем эту задачу в таблицу «Задачи» (где соответствующий набор полей, адекватно описывающий задачу).
2. Поступил вариант решения от сотрудника: выбираем ID сотрудника из таблицы «Сотрудники», выбираем ID задачи из «Задач», пишем их и «Вариант решения» в таблицу «Планирование».
3. Когда решение задачи перейдёт в стадию «Поиск поставщика», во все записи с ID этой задачи в таблице «Планирование» запишем дату этого знаменательного события. А в таблице «Задачи» поменяем значение поля «СТАДИЯ» для этой записи.
4. Когда шреддер реально будет приобретён, во все записи с нашим ID_ЗАДАЧИ запишем в поле ID_ОБОРУДОВАНИЯ этот самый ID из «Перечня оборудования». (Соответственно в «Задачах» задача будет помечена как выполненная.)
 
Сверху