Органайзер (или как воевать с заказчиком)

[Sat]

Органайзер (или как воевать с заказчиком)

Заказали мне маленькую работку. Написать органайзер для сайта. Вот там в одном месте есть просмотр задач в одной категории. Всего количество категорий не оговорено. Подразумевается динамическое добавление. Мне интересно как можно это реализовать, если заказчик (он-же дал шаблоны на ХТМЛ) хочет, чтоб для каждой категории задач реализовывалась своя таблица(т.е. он привёл в шаблонах для пример десяток категорий). Причём таблицы отличаются и по смыслу и по количеству полей.
Попробовать сделать это при помощи шаблонов, хранящихся в базе данных и связанных с таблицей категорий задач? Но такая реализация не проходит в то количество денег которые предлагает заказчик.
Цель вопроса: Как попроще можно реализовать такую конструкцию?

 

[zahhar]

Может быть я где-то недопонял о чем речь, но предложу такой вариант: категории описываются в каком-нибудь удобоваримом, простом и распространенном формате (например - XML). Ваш скрипт на основе описания категории строит (изменяет) таблицы и генерирует формы ввода/таблицы вывода. Тут, конечно, придётся пожертвовать красивостями оформления и принципом о неизменности структуры БД в процессе жизни приложения, но задача будет решена.

Второй вариант - создать универсальную структуру БД и механизм добавления новых категорий через веб-интерфейс. Новая категория не будет физически порождать новые таблицы в БД, она будет только хранить пары ключ:значения, причем у каждой категории может быть произвольное значение ключей. Таким образом можно реализовать правила для значений и вся остальную требуху СУБД. Если заказчик может изготавлять шаблоны для каждой категории - флаг ему в руки, пусть включает в эти шаблоны ключи, а движок шаблонов (да хоть тот же СМАРТИ возьмите) будет заполнять их значениями для нужного ключа нуджной категории из универсальной таблицы.

Не знаю уж насколько понятно я изложил и пройдут ли эти реализации по вашему бюджету...

 

[Sat]

Спасибо. Но там есть проблема про которую я забыл упомянуть. Данные которые выводятся в HTML таблицу, могут собираться из разных таблиц СУБД.
Т.е. если бы все данные которые мне надо вывести лежали в одной таблице, было бы легко. Если бы они лежали только в таблицах СУБД, было бы сложнее но выполнимо. А так данные могут получаться из письма (Вся связка идёт как раз с почтовым ящиком.) могут генерироваться динамически (типа сегодняшей даты). Т.е. абсолютно разнообразные источники.
Вариантов решения много. Но ни один из них меня не устраивает.
Наиболее приемлемыми являются:
1. Сделать таблицу с 3-мя полями:
а) Источник данных(письмо, СУБД, или PHP код).
б) Название в ХТМЛ таблице.
в) Зависимый от источника текст(ID письма, таблица+поле СУБД, ну или сам по себе ПХП код).

2. Попытаться всё переносить в СУБД, и уже определяться только по ней. Но получается избыточность данных.

3. Попытаться объяснить заказчику, что такая реализация будет стоить много денег

 

[zahhar]

Лучше всего третье. И искать пути более элегантного решения.

 

[Screjet]

По моемому ничего общего с органайзером. Если в первом посте действительно нечто было похоже на органайзер, то во втором очень мало осталось от такового.

Обобщи проблему.

 

[Sat]

обобщаю:
прблизительно дерево навигации по заданиям такое
->категория задач
-->список задач в категории
--->Детальный просмотр задачи. Пометка как выполнено и т.д.

Вот основная закгвоздка во 2-м пункте. В каждой категории абсолютно разные (как по структуре, так и по источникам данных) таблицы, в которых и выводится список задач. Источниками данных могут быть:
1. Различные таблицы БД.
2. Текст письма(email) или какая-либо другая его часть (заголовок, поле From и т.д.).
3. Результат работы какого-либо скрипта PHP
4. Данные введённые пользователем вручную (например комментарии к задаче).

Примеры:
а) Категория "Контакт"
структура таблицы:
- ID задачи (не знаю зачем, но заказчик хочет), текст этого поля является ссылкой на детальный просмотр задачи
- Статус пользователя (зарегистрированный, незарегистрированный, неизвестный)
- email1
- email2
- телефон
- мобильный телефон
- тема, зачем я хочу с ним связаться
- ICQ
- чекбокс, пометить задачу как выполненую

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

б) Категория "Проконтролировать выполнение задания" (сайт является посредником между заказчиками и исполнителями работы)
- ID задания(которое выполняет сайт)
- Информация о заказчике (несколько полей, список уж как-нибудь соберу)
- Информация о руководителе проекта.
- Стадия выполнения задания (Планирование, реализация, отладка, готово).
- Доп информация (может быть несколько полей)
- Кнопка "удалить задачу"
- Чекбокс "пометить как выполненое"
- Ссылка "Изменить дату напоминания"

И вот таких категорий уже 15, и планируется динамическое добавление.

Прошу не путать термины "задача" и "задание"
Задание - некоторая работа, выполнение которой контролируют администраторы сайта, и выполняют исполнители

Задача - Элемент диспетчера задач (органайзера), обладающий набором собственных свойств.

 

[zahhar]

Нууу, батенька... Да вам надо с заказчиком адиться за стол и делать нормальное детальное ТЗ. Или же этой фирме нужен разработчик в штат, который будет затачивать решение под добавляющиеся или изменяющиеся требования.

Общая недоработка. которая сейчас уже видна: в категории "контакт" у вас имеет место быть дублирование данных, судя по источникам (одна из таблиц, мейл или ручками). Здесь вы должны завести у себя одну большую, включающую всевозможные контактные данные, таблицу "Контакты", куда заносится любая информация о любых людях. В таком случае вы пишете механизм напомления только этой таблицы (дёргать из письма, из таблиц, форма веб-интерфейса), а категория "Контакт" упрощается до вида:
- кто (ID из таблицы "Контакты")
- с кем (ID из таблицы "Контакты")
- тема (как у вас)
- прочие поля (статус задания, ссылка на детальный просмотр)

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

что касается чекбокса "пометить как выполненное", то тут скорее всего одним чекбоксом не обойтись. Лучш всего ввести серию значений под названием "статус задания", нгапример "новое", "назначено", "выполняется", "выполнено". Тогда будет очень легко установить, какие статусы для какой категории требуются и дать пользователю самому редактировать список статусов.

Уже по этим двум недоработкам видно, что прежде чем начинать думать о практическом решении, стоит посвятьтить порядочно времени разработке детального проекта системы на бумаге, потому что то, что вы тут изложили не особо эффективно в эксплуатации и сложно и дорого в реализации.

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

 

[Sat]

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

Всё что касается интерфейса, диктуется заказчиком. Он хочет обойтись чекбоксом типа "Выполнено".

А с заказчиком садиться за стол и делать ТЗ уже поздно. Он не знает проект. Предыдущий программист свалил и контакта с ним почти нет...

 

[zahhar]

Как раз таки в вашем текущем варианте налице дублирование. "Данные о человеке с которым надо контактировать, могут быть взяты из одной из 3-х таблиц БД"- что это за три таблицы? Почему у вас уже сейчас данных об одной сущности лежат в трёт таблицах. а не в одной и почему вы хотите тащить их в четвёртую таблицу, вместо того, чтобы всалить все в одну и далее пользоваться связями?

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

 

[Sat]

объясняю 3 таблицы (созданы до меня и используются во всём проекте)
1 - Данные о заказах (там-же и данные о заказчике).
2 - Данные о зарегистрированных пользователях
3 - Данные о пользователях, которые хоть как-то засветились на сайте, но не подходят ни под одну из категорий.
4 - Таблица "связка" заказ - исполнитель, + ещё чуть чуть данных о заказе.


Сам лично я бы за такую организацию БД руки бы поотрывал. А на детальное планирование заказчик не даёт времени...

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

 

[zahhar]

Про чекбокс типа "выполнено". Ну ок - хочет - пусть получает. Но как показывает практика, скоро (или же для каких-то отдельных категорий) ему может стать недостаточно одного чекбокса и он захочет рядом иметь "статут" задачи. Получится снова дублирование, т.к. "закончено" - это тоже статус. Кончено, если вы уверены что этого никогда не случится или что потом можно будет переделать в случае чего - делайте так. Но я бы для такого проекта предусмотрел возможность выбора одного значения из нескольких. Если для конкретнйо задачи пользователь указал, что статусом может быть только 2 значения - "в работе" и "выполнено", то выражал бы этов интерфейсе чекбоксом (нет галки/есть галка), а как только задказчику вздумается добавить третий вариант статуса - "отложен" например - чекбокс автоматически сменяется на выпадающий список. Т.е. идея в том, что программа выбирает ниболее подходящий элеимент управления в зависимости от тех данных, котоыре нужно предоставить.

Ещё сюда же. Как ни крути, а возможно (точно вам говорю полоэжа руку на всё что угодно) в данном случае обойтись не 15 таблицами, а гораздо меньше. Например в худнем соучае 4-5. В лучшем так и вообще 2-3. (не считая таблиц-справочников, естессно). Для худшего случая таблицы будут такими: "контакты", "задачи", "свойства_задач", "значение_свойств_задач". Эффективность выборок кончеро зависит как от реализации, так и от объёмов данных. Кстати, каковы объемы? какой прогнозируемый прирост данных? (сколько записей/день/мес/год или Мб/день/мес/год), каое кол-во пользователей приложения?

-~{}~ 07.09.04 14:20:

Можно попробовать объяснить, что если у вас нет времени или денег - не будет вам и нормального решения. Если заказчик отказывается понимать настолько элементарные вещт, то я лично предпочитаю не иметь дела с такими заказчиками, благо на рынке есть и другие, гораздо более здравомыслящие. Ну да ладно, это лирическое отступление.

Если переделывать нет возможности, то остаётсятолько идти на поводу и плодить дублирование. Подумайте всё-таки над описанием каждой категории в формате XML.

 

[Sat]

пользователь один. Примерно идёт приход до 200 писем в день, на которых основываются новые задачи.
Проект вышел на свою прогнозируемую мощность. Изменение числа пользователей маловероятно, скорее просто постепенная смена контингента посетителей.

Текущие объёмы - около 500 заказов, примерно 1500 зарегистрированных заказчиков, и около 200 исполнителей.

-~{}~ 07.09.04 15:22:

Спасибо, подумаю...

 

[zahhar]

Какой объям БД у вас сейчас? Как быстро она растёт? 1000 записей в день? 10кб в день?

 

[Sat]

Таблица с заданиями (планируется) прирост 200 записей.
Таблица заказов приблизительно 2 записи в день.
Таблица исполнителей уже не растёт, может быть одна запись в месяц.
Таблица с "левыми" пользователями растёт примерно по 10 в день.

Текущий объём БД: 47 мегабайт.

 

[zahhar]

Ну так ниче страшного, 50 мегов фигня, прироста даже по мегу в месяц - ништяк. Можешь использовать любое, даже самое извращенное решение.

 

[Sat]

Совесть не позволяет...