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

.::PhoenikS::.

Новичок
Originally posted by neko
clob это что у нас
oracle?
Не только, под клобом понимались любые символьные данные, не входящие в пределы SQL varchar и подобных.
в моем конкретном случае это text и mediumtext mysql'я.

В оракле же можно и так использовать трансформации, а также делать выборки xpath'ом прямо с xmltype-полей. Другое дело, что там это очеееень медленно и пока ещё оооочень криво (оин только xmltransform чего стоит - кто пользовал, тот знает).

Я больше приверженец mysql в плане скорости работы.
ЗЫ в Оракле клобы (более 64к) медленно "вытаскиваются" с базы, в отличие от mysql. Хотя тут возможно так база настроена, что я могу доспустить.
 

Gas

может по одной?
XML+XSL - нормальная схема для отображения. (твои пункты 3 и 4)
Не нормально - это хранение данных в формате XML в базе.

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

.::PhoenikS::.

Новичок
Originally posted by Gas
XML+XSL - нормальная схема для отображения. (твои пункты 3 и 4)
Не нормально - это хранение данных в формате XML в базе.

Пример. Есть категории товаров, есть сами товары связанные с категориями. Нужен поиск товаров по их характеристикам. Сколько же телодвижений тебе предстоит сделать вместо самого обычного SQL запроса
Да-да-да.Именно на магазинах и катали, причем ещё на пхп4.
Так вот, ты будешь смеяться, но я сделаю выборку с поиском 1-м запросом, причем он будет простой.
 

neko

tеam neko
ну как и говорил -- кривизна

я было подумал что используется субд, которая как родной тип данных понимает xml

.::phoenikS::.
про медленный и кривой оракл можешь не рассказывать, т.к. все с тобой уже ясно

а в обычную субд типа mysql
в качестве файловой системы использовать ненужно
она не для этого сделана
 

Gas

может по одной?
Так вот, ты будешь смеяться, но я сделаю выборку с поиском 1-м запросом, причем он будет простой.
будь добр, покажи.
Одно из двух, или буду смеятся или задумаюсь, вдруг пригодится.
 

.::PhoenikS::.

Новичок
Originally posted by neko
ну как и говорил -- кривизна

я было подумал что используется субд, которая как родной тип данных понимает xml

.::phoenikS::.
про медленный и кривой оракл можешь не рассказывать, т.к. все с тобой уже ясно

а в обычную субд типа mysql
в качестве файловой системы использовать ненужно
она не для этого сделана
Я не понимаю, вы читать умеете? Я сказал, что медленный и кривой не оракл, а его работа с XML, т.е. XMLDB.

Базу, как файловую систему, я не использую, в моем конкретном случае удобнее хранить XML именно в поле, а не просто на диске, хотя никто бы не помешал это сделать, допустим, используя ID записи, как имя файла. Это как раз дело второе. Вопрос изначально стоял: как обработать и КАК (а не где, снова к вопросу о "читать не умеете" выше по тексту) сохранить данные.
 

[DAN]

Старожил PHPClub
Кстати, PostGres поддерживает XPath-запросы к xml-контенту текстовых полей =)
Насчет тормознутости сказать ничего не могу, не тестил пока.
Но, имхо, в реляционной СУБД держать в блобах xml-данные - это большой изврат.
 

neko

tеam neko
сказал, что медленный и кривой не оракл, а его работа с XML, т.е. XMLDB.
правильно эта мысль выражается несколько иначе
предложение начинается обычно со слов "я не умею.."

Базу, как файловую систему, я не использую
используешь

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

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

-~{}~ 15.12.04 17:44:

[DAN]
это тоже самое что делает наш герой
решение не фонтан

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

.::PhoenikS::.

Новичок
Originally posted by Gas
будь добр, покажи.
Одно из двух, или буду смеятся или задумаюсь, вдруг пригодится.
Гэз, приятно, что нормально все воспринимаешь.

Идея такая, у тебя есть шаблоны с полями (как я говорил в самом начале). Самое простое, дать полям цифровой индекс.
Второе, все данные самих товаров ты заносишь в базу сам, так вот, на этом этапе тебе никто не помешает заполнить таблицу ввида
ид_товара, ид_поля_шаблона, значение_поля_для_этого_товара

и запрос сводится к

SELECT mt.*
FROM main_table mt
INNER_JOIN xml_cache xc USING ид_товара
WHERE значение_поля_для_этого_товара LIKE "%чего-нить там%"

Названия вымышлены :)))

Можно переписать этот запрос на EXISTS, домавить поиск по иерархии каталога товаров(допустим только в этой ветке), разделить данные на строковые, полнотекствые и цифровые. (дата мне не нужна - у меня для нее юниксовый таймстэмп используется) После этого немного поменяй запрос под эти типы, так ты ещё и снизишь нагрузку на сервер. Не думаю, что надо говорить о том, что строковые индексы медленнее цифровых.
Плюс используя такие шаблоны, сразу получаешь форму поиск по конкретным полям (они ведь все внутри), обернув его XSL (опять же проще).

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

-~{}~ 15.12.04 17:59:

Neko, ты на самом деле странный, тебе про фому, а ты про ерему. Этот XML, если уж на то пошло, относится непосредственно к конкретному кондиционеру или хрен знает чему ещё. Лежит он в таблице наряду со многими другими полями и служит для удобства экспортирования, вывода и редактирования.

XMLDB в оракле далеко не быстрый (ты пробовал использовать бенчмарки?)
Да хотя бы посмотри на официальный сайт libxml, даже там есть графики тестов производительности.
То, что он кривой, могу доказать хоть сейчас, выполни трансформацию с документом больше 64к - результат получишь обрезанный (база - 10g). Про изменение нодов я промолчу - в доке will be implemented in near future, хотя это сделать можно другими, хотя и извратными способами.

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

Поиск у тебя будет по нескольким таблицам сразу, у меня же по 2-м.

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

Gas

может по одной?
.::phoenikS::.
ид_товара, ид_поля_шаблона, значение_поля_для_этого_товара
Или я что-то не понимаю и в базе у тебя хранится не xml, а чистые данные связанные с конкретным xml шаблоном?

-~{}~ 15.12.04 17:18:

при этом сам xml шаблон не суть важно где лежит (база, файлы).

-~{}~ 15.12.04 17:18:

так?
 

neko

tеam neko
.::phoenikS::.

Лежит он в таблице наряду со многими другими полями
т.е. ты несколько столбцов "свернул" в один?
в реляционке
если это по твоему нормально, то да я верю, что тебе удобно
служит для удобства экспортирования, вывода и редактирования
однако это очевидно неверное применения инструмента (т.е. рсубд)
да можно туда запихнуть все что угодно
и после этого рассказывать как это офигенно удобно, что с переменным успехом время от времени делается разными посетителями форума
однако сам подход это ничуть не улучшает

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

Такой гибкости ты не получишь, как тут.
это заблуждение

правда тут надо признать 2 вещи
mysql довольно убог в плане автоматизации таких процессов
и как ты сказал выше он супер-быстр и поэтому тебе нравится

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

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

Поиск у тебя будет по нескольким таблицам сразу, у меня же по 2-м.
(пояснение для нечитавших тред)
поиск бывает разный, требования к возможности что-либо выбрать тоже
поскольку иначе автором вопроса не указано, мы обсуждаем некий общий случай...
тебе рассказать 10 проблем которые у тебя будут в общем случае (это не в твоем личном) или сам догадаешся?
типа нахождения наименее энергопотребляющих кондиционеров с шириной не более 75см?

А вообще трудно говорить с человеком, который "уперся", не разобравшись...
ППКС
 

.::PhoenikS::.

Новичок
Originally posted by Gas
.::phoenikS::.

Или я что-то не понимаю и в базе у тебя хранится не xml, а чистые данные связанные с конкретным xml шаблоном?

-~{}~ 15.12.04 17:18:

при этом сам xml шаблон не суть важно где лежит (база, файлы).

-~{}~ 15.12.04 17:18:

так?
Если утрировать, то так, но данные, связанные с конкретным шаблоном всего-лишь кэш, XML, развернутый в плоскую структуры. Дело в том, что ядро сформировано по принципу реестра, все записи (объекты) имеют типизированную структуру, а xml-шаблоны служат для расширения этой структуры (где это необходимо), поэтому он (xml) и храниться в базе наравне с другими свойствами (как то id, title или время изменения) - его просто неудоюбно зачитывать из отдельного файла, проще получить запросом, такая схема позволяет также легко производить наследование объектов (те же шаблоны), использовать систему прав доступа к объектам (также наследуемую), делать иерархические выборки (аналог CONNECT BY) и т.п.


2 Neko
-----------------------------
т.е. ты несколько столбцов "свернул" в один?
в реляционке
если это по твоему нормально, то да я верю, что тебе удобно

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

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


Да, триггеров в Mysql нет, но путем унификации процедур удаления либо обновления, триггеры заменяются внешними ключами и несколькими процедурам, причем программист исполюуя API не заботится об операциях такого уровня - они вынесены в базовый абстрактный класс, от которого наследуют все объекты системы.


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

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

Если проблемы еще наплаву, я хотел бы их выслушать.


-----------------------------
я правильно понял, что "мама негорюй" это новая форма подачи результатов тестирования?
-----------------------------

нет, это я сгоряча так выразил свое мнение.
 

neko

tеam neko
ты не понимаешь сути
ну разумеется.
вот ты -- понимаешь, а мне куда

Плюс попробуй сделать вложенные описания (дерево) на чистой базе - у тебя не получится
эксперты в городе!
мужик я пробовал, и у меня получилось, веришь/нет?
но вот тут пролупился, сразу видно чукча не читатель
вопрос был в не в ДЕРЕВЕ
а в характеристиках для товара
характеристики это набор полей -- кортеж, там никакой иерархии нет

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

я и рассматривал общий случай - у меня допускается любой поиск, т.к. форма поиска уже "знает" от шаблона
т.е. я правильно понимаю, что все это дело суется в LIKE?

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

пойми это бы еще имело толику смысла если бы реально была мелкая иерархия (хотя это ОЧЕНЬ спорно)
или если бы работал с нативной xml субд или с каким-нибудь гибридом типа юкона
что мы имеем тут, так это слабое знание сильных сторон реляционной модели
+ желание втулить любимую технологию

а задача между тем для первокласника который уже освоил alter table....

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

_RVK_

Новичок
Что то подобное я видел в движке xoops. Но там есть смысл. Смысл в возможности визуального редактирования страниц, и придания им любого вида и структуры. Без xml этого сложно добится.

Но .::phoenikS::., всей этой гибкости, что ты говоришь можно добится и обычными методами. Я не услышал ни одного довода чем твой подход лучше традиционного. Просто, как мне кажется, ты изначально пошел по этому пути, и тебе неведомо что есть и другие, более традиционные.
Пока согласен с neko, решение выглядит кривым. Но работает, и бог сним....
 

.::PhoenikS::.

Новичок
Originally posted by neko
ну разумеется.
вот ты -- понимаешь, а мне куда
-------------------------------------------

видимо нет, читай ниже


-----------------------------------
эксперты в городе!
мужик я пробовал, и у меня получилось, веришь/нет?
но вот тут пролупился, сразу видно чукча не читатель
вопрос был в не в ДЕРЕВЕ
а в характеристиках для товара
характеристики это набор полей -- кортеж, там никакой иерархии нет
-----------------------------------

да, для плоской структуры удобнее таблица, а когда у тебя сложное составное поле? вида

название организации
управляющий
телефон
(допустим этого хватит)

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


А мы ещё кажется рассматривали универсальный случай? Да?Видимо, нет, я что-то путаю...


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


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

пойми это бы еще имело толику смысла если бы реально была мелкая иерархия (хотя это ОЧЕНЬ спорно)

Иерархия порядка 100000 записей обслуживается элементарно и с легкостью пнем на 2.8Гг под виндами, причем порядка 50 случайных (по параметрам) конкурентных поисковых(заметь, не простая выборка веток каталогов, каторая как раз и составляет львиную долю нагрузки типичного магазина, в отличие от поиска - это около четверти) запросов отрабатывают меньше , чем за 2 секунды, для ВЭБ такое время отклика более чем нормально.



------------------------------------------------
+ желание втулить любимую технологию

а задача между тем для первокласника который уже освоил alter table....
------------------------------------------------

желание? поверь, делать что-то ради того, что просто хочется, нет времени.

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

Молодец, чувак! Sun, HP и Dell жмут тебе руку за то, что ты поднимаешь их объемы продаж.



---------------------------------
а вот еще попустил:

если ты так сильно хочешь из базы получить уже xml, тогда для вывода результат можно обернуть вьюхой или процедурой -- оба способа достаточно хороши
[/QUOTE]
----------------------------------
[/b]

Читай выше, про сервера, конечно каждый раз лучше собирать данные, чем брать готовые. А вообще, атомарная логика - это сила. Я был неправ, а кэши и буфферизованные операции придумали идиоты. Какие странные люди, да? Может ты хороший грамотный программист, возможно у тебя есть огромный опыт, ты наверняка знаешь несколько языков, но ты почему-то не видишь дальше своего носа (или не хочешь видеть)

Я понял, хороший программист - это тот кто работает руками, а не головой. Простите...
 

neko

tеam neko
а можно этот мусор отформатировать нормально, а то разибрать влом?
 

_RVK_

Новичок
Я понял, хороший программист - это тот кто работает руками, а не головой.
Хороший программист это тот кто может лугко доказать достоинства своего решения. Лично я пока видел "удобства", которые легко реализуются традицонными методами. Это когда БД используют для того, для чего она предназначенна.
Давай спорить что я напишу систему, которая будет хранить информацию в виде перфокарт, и обладать всеми достоинствами твоей системы. Но смысл в чем? Я врятли смогу объяснить, как и ты сейчас не можешь.
 

.::PhoenikS::.

Новичок
Originally posted by _RVK_
Что то подобное я видел в движке xoops. Но там есть смысл. Смысл в возможности визуального редактирования страниц, и придания им любого вида и структуры. Без xml этого сложно добится.

Но .::phoenikS::., всей этой гибкости, что ты говоришь можно добится и обычными методами. Я не услышал ни одного довода чем твой подход лучше традиционного. Просто, как мне кажется, ты изначально пошел по этому пути, и тебе неведомо что есть и другие, более традиционные.
Пока согласен с neko, решение выглядит кривым. Но работает, и бог сним....
Я не видел xoops внутри, поэтому не буду ничего говорить, xml именно у меня сделан именно для гибкости вывода и для гибкости редактирования, расширяемости. На нем же построена система дизайнов и вывода страниц, причем это работает быстро.

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

Поверь, я пробовал сделать по-разному, в итоге пришел к этому. Почему, я объяснял, и я не принуждаю никого бросаться переписывать свой код, очертя голову. Хочется обратить внимание на то, что по большей части народ уверен в своих силах, считает себя истиной в последней инстанции, считает, что он самый умный, поэтому вправе втаптывать в грязь чужие идеи. Я НИГДЕ не сказал, что другие варианты - хрень, я только обратил внимание на их узкие места. Причем вполне корректно (без высказываний о чукчах, чуваках и т.п. первым, потом уже просто вынудили, чесслово).

Ни одного слова, чем лучше? Если рассматривать в контексте всей системы, где XML занимает место наравне с субд:
- унификация
- простота API для конечного программиста (как следствие первого)
- масштабирование
- гибкость (XML придумали для именно такого рода задач, главно правильно скомбинировать, а не упираться в одну субд, файловую систему, xml или что бы там ни было другого)
- функциональность
- хорошее соотношение скорости и универсальность (и того, и другого не может быть по определению сразу по максимуму)

-~{}~ 15.12.04 20:55:

Originally posted by _RVK_
Хороший программист это тот кто может лугко доказать достоинства своего решения. Лично я пока видел "удобства", которые легко реализуются традицонными методами. Это когда БД используют для того, для чего она предназначенна.
Давай спорить что я напишу систему, которая будет хранить информацию в виде перфокарт, и обладать всеми достоинствами твоей системы. Но смысл в чем? Я врятли смогу объяснить, как и ты сейчас не можешь.
Я согласен большей частью, не буду спорить, ты действительно прав, программирование тем и хорошо, что можно сделать одно и тоже по-разному, и ты можешь написать такую систему (хотя у неё будут проьлемы со вводом-выводом, и все упрется в перфоманс, но это детали :). Но!
Именно поэтому программист должен работать головой больше, чем руками, тебе так не кажется?

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

neko

tеam neko
короче скучно стало
откуда-то взялись иерархии которых и в помине не было в начальном вопросе

дебильные рассуждения про фрагментацию
видимо это такая часть sql99
фрагментируйте на альтер -- всеми субд реализована!

пни под виндами, и рассуждения о скорости вслух...
атомарная логика...
такой формат хранения вообще-то прямое ее нарушение

надоело, одно и то же повторять.

вообще меня прикалывает когда людм мне рассказывают про xml ;-)
 

.::PhoenikS::.

Новичок
Originally posted by neko
короче скучно стало
откуда-то взялись иерархии которых и в помине не было в начальном вопросе

дебильные рассуждения про фрагментацию
видимо это такая часть sql99
фрагментируйте на альтер -- всеми субд реализована!

пни под виндами, и рассуждения о скорости вслух...
атомарная логика...
такой формат хранения вообще-то прямое ее нарушение

надоело, одно и то же повторять.

вообще меня прикалывает когда людм мне рассказывают про xml ;-)
Иерархия к вопросу об униыверсальности. Ты видимо, непроходимо туп.

Вот-вот, мысли атомарно ))) И будет тебе счастье.

Прикалывает, когда рассказывают? Прикалывайся, идиотик!

Надоело с утупком вести полемику...


Модераторы? стирайте этот пост, редактируйте, главное, я высказал все, что хотел
 
Сверху