ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / посоветуйте БД для хранения сложносвязных объектов
23 сообщений из 23, страница 1 из 1
посоветуйте БД для хранения сложносвязных объектов
    #38579179
baleog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baleog
Гость
Есть задача хранить в БД сложносвязные объекты:
* У классов глубокое наследование (макс. глубина до пары десятков)
* Есть "вложенные" объекты
* Множество полиморфных ассоциаций (многое к 1, 1 ко многим, многое ко многим).
* Все ассоциации двусторонние

Фактически полей у объектов немного, а вот ассоциаций в среднем штук по 10 у каждого.

Желательны:
* транзакционность
* параллельная запись

Посоветуйте, пожалуйста, БД для такой ситуации.

Вроде бы по функционалу подходит JPA совместимый фреймворк для sql сервера - но смущает необходимость большого числа join'ов
...
Рейтинг: 0 / 0
05.03.2014, 16:01
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38579264
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DPH3
Участник
baleog,

А что с этими сложными объектами надо потом делать? Только хранить в БД или искать по произвольным сложносочиненным запросам?
Обновляется сразу большой и сложный объект или каждый из его кусочков?
И какие требования к производительности, сколько будет этих объектов и т.п.?
...
Рейтинг: 0 / 0
05.03.2014, 17:01
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38579287
baleog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
baleog
Гость
> Только хранить в БД или искать по произвольным сложносочиненным запросам?

и хранить и поиск. Поиск по Id либо запрос всех объектов заданного класса и его потомков. Полнотекстовый поиск будет нужен очень редко

> Обновляется сразу большой и сложный объект или каждый из его кусочков?

Весь объект обновляется. Обновлять только измененные поля было бы неплохо, но не обязательно

> И какие требования к производительности, сколько будет этих объектов и т.п.?

Объекты хранятся "пакетами". В каждом пакете порядка 100 тысяч объектов. Пакетов может быть сотни.
Обновление 1000 объектов со всеми связями не должно превышать 1сек (а лучше меньше).
Важна высокая доступность базы, как на чтение, так и на запись
...
Рейтинг: 0 / 0
05.03.2014, 17:11
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38579311
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DPH3
Участник
baleog,

Хм, можно посмотреть на какую-нибудь документориентированную БД. Cassandra, например, там хотя бы транзакции есть. Монго, конечно, не подходит )

Если отказаться от декларативной ссылочной консистентности на уроне БД, то можно объект со всеми его связями хранить как одну сущность (блобы, сложные структуры, xml-поля - в зависимости от конкретной СУБД). Но тут надо придумать схему проверки целостности на уровне приложения. Тогда и join будет мало и операции сохранения-получения будут очень дешевыми.

Выбор конкретной СУБД тут зависит от личного опыта и денег. Любая из взрослых СУБД подойдет (Oracle, DB2, MS SQL, Postgresql etc)
...
Рейтинг: 0 / 0
05.03.2014, 17:23
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38579360
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Если вы переведете ваши сложносвязанные объекты на язык хранения - достать данные, поменять данные и т.д. то вполне может оказаться что все не так уж плохо (и наследование будет не глубоким, и вложенные объекты не проблема, и ассоциации не вопрос)
baleog Обновление 1000 объектов со всеми связями не должно превышать 1сек (а лучше меньше). Надеюсь вы понимаете, что конкретные цифры упираются скорее в железо и логику запроса, а не в "какую СУБД выбрать".
...
Рейтинг: 0 / 0
05.03.2014, 17:59
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38580347
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
baleogЕсть задача хранить в БД сложносвязные объекты:
* У классов глубокое наследование (макс. глубина до пары десятков)
* Есть "вложенные" объекты
* Множество полиморфных ассоциаций (многое к 1, 1 ко многим, многое ко многим).
* Все ассоциации двусторонние

Фактически полей у объектов немного, а вот ассоциаций в среднем штук по 10 у каждого.

Желательны:
* транзакционность
* параллельная запись

Посоветуйте, пожалуйста, БД для такой ситуации.

Вроде бы по функционалу подходит JPA совместимый фреймворк для sql сервера - но смущает необходимость большого числа join'ов
mysql. обзовите ваши связи тагами и нарисуте пару примитивных SQL запросов вытягивающих вашу фигню по набору тагов
...
Рейтинг: 0 / 0
06.03.2014, 15:47
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38584594
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
Yo.!,

А поподробней, можете?

Как пример: ПХП массив, имеющий глубину вложенности элементов до 5-и, на каждом уровне есть 2-4 простых текстовых поля 8-500 символов, пара числовых и 0-3 булевых. Кроме этого, на каждом уровне есть 2-3 списка по 2-10 подчиненных элементов примерно похожей небольшой структуры. Надо хранить около 100 000 таких экземпляров.

Да, на некоторых подуровнях список элементов может полностью совпадать в разных экземплярах.

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

Сейчас, решаю хранением в явном виде ПХП-массива как статического элемента дочернего класса. Есть код, который из результата формы формирует текст ПХП-скрипта этого класса автоматически. Не это не айс, с т.з. количества наследников (сейчас уже около 300, будет под 100 000). Можно оставить пока и так, потому как на запрос к серверу активируется строго один дочерний класс. Но хочется упихать в БД.

Есть вариант в виде sql-дерева, но количество таблиц, содержащих разные по структуре элементы - около 20. Соответственно даже для безджойнового варианта деревянной выборки (фак в разделе mySql тут) - всё равно надо соединять эти 20 таблиц и через group_concat() строить json массивы для отдачи в ПХП (не проблема, эта часть запроса у меня строится автоматически). В среднем, текст запроса тянет на 10к и поболе.

Собственно экземпляр массива - это набор правил для автоматического выделения содержательной части товарного описания из заданного произвольного текста (прайс-листа). Для каждой новой фирмы - строится один раз и в полуручном режиме.
...
Рейтинг: 0 / 0
12.03.2014, 23:38
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38584666
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
Arhat109Yo.!,

Есть вариант в виде sql-дерева, но количество таблиц, содержащих разные по структуре элементы - около 20. Соответственно даже для безджойнового варианта деревянной выборки (фак в разделе mySql тут) - всё равно надо соединять эти 20 таблиц и через group_concat() строить json массивы для отдачи в ПХП (не проблема, эта часть запроса у меня строится автоматически). В среднем, текст запроса тянет на 10к и поболе.

Собственно экземпляр массива - это набор правил для автоматического выделения содержательной части товарного описания из заданного произвольного текста (прайс-листа). Для каждой новой фирмы - строится один раз и в полуручном режиме.

Если хотите хранить именно массивы, то в PostgreSQL есть средства для работы с массивами.
А так, в начале посоветую проанализировать структуру данных.
Возможно она сможет быть наложена на реляционную структуру без использования массивов.
...
Рейтинг: 0 / 0
13.03.2014, 07:35
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38584830
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
на мой взгляд хватит трех примитивных табличек. arrays, elements, relations. в relations ссылка на массив и елемент. т.е. через relastions один массив может быть "вложен" в несколько элементов других массивов. нумберы, будеаны и чары можно вынести из елементс, не знаю, тут по вкусу. можно сразу подумать на тему партиций, вроде в постгрес они хоть и не совсем правильное но какое-то партиционирование было.
...
Рейтинг: 0 / 0
13.03.2014, 10:36
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38584894
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DirksDR
Участник
baleogЕсть задача хранить в БД сложносвязные объекты:
* У классов глубокое наследование (макс. глубина до пары десятков)
* Есть "вложенные" объекты
* Множество полиморфных ассоциаций (многое к 1, 1 ко многим, многое ко многим).
* Все ассоциации двусторонние

Фактически полей у объектов немного, а вот ассоциаций в среднем штук по 10 у каждого.

Желательны:
* транзакционность
* параллельная запись

Посоветуйте, пожалуйста, БД для такой ситуации.

Вроде бы по функционалу подходит JPA совместимый фреймворк для sql сервера - но смущает необходимость большого числа join'ов
Загляните на форум Cache.
Там есть классы, наследование, вложенность объектов, SQL.
И есть низкоуровневый доступ "key-value" к тем же данным.
Есть возможность задать структуру хранения максимально отвечающую Вашей задаче.
Если упретесь в какие-то ограничения объектного или SQL доступа, то всегда можно эти ограничения обойти через доступ "key-value".
По скорости доступ "key-value" на порядок быстрее SQL Cache и SQL других СУБД.
...
Рейтинг: 0 / 0
13.03.2014, 11:25
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38585269
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DPH3
Участник
Arhat109Выборка всего экземпляра(узла), его части с заданного подуровня, поиск всех верхних узлов по образцу из подуровня.

А вот про "поиск всех верхних узлов по образцу из подуровня" нельзя ли рассказать поподробнее? Под образцом тут что понимается?
...
Рейтинг: 0 / 0
13.03.2014, 15:10
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38585404
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
Yo.!,

Посчитал. В 3НФ получается 15 табличекразной структуры. Это со связями М:М.
...
Рейтинг: 0 / 0
13.03.2014, 16:26
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38585406
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
DPH3,

За свою проблемку отвечу: да, всё пристальнее смотрю в сторону mumps/Cache.
...
Рейтинг: 0 / 0
13.03.2014, 16:27
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38585686
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
Arhat109Посчитал. В 3НФ получается 15 табличекразной структуры. Это со связями М:М.
3НФ студент, что ли ? что за связи М:М у тебя в пхп массивах ?
...
Рейтинг: 0 / 0
13.03.2014, 20:25
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38618410
ДаВот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ДаВот
Гость
DirksDR,
просто за упоминание слова "Cache" в приличных обществах должны немедленно выражать порицание и раздавать щелбаны! Это не просто НЕ база данных - это просто маркетинговый развод лохов. Объем изначальных архитектурных, системных и идеологических дефектов в этом поделии зашкаливает за все, за что может зашкалить. В сущности это просто файл с небольшими доморощенными надстройками, которые еще и работаю как им вздумается.

И ВСЕ!!!

На разработчиков переложена ответственность, по ручной организации транзакций, по ручной организации коллективной работы пользователей, по ручному восстановлению данных при падении этого поделия по любой причине. Естественно, средний разработчик на все это плюет! В результате поделие производит артефакты в данных в большом количестве. А в случае падения - основной задачей является ручная сборка внутренних структур. Собственно вот она цена "производительности".
...
Рейтинг: 0 / 0
18.04.2014, 10:33
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38618958
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DirksDR
Участник
ДаВот,

В приличном обществе не принято анонимно охаивать что-либо и кого-либо.
...
Рейтинг: 0 / 0
18.04.2014, 15:43
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38619436
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
ДаВот,

Не нравится - не ешьте. Пользуйте старый добрый Mumps, который устойчиво работает практически без каких-либо изменений с лохматого 1979 года... будет вам и "скорость" и "надежность". Собственно ваши "хваленные" СУБД, пользуют эту технологию при организации индексов, как раз для организации "скорости" доступа. Вроде надежны... или "что-то мешает"? :)

Не нравится, ну пишите БД, такие чтоды не создавать индексы. Это реальная скорость ваших СУБД без идей Mumps.
...
Рейтинг: 0 / 0
19.04.2014, 11:50
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38619571
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Настоящая ОО-СУБД - это GemStone/S, и, возможно, MagLev.

http://www.sql.ru/forum/956682/gemstone-s
...
Рейтинг: 0 / 0
19.04.2014, 18:29
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38620731
ДаВот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ДаВот
Гость
DirksDR,В приличном обществе не принято анонимно охаивать что-либо и кого-либо.
Отличный ответ в стиле Cache! Вот пример технических достижений Cache, способов их достижения и самого маркетинга Cache. Вместо того, чтобы обсудить содержание переключились на обсуждения самого моего сообщения. И так с этим поделием во всем.
...
Рейтинг: 0 / 0
21.04.2014, 17:42
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38620738
ДаВот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ДаВот
Гость
Arhat109, проблема не в Mumps, а в том какими веселыми способами этот скелет заставляют двигаться и выглядеть как бы живым и местами улыбающимся. Пирамиды и целые сферы легкого вранья-умалчивания (о свойствах продукта) перемежающиеся маркетинговыми эскападами с точно выверенным текстом (а то гладишь и в суд подадут) умножаются на тотальную некомпетентность принимающих решения со стороны части заказчиков. И живем. И продать можем, что хотим! Вот это ДЕЙСТВИТЕЛЬНО весело.
...
Рейтинг: 0 / 0
21.04.2014, 17:55
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38621288
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DirksDR
Участник
ДаВот,

Вместо того, чтобы обсудить содержание
На этом форуме уже много раз это обсуждалось.
Есть недостатки, есть достоинства.
На мой взгляд достоинства перевешивают, на Ваш - нет.
Это называется демократия. Или плюрализм? Неважно.
...
Рейтинг: 0 / 0
22.04.2014, 11:54
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38621316
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DirksDR
Участник
ДаВот...какими веселыми способами этот скелет заставляют двигаться и выглядеть как бы живым и местами улыбающимся. Пирамиды и целые сферы легкого вранья-умалчивания (о свойствах продукта) перемежающиеся маркетинговыми эскападами с точно выверенным текстом (а то гладишь и в суд подадут) умножаются на тотальную некомпетентность принимающих решения со стороны части заказчиков.

У Вас яркий и образный язык.
Если будет желание, поделитесь когда и на каких задачах Вы поимели такой печальный опыт работы с Cache.
Или это просто "маркетинговая эскапада"?
...
Рейтинг: 0 / 0
22.04.2014, 12:08
| Ответить | Цитировать | Написать  
посоветуйте БД для хранения сложносвязных объектов
    #38623915
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arhat109
Участник
ДаВот,

ну какая это "проблема"? Разве что когда своего мозга нет, дабы критически осмысливать рекламные акции. Собственно и ваше сообщение - "сказать по делу-то что хотели?" :)
...
Рейтинг: 0 / 0
24.04.2014, 07:00
| Ответить | Цитировать | Написать  
23 сообщений из 23, страница 1 из 1
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / посоветуйте БД для хранения сложносвязных объектов
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&msg=38620738&tid=1552380]:
 0ms
get settings:
 11ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 28ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 63ms
get tp. blocked users:
 1ms
others: 237ms
total:  378ms
созд. / загр.: 378ms
x
x
Закрыть


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