Virtual File System

[ONK]

Нечто, прям мои мысли украл.

 

[Develar]

То, что хочет автор, давно реализовано и используется. В частности, моя система основана на подобной системе (а мне ее подсказал более опытный, чем я, коллега по работе) и похожа на систему 440hz (http://www.440hz.spb.ru/news/?NID=gdmhpu6ny30spzra) и его пример с интернет-магазином.

Только все это проистекает из понимания ООП и теории баз данных (РСУБД или ООСУБД не суть).

Вспоминается фраза одного из участников клуба (имя забыл)

Каждый открывая для себя Америку будет бежать с этим на форум?

 

[Rammstein]

Ещё вчера текст написал Но дождался пока выделенка будет. Теперь я тут чаще появляться буду =)

Вы вот тут дружно утверждаете, что я делаю велосипед, но никто конкретной ссылки на реализацию так и не дал. Парадокс… Всё сводится к собственным проектам.

Итак, повторяю ещё раз.
Объекты с произвольной структурой и связями с другими объектами. Их нужно хранить в БД. Они практически всегда существуют в проектах. При их ручном кодинге, тратится чуть ли не половина времени разработки (опять же, от проекта к проекту меняется количество времени). Существует такое решение как Propel, но требует туеву хучу библиотек и ещё много заморочек. Так же существует проблема с хранением дерева, в каждый узел которого можно сохранить несколько объектов – придётся ручками реализовывать (хотя, может ситуация и изменилась).
Теперь я предлагаю сделать те же объекты с произвольной структурой и связями, но ещё добавив древовидную структуру. Задача сделать их не разрозненными, а одним целым.
Я уже просто мешаю то, что было в статье и то, что у меня имеется сейчас, поэтому и возникает путаница.
Пример использования смотрите выше.

Ясен фиг, что объекты с произвольной структурой уже реализованы в том же Propel (но автоматизация там полное ниачём)

 

[440hz]

Rammstein
так о том и речь:

1. дерево (реализовано сотни раз). прицепить к узлу ссылку (id) на объект(ы) - пишется за 5 минут.

2. манипулирование объектами их свойствами и связями друг с другом. то же реализовано.

может какого-там стандарта нет, так это уже не наша беда. каждый пишет для себя как удобно.

в предствлении того же магазина:

1. витрина
2. товары.

товар входит в какой-то отдел витрины и может быть связан с какими-то товарами.

вот новизной эта идея ну ни как не пахнет ... структуризацией, приведением к какому-то стандарту - может и прокатит.

p.s. вечером дам ссылку на исходники и на попробоать как все работает у меня. правда версия не последняя ...

 

[Rammstein]

2 440hz
Да, я не претендую на изобретение NestedSets, например, или тех же объектов с произвольной структурой. Тут я как раз и говорю о стандартизации и создании единого интерфейса.

 

[440hz]

Автор оригинала: Rammstein
2 440hz
Да, я не претендую на изобретение NestedSets, например, или тех же объектов с произвольной структурой. Тут я как раз и говорю о стандартизации и создании единого интерфейса.

мысля нужная ... готов поучастовать ...

 

[kvf77]

440hz

Вроде есть стандарт на такое хранилище в Java - надо поискать точный номер. помоему где-то видел даже зачатки PHP реализации

 

[Rammstein]

2 440hz
Отлично!

2 kvf77
Было бы хорошо увидеть ссылки....

 

[kvf77]

Rammstein
нашел - называется это Java Content Repository (JSR-170) поиск выдает полную инфу по этому поводу

http://www.theserverside.com/news/thread.tss?thread_id=25990

 

[Rammstein]

ок. Читаю.

-~{}~ 01.03.06 23:46:

Как не удобно-то. Забыл добавить. Хранить все объекты в дереве (всмысле NestedSets) слишком накладно. Поэтому каждый объект - узел в нашем случае не подойдёт. Лучше использовать такой принцип: если у эллемента есть дочерние элементы, то он - узел, иначе - просто входит в узел.

 

[Нечто]

Зачатки opensource реализации JSR-170 на PHP можно чекаутнуть с https://svn.domain51.net/svn/d51CR/tags/everythingAsItems/

Вообще я какое-то время занимался вопросом CR для PHP.

 

[Develar]

http://pear.php.net/package/VFS

 

[Rammstein]

2 Develar
Уже смотрел. Далеко не то, что нам нужно.

 

[440hz]

Автор оригинала: Rammstein
ок. Читаю.

-~{}~ 01.03.06 23:46:

Как не удобно-то. Забыл добавить. Хранить все объекты в дереве (всмысле NestedSets) слишком накладно. Поэтому каждый объект - узел в нашем случае не подойдёт. Лучше использовать такой принцип: если у эллемента есть дочерние элементы, то он - узел, иначе - просто входит в узел.

не. дерево это дерево, а что мы к узлу прицепим наше личное дело.

 

[Rammstein]

Опять же каким образом цеплять
Если в само NestedSets вносить данные, т.е. само дерево будет

Root
 |- Some_New
      |- Obj1
      |- Obj2

то по мере увеличения количества объектов, выборка станет достаточное количество времени занимать. А вот если дерево будет таким:

Root
 |- Some_New

, и к объекту добавить свойство node. Так в нашем случае:

id | obj_name | obj_node
1  | Obj1         | Some_New
2  | Obj2         | Some_New

Будет быстрее. Т.е. если эллемент не имеет потомков (Obj1, Obj2), то он не указывается как узел, а только входит в какой-нибудь другой узел (Some_New) и связывается полем obj_node.
Т.е. в первом случае связывающий элемент хранится в дереве, а во втором, в описании объекта (то бишь в таблице его).

 

[440hz]

Rammstein
NestedSets - весчь хорошая, но не панацея. Можно и свое написать ...

на выходных попробую сформулировать как у меня реализовано. будет что похаять.

в САМОМ дереве объекты не хранятся. дерево хранит только уровни подчиненности.

связь объектов и узла дерева через промежутучную таблицу node_id -> obj(s)_id. нужно выбрать объекты данного узла - лезем в табличку.

 

[Rammstein]

Да, на счёт дополнительной таблиц я тоже думал. Получается ещё фитча - ссылки. Т.е. один объект можно поместить в разные узлы.

 

[440hz]

Автор оригинала: Rammstein
Да, на счёт дополнительной таблиц я тоже думал. Получается ещё фитча - ссылки. Т.е. один объект можно поместить в разные узлы.

ну будет таблица не один-ко-многим а многие-ко-многим. это даже не вопрос.

линк как таковой в моих задачах мне не был нужен, но как фича имеет место быть.

с реализацией на самом деле проблем нет.

вопрос в общем подходе и организации Объектно Ориентированной Модели хранения объектов как таковой. т.е. в неком стандарте и API к нему. вот на эту тему готов пообщаться ...

 

[Rammstein]

Да, нужно чтоб удобно было. Изучаю всё ещё JSR

-~{}~ 02.03.06 22:00:

Предлагаю сформулировать чё мы хотим и какие фичи будет иметь.
Название нужно поменять. Можно немного приспи.... позаимствовать: PHP Content Repository. Ну, это не самое важное, но для работы удобней иметь название....

Фичи которые будем реализовывать:
- объекты с произвольной структурой
- организация в дерево всех объектов
- ссылки (один объект в разных узлах дерева)
- версионность
- индексирование (сделать только возможность его создания - релизацию пока не трогать)
- поиск (см. выше)
Какие ещё? Думаю, пока хватит. Но вообще лучше всё что может потребоваться сюда вкинуть, а то потом переделывать всю систему из-за одной фичи не хотелось бы.

Остаётся вопрос. Сам узел делать как обычный объект, но с доп. данными и методами, связанными с позиционированием его в дереве или же делать как отдельный класс. Как считаешь?
Это удобно в том плане, что может кому-то понадобится создать узел с типом "статья", а всё что в этот узел будет входить - параграфы. Фактически, более расширяемо.

 

[440hz]

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

так же рализован поиск, фильтрация и т.д. даже FULLTEXT присуствует.