Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Наследование атрибутов / 25 сообщений из 77, страница 1 из 4
  1  все
08.08.2005, 20:28
    #33206513
VladiCh
VladiCh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
Ситуация:
Есть база данных, в которую сериализуются объекты различных типов из .NET-овского клиента.
Между объектами могут существовать различные отношения - наследование, агрегирование и т.п.
Наследование на уровне базы данных реализовано при помощи отношения один-к-одному. Уровней иерархии наследования в среднем 2-3. У всех объектов существует общий предок. Типов объектов достаточно много (несколько десятков, в перспективе до сотни-двух), соответственно столько и отношений один-к-одному к таблице, хранящей информацию о самых базовых объектах.

Вопросы:
Насколько будет замедляеться вставка в таблицу, при возрастании количества отношений один-к-одному к ней? Насколько быстро выполняется выборка из таблиц, связанных по ключу при отношении один-к-одному (скажем по отношению к один-ко-многим - также, быстрее, медленнее)?
Насколько серьезно все это будет тормозить при возрастании количества данных?

Интересует опыт людей, работавших с аналогичными структурами данных, субъективная оценка.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 14:32
    #33206893
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
VladiChТипов объектов достаточно много (несколько десятков, в перспективе до сотни-двух),

Ну и не дурили бы народу мозги и сказали бы КЛАСС, а не объкт, потом тип объектов....
VladiCh
Вопросы:
Насколько будет замедляеться вставка в таблицу, при возрастании количества отношений один-к-одному к ней? Насколько быстро выполняется выборка из таблиц, связанных по ключу при отношении один-к-одному (скажем по отношению к один-ко-многим - также, быстрее, медленнее)?
Насколько серьезно все это будет тормозить при возрастании количества данных?
1. Смотря куда?? Если есть отношение Автомобиль-ЛегковойАвтомобиль-Волга, то при вставке в таблицу Автомобиль, вообще не зависит от кол-ва потомков. Если в ЛегковойАвтомобиль, то зависит от кол-ва записей в таблице Автомобиль, хотя не на много, т.к. проверка идет по индексу. Если в табл. Волга, то то зависит от кол-ва записей в таблице ЛегковойАвтомобиль, хотя не на много, т.к. проверка идет по индексу.
2. Теоретически быстрее чем один-ко-многим, хотя это скорее всего зависит от кол-ва связываемых таблиц.
3. Любая БД на тестовых небольших данных показывает наилучшую производительность, чем при больших данных. Все зависит от запросов, проверок, вставок, и индексов.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 14:54
    #33206960
VladiCh
VladiCh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
basНу и не дурили бы народу мозги и сказали бы КЛАСС, а не объкт, потом тип объектов....
Дело в том, что класс в этой системе тоже является объектом, поэтому устоялась терминология - объект и тип. Информация о всех типах объектов и их атрибутах (метаданные) описана в этой же базе данных рекурсивно, т.е. эти описания также являются объектами системы.

Отношения примерно такие:
Объект - Автомобиль - Легковой автомобиль - Волга
То есь при добавлении любого объекта обязательна вставка в таблицу "Объект". Соответственно в этой таблице записей будет столько же, сколько в системе объектов (теоретически могут быть сотни тысяч - миллионы объектов).
При добавлении новой "Волги" прийдется вставлять данные в 4 таблицы.
Соответственно при выборке всех "Волг" придется связывать 4 таблицы.
Запросы на выборку, вставку и т.п. генерируются автоматически на основании метаданных. То есть это что-то типа небольшой ORM-системы.

basТеоретически быстрее чем один-ко-многим, хотя это скорее всего зависит от кол-ва связываемых таблиц.
Насколько быстрее и за счет чего?

basЛюбая БД на тестовых небольших данных показывает наилучшую производительность, чем при больших данных. Все зависит от запросов, проверок, вставок, и индексов
Это понятно, поэтому и интересует опыт людей, делавших что-то подобное. Понятно, что это все зависит от запросов, но хотя бы в первом приближении, можно ли оценить так сказать скорость замедления работы при увеличении количества объектов и/или типов объектов в системе?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 15:37
    #33207093
Old Nick
Old Nick
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
Как предполагается работа с наборами объектов?

1 вариант:

select * from Objects o join Automobiles a on a.ID = o.ID where a.WhealsCount = 4

2 вариант:

while(true)
{
Automobile auto = Automobile()
auto.Serialize()
if auto.WhealsCount = 4
{
...
}
}
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 16:31
    #33207320
Alexey Rovdo
Alexey Rovdo
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
VladiChСитуация:
Есть база данных, в которую сериализуются объекты различных типов из .NET-овского клиента.
Между объектами могут существовать различные отношения - наследование, агрегирование и т.п.
Наследование на уровне базы данных реализовано при помощи отношения один-к-одному. Уровней иерархии наследования в среднем 2-3. У всех объектов существует общий предок. Типов объектов достаточно много (несколько десятков, в перспективе до сотни-двух), соответственно столько и отношений один-к-одному к таблице, хранящей информацию о самых базовых объектах.

Вопросы:
Насколько будет замедляеться вставка в таблицу, при возрастании количества отношений один-к-одному к ней? Насколько быстро выполняется выборка из таблиц, связанных по ключу при отношении один-к-одному (скажем по отношению к один-ко-многим - также, быстрее, медленнее)?
Насколько серьезно все это будет тормозить при возрастании количества данных?

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

Эх, а ведь именно для таких случаев могут оказаться полезны объектные СУБД.
И именно проблему быстродействия при вставке в таблицы, связанные gj ключу, мы исследовали при сравнении ООСУБД Versant FastObjects с Sybase и Oracle в этой ветке.

Основываясь на полученных результатах, можно заметить, что в описанных в вопросе условиях торможение будет весьма существенным, особенно при больших (более 2-3 Гб или более 2-3 млн. записей) объемах данных. Единственный способ борьбы - отключение констрейнтов и индексов. Цена вопроса - порядки (т.е. быстродействие может изменяться на несколько порядков).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 16:31
    #33207326
VladiCh
VladiCh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
Есть прототип языка запросов, в котором можно задавать фильтры, т.е. что-то типа "Automobiles:WhealsCount = 4", это в результате разворачивается в вариант 1
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 16:35
    #33207344
Old Nick
Old Nick
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
Но в таком случае заковыристых запросов не написать, только простые, остальные буду в апликейшн-сервере обрабатываться?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 16:36
    #33207347
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
VladiCh
Отношения примерно такие:
Объект - Автомобиль - Легковой автомобиль - Волга
То есь при добавлении любого объекта обязательна вставка в таблицу "Объект". Соответственно в этой таблице записей будет столько же, сколько в системе объектов (теоретически могут быть сотни тысяч - миллионы объектов).
При добавлении новой "Волги" прийдется вставлять данные в 4 таблицы.
Соответственно при выборке всех "Волг" придется связывать 4 таблицы.
Запросы на выборку, вставку и т.п. генерируются автоматически на основании метаданных. То есть это что-то типа небольшой ORM-системы.

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

VladiCh basТеоретически быстрее чем один-ко-многим, хотя это скорее всего зависит от кол-ва связываемых таблиц.
Насколько быстрее и за счет чего?

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

VladiCh
Понятно, что это все зависит от запросов, но хотя бы в первом приближении, можно ли оценить так сказать скорость замедления работы при увеличении количества объектов и/или типов объектов в системе?
А че Вы не можите предусмотреть какие понадобятся запросы к БД, вот все их проанализируйте и поймете во сколько раз будут тормоза.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 16:48
    #33207404
Роман Дынник
Роман Дынник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
В плане опыта могу сказать вот что:
таблицу общего предка побейте для создания partitioned view(mssql) или partitioned table(oracle) так как там будет оооочень большое kоличество записей. Бить ее лучше прямо по ID, причем порциями сначала линейновозрастающими, потом как удобно. Например, пусть в первой порции мы хотим держать какие-либо метаданные которые часто используются (объекты типа класс, константы...) разумно эти данные поместить в первую партицию и под эту порцию выделить ID c 1 по 1000, другие партиции по усмотрению.
Если в качестве первичного ключа вы используете GUID то для таблицы единого предка сделайте составной первичный ключ ID,GUID , в этом случае все потомки также будут содержать ID и GUID, но для внешних связей использовать только GUID (как альтернативный ключ). ID в данном случае нам нужен только чтоб побить общего предка (ID в данном случае может быть не уникальным), а возможно и потомков на партиции.

Дальнейшие опасения в плане времени на CRUD операции решаются советами с DBA, так можно посоветовать например разнести таблицы, индексы по различным файловым группам/tablespace, использовать distributed partitions ...

P/S/
Думаю вы выбрали правильную дорогу.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 16:58
    #33207452
gardenman
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
Вообще-то в Db2 подобная проблема решена очень давно с использованием структурных типов и типизированных таблиц. Например:


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
set current schema tst@

-- создаем пустой (абстрактный) тип без атрибутов
сreate type customer_t
mode db2sql
not instantiable
not final
@

-- создаем субтип
create type person_t under tst.customer_t as (
	name char( 35 ),
	birthday date
) mode db2sql
instantiable
@

-- создаем еще один субтип
create type org_t under tst.customer_t as (
	name char( 35 ),
	inn  char( 12 )
) mode db2sql
instantiable
@

create table cust (
	customer_id int not null,
	customer tst.customer_t,
	primary key (customer_id)
)
@

insert into cust values
(  1 , tst.person_t()..name('John Smith')..birthday(current date)),
(  2 , tst.org_t()..name('John Smith')..inn('1234567890'))
@

select 
	customer_id,
	substr(rtrim(type_name(customer))||'.'||rtrim(type_schema(customer)), 1 , 30 )
from
	cust
@

CUSTOMER_ID  2                              
----------- ------------------------------
           1  PERSON_T.TST                  
           2  ORG_T.TST
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 16:58
    #33207455
Old Nick
Old Nick
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
У нас в таблице базовых объектов было полмиллиона записей с кластерным ключем по идентификатору. Проблем с производительностью не было никаких
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 17:00
    #33207463
VladiCh
VladiCh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
2Old Nick
Так язык запросов и не претендует на полную универсальность. Более 90% наших потребностей он покрывает, т.е. выборки с условиями, выборки связанных объектов и т.п. Более сложные выборки можно реализовать например работая не с физическими таблицами, а используя логические - view + триггера на вставку и удаление. А то, что нельзя реализовать и так, можно действительно реализовать в сервере приложений (ну или на худой конец, расширить язык запросов, в его реализации мы никак не связаны).

По поводу отключения constraint'ов и триггеров - а самому это отслеживать не дороже ли получится в плане быстродействия?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 17:02
    #33207476
VladiCh
VladiCh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
2Old Nick: Полмиллиона записей - не так уж и много. А количество типов объектов и средний уровень вложенности наследования какой был?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 17:06
    #33207492
VladiCh
VladiCh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
2gardenman: Ну так не во всех субд подобная функциональность имеется. Конечно идеальный вариант, чтобы наследование поддерживалось на уровне СУБД, но увы, в MSSQL подобной функциональности нет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 17:09
    #33207502
Old Nick
Old Nick
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
Средний уровень вложенности наверное 3-4. Количество типов около 120. Примерно половина из них не имеет физических таблиц.

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 18:08
    #33207680
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
VladiCh2gardenman: Ну так не во всех субд подобная функциональность имеется. Конечно идеальный вариант, чтобы наследование поддерживалось на уровне СУБД, но увы, в MSSQL подобной функциональности нет.

Так берите Cache и дешевле будет и веживаться не надо, ну если надо конкретно ООБД, то и надо использовать ООСУБД или СУБД, поддерживающеая ОО. А то опять велосипед получается.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 18:14
    #33207696
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
VladiCh
По поводу отключения constraint'ов и триггеров - а самому это отслеживать не дороже ли получится в плане быстродействия?
Я имел ввиду отключить только фориген кеи, да и то после того как логика приложения будет оттестирована и сдана в эксплуатация и нет никаких сообщений типа, связанных с ФК, вот тогда и можно отключить, и при внесении чего-то нового опять на некоторое время включить констрейны.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 18:20
    #33207714
VladiCh
VladiCh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
basТак берите Cache и дешевле будет и веживаться не надо, ну если надо конкретно ООБД, то и надо использовать ООСУБД или СУБД, поддерживающеая ОО. А то опять велосипед получается.
У нас есть определенные требования, которые трудно реализовать существующими средствами. Например не под каждый класс заводится своя таблица, так же как похоже и у Old Nick. Данные разбиваются на 2 категории - т.н. "статические" - хранятся в текстовом виде в отдельной таблице и т.н. "динамические" - хранятся в своих таблицах. Также атрибуты объектов являются не списком, а иерархией, т.к. система предназначена в основном для хранения документов. Честно говоря не знаком с Cache, так что не знаю как там и что реализовано, но из тех ORM и OOСУБД, которые я смотрел, ничего, что можно использовать в качестве основы, серьезно не дорабатывая, не нашел.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 18:34
    #33207736
Old Nick
Old Nick
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
Каше именно так и хранит данные, как Вы у себя проектируете, причем к ним можно получить доступ и в виде таблиц. Так что может быть действительно стоит на нее посмотреть и код можно писать на С# и на Java и еще много на чем
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 19:00
    #33207771
Jericho
Jericho
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
bas VladiCh2gardenman: Ну так не во всех субд подобная функциональность имеется. Конечно идеальный вариант, чтобы наследование поддерживалось на уровне СУБД, но увы, в MSSQL подобной функциональности нет.

Так берите Cache и дешевле будет и веживаться не надо, ну если надо конкретно ООБД, то и надо использовать ООСУБД или СУБД, поддерживающеая ОО. А то опять велосипед получается.

нуу ООСУБД эт конечно интересно и классно но не проще ли вместо изучения новой субд и попробовать нечто среднее например Hinername (Java), NHIbernate (.NET) или другой ORM ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 19:11
    #33207791
VladiCh
VladiCh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
ORM не катит, т.к. тут обратное преобразование - скорее ROM, чем ORM :) и довольно специфическое. А насчет Cache - теперь переделывать уже поздно, ядро практически уже готово и свою функцию выполняет. Да и связываться с новой СУБД не хочется, думаю на изучение ее возможностей ушло бы приличное время, да и тут всякие нетехнические моменты есть, по которым предпочтительнее MSSQL.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 19:29
    #33207800
Jericho
Jericho
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
VladiChORM не катит, т.к. тут обратное преобразование - скорее ROM, чем ORM :) и довольно специфическое. А насчет Cache - теперь переделывать уже поздно, ядро практически уже готово и свою функцию выполняет. Да и связываться с новой СУБД не хочется, думаю на изучение ее возможностей ушло бы приличное время, да и тут всякие нетехнические моменты есть, по которым предпочтительнее MSSQL.
Может я не совсем четко отследил Вашу мысль, но поясните пожалста почему ОРМ не проходит?
Насколько я понял у вас есть некая таблица в которой хранятся Oid всех сущностей используемых в системе и эта таблица связана с иными как 1-N т.е. в остальных таблицах хранятся аттрибуты этих объектов (в одной таблице может хранится несколько однотипных аттрибутов разных объектов)....
так же у вас базовый класс всех сущностей представлен в этой таблице как объект и все явно или косвенно наследуются от него. Вас беспокоит так же вопрос производительности системы при расширении базовой таблицы до нескольких миллионов экземпляров объектов, но этот вопрос имхо очень хорошо прокоментировал Роман Дынник. и мне трудно найти причины, кроме уже существующего оттестированного набора процедур с реализованной в них сложной бизнес логикой, для отказа от ORM (хотя некоторые орм могут использовать и хранимые процедуры для выбора сущностей).
Если я все правильно понял из вышеизложенной ветки дискуссии то поясните ваш отказ от ОРМ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 19:47
    #33207813
VladiCh
VladiCh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
ORM обычно используется как порождение структуры базы данных на основе классов, здесь ситуация противоположная - существующие сущности в базе данных маппятся на классы, которые можно или автоматически генерировать или писать вручную. То есть разработка системы начинается от базы данных, а не от ее клиента. С каждым классом может быть связана своя логическая таблица (которая реально может быть и view), а может и не быть связана.
Часть атрибутов объекта хранится в таблице, связанной с его типом ("динамические атрибуты"), часть в отдельной таблице, которая одна на все типы ("статические атрибуты" - как правило это текстовая информация, не участвующая в бизнес-операциях). Текстовую информацию удобно хранить таким образом, т.к. по ней производится общий поиск и легко можно выполнять различный анализ этой информации без привязки к конкретному типы объекта. Если нужна скорость вставки, то все поля объекта могут быть "динамическими" - храниться в таблице, связанной с типом объекта.

Таблица, в которой хранятся OID объектов - это таблица базового типа. Таблицы дочерних типов относятся к ней 1-1. Как навешать на это все обычный OR-маппинг?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 19:51
    #33207815
VladiCh
VladiCh
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
Да, еще - атрибуты объекта организованы в дерево, а не простым списком, что тоже непонятно как реализовать в обычном ORM.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.08.2005, 19:53
    #33207818
Old Nick
Old Nick
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Наследование атрибутов
У меня есть уже готовая система с ROM (как Вы его назвали)

Создание новых классов выполняется прямо из интерфейса приложения, оттуда же создание методов классов. А также автоформы для редактирования объектов.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Наследование атрибутов / 25 сообщений из 77, страница 1 из 4
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]