Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
А что выдаст корень из двух? А что выдаст (1/3 - 1.0E-90)?
6 ноя 03, 12:56    [408783]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andrei N.Sobchuck
Guest
"А что выдаст корень из двух?"
1.4142135623731. Мат.библиотека оперирует числами с ограниченной точностью IEEE. С соответсвующими ограничениям.

"1/3 - 1.0E-90"
1.0E-90 - это число ограниченной точности в формате IEEE. Перед
вычислением 1/3 приведётся к этому формату. Результат - 0.33333333333333.
А если записать 1/3 - 1/10**90, то получим
(1/3) - (1/(10 raisedTo: 90)) ->
(999999999999999999999999999999999999999999999999999999999999999999999999999999999999999997/3000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)
6 ноя 03, 13:11    [408808]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Вахитов
Guest
Посоветуйте какие-нибудь книги по обработке транзакций и хранению данных БД.
6 ноя 03, 21:53    [409381]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
Странный спор. ST имеет свою нишу, в которой он лучше любого другого известного сейчас языка программирования. Там он интенсивно используется и C++ ему не конкурент. Это медицинский факт. Точно так же ST не конкурент C/C++ в каких-то других областях.

Эта ниша не совпадает с той, где нужно интенсивно вычислять число Pi или квадратные корни. Кстати на фортране это делать гораздо удобнее и быстрее, чем на C/С++. Сравнивать языки по длине программ, вычисляющих факториал несерьезно. Программа печатающая "hello world" в бейсике гораздо короче чем в C.
Еще пример: программа печатающая сама себя в gw-basic состоит из одного оператора: llist. Попробуйте в качестве упражнения написать такую программу на C или паскале. А потом обобщите, так чтоб при небольшой модификации печаталась любая программа. Значит ли это, что васик язык всех времен и народов и обо всех остальных нужно немедленно забыть?
7 ноя 03, 00:49    [409469]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
--Странный спор. ST имеет свою нишу, в которой он лучше любого другого известного сейчас языка программирования. Там он интенсивно используется и C++ ему не конкурент.

укажите тему пожалуйста.
А то куда не посмотришь - все на С++. (из приличного софта конечно).
доморощенные поделки я конечно в счет не беру.
7 ноя 03, 22:22    [409977]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
Lepsik
>укажите тему пожалуйста.
>А то куда не посмотришь - все на С++. (из приличного софта конечно).
доморощенные поделки я конечно в счет не беру.

Уже указал в посте [285990] в этом топике. Таких линий наверное не мало, при желании можно найти точную информацию. Я знаю что они точно есть в Торонто или Оттаве. Общался даже с человеком, который с сеньора C++-сника пошел на интермедиата ST, поскольку посчитал, что в перспективе это лучше в плане работы. Он говорил, что так и получилось.
8 ноя 03, 00:33    [410005]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
c127 писал:
Кстати на фортране это делать гораздо удобнее и быстрее, чем на C/С++.


Откуда такие сведения? :)
Имею некий (более года) опыт на фортране и большой на С++. В плане обычных математических вычислений они одинаковы, никто ни перед кем не имеет преимуществ в синтаксисе.

Но С++ имеет преимущества в технологиях:
1. небольшие ф-ции можно делать inline, и поднимать быстродействие за счет некоторого разбухания результирующего двоичного кода.
2. есть возможность писать многопоточные вычислительные алгоритмы, что может дать существенный прирост на мультипроцессорных машинах или на том же Intel Hiper-threading.
8 ноя 03, 01:55    [410011]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 vdimas

Это мы уходим от темы.

>Откуда такие сведения? :)
>Имею некий (более года) опыт на фортране и большой на С++. В плане обычных математических вычислений они одинаковы, никто ни перед кем не имеет преимуществ в синтаксисе.

Для float вычислений синтаксис фортрана удобнее. Это конечно субъективная оценка. Кроме того C дает слишком много свободы программисту, иногда это недостаток. Поэтому в фортране часто намного легче отлавливать ошибки, а если не использовать allocate и указатели (это не сложно), то не будет утечки памяти.

>Но С++ имеет преимущества в технологиях:
1. небольшие ф-ции можно делать inline, и поднимать быстродействие за счет некоторого разбухания результирующего двоичного кода.
2. есть возможность писать многопоточные вычислительные алгоритмы, что может дать существенный прирост на мультипроцессорных машинах или на том же Intel Hiper-threading.

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

Нужно знать где нужно и где не нужно использовать каждый язык. На фортране не нужно писать обработку строк, списков, логику, GUI.
9 ноя 03, 06:17    [410361]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
2vdimas

--Имею некий (более года) опыт на фортране и большой на С++. В плане обычных математических вычислений они одинаковы, никто ни перед кем не имеет преимуществ в синтаксисе.

оптимизированный (оптимизатором ) код на фортране делает С++ в разы.

--2. есть возможность писать многопоточные вычислительные алгоритмы, что может дать существенный прирост на мультипроцессорных машинах или на том же Intel Hiper-threading.

fortran уже давно имеет поддержку многопотоковости. см. Compaq Fortran.

там даже COM сервера делать можно
10 ноя 03, 21:34    [411779]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Sergij Gromov
Member

Откуда: 49°49'44.58"N, 23°59'40.42"E
Сообщений: 443
Ребята !! Ау !!!

Я своих пару копеек вставлю.... про М-технологию.

Имею махонькую прогу, сам ваял, потому не претендую на оригинальность :((

Суть в том, что эта прога обслуживает телефонный справочник Киева - 1500000 (приблизительно) записей. Размер базы - 150 метров, данные браз из базы на Ацесе. Могу прислать, посмотрите быстродействие поиска :)

ICQ#137727952
11 ноя 03, 18:35    [413445]     Ответить | Цитировать Сообщить модератору
 Как изменить режим экрана во время запуска  [new]
Alisher
Guest
Прошу Вас помогите мне разбирать с следующим проблемам:

Как изменить режим экрана во время запуска программ (VB 6.0)?
Например: Текущий режим экрана: 1024 х 768, когда программа
запускается режим экрана должно измениться автоматически на 800 х 600 px
и при выхода тоже автоматически изм. на 1024 х 768?

За ранее спасибо Вам большое!!!
30 янв 04, 13:24    [514494]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Хорошая шутка, особенно после 13 страниц яростных споров :)
30 янв 04, 15:33    [514921]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
sovnarkom
Member

Откуда:
Сообщений: 9
Работаю с М со времен Очакова и покорения Крыма... :)
Писал на нем все и всем... Никто не жалуется до сих пор!
Рискну подытожить...
Что спорить о деревьях, если пишешь на плоских, как асфальт, таблицах?!

Чем хорош М? Да тем, что его можно легко использовать в том случае, когда количество данных, привязанных к 1 индексу заранее не известно и может колебаться от 0 до практически бесконечности... Например, на М очень легко пишутся вещи типа программ по регистратуре поликлиник, ибо нет проблем описать, что Иванов ни разу в жизни не чихнул, а Петров приходит с жалобами на хронический ринит "эври дэй"... Выглядеть это будет примерно так:

^Rinit("Иванов")
^Rinit("Петров","18.10.2003")
^Rinit("Петров","21.10.2003")
^Rinit("Петров","09.11.2003")
...............
^Rinit("Петров","20.05.2004")

Вот так... Все ясно, как божий день!
Теперь хотим выбрать даты посещений поликлиники Петровым...

s date="" f s date=$o(^Rinit("Петров",date)) q:date="" d
.w !,(^Rinit("Петров",date)

Аллесс нормаллесс!

Чем еще хорош М? Сокращенным синтаксисом! Я когда смотрю на мегабайтные исходники 1С, меня просто плющит от того, насколько людям не влом описывать операторы и функции полными их наименованиями! То ли дело МСМ! Go = g, Do = D, $Order = $o и т.д. и т.п.... Т.е. хочешь - пиши оператор полностью, хочешь, сократи его до 1 буквы!

Не согласен, что выборки данных из наиболее "нижележащих" узлов более долго выполняются, нежели выборка данных из "плоской" таблицы! Подняться на уровень следующего узла-родителя и опуститься по нему это всего-навсего поиск следующего адреса в индексной структуре и происходит практически мгновенно... Кроме того, все зависит от квалификации программера! Хороший программер всегда ведет в сложных случаях некоторые параллельные индексные структуры, которые в нужный момент могут сократить время выборки практически к 0, а места на винте практически не занимают... Например, в проге по "Основным средствам" передо мной стояла задача - обеспечить мгновенную выборку как с Инвентарного Номера (ИН) на МОЛ, так и наоборот... Небольшая трабла возникла бы в том случае, если я создал только такую структуру (индексами служат ИН):
^OS(1000)="Иванов"
^OS(1001)="Петров"
^OS(1002)="Иванов"
^OS(1003)="Петров"
^OS(1012)="Петров"
^OS(1033)="Петров"
.......

В таком случае, для того, чтобы выбрать все ОС на Иванове, мне пришлось бы колбасить всю базу сверху вниз, а при большом количестве индексов это заняло бы пару секунд... Но, чтоб не парить юзера даже такой микрозадержкой его внимания, я создал параллельную структуру (индексами служат МОЛ)!!!!!!:

^MOL("Иванов",1000)=""
^MOL("Иванов",1002)=""
^MOL("Петров",1001)=""
^MOL("Петров",1003)=""
^MOL("Петров",1012)=""
^MOL("Петров",1033)=""
.......
И все... База не содержит никаких данных, кроме индексов ИН, которые относятся к данному МОЛу. Единственный напряг - дописать модулек, который одновременно пишет данные и в глобаль ^OS и в ^MOL...
Кстати, когда наш директор решил глянуть эту реализацию на 1С, то он обалдел, ибо выборка ИН по МОЛам могла длиться до 3-х минут! (Я опять же не только о минусах 1С, которых и так предостаточно, а еще и о реализации задачи программистами)
Кстати, о реализации... На одном предприятии стояла в 1993 году ХТ... На ней была Фокспром написана прога по реализации продукции... Работала она по созданию полного отчета 8 часов! Т.е. толпа приходила, врубала прогу - и уходила по свои делам... Машина колбасила весь день, а к вечеру результат был готов... (Если электроэнергию не отрубят...) Я поставил им по тем временам крутую тачку AMD DX2-66 под МСМ 3.0.10, написал прогу и запустил... Файл результатов был получен через... (угадай с 3-х раз) .... 20 секунд! Да, я согласен, что DX2-66 была в то время гораздо производительней ХТ, но не в 8*3600/20=1440 же раз! ))))))))) Вот так-с... "Программеров буйных мало, вот и нету Биллов Гейтсов"... ))
Ну, можно много еще чего хорошего написать об М технологии... Кстати, а чего NASA трахается с этим Майсиклем?! Может поэтому программа по СОИ так и не была создана?!!! ) Попросили бы МСМщиков - мы напишем и не такое!!! )))
29 май 04, 11:23    [709329]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 sovnarkom
Структуры которые Вы описали как раз очень легко хранятся именно в "плоских" файлах.
Например вам надо выбрать кто жаловался в определённый день. И получается что корнем должен быть уже не человек, а день.
Ну и к тому же Вы работаете именно с записями, а не с данными.
То что кто-то сделал хуже еще не говорит что Вы сделали хорошо :)
31 май 04, 10:10    [710364]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Pusto
Guest
sovnarkom
Файл результатов был получен через... (угадай с 3-х раз) .... 20 секунд! Да, я согласен, что DX2-66 была в то время гораздо производительней ХТ, но не в 8*3600/20=1440 же раз!

Ты будешь смеяться, но не далее, как в этом году я тоже оптимизировал одну прогу, написанную на VFP, и тоже получил ускорение в 1400 раз. Но я ее писал на том же VFP. Структура исходных таблиц при этом не менялась! А представь, что мне было бы разрешено под эту задачу поменять структуру входных данных? Я думаю, что еще раз в 3-5 ее ускорил бы.
Вывод: Квалификация программиста тоже очень много значит. Я не буду утверждать, что смог бы переписать упомянутую тобой программу так, чтобы на AMD DX2-66 она выиграла у МСМ, но разница была бы точно не на 3 порядка.
Я это не к тому говорю, чтобы утверждать, что Fox круче MCM - у каждого подхода свои плюсы и минусы (даже допускаю, что Fox медленнее MCM). Я это к тому, что сравнения программ РАЗНЫХ программистов на РАЗНЫХ языках (а у тебя к тому же - на РАЗНЫХ компьютерах) малоинформативны и ОЧЕНЬ необъективны.
31 май 04, 10:33    [710401]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
автор
Что спорить о деревьях, если пишешь на плоских, как асфальт, таблицах?!

Да, выпуклые деревья это сила....

автор

Но, чтоб не парить юзера даже такой микрозадержкой его внимания, я создал параллельную структуру (индексами служат МОЛ)!!!!!!:
...
Единственный напряг - дописать модулек, который одновременно пишет данные и в глобаль ^OS и в ^MOL...

Это называется "зависимомсть приложений от физических структур хранения данных", одна из главных причин вымирания иерархических и сетевых СУБД.
Надо поменять что-то в структурах хранения, новый "индекс", другая организация, побежали перелапачивать все приложения... а где нибуть ещё и забыли чтонить перелопатить, какойнибудь модулек " который одновременно пишет данные и в глобаль ^OS и в ^MOL...".
31 май 04, 11:09    [710522]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
MGR
Guest
автор
Кстати, о реализации... На одном предприятии стояла в 1993 году ХТ... На ней была Фокспром написана прога по реализации продукции... Работала она по созданию полного отчета 8 часов! Т.е. толпа приходила, врубала прогу - и уходила по свои делам... Машина колбасила весь день, а к вечеру результат был готов... (Если электроэнергию не отрубят...) Я поставил им по тем временам крутую тачку AMD DX2-66 под МСМ 3.0.10, написал прогу и запустил... Файл результатов был получен через... (угадай с 3-х раз) .... 20 секунд!


Ну 1440 я не делал. Но один отчёт в 97году заставил работать вместо 80 минут - 10 секунд. То есть в 480 раз.
Просто переписав чуток код отчёта. ФоксПро 2.6 для ДОС.
Там ещё можно было добавить индекс добившись ускорения в 2 раза, однако не хотелось увеличивать размер индексного файла - итак зашкаливало, да и 10секунд - нормально.
Так что вопрос в руках, а не в технологии только.
BTW: Для фокса для ДОСа переход с 286-20 на 486-40 давал выигрыш в 10-20 раз. Так что переход с ХТ на 486-DX2 мог дать и 30-50 раз выигрыша.
31 май 04, 11:12    [710543]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Это называется "зависимомсть приложений от физических структур хранения данных", одна из главных причин вымирания иерархических и сетевых СУБД.
Надо поменять что-то в структурах хранения, новый "индекс", другая организация, побежали перелапачивать все приложения... а где нибуть ещё и забыли чтонить перелопатить, какойнибудь модулек " который одновременно пишет данные и в глобаль ^OS и в ^MOL...".


Это называется по-другому - что у Вас РАЗРЕШИЛИ использовать "зависимость приложений от физических структур хранения данных". И спецификой М это вовсе не является.
31 май 04, 11:15    [710556]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
ну я
... РАЗРЕШИЛИ использовать "зависимость приложений от физических структур хранения данных". И спецификой М это вовсе не является.

Т.е. Вы хотите сказать, что допустим если я вижу, что некоторая операция может выполнятся быстрее, если к существующем в БД объектам добавить индекс XYZ, и если я добавлю в M-ситему некий индекс XYZ, то существующие программы на допустим COS ( если я правильно помню, так называет язык в CAHCE) сами тут же начнут использовать этот индекс без каких либо переделок? А потом, когда изменится распределение данных и использование этого индекса станет во многих случаях невыгодным, они сами автоматически перестанут его использовать без каких либо действий с моей стороны?
31 май 04, 11:28    [710597]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
Очень хочется услышать, что же такого есть у Каше, что выгодно отличает её от других промышленных СУБД ? Может производительность ? Или удобство и простота в использовании? Масштабируемость ? Или .... , что ?


С моделями данных у Кашистов проблемы -

"Что спорить о деревьях, если пишешь на плоских, как асфальт, таблицах?!"

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

или

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=4#656977


но самое смешное и у разработчиков Каше точно такие же проблемы :

http://www.dbdebunk.citymax.com/page/page/622933.htm

Детский сад, ей богу, постоянно путаются в модели и реализации, непонятно к чему приплетают Объектную модель (про которую никто ничего не знает).

Теперь, наконец-то доползли до практической части (реализации) - оптимизации запроса (или языка к доступа к данным), и способов индексации.

Раскажите при всём честном народе как Каше будет учитывать индексы, по какому принципу в ней минимизируется число считываний с диска и т.д.

Интересно будет послушать, может тут скрывается невиданная мошь Каше ?
31 май 04, 12:53    [710845]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Wadim
Member

Откуда:
Сообщений: 31
To Andreww:

Из моего небольшого опыта работы (в смысле что больших проектов за спиной на Каше у меня нет):

Очень удобно что таблицы автоматически проецируются в объекты и наоборот.
Очень удобно что есть прямой доступ к объектам.
Если в SQL базах данных весь доступ только через запросы, то тут есть возможость писать как бы внутри сервера. Весь код выполняется на стороне сервера. Не только в смысле что на одной машине а в смысле что внутри Каше. Не теряется время на передачу данных между сервером приложений и базой данных.

В тоже время есть возможность доступа к Каше через ODBC, через СКЛ запросы.

По поводу скорости сказать точно не могу. На семинаре мне заявили что Каше быстрее MS SQL. Я сделал простой запрос по таблице из миллиона записей SELECT * FROM Table1 WHERE FirstName like 'ER%'.
MS SQL был быстрее. Но в Каше сказали что я что-то там неправильно настроил. Сейчас веду с ними переписку, чтоб сказали как правильно настроить.

Вообще они заявляют что сравнивать только по запросу это не правильно.
Я думаю, что из-за того, что сервер приложения объединен с базой, Каше получает значительный выйгрыш в скорости

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

Еще одно преимущество. Постараюсь объяснить на примере:
У меня есть таблица1 на основе которой создается объект1 и таблица2 связанная с таблицей1 отношением один-много и на основе таблицы2 создается объект2. Мне нужно вытащить например 100 объектов из таблицы1 и у каждого объекта1 есть 10 объектов2.
В обычной базе мне нужно сделать 1 запрос к таблице1 и еще 100*10=10000 запросов к таблице2. В каше из-за того что весь доступ выполняется на уровне сервера я об этом не беспокоюсь. В обычной же базе мне тут надо извращатся создавая отдельных запрос к таблицы 2. Запихивая результат куда-то и потом уже обращатся к этому результату как к набору данных.
Что я имею ввиду. То что в Каше есть изначально. В обычной субд делается руками и не всегда оптимально. прямого доступа в обычной базе данных все равно не сделаешь (во всяком случае я не знаю)

Использовать или нет индекс при СКЛ запросе решает оптимизатор запросов На сколько он хорош по сравнению с MS SQL или Oracle не могу сказать. Но если очень интересно, вышлите мне запрос на который бы вы хотели посмотреть план запроса от Каше и я вышлю обратно этот план.
При прямом доступе к данным существует возможность обращатся как к индексу так и к данным. Но в обычных базах данных прямого доступа нет. Так и сравнивать не с чем.

Про работу с диском ничего не могу сказать.

Из того что вызывает сомнения:
Как обслуживать эту базу данных. На сколько она часто "падает". Реального опыта у меня нет только тестовые прокты. На сайте Каше говорят что все тип-топ.
Вызывает сомнения однозначность преобразования таблица в объект. Например: у меня есть три таблицы Таблица1 связанна с Таблице2. И Таблица 2 связанна с Таблице3. В сервере приложений я могу представить эти таблице как в цепочке: Таблица1<-Таблица2<-Таблица3. А могу и Таблица1<-Таблица3<-Таблица2. В Каше я не уверен что так легко все это будет.


С уважением.
31 май 04, 13:48    [711050]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
jvvjvv
Member

Откуда:
Сообщений: 56
ИМХО, активизация обсуждения Cache вызвана скорой (7-9 июня 2004 года) конференцией по этой системе ;-))
Вот ссылка :
http://www.intersystems.ru/events/symposium2004/index.html
31 май 04, 14:14    [711143]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
автор
Очень удобно что таблицы автоматически проецируются в объекты и наоборот.
Очень удобно что есть прямой доступ к объектам.

Запишем в плюс, если это действительно удачно.

автор
У меня есть таблица1 на основе которой создается объект1 и таблица2 связанная с таблицей1 отношением один-много и на основе таблицы2 создается объект2. Мне нужно вытащить например 100 объектов из таблицы1 и у каждого объекта1 есть 10 объектов2.
В обычной базе мне нужно сделать 1 запрос к таблице1 и еще 100*10=10000 запросов к таблице2. В каше из-за того что весь доступ выполняется на уровне сервера я об этом не беспокоюсь. В обычной же базе мне тут надо извращатся создавая отдельных запрос к таблицы 2. Запихивая результат куда-то и потом уже обращатся к этому результату как к набору данных.
Вы тут ошибаетесь, нужные данные вы точно так же можете в этом случае вытащить одним запросом и не надо такой разветвленной процедурности, а маппинг этих данных на объекты уже другой вопрос.


автор
В обычной субд делается руками и не всегда оптимально. прямого доступа в обычной базе данных все равно не сделаешь (во всяком случае я не знаю)

Вот толко не руками, а декларативным запросом, а уже оптимизатор, владеющий информацией о текущих ресурсах СУБД и статистикой по БД выбирает пути доступа близкие к оптимальным.
Прямого доступа действительно нет ( если под "обычной" имеется ввиду современная промышленная "реляционная" СУБД), но он чаще всего вреден, поскольку ведет к "зависимости приложений". Упомянутый вами "прямой доступ" вообще говоря не прямой, а просто процедурный к отдельным элементам данных, при этом вы не можете определить и контролировать "оптимальность" процесса на уровне доступа к блокам данных и к кэшу данных, оптимальность работы с которыми является определяющей для СУБД работающей с большими объемами данных, процессор же базы данных не может соптимизировать этот процесс по причине того, что не знает, что в следующий момент предпримет ваша процедура, по какому пути пойдет.
Например, если взять ваш же пример, только допустим нужная выборка будет уже не 100*10 ( тут кстати получается 1000, а не 10000 :) ), а допустим 1000*1000, то алгоритм Nested Loops которй у Вас получится при реализации методом "прямого доступа" скорее всего будет уже далеко не самым оптимальным, а значительно более оптимальными могут оказаться алгоритмы типа HASH JOIN, SORT MERGE JOIN и.т.п. причем эффективными могут оказаться разные алгоритмы в зависимости от текущего распределения данных и взятых предикатов выборки.

автор
Не только в смысле что на одной машине а в смысле что внутри Каше. Не теряется время на передачу данных между сервером приложений и базой данных.
Большинство промышленных СУБД содержат встроенный процедурный язык, выполняющейся в ядре системы или возможность написать расширение на внешних языках, эти процедурные расширение можно рассматривать как ядро сервера приложений, на которое распространяются и система бизопасности и система отказоустойчивости СУБД. Т.е. практически любая промышленная СУБД содержит в той или иной мере сервер приложений, т.е содержит средства обеспечения и поддержания бизнес логики, а не является "чистым" хранилищем данных,спричем эта тенденция усиливается, хотя с ней многие спорят. CACHE в поддержке этой тенденции не оригинален.

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

Опять же достаточно типичное поведение, не отличающееся от многих в индустрии, например Oracle Internet Aplication Server работает по тому же принципу.
31 май 04, 15:17    [711398]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
как Каше будет учитывать индексы, по какому принципу в ней минимизируется число считываний с диска

Вопрос совершенно очевидный для sql-щиков и совершенно непонятный для м-щиком. Поскольку доступ к индексам и решение как именно его использовать в sql-ориентированных системах выполняет sql-движок, а в м при прямом доступе это пишет программист.

если я добавлю в M-ситему некий индекс XYZ, то существующие программы на допустим COS ( если я правильно помню, так называет язык в CAHCE) сами тут же начнут использовать этот индекс без каких либо переделок

Опять то же самое. "добавить индекс" при прямом доступе вообще-то именно и означает что будет доработано соответствующее число функций. Отмечу, что при прямом доступе это именно написанные самим программистом функции. Как именно он их напишет - модульно или копипастом рассует код по всей аппликухе - тут уж каше ему никак мешать не будет.
31 май 04, 15:20    [711410]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
ну я
Опять то же самое. "добавить индекс" при прямом доступе вообще-то именно и означает что будет доработано соответствующее число функций. Отмечу, что при прямом доступе это именно написанные самим программистом функции. Как именно он их напишет - модульно или копипастом рассует код по всей аппликухе - тут уж каше ему никак мешать не будет.

И ещё 10 раз будет опять тоже самое, поскольку ещё лет тридцать назад в СУБД сообществе было выяснено и установлено, что cледует избегать физической навигации, выполняемой программами пользователей или происходящей внутри функций.

"когда программист осуществляет навигацию к искомым данным, он заменяет функции оптимизатора запросов написанными вручную вызовами более низкого уровня. История наглядно продемонстрировала, что хорошо написанный и хорошо настроенный оптимизатор почти во всех случаях добивается лучших результатов, чем написанные вручную вызовы. Далее, если изменится некоторое число индексов или данные в кластере будут реорганизованы, навигационный интерфейс не сможет автоматически приспособиться к переменам. Значит, если изменятся физические пути доступа к данным, программисту придется модифицировать программу. С другой стороны, оптимизатор запросов просто создает новый план, который оптимизируется для новой среды." M. Stonebraker, L. Rowe, B. Lindsay, J. Gray, M. Carey, M. Brodie, Ph. Bernstein, D. Beech. “Third-Generation Data Base System Manifesto”

Естественно можно нарыть отдельные случаи, когда прямая навигация оказывается более эффективной, но их всё меньше, да и цена таких решений может превысить преимущества.
31 май 04, 15:54    [711535]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить