Здравствуйте, dimzon, Вы писали:

D>Ну ладно, наверно хватит флеймить, есть предложения/пожелания/советы по существу?

У меня вот такие предложения, которые можно было бы реализовать в XML-DB маппере. В тех приложениях, которые разрабатывает наша компания, такие штуки бывают очень полезными.

1. Свойством объекта считать не только его дочерние элементы, но и атрибуты. Вообще, атрибут — елемент должны быть с легкостью взаимозаменяемыми, ибо в разных ситуациях удобнее юзать либо то, либо другое.

2. Предусмотреть возможность работы с повторяющимися дочерними элементами. Например, у персоны может быть не один телефон, а несколько. Естественно, в базе это будет лежать в отдельной таблице. В общем случае, такие повторяющиеся элементы могут иметь не только скалярное значение, но и быть некими субструктурами.

3. Некоторые дочерние элементы (не атрибуты) могут быть языкозависимыми. В XML они будут размечены атрибутом xml:lang, в базе — храниться в отдельной таблице. Опять же, языкозависимыми могут быть не только отдельные строки, но и целые структуры.

4. Наконец, часть элементов XML структуры может не иметь соотв. полей в таблицах базы, а складываться в одно большое поле прямо в XMLном виде. Очень пользительно, когда у объекта есть пара сотен свойств, по которым не нужны поиск, индексирование и т.п.

Здравствуйте, lazymf, Вы писали:

D>>Раскажите, плиз, о методологии работы мепера или может дадите ссылочку где можно почитать об этом.
L>Вот здесь есть кое-какая инфа.

Вот ведь чувак поднялся! Ну просто все его цитируют и берут за основу своих продуктов. И все из-за того, что никто больше ничего цельного по этому поводу не написал. А ведь в сущности, его "белая бумага" никаких звезд с неба не хватает. Немного теоретического анализа, плюс общие очертания возможной реализации. На мое ХО, далеко не самой удобной.

Здравствуйте, Андрей Майоров, Вы писали:

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

Все так, но где же конструктив? Дай ссылку на что-нибудь более полезное.

Здравствуйте, lazymf, Вы писали:

L>Все так, но где же конструктив? Дай ссылку на что-нибудь более полезное.

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

Здравствуйте, Андрей Майоров, Вы писали:

АМ> 1. Свойством объекта считать не только его дочерние элементы, но и атрибуты. Вообще, атрибут — елемент должны быть с легкостью взаимозаменяемыми, ибо в разных ситуациях удобнее юзать либо то, либо другое.
Хм. Не совсем ибо элементы типизированные. + Эти элементы могут нести дополнительные служебные атрибуты. Однако часть служебных свойств объекта (первичный ключ, версия) будут аттрибутами.

АМ> 2. Предусмотреть возможность работы с повторяющимися дочерними элементами. Например, у персоны может быть не один телефон, а несколько. Естественно, в базе это будет лежать в отдельной таблице. В общем случае, такие повторяющиеся элементы могут иметь не только скалярное значение, но и быть некими субструктурами.
Если ты подразумеваешь связи ОДИН КО МНОГИМ и МНОГИЕ КО МНОГИМ то ес-нно маппер будет поодерживать это счастье.


АМ> 3. Некоторые дочерние элементы (не атрибуты) могут быть языкозависимыми. В XML они будут размечены атрибутом xml:lang, в базе — храниться в отдельной таблице. Опять же, языкозависимыми могут быть не только отдельные строки, но и целые структуры.
Хм. А можно use case этого счастья? Я в том смысле что хочу оценить насколько сильно это нужно и соотв. стоит ли заморачиваться.

АМ> 4. Наконец, часть элементов XML структуры может не иметь соотв. полей в таблицах базы, а складываться в одно большое поле прямо в XMLном виде. Очень пользительно, когда у объекта есть пара сотен свойств, по которым не нужны поиск, индексирование и т.п.
А в чём цимус, товарисч? Прикинь если к концу разработки проекта потребуется поиск по такому "свойству". Чё делать будешь? А если отчёт строить? Моё мнение что быстрее и лучше обычного SELECT-а с отбором данных для отчета никто не справится. Всякие маппинги они для редактирования/модификации/вставки хороши — жизнь упрощают а вот если данные нужны только для чтения — тут однозначно обычный SELECT. Не, думаю не надо смешивать реляционную БД и XML-ный middleware таким образом

Здравствуйте, dimzon, Вы писали:

АМ>> 1. Свойством объекта считать не только его дочерние элементы, но и атрибуты. Вообще, атрибут — елемент должны быть с легкостью взаимозаменяемыми, ибо в разных ситуациях удобнее юзать либо то, либо другое.
D>Хм. Не совсем ибо элементы типизированные. ...

А что, тип элемента будет указан прямо на элементе? Не лучше ли это делать в отдельном настроечном файле?

АМ>> 2. Предусмотреть возможность работы с повторяющимися дочерними элементами. Например, у персоны может быть не один телефон, а несколько. Естественно, в базе это будет лежать в отдельной таблице. В общем случае, такие повторяющиеся элементы могут иметь не только скалярное значение, но и быть некими субструктурами.
D>Если ты подразумеваешь связи ОДИН КО МНОГИМ и МНОГИЕ КО МНОГИМ то ес-нно маппер будет поодерживать это счастье.

Не совсем так. То есть ты, конечно, прав, это можно выразить связью 1->*, но о таком решении нужно говорить, скорее, в том случае, если у нас одна таблица соответствует одному объекту. Я же говорю о сохранении/загрузке более-менее полноценного типа в стиле XSD. У него могут быть сабэлементы, которые могут повторяться несколько раз, но все это в комплексе является одним "куском" данных.

АМ>> 3. Некоторые дочерние элементы (не атрибуты) могут быть языкозависимыми. В XML они будут размечены атрибутом xml:lang, в базе — храниться в отдельной таблице. Опять же, языкозависимыми могут быть не только отдельные строки, но и целые структуры.
D>Хм. А можно use case этого счастья? Я в том смысле что хочу оценить насколько сильно это нужно и соотв. стоит ли заморачиваться.

Хочется, чтобы можно было спокойно работать с таким вот XML, например:

<item id="">
    <displayName xml:lang="ru">...</displayName>
    <displayName xml:lang="en">...</displayName>
</item>

Или, вот с таким:

<item id="">
    <locale xml:lang="ru" name="">
        <description>...</description>
    </locale>
    <locale xml:lang="en" name="">
        <description>...</description>
    </locale>
</item>

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

АМ>> 4. Наконец, часть элементов XML структуры может не иметь соотв. полей в таблицах базы, а складываться в одно большое поле прямо в XMLном виде. Очень пользительно, когда у объекта есть пара сотен свойств, по которым не нужны поиск, индексирование и т.п.
D>А в чём цимус, товарисч? Прикинь если к концу разработки проекта потребуется поиск по такому "свойству". Чё делать будешь? А если отчёт строить? Моё мнение что быстрее и лучше обычного

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

D> SELECT-а с отбором данных для отчета никто не справится. Всякие маппинги они для редактирования/модификации/вставки хороши — жизнь упрощают а вот если данные нужны только для чтения — тут однозначно обычный SELECT. Не, думаю не надо смешивать реляционную БД и XML-ный middleware таким образом

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