Меню
Что нового?

Хранение и красивый вывод большого кол-ва инфы

ChesterOne

Guest
Хранение и красивый вывод большого кол-ва инфы

Я занимаюсь веб разработкой. Но чего уж греха таить, занимаюсь и заливкой инфы на сайт. Хоть это дело ужасно не интересное, однако приходица. У нас есть и CMS-ка, обыкновенная.
Часто так случаеца, что на сайте есть много структурированной инфы. Например, есть характеристики кондиционеров: обороты, мощность ну и т.д.
Неоюходимо хранить и выводить ее в красивом виде. Ну, со стилями, бордюрами.
Решения:
1. Хранить весь вид в ХТМЛ - гибкость теряеца напроч
2. Хранить каждую хар-ку в отдельном поле и выводить по шаблону.
Но характеристик очень много. 20-40. Причем они часто разняца. Да и заливка очень затрудняеца. :(

Думаю есть еще и 3-й вариант. Я точно не знаю, но думаю можно хранить все в формате XML, и из него генерить ХТМЛ-ник. Что то вроде

PHP: 
<conditioner name="CHG235 L">
<rotates>3500</rotates>
<power>3500</power>
..
</conditioner>
А как вы храните и выводите данные? Поделитесь, пожалуйста.
 

Gas

может по одной?
В базе нужно хранить только _данные_
А оформлением заниматься перед выводом.

-~{}~ 10.12.04 11:54:

ИМХО. xml можно в данном случае заюзать для импорта/експорта данных. А для хранения информации база лучше.
 

ChesterOne

Guest
Простите, но как же хранить только _данные_, как то же нужно узнать где обороты, а где мощность. Или вы предлагаете выделить под каждую хар-ку по полю?

-~{}~ 10.12.04 15:58:

Я имел в виду хранить данные в БД в формате xml
 

Gas

может по одной?
Тогда сделай таблицу со списком характеристик (название, тип и т.д.) и таблицу со значениеями этих характеристик для каждого объекта.

-~{}~ 10.12.04 12:01:

Я имел в виду хранить данные в БД в формате xml
Нажмите для раскрытия...
а смысл? как ты потом поиск будешь делать?
 

ChesterOne

Guest
PHP: 
[ConditionerFields]
ID, Field

[ConditionerParams]
ID, ConditionerID, FieldID, FieldValue

[Conditioner]
ID, ConditionerName
Что то вроде этого?
 

Gas

может по одной?
Да, типа того. А насчёт
как то же нужно узнать где обороты, а где мощность
Нажмите для раскрытия...
можешь добавить поле в ConditionerFields, которое будет задавать тип.
 

ChesterOne

Guest
Ах да. Точно, забыл :)
Спасибо. Ты мне очень помог.
 

.::PhoenikS::.

Новичок
народ, смотрите "дальше", коли юзаете XML, почему бы не хранить ОТДЕЛЬНО описание правил заполнения(можно сказать, шаблон) и данные для конкретного кондиционера, а потом собрать на лету и обертывать в дизайн, поверьте, получается ОЧЕНЬ гибко, и вменяемо быстро (не как чистая БД, но..).
ЗЫ думаю, не надо говорить, что на выводе этот XML (собранный) можно обернуть XSL-кой ))
 

ChesterOne

Guest
А я незнаю что такое XSL. Читал, но забыл. Вернее непонял.
..или забыл...
:)
 

Gas

может по одной?
.::phoenikS::.
Не вижу принципиальной разницы в подходах в данном случае:

1. db -> php -> html template
2. db -> php -> xml -> xsl template

или ты предлагаешь данные хранить всё таки в xml?
 

.::PhoenikS::.

Новичок
Originally posted by Gas
.::phoenikS::.
Не вижу принципиальной разницы в подходах в данном случае:

1. db -> php -> html template
2. db -> php -> xml -> xsl template

или ты предлагаешь данные хранить всё таки в xml?
Нажмите для раскрытия...
именно данные, причем схема была видимо недостаточно хорошо обрисована:

xml шаблона содержат правила для заполнения этого шаблона (по сути это набор правил конструктора) + содержат названия полей этого шаблона
xml объекта, данные стыкуются с данными шаблона, содержится ТОЛЬКО сами данные, т.е. грубо говоря идентификатор поля из шаблона и значение этого поля.

После сборки такого XML он отдается в трансформатор (xsl), который выполняет совмещение этих данных, грубо говоря названия полей отрисовывает слева, а значения (из данных объекта) - справа.

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

А если к этому добавить нехитрое кэширование, то получается "то, что доктор прописал".

И ещё подсказка для затравки, эти самые шаблоны моно сделать наследуемыми ))))
 

Gas

может по одной?
.::phoenikS::.
Ну меня ты можешь не убеждать в использовании для отображения xsl преобразований. Тему XSLT vs HTML templates поднимать не будет. Лично я пока не пришёл к выводу что мне xsl нужно. ChesterOneу рекомендую почитать для общего развития.

.::phoenikS::. проясни один момент и всё. _Данные_ у тебя хранятся в базе или в xml? Если в xml то какие операции над ними производятся и насколько это удобно.
 

.::PhoenikS::.

Новичок
Originally posted by Gas
.::phoenikS::.
Ну меня ты можешь не убеждать в использовании для отображения xsl преобразований. Тему XSLT vs HTML templates поднимать не будет. Лично я пока не пришёл к выводу что мне xsl нужно. ChesterOneу рекомендую почитать для общего развития.

.::phoenikS::. проясни один момент и всё. _Данные_ у тебя хранятся в базе или в xml? Если в xml то какие операции над ними производятся и насколько это удобно.
Нажмите для раскрытия...
Я не убеждаю))) у меня xsl оправдан схемой )))

Данные хранятся в XML, который лежит как CLOB в базе, а с XML какие можно провертывать операции, если его развернуть в DOM?

Сразу для тех, кто будет грешить на производительность:
на столь малых объемах данных (неразветвленное дерево документа + объем до 20К, который, кстати, для кондиционеров трудно забить, да и не только кондиционеров )))) такие операции быстры и сопоставимы со скоростью исполнения SQL запроса, поэтому миллисекундами можно пожертвовать в пользу гибкости
 

Gas

может по одной?
neko
выбираешь все записи, "разворачиваешь каждую в DOM", делаешь поиск. Замечательно. Быстро, убодно.

.::phoenikS::.
Никогда бы так не стал делать и рекомендовать тоже.
 

.::PhoenikS::.

Новичок
Originally posted by Gas
.::phoenikS::.
Никогда бы так не стал делать и рекомендовать тоже. [/B]
Нажмите для раскрытия...
Первое.
А где было про "делаешь поиск" ?
Вообще-то с выборки ты имеешь уже все, что тебе надо, потом собираешь это простой конкатенацией в 1 документ и его отдаешь на трнсформацию.

Второе.
Ты спросил, что можно делать с XML, я ответил на этот вопрос вполне корректно. Или я не прав?

Третье, специально для тех, кто "в танке".
Трансформация у тебя махом собирает все, что надо за одно преобразование.

И четвертое, для "танкистов в глухой броне".
Легко пишется простейший файловый кэш (или, что лучше,memcahed берется), и ты получашь почти нулевые затраты на вывод, более того, если сделать грамотно и совместить (подумав, а не крича, что все, мол, ацтой) шаблоны и XML+XSL, ты получаешь практически идеальную по соотношению "гибкость-производительность" схему.
Если будет интересно, можно продолжить дискуссию (например рассмотреть поиск по XML средствами MySQL, хотя это и странно звучит на первый взгляд)

З.Ы.
Как я уже сказал, схема выстрадана и опробована не один раз, не хочу показаться голословным, но говорю только то, в чем компитентен. И предлагаю решение, которое либо устраивает, либо нет.
 

.::PhoenikS::.

Новичок
Originally posted by neko
разворачивать можно по разному вопрос вот в чем
Нажмите для раскрытия...
Я говорил относительно PHP5 (соответственно libxml2)
Под развертывание понимался парсинг документа в DOM, используя DOMDocument::loadXML();
 
Войдите или зарегистрируйтесь для ответа.
Сверху