Добрый день, уважаемые форумчане!
Хотелось бы узнать ваше мнение, а так же, может и совет!
В общем дело в следующем.

Пишу приложение, которое будет работать с картой и расставлять маркеры. К маркеру можно добавить свое изображение, название, описание.
Есть еще виды маркеров, обычный и скрытый. Хотя виды можно и добавить в будущем.
Данную информацию о маркерах я позже преобразую в xml формат. Пример текста который получится будет выглядеть примерно так:



Мои действия:
1. Формирую подобный текст;
2. Сохраняю данный текст в ячейку таблицы БД;

Далее, когда клиент захочет посмотреть данное описание, то оно будет отправляться по частям (ну чтобы нельзя было воспользоваться всякими FireBug'ами и т.п.

3. Разбиваю данный файл на task'и (используя parsing-скрипт) и располагаю их в другой таблице
4. Отлавливаю, если есть answer и заношу его в отдельную ячейку и вырезаю ее из строки task'а
5. Отправляю данный task клиенту ну и он видит уже что там-то там маркер, ну ему и нужно будет с ним что то сделать...
6. Как действие какое-нибудь выполнено, то получаем другой task (например введен правильный ответ).


Является ли это хорошим решением или все же лучше реализовывать подобную вещь как то по другому? Защита инфы содержащейся в ячейке очень важна (пользователь не должен знать за ранее все task'и).

Понимаю, что может данный вопрос не совсем к php, но так как вся логика пишется на php, а другую тему подходящую не нашел...

Буду очень благодарен, если выскажите свое мнение!
Спасибо!!!

то есть клиент получает сразу же правильный ответ?

Нет))) Ответ заноситься в другую таблицу и вырезается из строки, которая передается клиенту. После того, как он дает ответ, данные сверяются на сервере с ответом, если ответы совпали - то передается следующее задание, иначе сообщается об ошибке. (пункт 4).

Ну и данные, которые передаются клиенту имеют структуру JSON.

очень запутанно и сложно. зачем xml, почему бы не хранить все непосредственно в БД? одна строка - один вопрос. 

baldina - да, это конечно тоже вариант.
Но тут есть несколько нюансов: 
1. Функциональные возможности по созданию "инструкций" еще полностью не ясны и может получиться так, что не просто будет хранить данную инфу в таблице.
2. Не все "инструкции" могут понравиться пользователям и следовательно их не надо будет разбивать на части, что сохранит нам 2ую таблицу в БД и не будет ее забивать (и в планах, если кто то использует инструкции и дошел по ним до конца, то они будут удаляться из 2ой таблицы, при условии, что ими больше не кто не заинтересован).
3. Легкость в интеграции с другими языками (например с C#) - так как на многих языках есть свой парсинг xml.
4. Скорее всего будет возможность редактирования этих данных и пользователь, создавший эти инструкции может разом получить их из одной ячейки.


Сейчас реализация идет на веб-технологиях. Но если она будет успешной, то будет перенос как минимум на C#+XAML. xml в данном случае используется для того, чтобы не придумывать какую-то свою структуру данных и не писать потом свой парсинг. А написанные данные пользователем все равно нужно засовывать в какой то формат и передавать php скрипту, который уже будет его обрабатывать. 

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

Или baldina можешь предложить вариант, который позволяет хранить все "инструкции" созданные пользователем в удобном виде (пока работает пользователь, все данные сохраняются с помощью javascript) и потом - передача на сервер.

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

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

2. не понял аргумент. 

3. зачем навешивать xml (независимо от легкости работы с ним), если от него можно вообще отказаться. это лишний слой.

4. пользователь, создавший эти инструкции может разом получить их из всех ячеек.



т.е. в объектах/массивах javascript

в формате json, откуда легко и просто получается в виде объектов и массивов серверного языка. которые легко и просто кладутся в хранилище.
хранилищем, кстати, может быть и xml, но на прикладном уровне лучше про формат хранения вообще ничего не знать.

можно же просто в json хранить данные

baldina, на счет второго:
Вот смотри, у нас есть запись в таблице inctructions вида приведенного выше (в xml формате), но пусть там будет например 30 строк. Если клиент решил открыть их, то эти данные разбиваются на 30 строк и сохраняются в др. таблицу и по частям начинают отправляться пользователю. Как только пользователь прошел все инструкции, они удаляются по id из таблицы instructions.
Если пользователю не понравилось описание данных инструкций, то он их и не будет отрывать и следовательно 2ая таблица не будет дополнительно забиваться, что увеличит скорость работы БД при большом количестве инструкций и пользователей.

json'е хранить можно, но по мне это не очень удобно читается, если данных много (т.е. не такая очевидная структура), а вот xml - нагляден и понятен.
В общем пока окончательно не решил, на чем остановиться, но думаю к концу недели сделаю свой выбор (еще поинтересуюсь у людей в живую).

а как насчёт моего любимого формата - INI?   



INI по сравнению с XML в разы быстрее. Да и обработка заключается в использовании одной функции..

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


очень спорно, что xml нагляднее json при больших объемах. слишком много в нем избыточных букв. хотя аспект понятности исходных данных в данной задаче  мне не кажется важным.

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

В общем, поговорил я с людьми... И сделал такой вывод:
1) Как мин. первую версию решено реализовывать в json
2) Из-за того, что в xml возможностей больше, то есть вероятность, что при увеличении сложности приложения будет переход на него

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

Ну в общем, время и результат покажет, может и Fortop ты будешь прав!


Всем большое спасибо за обсуждение! 
Если друг что-т интересное выявлю - сообщу! =)