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

Объектное ориентированное хранение информации (деревья + классы с наследованием)

440hz

440hz

php.ru
Объектное ориентированное хранение информации (деревья + классы с наследованием)

Не помню старого поста. там было про Виртуальную файловую систему. Кто помнит киньте сюда ссылку на тред.

Там обещал показать как устроены свои наработки в этой области.

http://art.440hz.ru/
http://art.440hz.ru/adm/

demo:demo - полные права.

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

p.p.s не удаляйте там все сразу. дайте другим посмотреть.
 

Lisi4ka

Новичок
440hz
Почему нельзя просто создавая объект класса заполнять его значениями из таблицы?
 
440hz

440hz

php.ru
Lisi4ka
а для каждого свойства делать отдельный столбец? а для каждого типа объектов отдельную таблицу?
а так заказчик сам все планирует и не дергает каженный раз разработчиков когда ему нужно добавить или удалить свойство.
+ связи объектов друг с другом ...

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

вся беда в том, что программирование объктов очень развито, а вот их хранение и обработка пока развита на уровне SQL, а это плоское хранение. для этого и сделана объектная надстройка.
 
itprog

itprog

Cruftsman
440hz

А каково время генерации дерева ?

Кстати, интересно было бы посмотреть на исходники (желательно новой версии) :)

ps: а зачем такие идентификаторы "pvdlnqgqy7vcaxid"?
 
440hz

440hz

php.ru
Автор оригинала: itprog
440hz

А каково время генерации дерева ?

Кстати, интересно было бы посмотреть на исходники (желательно новой версии) :)

ps: а зачем такие идентификаторы "pvdlnqgqy7vcaxid"?
Нажмите для раскрытия...
1. а сайт быстро отдается? вот такая и скорость ...
2. готовлю ...
3. идея использовать autoincrement так и подмывает в запросе написать ?id=1 а так пойди подбери ... параноийя рулит ...
3.1 я не раз встречал на сайтах такое ?user_id=12345 и при замене ?user_id=1 получал сами знаете что.
 

Кром

Новичок
440hz
Есть ли подробное описание архитектуры хранения?

И попутно вопрос:
а для каждого свойства делать отдельный столбец? а для каждого типа объектов отдельную таблицу?
Нажмите для раскрытия...
А почему бы и не делать отдельный столбец и отдельную таблицу?
 

neko

tеam neko
я понимаю, что мои ламерские претензии не имеют отношения к "объектному подходу", но вот там куски текста наверху страницы.. где написано "сортировать по:", они тово -- наезжают друг на дружку в FF/1.5
 
440hz

440hz

php.ru
Автор оригинала: itprog
1. Быстро, просто думал что результат где-то кэшируется
Нажмите для раскрытия...
да нет. там за счет" /?a=a" вызововы все в живую + header() выдаются запрещающие кеширование. в общем online.

апач:
Код: 
   Server uptime: 15 hours 14 minutes 22 seconds
   Total accesses: 365154 - Total Traffic: 4.9 GB
   CPU Usage: u7526.3 s1993.13 cu.382813 cs.101563 - 17.4% CPU load
   6.66 requests/sec - 93.5 kB/second - 14.1 kB/request
   103 requests currently being processed, 63 idle servers
KKK_K_K_K_K_WKK__WKW__KK_K_K_KKKK_K_KKKKW_WKK__KK__W__KKK__KKKK_
__K___KKKWWK__KKKKK_KKK__KW_K___KKKKKK_WW_KKKKKK__WK__K_KKKKKK_K
_WK_K__KK__WK_KK__KKW____.K.__K..WK_K_.........K...K...K.K......
ну и uptime
Код: 
load averages: 2,20 1,80 1,67
-~{}~ 27.03.06 15:12:

Автор оригинала: neko
я понимаю, что мои ламерские претензии не имеют отношения к "объектному подходу", но вот там куски текста наверху страницы.. где написано "сортировать по:", они тово -- наезжают друг на дружку в FF/1.5
Нажмите для раскрытия...
да. и еще много где немного наезжает. руки не доходят ... извечная проблема. клиент просил под IE, а за овместимость недоплатил. на том и оставили.

-~{}~ 27.03.06 15:16:

Автор оригинала: Кром
440hz
Есть ли подробное описание архитектуры хранения?

И попутно вопрос:

А почему бы и не делать отдельный столбец и отдельную таблицу?
Нажмите для раскрытия...
1. пишем ... просто как выяснилось я совсем не писатель. по-этому идет туго.

2. и заводиить все руками? не. ну можно конечо написать диспетчер который будет подсовывать нужные таблицы и поля, но это ИМХО пишется через "мягкий знак".
---
ну в любом случае потеряется именно общий подход к реализации. если к примеру нужно сделать поиск по всем объектам а у тебя их 50 разных ? что? 50 JOIN делать с учетом каждого столбца? 8)


сейчас вся эта "ботва" реализована 1 таблицей для дерева + 6 таблиц на свойства и объекты + 1 тиблица на связи.
 
440hz

440hz

php.ru
Автор оригинала: itprog
По-моему оно перестало работать, на http://art.440hz.ru/ долго думает и выдает белый экран..
Заработало...
Нажмите для раскрытия...
там сервак под большой нагрузкой. там один из сайтов имеет 50000 хостов в день и 300000 показов. иногда подтормаживает ...
вечерком перенесу на другой хост.
 

Кром

Новичок
и заводиить все руками? не. ну можно конечо написать диспетчер который будет подсовывать нужные таблицы и поля, но это ИМХО пишется через "мягкий знак".
Нажмите для раскрытия...
Именно диспетчер. Все это можно сделать прозрачно для пользователя. Т.е. пользователю совершенно не обязательно знать, как мы реализуем добавление нового свойства. И в чем здесь виден "мягкий знак"? Хотелось бы узнать подробности.

ну в любом случае потеряется именно общий подход к реализации.
Нажмите для раскрытия...
А нужен ли общий подход на уровне native sql? Почему бы общий подход не вынести на 1-2 уровня выше?

если к примеру нужно сделать поиск по всем объектам а у тебя их 50 разных ? что? 50 JOIN делать с учетом каждого столбца?
Нажмите для раскрытия...
Это очень спорный вопрос, можем начать дискуссию.
Если говорить об объектном подходе в непосредственном хранении самих данных, то мне отдельная таблица или ряд связанных таблиц представляется как марица для объекта.
Исходя из того, что объекты, возьмем для примера news и user, разные, они имеют разный набор характеристик. А значит, если мы ищем такой параметр, как "год рождения", имеет смысл искать его только в конкретной матрице. Т.е. в группе таблиц tb_user_...
В этом случае никакой join по 50 таблицам не нужен. В то время как слияние всех объектов в одной таблице приведет к тому самому поиску по данным из 50 таблиц.
Я сразу оговорюсь по поводу параметров совпадающих у всех объектов. Это в основном системные параметры (такие как дата создание объекта и т.д.). Их нужно выносить в общие таблицы, представляющие из себя реестр всех объектов в системе.
Мне это видеться так.
 
440hz

440hz

php.ru
Кром
может я не точно вырзился. я ничего не имею против множества таблиц. такая схема то же рабочая. просто именно эта реализация была такой. 8)
 
Войдите или зарегистрируйтесь для ответа.
Сверху