|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Нууу, по-любому у нас уже серьёзный прогресс в отношении к ООБД. Раньше, насколько я мог заметить по форуму, было только "Фууу, отстой!". А теперь уже скорее "надо попробовать что-то реализовать, а потом уже можно и обсудить", не правда ли? :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 15:31 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Bogdanov Andrey Именно поэтому я и задаю вопросы здесь - может быть разобравшиеся люди на них смогут ответить. В ответ же вижу только язвительные замечания и заверения о том, что "все круто" без каких-либо доказательств. Андрей, если Вам нужно хранить коллекцию объектов, то что может быть проще использования для этих целее OODB.. Может чего-то не понимаю, но какие требуются доказательства? Описали класс на той же Java и все. Не нужно проектировать для хранения свойств какую-то немыслимую структуру БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 15:36 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
FuzzyНууу, по-любому у нас уже серьёзный прогресс в отношении к ООБД. Раньше, насколько я мог заметить по форуму, было только "Фууу, отстой!". А теперь уже скорее "надо попробовать что-то реализовать, а потом уже можно и обсудить", не правда ли? :)) :) не так. Направо пойдёшь - коня потеряешь (я там был уже :)) ). ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 15:36 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
iscrafm Bogdanov Andrey Именно поэтому я и задаю вопросы здесь - может быть разобравшиеся люди на них смогут ответить. В ответ же вижу только язвительные замечания и заверения о том, что "все круто" без каких-либо доказательств. Андрей, если Вам нужно хранить коллекцию объектов, то что может быть проще использования для этих целее OODB.. Может чего-то не понимаю, но какие требуются доказательства? Описали класс на той же Java и все. Не нужно проектировать для хранения свойств какую-то немыслимую структуру БД. для начала лучше OXMLDB - они проще и уже работают ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 15:41 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Petro123для начала лучше OXMLDB - они проще и уже работают так и OODB работают Если Вы разрабатываете приложение, допустим на Java, то зачем еще дополнительная морока с БД, создал персистент класс и все. Жаль только что к языку привязано, что в общем-то естественно. Для делфи пришлось самим делать :( ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 15:50 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
iscrafm Petro123для начала лучше OXMLDB - они проще и уже работают так и OODB работают Если Вы разрабатываете приложение, допустим на Java, то зачем еще дополнительная морока с БД, создал персистент класс и все. Жаль только что к языку привязано, что в общем-то естественно. Для делфи пришлось самим делать :( С одной стороны, жаль, а с другой -- зато компилятор может всё проверить перед компиляцией, что по сравнению с непроверяемым текстом SQL-запроса, как мне кажется, реальная фича. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 16:00 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
iscrafmОписали класс на той же Java и все. Не нужно проектировать для хранения свойств какую-то немыслимую структуру БД. Именно так - ОО подход это попытка обойтись без моделирования данных и МД вообще. Понятно какие системы так можно построить :). Поэтому т.н. "ООСУБД" СУБД по сути не являются, т.к. не имеют никакой МД. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 16:12 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
iscrafmАндрей, если Вам нужно хранить коллекцию объектов, то что может быть проще использования для этих целее OODB.. Может чего-то не понимаю, но какие требуются доказательства? Проще не значит лучше. Еще проще взять memory-mapped файл. Но база данных отличается еще и тем, что предоставляет возможности поиска. iscrafmОписали класс на той же Java и все. Не нужно проектировать для хранения свойств какую-то немыслимую структуру БД. Я привел конкретный пример поиска по входящим в накладную товарам. Я не верю, что следуя вашей рекомендации "просто описать класс на java" я получу такой поиск за приемлимое время. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 16:12 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
_мод iscrafmОписали класс на той же Java и все. Не нужно проектировать для хранения свойств какую-то немыслимую структуру БД. Именно так - ОО подход это попытка обойтись без моделирования данных и МД вообще. Понятно какие системы так можно построить :). Поэтому т.н. "ООСУБД" СУБД по сути не являются, т.к. не имеют никакой МД. Ну вот до чего мы уже договорились, и ОО подход это какая-то "попытка" чего-то там, и ООБД вообще не БД ни разу... Асм рулит? Давайте без холиваров обойдёмся, пожалуйста. Есть ещё мнения, почему не использовать ООБД в описанной в первом топике конфигурации, кроме: 1) необкатанная технология, чёрт её знает, чего от неё ожидать, 2) можем получить какие-нибудь грабли при репликации (см.п.1), 3) плохо уже то, что не будем долго думать над структурой БД, и вообще это не для крутых перцев. (кажется, это всё, что было упомянуто?) ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 16:18 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Bogdanov Andrey iscrafmАндрей, если Вам нужно хранить коллекцию объектов, то что может быть проще использования для этих целее OODB.. Может чего-то не понимаю, но какие требуются доказательства? Проще не значит лучше. Еще проще взять memory-mapped файл. Но база данных отличается еще и тем, что предоставляет возможности поиска. iscrafmОписали класс на той же Java и все. Не нужно проектировать для хранения свойств какую-то немыслимую структуру БД. Я привел конкретный пример поиска по входящим в накладную товарам. Я не верю, что следуя вашей рекомендации "просто описать класс на java" я получу такой поиск за приемлимое время. Ну чего невероятного-то? Всё то же самое, что и РБД -- индекс по полю, по нему быстро ищется то, что нужно. Чего особенного-то??? Три метода запросов есть: по образцу (особенно ништяк должен быть, когда ищем документ тупо по номеру или по дате), S.O.D.A. (выглядит достаточно страшно, но не страшнее SQL-a), и native query (самый супер с виду, но возможны тормоза, если анализатор не сможет распознать алгоритм отбора). Для приведённого конкретного примера я бы попробовал сперва native query, а потом S.O.D.A. (тут уж промашки не будет). Хотя можно и образцом обойтись, если подумать. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 16:24 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
FuzzyДавайте без холиваров обойдёмся, пожалуйста. Да пожалуйста. Но не разобравшись в основах нет смысла идти дальше. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2007, 16:49 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
FuzzyНу чего невероятного-то? Всё то же самое, что и РБД -- индекс по полю, по нему быстро ищется то, что нужно. Чего особенного-то???Если все так просто, то неужели так трудно привести пример. Я очень хочу поверить, но моя естественнонаучноя сущность не позволяет просто верить. Я не очень понимаю где тут индекс строить. Давайте я начну с примера (прошу прощения за ошибки в java-синтаксисе). Вот пара классов (по крайне мере именно такая реализация возникла у меня как "первое желание") - как будет выглядеть поиск документов по товару? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Для сравнения (уверен, что каждый из читающих и сам бы нарисовал) приведу реляционный вариант (использую синтаксис Oracle). Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 09:19 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Bogdanov AndreyЯ не очень понимаю где тут индекс строить. Теоретически по значению свойств объектов ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 09:24 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
_мод Bogdanov AndreyЯ не очень понимаю где тут индекс строить. Теоретически по значению свойств объектовНу так это опять "теоретически". Неужто никто не может практически? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 10:39 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Bogdanov Andrey FuzzyНу чего невероятного-то? Всё то же самое, что и РБД -- индекс по полю, по нему быстро ищется то, что нужно. Чего особенного-то???Если все так просто, то неужели так трудно привести пример. Я очень хочу поверить, но моя естественнонаучноя сущность не позволяет просто верить. Я не очень понимаю где тут индекс строить. Давайте я начну с примера (прошу прощения за ошибки в java-синтаксисе). Вот пара классов (по крайне мере именно такая реализация возникла у меня как "первое желание") - как будет выглядеть поиск документов по товару? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Для сравнения (уверен, что каждый из читающих и сам бы нарисовал) приведу реляционный вариант (использую синтаксис Oracle). Код: 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.
Насколько я блин понял документацию и примеры, поиск будет выглядеть примерно так: Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 10:43 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Bogdanov Andrey _мод Bogdanov AndreyЯ не очень понимаю где тут индекс строить. Теоретически по значению свойств объектовНу так это опять "теоретически". Неужто никто не может практически? В доках написано, для случая выше индекс устанавливать нуно как-то так: Код: plaintext 1.
Андрей, я очень извиняюсь, но как насчёт того, чтобы самому просто взять, да поглядеть, как и чего делается? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 10:46 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
FuzzyАндрей, я очень извиняюсь, но как насчёт того, чтобы самому просто взять, да поглядеть, как и чего делается?Если я соберусь что-то писать используя данный прордукт, то я буду подробно знакомится с документацией. Пока же я всего лишь хочу понять, как это может работать. Я думал, что тут есть люди работавшие с продуктом и могущие ответить на некоторые вопросы. Если таковых нет, то можно честно сказать, что опыт практического применения пока отсутствует. В ближайшие полгода мне не светит использование никаких новых технологий, поэтому углубляться в предмет и тратить время на самостоятельное изучение мне не хочется. Но быдь хоть немного в курсе - хотелось бы. Fuzzy Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 11:13 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Bogdanov Andrey Fuzzy Код: plaintext
Может, я чего-то сильно не догоняю? А почему невозможна для инкапсулированных коллекций? Индексация она и в Африке индексация, как и поиск. Чем тут ООБД отличается от РБД? Я не могу никак понять, что Вы имеете в виду, какие трудности??? Поясните, пожалуйста, Вашу мысль. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 11:21 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
FuzzyМожет, я чего-то сильно не догоняю? А почему невозможна для инкапсулированных коллекций? Индексация она и в Африке индексация, как и поиск. Чем тут ООБД отличается от РБД? Я не могу никак понять, что Вы имеете в виду, какие трудности??? Поясните, пожалуйста, Вашу мысль.По правде говоря, писать уже тяжело - шампанское мешает. Но попробую объяснить свои затруднения. Даже для строковых значений простое индексирование не очень помогает при операциях типа like. Нужно иметь "специальный" индекс. Ну и с коллекциями похожая тружность. Что именно индексируется при написании коллекция.indexed(true)? Как физически работает такой индекс? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 13:32 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Bogdanov Andrey FuzzyМожет, я чего-то сильно не догоняю? А почему невозможна для инкапсулированных коллекций? Индексация она и в Африке индексация, как и поиск. Чем тут ООБД отличается от РБД? Я не могу никак понять, что Вы имеете в виду, какие трудности??? Поясните, пожалуйста, Вашу мысль.По правде говоря, писать уже тяжело - шампанское мешает. Но попробую объяснить свои затруднения. Даже для строковых значений простое индексирование не очень помогает при операциях типа like. Нужно иметь "специальный" индекс. Ну и с коллекциями похожая тружность. Что именно индексируется при написании коллекция.indexed(true)? Как физически работает такой индекс? Честно говоря, юх его знает, чего там делается внутри энтой самой db4o... Но я бы сам, если бы реализовывал такое индексирование, сделал бы так: при поступлении требования построить индекс по полю lines класса Invoice создавал бы таблицу, где по ID объекта Article можно быстро найти ID тех объектов Invoice, у которых этот данный объект Article встречается в коллекции в поле lines. Может быть, даже писал бы такую инфу прямо в объект Article. Вот. А ID объекта в ООБД прямо указывает на месторасположение нужного объекта, ничего больше искать нигде не нужно. Как Вам такая реализация? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 14:05 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Fuzzy ...Может быть, даже писал бы такую инфу прямо в объект Article. ... Как Вам такая реализация? Вот это меня и напрягает немного. Это как-то нарушает мои представления об ООП. Aricle ничего не знает (и не должен знать) о том, что есть какие-то там накладные. Этот класс должен уметь существовать сам по себе. Сегодня мы подключили модуль с наладными, а завтра - инвентаризацию - нам что теперь Article каждый раз пересобирать? У нас в системе на таблицу Account более двухсот ссылок, общий объем ссылающихся таблиц гигабайтами меряется, так что все это удовольствие в Account запихивать? Может быть все не так мрачно, а у меня паранойя? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 14:11 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Bogdanov Andrey Fuzzy ...Может быть, даже писал бы такую инфу прямо в объект Article. ... Как Вам такая реализация? Вот это меня и напрягает немного. Это как-то нарушает мои представления об ООП. Aricle ничего не знает (и не должен знать) о том, что есть какие-то там накладные. Этот класс должен уметь существовать сам по себе. Сегодня мы подключили модуль с наладными, а завтра - инвентаризацию - нам что теперь Article каждый раз пересобирать? У нас в системе на таблицу Account более двухсот ссылок, общий объем ссылающихся таблиц гигабайтами меряется, так что все это удовольствие в Account запихивать? Может быть все не так мрачно, а у меня паранойя? Секундочку, я имел в виду, что так делает сама db4o , а не клиентский программист! Клиентский программист пишет только лишь Код: plaintext 1.
Вы же об этом меня спрашивали? Я отнюдь не имел в виду, что в приложении нужно как-то менять объектную модель! ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 14:33 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
FuzzyСекундочку, я имел в виду, что так делает сама db4o , а не клиентский программист!Я понимаю. Просто представьте, что работает у меня приложение есть там класс Article и в базе уже много экземпляров хранится и тут кто-то новый модуль пишет и имеющимся классом ползуется. Ведь это не должно требовать пересборки класса Article, и вообще никаких изменений в хранящиеся экземпляры вносить не должно. То есть идея "писал бы такую инфу прямо в объект Article." однозначно не подходит. Ну а если для каждой связи "создавал бы таблицу", то вся ООБД просто в настройку на РБД превращается, просто процесс мапинга между объектными и реляционными структурами скрыт от программиста и не управляем. Честно скажу особых преимуществ и тут не вижу - я предпочитаю "понимать" подноготную. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 14:44 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
Bogdanov Andrey FuzzyСекундочку, я имел в виду, что так делает сама db4o , а не клиентский программист!Я понимаю. Просто представьте, что работает у меня приложение есть там класс Article и в базе уже много экземпляров хранится и тут кто-то новый модуль пишет и имеющимся классом ползуется. Ведь это не должно требовать пересборки класса Article, и вообще никаких изменений в хранящиеся экземпляры вносить не должно. То есть идея "писал бы такую инфу прямо в объект Article." однозначно не подходит. Ну а если для каждой связи "создавал бы таблицу", то вся ООБД просто в настройку на РБД превращается, просто процесс мапинга между объектными и реляционными структурами скрыт от программиста и не управляем. Честно скажу особых преимуществ и тут не вижу - я предпочитаю "понимать" подноготную. А кто говорил про преимущества ООБД перед РБД в поиске ??? Я лишь утверждал, что потерь при этом нет. Примерный паритет. Выигрыш будет, когда найденные документы начнём из базы доставать, юзеру показывать, менять и обратно в базу сохранять. Т.е. выполнять непосредственно саму работу с базой, для чего OLTP-система и предназначена. Тут-то Вы со мной согласны? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 14:48 |
|
ООБД + OLAP
|
|||
---|---|---|---|
#18+
FuzzyА кто говорил про преимущества ООБД перед РБД в поиске ??? Я лишь утверждал, что потерь при этом нет. Примерный паритет. Выигрыш будет, когда найденные документы начнём из базы доставать, юзеру показывать, менять и обратно в базу сохранять. Т.е. выполнять непосредственно саму работу с базой, для чего OLTP-система и предназначена. Тут-то Вы со мной согласны?Вы вовсю хотите чтобы я с вами спорить начал. А я всего лишь понять хочу. В данном случае я вижу, что если мы просто храним объекты, как есть, то непонятно как организовать приемлимый по скорости работы поиск. В качестве решения вы предложили хранить объекты в таблицах, но если мы храним объекты в таблицах, то занчит, что ООБД при чтении/сохранении занимается преобразованием данных (пусть это скрыто от программиста) из объектного представления в реляционное и обратно. Но тогда я не понимаю как мы можем получить выигрыш в производительности на этих операциях, если сейчас все системы построенные на РБД делают ровно то же самое. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2007, 15:00 |
|
|
start [/forum/topic.php?fid=33&msg=35040450&tid=1548904]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
192ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 303ms |
0 / 0 |