Cache
Кто-нибудь пработал с новой постреляционной базой cache..
Хотелось бы узнать Ваше мнение стоит или нет с ней работать..
Судя по статьям слишком крутая!!!
Хотелось бы узнать Ваше мнение стоит или нет с ней работать..
Судя по статьям слишком крутая!!!
Цитата:
Originally posted by vladsoft
Кто-нибудь пработал с новой постреляционной базой cache..
Хотелось бы узнать Ваше мнение стоит или нет с ней работать..
Судя по статьям слишком крутая!!!
Кто-нибудь пработал с новой постреляционной базой cache..
Хотелось бы узнать Ваше мнение стоит или нет с ней работать..
Судя по статьям слишком крутая!!!
Обидно никто не отвечает....А тема ребята актуальная скоро реляционным бд кирдык....
Цитата:
Originally posted by vladsoft
Обидно никто не отвечает....А тема ребята актуальная скоро реляционным бд кирдык....
Обидно никто не отвечает....А тема ребята актуальная скоро реляционным бд кирдык....
Мне тоже было бы интересно ее погонять, только пока нет ни возможности, ни времени, ни самой базы.
Кстати, у меня лично есть подозрение, что ее писали русские по заказу французов.
Цитата:
Originally posted by smartsoft
Мне тоже было бы интересно ее погонять, только пока нет ни возможности, ни времени, ни самой базы.
Кстати, у меня лично есть подозрение, что ее писали русские по заказу французов.
Мне тоже было бы интересно ее погонять, только пока нет ни возможности, ни времени, ни самой базы.
Кстати, у меня лично есть подозрение, что ее писали русские по заказу французов.
Твои подозрения я могу с увереностью подтвердить, куча наших спецов после перестройки туды умотали...
Цитата:
Originally posted by vladsoft
Твои подозрения я могу с увереностью подтвердить, куча наших спецов после перестройки туды умотали...
Твои подозрения я могу с увереностью подтвердить, куча наших спецов после перестройки туды умотали...
Ну, что умотали, я знаю. Только, занимаются ли они непосредственно разработкой Cache, неизвестно...
Цитата:
Originally posted by smartsoft
Ну, что умотали, я знаю. Только, занимаются ли они непосредственно разработкой Cache, неизвестно...
Ну, что умотали, я знаю. Только, занимаются ли они непосредственно разработкой Cache, неизвестно...
Не на самом деле там русские руку приложили, вся бд основа если мне не изменяет память на работах нашего математика, наши как всегда за всех думают, буржуи до ума доводят, а пьем за их здоровье и еще покупаем все у них, взять хотя бы сотовую связь, мало кто знает, но принцип сотовой связи придумал наш физик алферов за что 2000 году получил нобелевскую вот так, а мы сейчас эти телефоны тоннами покупаем...да бабки им еще за связь крутые платим...
Цитата:
Originally posted by vladsoft
Не на самом деле там русские руку приложили, вся бд основа если мне не изменяет память на работах нашего математика, наши как всегда за всех думают, буржуи до ума доводят, а пьем за их здоровье и еще покупаем все у них, взять хотя бы сотовую связь, мало кто знает, но принцип сотовой связи придумал наш физик алферов за что 2000 году получил нобелевскую вот так, а мы сейчас эти телефоны тоннами покупаем...да бабки им еще за связь крутые платим...
Не на самом деле там русские руку приложили, вся бд основа если мне не изменяет память на работах нашего математика, наши как всегда за всех думают, буржуи до ума доводят, а пьем за их здоровье и еще покупаем все у них, взять хотя бы сотовую связь, мало кто знает, но принцип сотовой связи придумал наш физик алферов за что 2000 году получил нобелевскую вот так, а мы сейчас эти телефоны тоннами покупаем...да бабки им еще за связь крутые платим...
Забыл добавить бляди все эти буржуи самые настоящие...
На счет реляционных ты правильно заметил, а на практике пока не отвечу, пробую через ActiveX, пока не выходит, не видно всех обьектов.
[QUOTE=AdmigatorR]На счет реляционных ты правильно заметил, а на практике пока не отвечу, пробую через ActiveX, пока не выходит, не видно всех обьектов.[/QUOTE]
В "Базы данных" плавно едем. Потому как бе разницы - кто ее писал - французы или русские - но теме вроде место там.
З.Ы. Хотя если разговор продолжится так же - то самое место в гостевой ИМХО.
В "Базы данных" плавно едем. Потому как бе разницы - кто ее писал - французы или русские - но теме вроде место там.
З.Ы. Хотя если разговор продолжится так же - то самое место в гостевой ИМХО.
[QUOTE=vladsoft]Кто-нибудь пработал с новой постреляционной базой cache..
Хотелось бы узнать Ваше мнение стоит или нет с ней работать..
Судя по статьям слишком крутая!!![/QUOTE]
Весь нижеследующий текст -- одно сплошное имхо, кроме цитаты.
Статьи пишет сама Intersystems, разработчик этой СУБД. И в этих статьях Cache` сравнивается не с чем-нибудь, а именно с Oracle (знает Intersystems, кто сегодня лидер на рынке СУБД!)
Оснований верить статьям про Cache` лично у меня очень мало.
Во-первых, тесты выполнялись по заказу заинтересованной стороны.
Во-вторых, сравнивались неизвестно какие версии Oracle и Cache` (по крайней мере, в тех рекламных проспектах Intersystems, которые я держал в руках).
В-третьих, ничего не сказано о методике тестирования, об аппаратных платфомах и структурах баз данных для тестируемых СУБД.
В-четвёртых, слишком разные методики обращения к данным (хотя Cache` тоже поддерживает SQL).
В-пятых, "объектность" СУБД говорит о наличии позднего связывания, что по-любому медленнее (в Oracle применяется только ранее связывание).
Есть ещё парочка недостатков, не связанных непосредственно с характеристиками СУБД, но, на мой взгляд, довольно существенных.
Во-первых, "документированность" Oracle гораздо выше, чем Cache`.
Во-вторых, узкий спектр средств доступа к БД Cache`: native API, ODBC и ADO/OLEDB (сравним с Oracle: родная API aka OCI, ODBC, OLEDB/ADO, Oracle Object for OLE, Oracle Data ActiveX, Database Express CLX для Delphi/Kylix/C++Builder, DOA VCL, ODAC, AnyDAC, ну, и много ещё).
В заключение хочу сказать: многие эксперты полагают, что "потенциал дальнейшего развития теории реляционных баз данных еще далеко не исчерпан" (с).
Хотелось бы узнать Ваше мнение стоит или нет с ней работать..
Судя по статьям слишком крутая!!![/QUOTE]
Весь нижеследующий текст -- одно сплошное имхо, кроме цитаты.
Статьи пишет сама Intersystems, разработчик этой СУБД. И в этих статьях Cache` сравнивается не с чем-нибудь, а именно с Oracle (знает Intersystems, кто сегодня лидер на рынке СУБД!)
Оснований верить статьям про Cache` лично у меня очень мало.
Во-первых, тесты выполнялись по заказу заинтересованной стороны.
Во-вторых, сравнивались неизвестно какие версии Oracle и Cache` (по крайней мере, в тех рекламных проспектах Intersystems, которые я держал в руках).
В-третьих, ничего не сказано о методике тестирования, об аппаратных платфомах и структурах баз данных для тестируемых СУБД.
В-четвёртых, слишком разные методики обращения к данным (хотя Cache` тоже поддерживает SQL).
В-пятых, "объектность" СУБД говорит о наличии позднего связывания, что по-любому медленнее (в Oracle применяется только ранее связывание).
Есть ещё парочка недостатков, не связанных непосредственно с характеристиками СУБД, но, на мой взгляд, довольно существенных.
Во-первых, "документированность" Oracle гораздо выше, чем Cache`.
Во-вторых, узкий спектр средств доступа к БД Cache`: native API, ODBC и ADO/OLEDB (сравним с Oracle: родная API aka OCI, ODBC, OLEDB/ADO, Oracle Object for OLE, Oracle Data ActiveX, Database Express CLX для Delphi/Kylix/C++Builder, DOA VCL, ODAC, AnyDAC, ну, и много ещё).
В заключение хочу сказать: многие эксперты полагают, что "потенциал дальнейшего развития теории реляционных баз данных еще далеко не исчерпан" (с).
[QUOTE=Plisteron]
Статьи пишет сама Intersystems, разработчик этой СУБД. И в этих статьях Cache` сравнивается не с чем-нибудь, а именно с Oracle (знает Intersystems, кто сегодня лидер на рынке СУБД!)
Оснований верить статьям про Cache` лично у меня очень мало.
[/QUOTE]
Вобще разгромные статьи Intersystems по отношению к Oracle действительно настораживают. Как то не сильно верится. Хотя справедливости ради надо заметить, что сами проводили тесты, а так же знакомые из другой компании. Тесты проводили на своих структурах БД, для своих продуктов. Соответственно с актуальной и исспользуемой версией Oracle, на одних машинах. Заинтересованными сторонами не были, было желание сравнить эффективность. На наших задачах даже с одинаковой структурой базы Cache действительно работала быстрее.
Но есть у нее один недостаток - глючноватая она. С проблемой потери целостности данных не сталкивался сам, хотя знакомые говорили (но отсутстве кривых рук знакомых, а не глюка в СУБД тоже не гарантированно=)), но вот подвисание самого сервера, да и частые баги в среде разработки наблюдал не раз =)
В-четвёртых, слишком разные методики обращения к данным (хотя Cache` тоже поддерживает SQL).
В-пятых, "объектность" СУБД говорит о наличии позднего связывания, что по-любому медленнее (в Oracle применяется только ранее связывание).
Статьи пишет сама Intersystems, разработчик этой СУБД. И в этих статьях Cache` сравнивается не с чем-нибудь, а именно с Oracle (знает Intersystems, кто сегодня лидер на рынке СУБД!)
Оснований верить статьям про Cache` лично у меня очень мало.
[/QUOTE]
Вобще разгромные статьи Intersystems по отношению к Oracle действительно настораживают. Как то не сильно верится. Хотя справедливости ради надо заметить, что сами проводили тесты, а так же знакомые из другой компании. Тесты проводили на своих структурах БД, для своих продуктов. Соответственно с актуальной и исспользуемой версией Oracle, на одних машинах. Заинтересованными сторонами не были, было желание сравнить эффективность. На наших задачах даже с одинаковой структурой базы Cache действительно работала быстрее.
Но есть у нее один недостаток - глючноватая она. С проблемой потери целостности данных не сталкивался сам, хотя знакомые говорили (но отсутстве кривых рук знакомых, а не глюка в СУБД тоже не гарантированно=)), но вот подвисание самого сервера, да и частые баги в среде разработки наблюдал не раз =)
Цитата:
В-четвёртых, слишком разные методики обращения к данным (хотя Cache` тоже поддерживает SQL).
Ну вобще даже в статьях от Intersystems говорилось, что большой прирост производительности был при исспользовании где возможно прямого обращения к данным, самого быстрого. Это как бы их фича и я думаю они имеют право ей пользоваться, при одинаковой структуре БД. Хотя если верить статьям даже при исспользовании реляционного интерфейса скорость выше.
Цитата:
В-пятых, "объектность" СУБД говорит о наличии позднего связывания, что по-любому медленнее (в Oracle применяется только ранее связывание).
Ну объектность там не совсем настоящая. Данные хранятся же просто в многоиндексных списках. А уже предстаялятся могут одновременно в реляционном и объектном представлении, пользоватся каким то из которых не обязательно.
Цитата:
Вобще она так же через объектный интерфес может общатся через ActiveX, и даже напрямую в роли java объектов. С различными CASE средствами хорошо работает. Удобно объектную модель строить, из UML экспортировать. CSP страницы надо отдать должное быстрее работают с БД по понятным причинам, чем многи другие веб технологии. А вобще отношение к этой СУБД не очень приятное с одной стороны, видимо из-за явных багов, но с другой стороны порой нравится вполне удачная задумка.
[QUOTE=aks]На наших задачах даже с одинаковой структурой базы Cache действительно работала быстрее.[/QUOTE]
Версии Cache` и Oracle, а также степень загруженности БД и настройки СУБД в студию! Да и аппаратную конфигурацию тоже + что за операционная система.
Наверняка, поигравшись в Oracle с настройкой конфиги и организацией таблиц, можно получить прирост быстродействия. Где-то использовать Index-organized tables, где-то использовать кластерные таблицы, где-то, наоборот, partitioning, сделать материализованные представления для редко изменяемых, но часто используемых в запросах данных...
А серьёзная глючность (совсем безглючного мало-мальски сложного софта не бывает) или зависаемость БД делает данную БД, строго говоря, непригодной ни к чему, кроме поддержки домашних БД "Семейный бюджет" или "Каталог фильмов на DVD"
Версии Cache` и Oracle, а также степень загруженности БД и настройки СУБД в студию! Да и аппаратную конфигурацию тоже + что за операционная система.
Наверняка, поигравшись в Oracle с настройкой конфиги и организацией таблиц, можно получить прирост быстродействия. Где-то использовать Index-organized tables, где-то использовать кластерные таблицы, где-то, наоборот, partitioning, сделать материализованные представления для редко изменяемых, но часто используемых в запросах данных...
А серьёзная глючность (совсем безглючного мало-мальски сложного софта не бывает) или зависаемость БД делает данную БД, строго говоря, непригодной ни к чему, кроме поддержки домашних БД "Семейный бюджет" или "Каталог фильмов на DVD"
[QUOTE=aks]Вобще она так же через объектный интерфес может общатся через ActiveX, и даже напрямую в роли java объектов. С различными CASE средствами хорошо работает. Удобно объектную модель строить, из UML экспортировать.[/QUOTE]
CASE, UML и всё такое прочее есть, понятное дело, и для Oracle.
[QUOTE=aks]CSP страницы надо отдать должное быстрее работают с БД по понятным причинам, чем многи другие веб технологии.[/QUOTE]
Что такое CSP, признаться, не имею представления, поэтому не могу подтвердить/опровергнуть/согласиться/оспаривать последнее утверждение.
CASE, UML и всё такое прочее есть, понятное дело, и для Oracle.
[QUOTE=aks]CSP страницы надо отдать должное быстрее работают с БД по понятным причинам, чем многи другие веб технологии.[/QUOTE]
Что такое CSP, признаться, не имею представления, поэтому не могу подтвердить/опровергнуть/согласиться/оспаривать последнее утверждение.
Ещё немного соображений по поводу СУБД Cache`, которые, по сути, являются выводами, сделанными мной из просмотра соответствующей темы на форуме *******.
На задачах с небольшим количеством изменений данных и предсказуемых выборках Cache` действительно оказывается быстрее Oracle за счёт, во-первых, блокировочного механизма транзакций (у Oracle версионный), во-вторых, за счёт отсутствия нормальной поддержки трагзакций (есть команды LOCK/TSTART/TCOMMIT/TROLLBACK, но, цитируя участников форума S Q L . R U, "за правильностью его использования программист должен был следить сам, и откат транзакций тоже должен был делать сам"). Соответственно, в Cache` нет накладных расходов на поддержку транзакций, они перекладываются на программиста.
Скорость работы реальных приложений, с триггерами и хранимыми процедурами, в Cache` может быть значительно ниже, чем в Oracle, при этом скорость разработки в языке, применяемом в Cache`, может также оказаться меньше, несмотря на компактность записи кода по сравнению с PL/SQL. Цитирую: "Были предложены вполне реальные задачи с покупкой авиабилетов, сравнили длину кода (а это трудоемкость), оказалось далеко не в пользу М-систем. А после предложения сравнить скорость защитники М-систем вообще разом пропали."
Цитата к вопросу о том, что производительность конкретной БД зависит не только от производительности СУБД: "Что до эффективности... В случае М-систем эффективность будет чрезвычайно сильно зависеть от квалификации разработчика как программиста. В случае SQL - разработчик несколько меньше связан с трудами Кнута и может больше внимания уделять предметной области."
PS. В связи с идиосинкарзией данного форума к сайту ЭсКьюЭл-точка-РУ, все ссылки на последний автоматически заменились на звёздочки. :( Кто хочет перейти по ссылками, замените звёздочки sql, точку и ru.
На задачах с небольшим количеством изменений данных и предсказуемых выборках Cache` действительно оказывается быстрее Oracle за счёт, во-первых, блокировочного механизма транзакций (у Oracle версионный), во-вторых, за счёт отсутствия нормальной поддержки трагзакций (есть команды LOCK/TSTART/TCOMMIT/TROLLBACK, но, цитируя участников форума S Q L . R U, "за правильностью его использования программист должен был следить сам, и откат транзакций тоже должен был делать сам"). Соответственно, в Cache` нет накладных расходов на поддержку транзакций, они перекладываются на программиста.
Скорость работы реальных приложений, с триггерами и хранимыми процедурами, в Cache` может быть значительно ниже, чем в Oracle, при этом скорость разработки в языке, применяемом в Cache`, может также оказаться меньше, несмотря на компактность записи кода по сравнению с PL/SQL. Цитирую: "Были предложены вполне реальные задачи с покупкой авиабилетов, сравнили длину кода (а это трудоемкость), оказалось далеко не в пользу М-систем. А после предложения сравнить скорость защитники М-систем вообще разом пропали."
Цитата к вопросу о том, что производительность конкретной БД зависит не только от производительности СУБД: "Что до эффективности... В случае М-систем эффективность будет чрезвычайно сильно зависеть от квалификации разработчика как программиста. В случае SQL - разработчик несколько меньше связан с трудами Кнута и может больше внимания уделять предметной области."
PS. В связи с идиосинкарзией данного форума к сайту ЭсКьюЭл-точка-РУ, все ссылки на последний автоматически заменились на звёздочки. :( Кто хочет перейти по ссылками, замените звёздочки sql, точку и ru.
Не заметил сразу сообщения. ))
[QUOTE=Plisteron]Версии Cache` и Oracle, а также степень загруженности БД и настройки СУБД в студию! Да и аппаратную конфигурацию тоже + что за операционная система.
[/QUOTE]
Версии и точную конфигурацию железа я вам сейчас не скажу, так как просто не помню уже. Не вчера дело было, а гдето год назад.
Скажу только что суть тестирования была взять уже готовую структуру базы, для готового продукта, и с одинаковыми условиями, без исспользования дополнительных улучшенных особенностей каждой СУБД протестировать их на одних данных на одном железе. Тестировалось довольно причем долго и Cache' тогда на нескольких проведенных тестах лидировал. Но это только наше наблюдение и на видение ситуации в целом оно конечно не претендует. )
[QUOTE=Plisteron]
Наверняка, поигравшись в Oracle с настройкой конфиги и организацией таблиц, можно получить прирост быстродействия.
[/QUOTE]
Ну вобще суть то была именно равноправное тестирование провести. Как бы покопавшись в Cache' немного перераспределив базу, исспользуя dirrect access везде где монжно, тоже можно увеличить быстродействие.
[QUOTE=Plisteron]
А серьёзная глючность (совсем безглючного мало-мальски сложного софта не бывает) или зависаемость БД делает данную БД, строго говоря, непригодной ни к чему, кроме поддержки домашних БД "Семейный бюджет" или "Каталог фильмов на DVD"[/QUOTE]
Ну про совсем безглючность это понятно. Даже не сложного софта без багов не бывает.
А по поводу зависания - во время работы с БД зависания и сглючивания сам не разу не замечал, хотя довольно много приходилось когда то с ней работать. Слышал слухи - но это слухи. ) Баги наблюдаются в процессе разработки как правило. Со средствами разработки. Но это как раз то что от нее отталкивает и почему ей не пользуемся.
[QUOTE=Plisteron]
CASE, UML и всё такое прочее есть, понятное дело, и для Oracle.[/QUOTE]
Так я знаю, я просто заметил справедливости ради, что не один Oracle обладает разными полезностями к разработке. Тем более у них подход немного разный. Cache' не смотря на свою хитрую структуру обычно всеже поззиционируется с объектной стороны )
Что такое CSP, признаться, не имею представления, поэтому не могу подтвердить/опровергнуть/согласиться/оспаривать последнее утверждение.
[QUOTE=Plisteron]Версии Cache` и Oracle, а также степень загруженности БД и настройки СУБД в студию! Да и аппаратную конфигурацию тоже + что за операционная система.
[/QUOTE]
Версии и точную конфигурацию железа я вам сейчас не скажу, так как просто не помню уже. Не вчера дело было, а гдето год назад.
Скажу только что суть тестирования была взять уже готовую структуру базы, для готового продукта, и с одинаковыми условиями, без исспользования дополнительных улучшенных особенностей каждой СУБД протестировать их на одних данных на одном железе. Тестировалось довольно причем долго и Cache' тогда на нескольких проведенных тестах лидировал. Но это только наше наблюдение и на видение ситуации в целом оно конечно не претендует. )
[QUOTE=Plisteron]
Наверняка, поигравшись в Oracle с настройкой конфиги и организацией таблиц, можно получить прирост быстродействия.
[/QUOTE]
Ну вобще суть то была именно равноправное тестирование провести. Как бы покопавшись в Cache' немного перераспределив базу, исспользуя dirrect access везде где монжно, тоже можно увеличить быстродействие.
[QUOTE=Plisteron]
А серьёзная глючность (совсем безглючного мало-мальски сложного софта не бывает) или зависаемость БД делает данную БД, строго говоря, непригодной ни к чему, кроме поддержки домашних БД "Семейный бюджет" или "Каталог фильмов на DVD"[/QUOTE]
Ну про совсем безглючность это понятно. Даже не сложного софта без багов не бывает.
А по поводу зависания - во время работы с БД зависания и сглючивания сам не разу не замечал, хотя довольно много приходилось когда то с ней работать. Слышал слухи - но это слухи. ) Баги наблюдаются в процессе разработки как правило. Со средствами разработки. Но это как раз то что от нее отталкивает и почему ей не пользуемся.
[QUOTE=Plisteron]
CASE, UML и всё такое прочее есть, понятное дело, и для Oracle.[/QUOTE]
Так я знаю, я просто заметил справедливости ради, что не один Oracle обладает разными полезностями к разработке. Тем более у них подход немного разный. Cache' не смотря на свою хитрую структуру обычно всеже поззиционируется с объектной стороны )
Цитата:
Что такое CSP, признаться, не имею представления, поэтому не могу подтвердить/опровергнуть/согласиться/оспаривать последнее утверждение.
Ну это их веб технология. ПО своей сути больше всего наверно напоминает java сервлеты и jsp.
Тоесть так же определенные классы базы генерируют web страницы (по сути как сервлеты). Можно создавать сразу CSP страницы - html с CSP тегами, которые при первом обращении генерируются в класс (аналог jsp).
Как раз отличается эффективностью доступа к БД, поскольку выполняются непосредственно в СУБД и обращаются напрямую к как правило к уже закешированным данным.
[QUOTE=aks]Как бы покопавшись в Cache' немного перераспределив базу, исспользуя dirrect access везде где монжно, тоже можно увеличить быстродействие.[/QUOTE]
Даже нужно. Надо сравнивать не в настройках по дефолту, а именно при максимальном тюнинге обеих БД и максимальном использовании фирменных технологий ускорения. Иначе какой смысл?
[QUOTE=aks]Ну это их веб технология. ПО своей сути больше всего наверно напоминает java сервлеты и jsp.
Тоесть так же определенные классы базы генерируют web страницы (по сути как сервлеты). Можно создавать сразу CSP страницы - html с CSP тегами, которые при первом обращении генерируются в класс (аналог jsp).
Как раз отличается эффективностью доступа к БД, поскольку выполняются непосредственно в СУБД и обращаются напрямую к как правило к уже закешированным данным.[/QUOTE]
Искреннее спасибо, что растолковали. А ведь могли и на Google отправить, или "RTFM" ответить. ;)
Даже нужно. Надо сравнивать не в настройках по дефолту, а именно при максимальном тюнинге обеих БД и максимальном использовании фирменных технологий ускорения. Иначе какой смысл?
[QUOTE=aks]Ну это их веб технология. ПО своей сути больше всего наверно напоминает java сервлеты и jsp.
Тоесть так же определенные классы базы генерируют web страницы (по сути как сервлеты). Можно создавать сразу CSP страницы - html с CSP тегами, которые при первом обращении генерируются в класс (аналог jsp).
Как раз отличается эффективностью доступа к БД, поскольку выполняются непосредственно в СУБД и обращаются напрямую к как правило к уже закешированным данным.[/QUOTE]
Искреннее спасибо, что растолковали. А ведь могли и на Google отправить, или "RTFM" ответить. ;)
[QUOTE=Plisteron]На задачах с небольшим количеством изменений данных и предсказуемых выборках Cache` действительно оказывается быстрее Oracle за счёт, во-первых, блокировочного механизма транзакций (у Oracle версионный), во-вторых, за счёт отсутствия нормальной поддержки трагзакций (есть команды LOCK/TSTART/TCOMMIT/TROLLBACK, но, цитируя участников форума S Q L . R U, "за правильностью его использования программист должен был следить сам, и откат транзакций тоже должен был делать сам").[/QUOTE]
Если это действительно так, Cache' - игрушка.
Если это действительно так, Cache' - игрушка.
[quote=aks]На наших задачах даже с одинаковой структурой базы Cache действительно работала быстрее.[/quote] хм... видишь ли, на определенных задачах - даже недосубд MySQL по скорости разрывает Oracle на части. вопрос в том, за счет чего реализовано преимущество в скорости и сохранится ли оно, например, при стрессовых нагрузках. или на сложной базе в сотни и тысячи таблиц.
Цитата:
за правильностью его использования программист должен был следить сам, и откат транзакций тоже должен был делать сам
угумс... все ясно. то про что я говорил. в итоге программер клепает свою корявую обвязку для поддержки транзакций. и преимущество по скорости куда то пропадает?
короче Freeman сказал абсолютно верно - игрушка...
[QUOTE=squirL]хм... видишь ли, на определенных задачах - даже недосубд MySQL по скорости разрывает Oracle на части. вопрос в том, за счет чего реализовано преимущество в скорости и сохранится ли оно, например, при стрессовых нагрузках. или на сложной базе в сотни и тысячи таблиц.
[/QUOTE]
Ну вобще то данные и нагрузки были явно не для MySQL )) В том то и дело что Cache' позиционируется как СУБД для работы с очень большими объемами данных и количеством пользователей одновременно.
Собственно как я говорил кроме нас тестировали мои знакомые (бывшие одногрупники) из других софтовых контор. Тестировали так же для своих комерческих продуктов, причем даже с настроенной и уже рабочей базой на Oracle.
По поводу транзакций хочу сказать, что тут вы немного не правы. То о чем вы говорите, это возникает из-за смешенного большого количества средств для разработки и написания внутренних програм разных версий в Cache'. Вот в старых версия обжект скрипта действительно есть такие транзакции. А так же блокировки. Которые реально ничего не блокирую, а просто для разработки программы служат и отката по выполнению.
Но есть и нормальный механизм работы с БД.
Так же как с ООП. Для того чтобы классы нормально работали, они все должны наследоваться от определенного класса Registred. А чтобы сохраняться в БД, от класса Persistent. Если же писать свой класс не имеющий родителей - надо писать самому всю работу по выделению памяти под объекты, менеджер памяти, осуществлять работу по вызову методов и т.п. Только это никто не делает, потому что есть нормальные классы, не отличающиеся в простоте описания или исспользования скажем от C++ или java.
Вобщем надеюсь понятна аналогия?
[/QUOTE]
Ну вобще то данные и нагрузки были явно не для MySQL )) В том то и дело что Cache' позиционируется как СУБД для работы с очень большими объемами данных и количеством пользователей одновременно.
Собственно как я говорил кроме нас тестировали мои знакомые (бывшие одногрупники) из других софтовых контор. Тестировали так же для своих комерческих продуктов, причем даже с настроенной и уже рабочей базой на Oracle.
По поводу транзакций хочу сказать, что тут вы немного не правы. То о чем вы говорите, это возникает из-за смешенного большого количества средств для разработки и написания внутренних програм разных версий в Cache'. Вот в старых версия обжект скрипта действительно есть такие транзакции. А так же блокировки. Которые реально ничего не блокирую, а просто для разработки программы служат и отката по выполнению.
Но есть и нормальный механизм работы с БД.
Так же как с ООП. Для того чтобы классы нормально работали, они все должны наследоваться от определенного класса Registred. А чтобы сохраняться в БД, от класса Persistent. Если же писать свой класс не имеющий родителей - надо писать самому всю работу по выделению памяти под объекты, менеджер памяти, осуществлять работу по вызову методов и т.п. Только это никто не делает, потому что есть нормальные классы, не отличающиеся в простоте описания или исспользования скажем от C++ или java.
Вобщем надеюсь понятна аналогия?
[QUOTE=aks]Ну вобще то данные и нагрузки были явно не для MySQL )) В том то и дело что Cache' позиционируется как СУБД для работы с очень большими объемами данных и количеством пользователей одновременно.[/QUOTE]
Тем не менее, в рейтингах http://wintercorp.com/VLDB/2005_TopTen_Survey/TopTenWinners_2005.asp как в номинации DW, так и в OLTP первые строчки таблицы занимают Oracle, DB2 и Daytona. О Cache` никаких упоминаний.
Тем не менее, в рейтингах http://wintercorp.com/VLDB/2005_TopTen_Survey/TopTenWinners_2005.asp как в номинации DW, так и в OLTP первые строчки таблицы занимают Oracle, DB2 и Daytona. О Cache` никаких упоминаний.
Не вижу противоречия. =) Я же не говорил, что мы утверждаем о преимуществе Cache'. Просто на нескольких конкретных задачах она действительно работала шустрее.
А к заявлениям Intersystems сам скептически отношусь )
А к заявлениям Intersystems сам скептически отношусь )
[QUOTE=vladsoft]Не на самом деле там русские руку приложили, вся бд основа если мне не изменяет память на работах нашего математика, наши как всегда за всех думают, буржуи до ума доводят, а пьем за их здоровье и еще покупаем все у них, взять хотя бы сотовую связь, мало кто знает, но принцип сотовой связи придумал наш физик алферов за что 2000 году получил нобелевскую вот так, а мы сейчас эти телефоны тоннами покупаем...да бабки им еще за связь крутые платим...[/QUOTE]
Похожая ситуация с автоматической коробкой передач.
Похожая ситуация с автоматической коробкой передач.