[СПВ] объектно-ориентированные системы хранения

> пишу свой велосипед для хранения инфы в базе в виде объектов

ИСП РАН какую-то СУБД написал, уже давно.
http://ru.wikipedia.org/wiki/Sedna

ИСП РАН: http://www.raspo.ru/developers.html?id=8

хмм, не, у меня не субд, у меня система поверх реляционной субд

ИСП РАН

Я уж было хотел сказать, что не помню, чтобы у нас в ИПС РАН такое писали :)

winfs?

ORM?

плохо подходит для динамического набора полей.
попробуй OODB, тот же Berkley. Хотя подход все-равно надо будет изменить.

нет, ормы затачиваются под определённые объекты, а у меня такого нет

>для динамического набора полей.

хотя да, ТС об этом не упоминал...

Ааа, я понял. Таких систем в открытом доступе вроде нет (я не видел) - потому что они очень специфичны для конкретных случаев. А так куча контор заново велосипедствует конструкцию, когда все каждое свойство объекта хранится как отдельны кортеж в БД. Лично я просто взял MongoDB - она как раз идеально для этого подходит. Но это NoSQL, транзакционная целостность будет висеть на тебе :)

нет, ормы затачиваются под определённые объекты, а у меня такого нет

O'RLY?

есть таблица свойств - в ней хранятся все свойства сущности - какие зададим в шаблоне

кастую KRoN73 в тред, вроде он знает такую систему

набор полей для объектов задаётся шаблоном, хотя можно и руками добавить любому объекту любое поле

любому объекту можно накидать свойств, совершенно любых

какие зададим в шаблоне

>руками добавить любому объекту любое поле

вот и я о том.

// подписываюсь на тред, потому как завершаю создание очень похожего велосипеда.

И таки да, вызываю KRoN73 - он 100% писал такое поверх mysql и видел боттлнеки.

тред явно просит переезда в /development

Я ничего не понял, но случайно не такого типа http://ru.wikipedia.org/wiki/MongoDB ?

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

А для такого вообще подойдет по таблице на шаблон и управляющее поле в главной таблице где хранятся общие поля.

acid state, правда придётся весьма специфический ЯП использовать

по таблице на шаблон? О_о
у меня сейчас в общем случае 4 таблицы
шаблоны, объекты, проперти и шаблоны пропертей с предустановленными типами

И какие поля у этих таблиц в общем случае?

запостил наверх ссылку на гитхаб с велосипедом, там в корне скл лежит

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

хмм? а какие ещё типы нужны? добавим)

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

дату я не вижу смысла хранить как отдельное поле, дата прекрасно конвертируется в unixtime и в строку
а вот перечисления, хмм, хорошая идея, вечером запилю
хотя, их тоже можно хранить в строке как case1|case2|...|caseN и нужным типом поля
для них придётся заводить таблицу, вроде property_list

>конвертируется в unixtime

не всегда

и в строку

медленновато. дата должна быть.

case1|case2|...|caseN и нужным типом поля

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

>не всегда
Date.getTime() =) жабка же

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

думаешь, будет сильно быстрее делать селект вида
select * from property_list where object_property_id = 100500?
и уже парсить полученный список?

>Date.getTime()
Он имел в виду например дни рождения людей старших 40 лет.

хмм, резонно, ок, сегодня запилю Дату и список

я думаю что ничего не будет быстрее флаговых (битовых) перечислений в 64 разряда, обрабатываемых простейшими & | !

http://www.datanucleus.org/

Используется в GAE. Пример использования http://code.google.com/intl/ru/appengine/docs/java/gettingstarted/usingdatast...

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

> ого, потыкаю на досуге. спасибо! можно, кстати, тоже запилить что-то вроде менеджера объектов, аннотации накидать и так далее чтобы автоматизированно сохранять\восстанавливать объекты

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

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

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

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

благодарю)

И таки да, вызываю KRoN73 - он 100% писал такое поверх mysql

Скастовался через G+ :)

…

Обычные объекты в MySQL-базе у меня все с фиксированной структурой. У каждого класса объекта есть описание привязок свойств объекта и полей в БД (вот, пример из класса, который прямо сейчас на работе пишу):

    function table_fields()
    {
        return array(
            'id' => array('is_editable' => false),
            'title' => array('title' => ec('Метка (тэг)')),
            'category_name' => array(
                'title' => ec('Категория'),
                'named_list' => 'pfs_news_keyword_categories',
                'type' => 'dropdown_edit',
            ),
        );
    }

Для упрощения разработки есть автогенерация табиц (реально только в юнит-тестах использую, на практике — чаще обратную задачу использую, делаю БД в MySQL, а потом скриптом на её основе — рыбу класса для доводки вручную).

Есть экзотические классы со структурами «одно свойство — отдельная запись» (с идентификацией по имени свойства в отдельном поле таблицы), есть даже пара древних монстров вида «одно свойство — одна таблица». Но это всё некрасивые извращения :)

Понемногу экспериментирую с MongoDB, там объекты целиком сохраняются, но до практического использования пока нигде не дошёл, бэкенд Mongo на уровне концепта и тестов.

…

Вообще, от идеи универсальных «умных» бэкендов я со временем отказался. Нужно ввести поле — добавил его в БД, добавил описание в класс. Всё, можно использовать. Требуются переменное число полей (например, параметры товара) — пишется не один класс товара, а кроме него — класс «параметр товара», массив которых и дёргается объектов «товар»: _http://rp1990.ru/catalogue/object/1806/

У меня ООП головного мозга, поэтому стараюсь всегда предельно разделять сущности объектов. В итоге, обычно, получается быстро, удобно и логично :)

ну так же и у меня - нужно новое поле - добавил в бд и в шаблон объкта, можно использовать