Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Yo!
Guest
при выборе субд скорость стоит на 4-ом месте, народ как-то гораздо больше волнует Reliability и возможности интегрирования.
http://www.evansdata.com/n2/surveys/database/2004_1/db_04_1_xmp1.shtml

допустим на предприятии есть такое решение, возникает необходимость в OLAP навесить какой-нибудь вебсервис для общения с ситемами клиентов (B2B) и связывание с местным документооборотом. к любой промышленой субд это все есть (где-то в стандартной поставке, где то отдельно), а тут как ? руками все делать ?
31 май 04, 16:09    [711583]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Wadim
Member

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

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

Согласен. Можно и все таблицы вытащить в одном запросе. Но CASHE решает проблему маппинга. В отличие от обычных баз данных (я намеренно пользуюсь этим термином, надеюсь на его интуитивное понятие, не хотелось бы посвящать топик определению терминов).
Сейчас попытаюсь опять объяснить на примере. Предположим у меня есть две таблицы "Заказ" и "Детали заказа". И дизайнер (человек который непосредственно отображает данные на страничке) решил отобразить 15 последних заказов (без деталей) на веб страничке. Я ему создаю объект который отображает делает маппинг (опять же надеюсь мы одинаково понимает этот термин) данных из таблицы в объект. Я даю дизайнеру описание этого объекта и дальше уже могу не заботится как он отображает его. Потом вдруг дизайнер захотел создать еще одну страничку где он отображает 15 заказов и их деталей. И мне нужно теперь думать. Для первой странички мне нужны только заказы. Я делаю запрос который возвращает только заказы. Для второй мне нужны заказы и детали и я делаю второй запрос который возваращает и детали и заказы и пишу новую процедуру которая делает маппинг по новому. Или можно сделать по другому. Сделать Lazy loading когда данные о деталях заказа будут считыватся только при непосредственном обращении к ним. Но опять же получается в этом случае мне нужно будет сделать 15*(количество деталей для заказов) запросов. А теперь представим что табличек не две, n. А теперь представим что страничек где эти таблицы используются не 2, а m. И получается что для каждой странички придется писать свой оптимизированный именно для это страницы запрос. и еще свою процедуру маппинга. И каждый раз когда дизайнер захочет добавить данные на страницу он должен будет "дергать" программера. Проще тогда уже не делать маппинг а прямо писать in-line SQL запросы на страничке. Тогда нам маппинг вообще не нужен.
Что у нас есть в CACHE.
Там тоже есть Lazy loading. Но уже встроенный. Не нужно писать его ручками. Там весь код выполняется в базе данных. Количество задействованных таблиц точно равняется количеству нужных. Пусть даже объединение происходит простым переборос (далеко кстати не плохой способ). И главное. Я даю дизайнеру описание объектов и уже не думаю где и как он будет это отображать.
Единственная проблема с оптимизацией это тоже SQL запросы скажем для поиска. Но решаются они точно так же как и в "обычной базе данных"

автор

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

Опять же не совсем это я имел ввиду. Чтоб вернуть значение из "обычной базы данных мне в любом случае надо писать запрос SELECT Name FROM PErsons WHERE ID=1. И вообще не возможно получить весь объект сразу.
А вот синтаксис для CACHE:
set p=##class(Person).OpenID(1)
p уже содержит объект персон. Со всеми свойствами и методами.
Мне кажется очень удобно.


автор

Опять же достаточно типичное поведение, не отличающееся от многих в индустрии, например Oracle Internet Aplication Server работает по тому же принципу.

К сожалению не могу обсудить на сколько это то же самое что CACHE. Никогда не работал с этим

автор

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

Вот тут и получается. Что в одних случаях мне нужно использовать прямой доступ к объктам. Например отображение информации о 5 объектах на страницы. Обычно объектов для отображение не больше 100 и можно сказать что объеденение методом Nested Loops в этом случае будет оптимальное или выгода от других методов будет незначительная.
А при операциях поиска данных, я опять же работаю с СКЛ запросами где есть оптимизатор индексы и т.д.

PS. Да. Действительно 100*10=1000 я только что проверил SELECT 100*10
31 май 04, 16:26    [711657]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ну я
Member

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

Оптимизатор АКБАР! Все, иду молиться новому богу, деинсталлирую все мампсы и иду с миссионерством в пользу sql (микрософт акбар, особенно оракл) по всем клиентам.
31 май 04, 16:28    [711670]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andrewq
Guest
to Wadim

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

Да у меня вобщем-то тоже

>>Очень удобно что таблицы автоматически проецируются в объекты и наоборот.

Иногда может быть весьма полезно, если при этом не страдает производительность, то вообще здорово !

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

Это как это "ПРЯМОЙ" :0 А транзакции, согласованость ?
Или эти вещи как и оптимизатор - считаются предрассудками осталых SQL-щиков и следить за согласованностью,
блокировками и прочим тоже предлагается разработчику на каком-нибудь CTS (Cache Transaction Script),
напоминающем помесь ассемблера с Basic-ом ? Если так, то сравнивать Cache надо с Fox-ом и Dbase-ом,
там он может будет первым.


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

Только чего-то КАШИСТЫ рассказывают о том как круто писать на внутреннем языке -
s date="" f s date=$o(^Rinit("Петров",date)) q:date="" d.w !,(^Rinit("Петров",date)
Который больше похож на синтаксис каких-то регулярных выражений...


>>По поводу скорости сказать точно не могу. На семинаре мне заявили что Каше быстрее MS SQL.

Было-бы странно, если бы вам производитель, который напрямую заинтересован в вас как в клиенте заявил,
что КАШЕ медленее ...


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

Ну этот запрос, он ничего не говорит ни о превосходстве\отставании MSSQL ни о Каше.
А вот тестик TPC у Кашистов имеется ?


>>Вообще они заявляют что сравнивать только по запросу это не правильно.

Правильно заявляют ! Пусть только, заявляя, ТРС покажут, для начала :).

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

Ну это смотря, что считать серверм приложений если просто процедурные расширения - то они сейчас у всех есть и
у всех (MSSQL, DB/2, Oracle) процедуры в базе хранятся и там же выполняются, без промежуточных затрат. Впрочем про это уже говорили.
А если про сервера приложений - то интеграция их с БД это скорее минус,обычный AppServ я могу на отдельную машину установить
соединив её толстенным каналом с сервером и крутить на отдельной железяке извращённую логику, вывод данных в XML,HTML, и куда ещё придётся
экспорт из всяких сторонних форматов (которые например от поставщиков приходят) и т.д. железку с БД не нагружая совершенно, мало станет одной машины , вторую поставить специально для WEB приложений, там и WEB-Server запускать и т.д


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

А вот это уже совершенно лишнее ! Зачем интегрировать в БД WEB-server ? Минимизировать накладные расходы на передачу ?
Современные WEB сервера (Apache и IIS ещё чего-то найти трудно) достаточно мощные и продвинутые продукты, много чего умеют и могут,
а внутри базы серверок наверняка получится простенький и лёгкий и для чего спрашивается нагружать
субд раздачей веб-страничек, и управлением соединениями ? Достаточно просто как следует продумать интеграцию с имеющимися ВЕБ-серверами - всё равно,
самые долгие операции будут при обращении к базе, да и с точки зрения безопасности - с Apache как-то спокойнее чем с неизвестным сервером, который ещё и внутри базы :0
31 май 04, 20:45    [712292]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемые коллеги !
В первой половине 80-х годов после изучения существующих и перспективных моделей данных и СУБД (особенно тщательно изучалась, конечно же, реляционная модель) мы выбрали MUMPS для разработок сложных информационно-логических систем. К сожалению, и критики, и сторонники этой технологии оценивают ее, как правило, неверно. MUMPS - идеальная среда для разработки СУБД, а не прикладных систем. Конечно, есть "мампсисты", которые используют прямой доступ к произвольным древовидным структурам, и получают наслаждение от действительно очень высокой производительности приложений. И им бесполезно рассказывать о независимости программ от путей доступа к данным. В конце концов они тоже иногда оказываются правы в некоторых частных проектах.
На MUMPS можно реализовать любую модель данных с минимальными затратами. Мы, например, реализовали классическую объектную модель (а не "современную" объектную модель, основанную на парадигме ООП, никакого отношения к базам данных не имеющей). Для лучшего понимания существа вопроса лучше сравнивать не реляционную модель с иерархической или сетевой, а записе-ориентированные системы с объектно-ориентированными. Тогда будет (конечно, после дополнительных исследований) понятно, что реляционная модель стала шагом назад в теории баз данных, реляционные СУБД - шагом назад в практике применения технологий баз данных, я SQL практически бесполезен для доступа к данным. Если кому-то действительно интересна теория и практика баз данных, я готов при личной встрече рассказать все что я знаю и понимаю в этой области.
31 май 04, 20:59    [712304]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемые коллеги !
В первой половине 80-х годов после изучения существующих и перспективных моделей данных и СУБД (особенно тщательно изучалась, конечно же, реляционная модель) мы выбрали MUMPS для разработок сложных информационно-логических систем. К сожалению, и критики, и сторонники этой технологии оценивают ее, как правило, неверно. MUMPS - идеальная среда для разработки СУБД, а не прикладных систем. Конечно, есть "мампсисты", которые используют прямой доступ к произвольным древовидным структурам, и получают наслаждение от действительно очень высокой производительности приложений. И им бесполезно рассказывать о независимости программ от путей доступа к данным. В конце концов они тоже иногда оказываются правы в некоторых частных проектах.
На MUMPS можно реализовать любую модель данных с минимальными затратами. Мы, например, реализовали классическую объектную модель (а не "современную" объектную модель, основанную на парадигме ООП, никакого отношения к базам данных не имеющей). Для лучшего понимания существа вопроса лучше сравнивать не реляционную модель с иерархической или сетевой, а записе-ориентированные системы с объектно-ориентированными. Тогда будет (конечно, после дополнительных исследований) понятно, что реляционная модель стала шагом назад в теории баз данных, реляционные СУБД - шагом назад в практике применения технологий баз данных, я SQL практически бесполезен для доступа к данным. Если кому-то действительно интересна теория и практика баз данных, я готов при личной встрече рассказать все что я знаю и понимаю в этой области.
31 май 04, 21:08    [712314]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Yo!
Guest
а что такое объект в каше ?
чем принципиально он отличается от колекции в оракле ?
в каких известных задачах можно увидеть преимущество ? (я знаю только лотус нотес не реляционный - но теперь его переводят на реляционую дб2.)
31 май 04, 21:16    [712324]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexander_Chepack
Member

Откуда: London
Сообщений: 22649
А ничего, если я с упорством маньяка через каждые 10 страниц в этом треде буду задавать один и тот же тупой вопрос - какова рыночная доля CACHE на мировом рынке? Вот просто непрерывно буду бубнить это? Я понимаю, что большинство клиентов в мире тупые и счастья своего не понимают - но, тем не менее, КАКОВА ДОЛЯ РЫНКА? Кому нужен продукт, несовместимый ни с чем?!

А то мне на работе надоело бодаться с очередными изобретателями (авторы - серьезные математики из Швеции) самой эффективной технологии индексации и поиска в файлах. Как в теории - так они впереди планеты всей. А как до тестов доходит и совершенно приземленных вопросов - типа, а можно ли выполнять бэкап без остановки сервисов и если нет, то сколько времени займет довести индексы до текущего состояния, если бэкап занимает 8 часов, а в час мы 5000 новых документов получаем (а всего у нас 4 000 000 файлов) то они смущаются. Типа у них офигенная технология, а о мелочах (которые делают их продукт неприемлимым для большинства клиентов) они не подумали. Более того, большинство этих мелочей у конкурентов реализованы, но из разговоров видно, что авторы давно поставили себя выше остальных и такими мелочами как анализ рынка и потребности и удобство клиентов просто не заморачивались. Справедливости ради стоит заметить, что на 60 килобаксов они нас (ну не нас - так как нас никто не спросил, а нашего европейского директора - они раскрутили), сейчас уже хотят больше - типа 15 штук за "дополнительный сервис", который есть у всех их конкурентов, но почему-то отсутствует у них. Одна незадача - директора того сняли недавно....

Думаю, закончится все тем, что мы потратим примерно ту же сумму на SharePoint Server 2003 и решим большую часть вопросов - может и без самой крутой технологии - хрен с ней с крутизной, нам надо чтобы работало.

А уж об синтаксисе CACHE, приведенном здесь, без хохота говорить нельзя - весь мир баз данных на SQL общается, и тут всерьез предлагается смотреть на какие-то закорючки. Продукт одназначно маргинальный.... кстати, нигде кроме Российскийх форумов я даже упоминания об этом продукте не слышал.
31 май 04, 21:53    [712332]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexander_Chepack
Member

Откуда: London
Сообщений: 22649

В первой половине 80-х годов после изучения существующих и перспективных моделей данных и СУБД (особенно тщательно изучалась, конечно же, реляционная модель) мы выбрали MUMPS для разработок сложных информационно-логических систем.


А ВЫ - это кто?

Если Вы - это абстрактный сферический Андрей Леонидович в вакууме - то нам, вообще говоря, до лампочки что Вы лично выбрали. Если ВЫ - это какой-то советский НИИ (конец 80-х говорите?) - то это даже еще смешнее...

А если ВЫ - это что-то другое - то может назовете все своими именами?
31 май 04, 21:58    [712338]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый Alexander Chepack !\

Я, Чернышев Андрей Леонидович.
Работаю в ЗАО Информ Икс.\
Мой рабочий телефон 797-69-11(12).
Приношу Вам свои извенения, если чем-то Вас обидел.
1 июн 04, 08:29    [712582]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Wadim
Member

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

Это как это "ПРЯМОЙ" :0 А транзакции, согласованость ?

Ну то что транзакции есть и согласованность существует это точно. Вот по поводу технической реализации я к сожалению помочь не могу. Если действительно интересуют такие детали, то можно обратится на форум где Кэшисты обитают (и их там много). Можно даже пойти на конференицю которую нам так любезно разрекрамировал jvvjvv (может он там работает)

Andrewq

Только чего-то КАШИСТЫ рассказывают о том как круто писать на внутреннем языке -
s date="" f s date=$o(^Rinit("Петров",date)) q:date="" d.w !,(^Rinit("Петров",date)
Который больше похож на синтаксис каких-то регулярных выражений...

"Я вам не скажу за всю Одессу...(с)" Но опять же, в Каше есть бэйсик, есть полная форма записи операторов, так что можно выбрать. По своему опыту могу сказать, что после недели работы лень берет свое и начинаешь писать f вместо for, s вместо set и так далее.

Andrewq

А вот тестик TPC у Кашистов имеется ?

Я про такой не слышал. В ответ на мой вопрос в центральный офис мне что-то мямлили.

Andrewq

А если про сервера приложений - то интеграция их с БД это скорее минус,

Мне кажется что плюс. Но чтоб далеко не отходить от темы разговора, скажем так: В Каше можно создать как интрегрированный сервер приложений, так и обычную n-звенку.

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

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

Хотелось бы услышать больше мнение людей которые имеют опыт работы на Каше и другой СУБД.
Очень интересно, кто-нибудь пытался сделать проект на Каше но после двух-трех месяцев трудов решил что все это фигня и начал опят делать все на обычных СУБД. Почему?

Из тех недостатков что я заметил это отсутсвие нормальной репликации и отсутствие guid. обещают все это исправить в следующей версии.
1 июн 04, 09:54    [712745]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
2 Андрей Леонидович
Андрей Леонидович
Тогда будет (конечно, после дополнительных исследований) понятно, что реляционная модель стала шагом назад в теории баз данных, реляционные СУБД - шагом назад в практике применения технологий баз данных, я SQL практически бесполезен для доступа к данным. Если кому-то действительно интересна теория и практика баз данных, я готов при личной встрече рассказать все что я знаю и понимаю в этой области.
Дык и изложили бы кратенько, а то до Москвы то далеко, и не понятно стоит ли ехать, а то чего ехать вдруг опять одни лозунги, а так хочется приобщится к будущему.
Ведь "после изучения существующих и перспективных моделей данных и СУБД " явно должны остаться четкие и понятные материьялы, вот и изложите нам тезисно так, тут же технический форум, а не рекламно-маркетинговый. Заранее спасибо!
1 июн 04, 09:58    [712758]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 Андрей Леонидович
Присоединяясь к предыдущим просьбам - давайте покажите как надо работать на приведённом выше примере: есть некие пациенты, которые ходят иногда в поликлиннику. И нам надо иногда делать выборки: кто ходил в определённый день в поликлиннику, когда определённый человек ходил, сколько человек приходит за день и т.д. Я думаю как это сделать на SQL все в курсе, а вот как это делать передовыми технологиями?
Я очень рад что Вам удалось организовать классическую объектную модель , но хотелось бы узнать практический смысл этого. Согласитесь, что Ваш мессадж ни содержит ни одного аргумента и соответсвенно не всеми может быть серьёзно воспринят.

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

Тогда может Вы и писали бы что работаете с СУЗ(Системой управления записями), а не СУБД? И не было бы никаких разногласий.

SQL практически бесполезен для доступа к данным
Извините, но это примерно как написать что бензин приктически бесполезен для двигателей внутреннего сгорания. Вы после 80-х годов то интересовались чего в мире твориться?
1 июн 04, 10:28    [712881]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
2 Wadim
Wadim
Но CASHE решает проблему маппинга.

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

автор
Опять же не совсем это я имел ввиду. Чтоб вернуть значение из "обычной базы данных мне в любом случае надо писать запрос SELECT Name FROM PErsons WHERE ID=1. И вообще не возможно получить весь объект сразу.
Ну про то что можно получить все данные объекта сразу, мы вроде уже согласились. Обычные, ну скажем всё таки не базы данных, а СУБД, ныне объктно-реляционные (DB2/Oracle/Informix :(, если не ошибаюсь Postgres),
в которых Вы с тем или иным успехом по результатам вашего запроса сразу можете получить "весь объект сразу" (качество ныне существующих объектно-реляционных средств тема отдельного обсуждения). В Oracle в вашей ситуации достаточно создать объектно-реляционное представление и получайте свой объект целиком. Причем представлений таких на вашу "PErsons" можно создать сколько угодно, в зависимости от требований и нужд конкоретных приложений.

Wadim
set p=##class(Person).OpenID(1)
p уже содержит объект персон. Со всеми свойствами и методами.

И c 90% ненужной в данном случае информацией? ( это я про "универсальный" маппинг).

Wadim
Вот тут и получается. Что в одних случаях мне нужно использовать прямой доступ к объктам. Например отображение информации о 5 объектах на страницы. Обычно объектов для отображение не больше 100 и можно сказать что объеденение методом Nested Loops в этом случае будет оптимальное или выгода от других методов будет незначительная.
Стоит ли городить огород что бы достать 5-объектов, такая операция и без организации "прямого" доступа будет выполнена с достаточной скоростью, того что ваша страница появится за 0,005 секунды а не за 0,05 секунды (условно) благодарный пользователь даже незаметит.

Wadim
А при операциях поиска данных, я опять же работаю с СКЛ запросами где есть оптимизатор индексы и т.д.

Честно говоря есть некоторые сомнения в оптимизаторе для метода доступа который не считается основным. Насколько я видел материалы Интерсистем, SQL-доступ они позиционируют как временное решение при переводе приложения с "обычной SQL" СУБД на CACHE, пока приложение не будет переписано под "прямой" доступ.
Т.е. можно действительно понять "прямой досуп" для крайних случаев, когда для основного доступа предлагается какой нибудь декларативный язык доступа, пусть это буде не SQL, у него действительно куча тараканов, пусть это будет некий M-QL.
1 июн 04, 10:43    [712945]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Wadim
Member

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

Alexander_Chepack

А ничего, если я с упорством маньяка через каждые 10 страниц в этом треде буду задавать один и тот же тупой вопрос - какова рыночная доля CACHE на мировом рынке?

Не думаю что это против правил форума. Но мне кажется что этот вопрос лучше задать людям которые знают и работают на Каше. Или непосредственно в офис Intersystems. Здесь таких немного и те без большого опыта работы(простите если кого обидел. Не все конечно.)

Alexander_Chepack

Кому нужен продукт, несовместимый ни с чем?!

Какой уровень совместимости Вы хотите достичь? SQL-92 поддерживается. Импорт, экспорт данных тоже существует. Работа с внешними базами данных через подлинокованные таблицы.

Alexander_Chepack

А уж об синтаксисе CACHE, приведенном здесь, без хохота говорить нельзя - весь мир баз данных на SQL общается, и тут всерьез предлагается смотреть на какие-то закорючки.

В ответ на заявления Кэшистов что реляционные базы данных это плоские двухмерные данных. Им заявляют что синтаксис языка у них плохой. :) :) :)
Не нравится ситаксис пишите на таком какой нравится: BASIC, SQL, полностью операторы в COS
1 июн 04, 10:47    [712970]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Андрей Леонидович

Ура ! Наконец-то !

"В первой половине 80-х годов после изучения существующих и перспективных моделей данных и СУБД (особенно тщательно изучалась, конечно же, реляционная модель) мы выбрали MUMPS для разработок сложных информационно-логических систем."

Есть тот, кто сможет (наверное) внятно объяснить, что же за модель используется в КАШЕ? Похожа она на реляционную, дополняет её ? Если нет, то что там используется вместо логики предикатов и теории множеств, на которых выстроена реляционная модель ? Почему главный разработчик из Intersystems не может двух слов связать, расказывая про модель в КАШЕ ? Согласитесь, это немножко настораживает.

"MUMPS - идеальная среда для разработки СУБД а не прикладных систем"

Так для чего нужна СУБД ? Для СУБД или всё-таки для прикладной области ? Если СУБД для СУБД, то С/C++ получше MUMPS-а будет, можно на нём такую работу с индексами написать - о-го-го, только долго это и непросто.

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

Вот это немножко напрягает :( Почему при встрече ?
"Бить будете папаша ?" (с) П.П. Шариков

Изложите свои соображения тут,или дайте ссылочку на тезисы, если они действительно стоящие их оценят и тогда можно и встречу устроить, а если это очередной пустозвонство "специалистов" середины 80-х из какого-нибудь НИИ "Сложных очень сложных, совсем сложных нелинейных проблем" жалко тратить время ей богу.

2 Wadim

"Какой уровень совместимости Вы хотите достичь? SQL-92 поддерживается. Импорт, экспорт данных тоже существует. Работа с внешними базами данных через подлинокованные таблицы."

Но везде почему-то кричат о прямом доступе и о "постреляционной"
модели, никто КАШЕ как обычную РСУБД не рассматривает и супер-скорости достигаются, вроде как, тоже после "ПРЯМОГО" доступа. Вот народ и засомневался.

"В ответ на заявления Кэшистов что реляционные базы данных это плоские двухмерные данных. Им заявляют что синтаксис языка у них плохой. :) :) :)"

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

"Не нравится ситаксис пишите на таком какой нравится: BASIC, SQL, полностью операторы в COS"

Но примеры-то приводят на языке, который выглядит как непойми что, представте, что вы в команде из 10-ти разработчиков и вам надо немного поправить чужой код, немало восхитительных часов вы проведёте разбирая строчки типа - D:$%^##$^"ПЕТРОВ"::^^P, а вот посмотрев SQL запрос или текст на TSQL(PL/SQL) можно довольно быстро сообразить, что происходит и исправить/дополнить/использовать в своей задаче. Кроме того, сокрашения операторов и переменных до одной строчки ничего не дают в плане выигрыша в скорости исполнения процедуры, только затрудняют её чтение.

P.S Пост от Andrewq мой - писал с чужого компьютера, а пароль забыл :(
1 июн 04, 11:44    [713182]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Wadim
Member

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

Видимо мне не удалось показать преимущество CACHE на примере.
Могу только посоветовать скачать версию Каше. Потратить три дня на учебный проект и после этого высказать свое мнение.

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

Я уже привел те факты которые выгодно выделяют Каше на фоне других СУБД.
Себе я это доказал когда делал проект на Каше.

Еще могу порекомндовать прочитать этот топик
[url=http://]http://xpoint.ru/archive/topic15/42/8591.html[/url]

ЗЫ to Andreww.
Обвинения в плохом синтаксисе я уже и не знаю как воспринимать после того как я в трех постах написал что Каше поддерживает как Бейсик, так и COS с сокращенной формой записи и расширенной. Как вам нравится в вашей группе так и пишите. Можете даже штраф брать с тех кто заменить for на f.
По вашему получается что если я могу написать только for это хорошо. А если у меня есть выбор написать f или for, то это плохо. Не демократично это, особенно в государстве где главной целью является построение гражданского общества
1 июн 04, 12:22    [713325]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
А топик - то уже два года пинаем, братцы.
1 июн 04, 12:26    [713338]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемые коллеги !

1. Я не занимаюсь продажами, и ничего не рекламирую.
2. Более 20-ти лет я занимаюсь исключительно теорией и проектированием баз данных.
3. Я просто сообщил о результатах, полученных более 20-ти лет назад, и подтвержденных всем последующим опытом.
4. Я постоянно изучаю все новые достижения в области баз данных, и всегда готов к переходу в другую, более эффективную, среду разработки, как только она появится.
5. Мы не используем объекты Cache, и, тем более, SQL. Мы используем Cache так же, как раньше использовали другие реализации MUMPS, то есть как платформу, на которой работает наша СУБД, и созданные в ее среде приложения. Кроме того, я считаю неэтичным комментировать в Internet продукты и технологии других разработчиков.
6. Проверенный факт: 1 месяц обсуждения проблем баз данных на подобных форумах отнимает до 15 часов жизни, тогда как при живом общении все эти же вопросы решаются в течение одного часа. А это, все-таки, время моей биологической жизни.

Я оставил свой телефон, и всегда готов к встрече. Желаю всем успехов.
1 июн 04, 18:44    [714787]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Да как-то не очень то мне просто из Питера в Москву мотаться... А кому и из других стран... Ну и странно надеяться на пользу от встречи с человеком который считает что SQL практически бесполезен для доступа к данным.
А вобще уже не первый раз - некто приходит и пишет что мы все отсталые люди, мыслим плоско, а как доходит чтоб привести примитивный примерчик - не дождётесь, неэтично мол.
1 июн 04, 20:20    [714937]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
Ну вот так всегда, всё так хорошо начиналось ...

>>1. Я не занимаюсь продажами, и ничего не рекламирую.

Вы учёный ? От того насколько хорошо будет продаваться КАШЕ и насколько широко он(она?) будет распостранён не зависит благосостояние вас и вашей компании ? Ну наконец-то, ура !

>>2. Более 20-ти лет я занимаюсь исключительно теорией и проектированием баз данных.

Давайте не будем заниматься сами знаете чем
Меряние детородным органом - любимое занятие быков производителей

Ведь могут и ссылочки на работы попросить

Кроме того, я в своей недолгой жизни видал профессоров из столичных и Питерских вузов которые занимались выч. математикой по 30 лет и свято верили в то, что определённый интеграл в аналитическом виде невозможно получить на ЦЭВМ.

Как говориться - Иногда мудрость приходит с годами, а иногда годы приходят одни ...

>>3. Я просто сообщил о результатах, полученных более 20-ти лет назад, и >>подтвержденных всем последующим опытом.

Если результаты настолько впечатляющие, почему про них молчит dbdebunk или, хотя бы, Database Journal ? Кроме того за столько лет у вас должны накопиться и материалы и тезисы - приведите их, хотя бы основу - в чём недостатки реляционной модели и как с ними справляются системы на основе MUMPS-овой модели (видите я даже не знаю как она называется) .

>>4. Я постоянно изучаю все новые достижения в области баз данных, и >>всегда готов к переходу в другую, более эффективную, среду >>разработки, как только она появится.

А весь мир продолжает оставаться и работать в менее эффективных средах, хотя MUMPS уже есть достаточно давно и всякие зануды, вроде Alexander_Chepack постоянно напоминают о процентном соотношении

>>5. Мы не используем объекты Cache, и, тем более, SQL. Мы используем >>Cache так же, как раньше использовали другие реализации MUMPS, то >>есть как платформу, на которой работает наша СУБД, и созданные в ее >>среде приложения.

Вы наверное удивитесь, когда узнаете, какое количество разработчиков продолжает использовать FoxPro, Clipper, DBASE и какими способами, но это, как ни странно не говорит о перспективности и эффективности этих технологий, хотя некоторые приложения созданные при помощи этих инструментов функционируют весьма успешно.

>>Кроме того, я считаю неэтичным комментировать в Internet продукты и >>технологии других разработчиков.

:( А мы вроде о моделях говорили, или как ?
При чём тут реализация в виде КАШЕ ?
Или всё этично обсуждать только при личной встрече ?


>>6. Проверенный факт: 1 месяц обсуждения проблем баз данных на >>подобных форумах отнимает до 15 часов жизни, тогда как при живом >>общении все эти же вопросы решаются в течение одного часа. А это, >>все-таки, время моей биологической жизни.

А мне казалось учёный должен использовать любую возможность для проверки своих теорий (моделей) на прочность, а уж тем более в интернет форуме - тут оппонентов много и не надо никуда ехать, может подскажут пару-тройку идей.
1 июн 04, 21:16    [715001]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Реляционная модель учит нас отделять физическую структуру от логической. Каше, я так понимаю, учит нас делать наоборот исходя из эффективности. Достоинства реляционной модели и отделения "мух от котлет" общеизвестны, надеюсь Кодда или Дэйта обитатели данной конфы читали. Производительность существующих реляционных СУБД вроде-бы всех вполне устраивает. Что до выбора оптимального физического пути к данным - то оптимизатор рулит однозначно. Особенно если он умный, зараза, как у DB2. А что если мы жестко "зашили" в нашу программулину физический путь к данным, а потом объем данных их их стркутура дэцл поменялись? Добавили пару-тройку атрибутов и искать стали по ним - вот незадача! И этот "зашитый" (hardcoded) путь перестал быть оптимальным. Что нам теперь, пргорамму переписывать? А в реляционных СУБД добавил пару колонок к таблице, залил данные, забацал индекс, собрал статистику - и усо. Ловкость рук - и никакого мошенства! Делается легко и непринужденно, причем без остановки базы так что пользователь может и не заподозрить что там такая капитальная "засада" происходит. А если мы жестко завязаны на физические пути доступа к данным, то вмешательство в структуру данных - это уже нейрохирургия. А оно нам надо? Стоит ли прибавка в производительности (если она вообще есть) отказа от гибкости?

Ссылки на сравнения производительности СУБД сделанные в 80х умиляют. Оракл в те времена был пятый, "игрушечный" под дос и "настоящий" под VMS и unix. Микрософтного SQL тогда еще вообще не было. С той поры много воды утекло. И производительность реляционных СУБД несколько улучшилась. Получили широкое распространение SMP-машины например. Архитектура серверов СУБД претерпела серьезные изменения. Не о чем говорить. Если наш советский МиГ-25 летал быстрее "супостата" но разворачиваться "не умел" это не значит что Су-27 должен по маневренности уступать F-18 а по скорости его превосходить. На самом деле все как раз наоборот.
1 июн 04, 21:48    [715027]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович

>2. Более 20-ти лет я занимаюсь исключительно теорией и проектированием баз данных.

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

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

Желательно доступные в интернете, но можно любые.
1 июн 04, 23:17    [715108]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
мы из разведки
Guest
Не могли бы Вы привести ссыски на результаты этих исследований (не реляционных баз данных конечно), особенно в части теории.

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

Желательно доступные в интернете, но можно любые.


http://www.informx.ru/seminar1.htm
2 июн 04, 11:13    [715891]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
да уж, сильный докладик
вот например цитата обличающая Оракл:
-----------------
Вот обещанный пример процедуры на PL/SQL из книги [13], написанной, между прочим, для профессиональных разработчиков (эта процедура размещена в теле пакета customermanager):

     PROCEDURE updatecustomer (custid IN INTEGER, fieldtype IN CHAR,
        newvalue VARCHAR2) IS
     BEGIN
        IF UPPER(fieldtype)='C' THEN
           UPDATE customer
             SET company=newvalue
             WHERE id=custid;
        ELSEIF UPPER(fieldtype)='A' THEN
           UPDATE customer
             SET address=newvalue
             WHERE id=custid;
        ELSEIF UPPER(fieldtype)='T' THEN
           UPDATE customer
             SET city=newvalue
             WHERE id=custid;
        ELSE
           customermanager.returnerror('Недопустимый тип поля');
        END IF;
        IF SQL%NOTFAUND THEN
           customermanager.returnerror('Недопустимый идентификатор
              покупателя');
        END IF;
     END updatecustomer;
UPPER(x) возвращает строку x, преобразовав ее символы в верхний
регистр

Похоже в PL/SQL существует проблема с косвенными обращениями ?..

Пользователям Икс вообще не нужно писать процедуры, подобные приведенной выше (причем, как видно, их нужно написать много, по крайней мере столько, сколько таблиц в схеме БД !?) в своих приложениях, поскольку такая (единственная !) процедура уже написана:

d U^%cpuh(io,id,ih,newvalue)

где io - идентификатор объекта;
id - идентификатор экземпляра;
ih - идентификатор характеристики.

И снова мы видим, что СУБД Oracle менее готова к употреблению, на этот раз уже программистами.
----------------------
Становиться даже как-то страшно за Оракл, не говоря уж о других.

Вобщем читать не советую, сплошая вода и передергивание. Единственная мысль которую я посчитал полезной: зачем в описании внешнего ключа писать имя и тип колонки (cust_id integer REFERENCES Customers)? По смыслу оно действительно лишнее. Но ведь так уж исторически сложилось...


Очень порадовался за отдел маркетинга фирмы Информ Икс или кем кто там занимается описанием продуктов. Вот строки из описания некой системы:

Информационная корпоративная система ИКС предназначена для полной замены существующей ручной информационной технологии учета или разрозненных автоматизированных модулей учета с целью ...

Важно подчеркнуть, что ИКС - единственная российская система, выполняющая расчет фактической себестоимости каждого кода продукции ...

ИКС – практически единственная российская система на сегодняшнем рынке, которая умеет правильно делать корректировки операций, совершенных в закрытых периодах с...
2 июн 04, 15:15    [716831]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить