Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
А как насчет фильтров на дополнительные поля или сортировки по таким полям? Мы рассматривали такой вариант, как хранение всех атрибутов в текстовом виде в xml, но он кучу подобного рода ограничений накладывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 17:49 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
VladiChСуществующие средства маппинга работают по всем трем вариантам + их вариации, но они нам все не очень подходят, т.к. в нашей системе помимо маппинга хранятся свои метаданные, которые могут изменяться из приложения + не для каждого типа требуется своя таблица (если все атрибуты типа - т.н. "статические"). То есть это комбинация стандартного маппинга с class table inheritance и хранением метаданных как объектов системы и хранением всех "статических" атрибутов всех объектов в отдельной таблице. Метаданные здесь стоят перпенидикулярно. Если вы сами в силах карандашом на бумажке для каждого атрибута класса написать однозначное соответствие атрибут --> (таблица, поле), то все то же самое можно сделать и в файле описания маппинга. Поскольку у вас обратный инжиниринг, то понадобятся всякие вспомогательные классы и неочевидные на уровне БД иерархии и ассоциации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 17:51 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
А если сериализовать каждый атрибут как отдельную строку в некой таблице - получается то же самое, что сейчас есть. Других вариантов сериализации я пока не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 17:51 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
2Templar. Совсем не перпендикулярно. Метаданные тут к тому, что они могут меняться в процессе работы приложения, при этом не меняется структура базы данных (т.к. меняться могут только текстовые атрибуты, которые хранятся по-другому, не так как остальные). И конечно это делается без перекомпиляции приложения и ручной настройки маппинга. Получается что обратный инжениринг в этом случае перпендикулярен. Прочитайте внимательнее то, что я об этом писал, если что непонятно - объясню подробнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 17:56 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Мы рассматривали такой вариант, как хранение всех атрибутов в текстовом виде в xml, но он кучу подобного рода ограничений накладывает да нет же, не в виде xml хранить, а в виде все той же структуры таблиц объек-атрибут-значение, запросов соответственно для получения данных будет несколько. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 17:57 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
В том то и дело, что для части атрибутов я могу написать на бумажке соответствие атрибут -> поле в таблице, а для части атрибутов соответствие будет атрибут -> строка в таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 17:57 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Роман Дынник Мы рассматривали такой вариант, как хранение всех атрибутов в текстовом виде в xml, но он кучу подобного рода ограничений накладывает да нет же, не в виде xml хранить, а в виде все той же структуры таблиц объек-атрибут-значение, запросов соответственно для получения данных будет несколько. И чем это тогда будет отличаться от того, что есть сейчас? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 17:59 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
а вы что вообще тогда хотите получить? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 18:00 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Да тут спор вообще-то начался из-за того, что мне посоветовали не заниматься ерундой и выбрать существующее ORM-средство. И я уже половину топика объясняю, почему это будет неудобно. Вот и вы мне тут объясняете что-то, а в результате пришли к тому, что уже сейчас реализовано :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 18:03 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
...в свое время причиной отказа от существующих orm-средств для меня послужило отсутствие нормального маппинга на хп. ... Описанную вами задачу может решить не средство orm, а скорее средство MDA, Bold например, но в данном случае вы отказываетесь от ручной поддержки структуры БД и возлагаете эту миссию на MDA средство которое по UML-диаграмме контролирует структуру данных . как следствие отпадает необходимость существования структуры объект-атрибут-значение. При этом конечный пользователь управляет моделью UML, а не создает атрибуты из какого-либо интерфейса приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 18:20 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Расслабьтесь, сама задача в том объеме, в котором была описана, уже решена :). Изначально топик создавался для того, чтобы прикинуть, что получится с этим решением при больших объемах данных (просто некоторые подозрения возникли, которые мне тут благополучно развеяли :)). MDA - это конечно хорошо, но UML-диаграммы - это слишком круто для обычного пользователя. Да и не для обычного тоже мне кажется проще реализовать изменение структуры данных в своем конфигураторе. В нем можно в принципе незначительно менять и структуру БД - для обычных атрибутов и редактировать описание связей. Это пока не реализовано, но я думаю будет следующим шагом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 18:27 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
У варианта с дополнительными атрибутами в отдельной таблице есть еще одно преимущество по сравнению с хранением атрибутов разных типов в разных таблицах - это возможность сквозного текстового поиска по всем типам данных без использования средств типа full-text search. Другими средствами организовать это довольно проблематично. Ну и еще одно преимущество - это собственно изменение структуры данных без изменения структуры БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 18:33 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
У меня это уже реализовано :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2005, 19:45 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
VladiCh Вопросы: Насколько будет замедляеться вставка в таблицу, при возрастании количества отношений один-к-одному к ней? Кол-во дочерних классов - это кол-во FK на родительскую таблицу. Чем больше их, тем больше серверу проверять. Но если в дочерних есть индекс на ссылающееся поле ( а он будет, ибо это - ПК дочерней таблицы), то практически замедления никакого не будет, ибо - индексный поиск, O(log(n)). Но самое главное - это все не для операций вставки , а для операций удаления. При вставках у вас эти FK проверяться не будут. Так что просто никакого влияния это не оказывает на создание экземпляров классов-братьев. А вот другое дело - вставка в родительскую таблицу всегда будет узким местом, его нужно грамотно уметь разводить, но это уже детали реализации, в основном, СУБД. VladiCh Насколько быстро выполняется выборка из таблиц, связанных по ключу при отношении один-к-одному (скажем по отношению к один-ко-многим - также, быстрее, медленнее)? Пофигу. Т.е. сам JOIN пофигу, а так естественно, чем больше записей генерирует запрос за счет "один-ко-многим" - тем медленнее выборка. Просто потому что записей больше. На практике join-ы у нас вообще никогда не тормозили, хоть в иерархии было по 10 уровней иногда. VladiCh Насколько серьезно все это будет тормозить при возрастании количества данных? Не более серьезно, чем в обычной БД с обычными таблицами (в смысле без применения наследования). Просто вообще никакой разницы. Но вообще log(n) - он рулит!! VladiCh Интересует опыт людей, работавших с аналогичными структурами данных, субъективная оценка. Опыт есть огромный в данном вопросе, он в общем согласуется с тем, что я написал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 03:04 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
VladiCh2Templar. Совсем не перпендикулярно. Метаданные тут к тому, что они могут меняться в процессе работы приложения, при этом не меняется структура базы данных (т.к. меняться могут только текстовые атрибуты, которые хранятся по-другому, не так как остальные). И конечно это делается без перекомпиляции приложения и ручной настройки маппинга. Получается что обратный инжениринг в этом случае перпендикулярен. Прочитайте внимательнее то, что я об этом писал, если что непонятно - объясню подробнее. У вас что, атрибуты хранятся вертикально? Тогда это нереляционная модель, а потому ORM не подходит по определению. Если сможете вначале свою доморощенную модель привести к реляционной, например, с помощью проекций, тогда все получится. P.S. Присоединяюсь к MasterZiv, особенных проблем нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 14:27 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Часть атрибутов горизонтально, часть вертикально. Насчет того что нереляционная модель - это вы конечно загнули... Вполне реляционная, просто часть атрибутов выбирается одной строкой, а часть списком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 15:11 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
>>>У вас что, атрибуты хранятся вертикально Templar, тут ядро для всех модулей - горизонтально, а расширенные атрибуты - вертикально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 17:34 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Роман Дынниктут ядро для всех модулей - горизонтально, а расширенные атрибуты - вертикально. Теперь ясно :) Тоже проецируется без особых проблем. Расширенные атрибуты идут как коллекция объектов класса "Атрибут" и иже с ним. VladiCh, это НЕреляционная структура. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 18:11 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Да понятно, что в принципе проецируется, любую реляционную БД во что-нибудь объектное можно спроецировать, вопрос в том, насколько потом с этим удобно будет работать :). Если поставить своей задачей во чтобы то ни стало заставить работать с такой структурой например nHibernate, я думаю, что такую задачу можно решить, но толку от этого будет мало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 18:32 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
2Templar. 1. На уровне логики приложения нет разделения на обычные - нерасширенные атрибуты. Об этом знает только слой доступа к данным. В случае с ORM слой доступа к данным находится внутри (ORM), поэтому придется вводить еще один слой, делающий прозрачным обращения к атрибутам любого типа. 2. Если реализовывать это предлагаемым вами способом, даже банальная загрузка атрибутов для коллекции объектов будет менее эффективной, чем специализированное решение, а про загрузку с различными сортировками / фильтрами по "расширенным" атрибутам и говорить нечего. Стандартные ORM-средства для таких задач неприспособлены и если их все-таки прикрутить, то эффективность генерируемых ими запросов будет весьма низкая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2005, 18:59 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
VladiCh2. Если реализовывать это предлагаемым вами способом, даже банальная загрузка атрибутов для коллекции объектов будет менее эффективной, чем специализированное решение, а про загрузку с различными сортировками / фильтрами по "расширенным" атрибутам и говорить нечего. Стандартные ORM-средства для таких задач неприспособлены и если их все-таки прикрутить, то эффективность генерируемых ими запросов будет весьма низкая. Я об этом сказал в самом начале. У вас НЕреляционная структура с вертикальным хранением атрибутов. Поэтому не только ORM, где R - это relational, но и обычный SQL в качестве средства запросов будет неэффективным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2005, 13:22 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Уважаемый Templar. Не хотелось бы здесь много времени уделять доказательствам того, что более эффективно, что менее. Просто поверьте на слово, что если соответствующим образом построить структуру базы данных и спроектировоать приложение, то запросы на выборку таких атрибутов будут довольно эффективными, а в некототрых случаях даже эффективнее, чем запросы на выборку из таблиц с горизонтальным хранением атрибутов. Например, при выборке коллекции, в которых содержатся разнородные объекты, в случае с вертикальным хранением, мне вернется один рекордсет, с горизонтальным столько, сколько типов объектов находится в коллекции, т.е. теоретически неограниченное количество. Да, структура нереляционная, если ее рассматривать с вашей точки зрения, как набор обычных атрибутов объектов. Если же представить, что все вертикально хранимые атрибуты - это просто некие сериализованные XML-данные объекта, то структура вполне реляционная. Как они представляются в приложении - это другой вопрос. Все зависит от точки зрения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2005, 09:41 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Да, еще по поводу эффективности. В общем случае SQL в качестве языка запросов к таким данным будет менее эффективен. Но у нас на уровне бизнес-логики и не используется SQL, используется свой довольно простой язык запросов, который транслируется в довольно эффективный для данной структуры SQL. Да, он менее гибкий и гораздо более проостой, чем SQL, но нашим требованиям вполне удовлетворяет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2005, 09:44 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Уважаемый VladiCh, при вертикальном хранении SQL в принципе не может быть эффективнее, т.к. требует большего числа joins. Если у вас чистый OLTP, то это не помеха. Если хотя бы несложные поиски со связыванием 3-5 сущностей, то соедиений будет не 3-5, а 9-15. Вы пошли по пути содзания собственной надстройки, это один из вариантов. Другой вариант - максимальное использование стандартных средств. Наприиер Роман вам предлагал раскрутить данные в реляцонную форму (например, через view) и далее по известной методе. Никто не говорит, что первый вариант плох или наоброт. Какой вариант оптимальнее в ваших условиях - вам и решать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2005, 13:31 |
|
||
|
Наследование атрибутов
|
|||
|---|---|---|---|
|
#18+
Связывание сущностей у нас производится только по горизонтально хранимым атрибутам. Вертикально хранимые, как я уже говорил, вспомогательные, и 90% из них - текстовые. Поиск и сортировка производится по вертикально хранимым атрибутам точно также как и по горизонтально хранимым без дополнительных накладных расходов. К чему я это все говорю - к тому, что при правильном использовании нашей модели (вертикально + горизонтально хранимые атрибуты) - т.е. с определенными ограничениями + использование адаптированной под эту структуру надстройки, потерь производительности по сравнению с горизонтально хранимыми атрибутами почти не будет, зато появляются определенные преимущества, про которые я тоже писал выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2005, 08:51 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=33211321&tid=1545694]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
80ms |
get tp. blocked users: |
1ms |
| others: | 260ms |
| total: | 444ms |
| 0 / 0 |
