yww@escape.ru
Слепо отвергая Каше, его противники могут потерять (для себя, конечно) действительно мощное средство разработки. И мощь эта (по моему личному мнению), заключается в возможности совместного использования и ООП и SQL, и COS в приложениях, создаваемых в рамках одной и той же среды разработки .

Вверху пример кода на Каше. Он вырезан из описания объекта реального проекта. Приведён он только для обозрения глазами.. при желании, вы сможете увидеть, что здесь присутсвует и объектная парадигма, и код COS и SQL.

Вам это может не нравиться, но это ваши проблемы. Не нравится - возьмите то, что вам по душе.


Разве у оракла нет ООП?

Народ,

Как вы относитесь к Идее отправить результат сравнения с intersystems в центральный офис Oracle и Micrososft и попросить их прокомментировать результат?

Они должны же признатся в своей беспомощности!

vadiminfo
Iura
Как вы относитесь к Идее отправить результат сравнения с intersystems в центральный офис Oracle и Micrososft и попросить их прокомментировать результат?

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

Знаю одно - Майкрософт и Оракле на пару опасаются MySQL.
Он становится популярным

Изопропил Iura...
Знаю одно - Майкрософт и Оракле на пару опасаются MySQL.
...

Источником знаний поделись


Oracle пыталась купить MySQL

Стивен Шанкленд (Stephen Shankland), CNET News.com
16 февраля, 2006, 9:38
Oracle предприняла попытку приобрести производителя СУБД open-source MySQL, что указывает на стремление к глубоким переменам софтверного гиганта, который все больше склоняется к принятию философии коллективного программирования.

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

В интервью на конференции Open Source Business Conference в Сан-Франциско генеральный директор MySQL Мартен Микос подтвердил, что попытка приобретения имела место, но не сообщил, когда это было и сколько денег предлагала Oracle. Он сказал лишь, что отклонил предложение, потому что хочет, чтобы его компания оставалась независимой. «Мы станем частью более крупной компании, но она будет называться MySQL», — сказал Микос.

Получить комментарии по поводу попытки приобретения у Oracle пока не удалось.

По мнению аналитика Redmonk Стивена Огрейди, такое приобретение было бы мудрым шагом со стороны Oracle. Она могла бы сделать из MySQL то же, что IBM сделала из Gluecode — компанию, которая коммерциализирует программное обеспечение сервера приложений open-source Geronimo Java и конкурирует с собственным проприетарным продуктом IBM WebSphere. Сейчас IBM предлагает ПО Gluecode в качестве бесплатного продукта под названием WebSphere community edition.

Между тем на рынке СУБД происходят важные перемены. IBM предложила бесплатную версию DB2, последовав за аналогичными шагами Microsoft и Oracle. В то же время такие компании как Ingres и EnterpriseDB пытаются создать мощные пакеты СУБД с открытым исходным кодом.

В январе MySQL объявила, что она завершила с прибылью два квартала подряд. Но это не означает прекращения потока денег извне. В понедельник стало известно, что MySQL собрала $18,5 млн в третьем раунде финансирования от Venture Partners, Intel Capital, Red Hat, SAP Ventures и Presidio STX, инвестиционной дочерней компании Sumitomo.

Однако финансовые шаги Oracle на порядок крупнее. Мощный всплеск покупательской активности компании привел к приобретению Siebel Systems за $5,8 млрд и PeopleSoft за $10,3 млрд. Oracle купила и две мелкие компании СУБД с открытым исходным кодом — Sleepycat только что и InnoDB в 2005 году. Но ее амбиции в этом отношении гораздо больше. Например, BusinessWeek сообщил о намерении Oracle приобрести производителя сервера приложений с открытым исходным кодом JBoss.

Микос и другие руководители с готовностью отмечают, что СУБД MySQL постепенно обзаводится все более мощными функциями, но отрицают, что компания намерена конкурировать с Oracle. СУБД Oracle часто используется в качестве базы данных для сложных, массивных систем типа систем планирования и управления ресурсами предприятия (ERP) от SAP или PeopleSoft.

«Мы не работаем со всеми этими ERP. Мы добавляем подобные функции, но ни в коем случае не собираемся поддерживать приложения PeopleSoft», — подчеркнул Микос. Вместо этого MySQL нацелена на приложения нового поколения, применяемые в таких компаниях как Workday, стартап типа «программное обеспечение в виде услуг», основанный соучредителем PeopleSoft Дейвом Даффилдом.

На самом деле MySQL и Oracle все же конкурируют. «Они явно укоренились в разных сегментах рынка — Oracle в сегменте мощных систем, а MySQL — более массовых и дешевых, — говорит Огрейди. — Но разве они не пересекаются в середине? Конечно пересекаются».

Источник: Oracle tried to buy open-source MySQL (15.02.2006)


Почему нет таких попыток по отношению к Cache ?
Я не противник Cache - но некторые факты заставляют задуматься.

Назовите хоть один факт за 2005 или 2006 год, когда крупные производители софта хотели объеденится или купить intersystems ?

Я знаю что существуют "базы данных" на прологе, но это еще ни о чем не говорит!

http://pr.cnews.ru/pr_body.shtml?cid=10161&pr=2005/05/04/33279

pavelvp
Ну и ещё пара экспериментов в догонку. По скорости. Тут говорили, что даже SQL в Каше офигенный просто, а уж напрямую так вообще улёт.
Вот такие нехитрые вещи я попробовал:
1) count(*)
2) max
3) min
4) avg
5) sum
6) between 10000 and 100000
7) order by
По полю типа double.
Как видно, никакой "реляционщиной" здесь и не пахнет (может быть за исключением последнего :-)). Вроде как Каше должен на них просто летать. Индексов, естественно, никаких не строилось.

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

DB2 IuraДанные будут занимать больше чем 1000 GB :( но не сразу :)
1000Gb это смешно для конторы. У меня дома 500 Gb. Скоро может быть 1000 Gb сделаю.

Будь внимательней ! Проблема не в носителях, а в объемах данных. Чем больше объем тем дольше искать. Зависимость не линейная, но всеже.

Если ограничится запросом типа
Select *
from table
where col1 = var

То траблов нет.

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

Select *
from pharsi
where id_slova in (select id_slova from slovar where slovo in ('Мальчик', 'держал', 'ключ') )


Причем каждое искомое слово может иметь несколько уникальных id в словаре.
Правельней будет - комбинация связка слово+терминалогическая принадлежность = уникальный ID. Правильная такая структура или нет это не обсуждается. Я не показываю всю структуру, а просто привожу упрощеный пример. Да и сам запрос поиска написан не полностью.

Думаю суть понятна, почему так критичен объем. ЗАПРОСЫ БУДУТ СЛОЖНЫМИ. И вероятней всего только на одно предложение потребуется написать три подзапроса.

pavelvp IuraПавел, как я и раньше писал, пробелма у Кеши не в поиске, а впредставлении данных. Если он реально хранит double в формате строки, то перед каждым вычислением, он должен переводить число из строки в double а потом выполнять операции. Ну и прикинь сколько это времени займет. Какое отношение тип double имеет к count(*) ??? Да я и не о поиске, а о размере БД и о фулл-скане - о том, что чудес не бывает...

Но кроме Count ты указал avg, sum, min, max
Поиск ведется у тебя по числам 10000 по 100000, которые в кеше представлены как строки. Если я не прав, то пусть Сергей поправит меня.

и то что у кеша файл был длинее - это также причина в формате хранения чисел!

число 10000 - это smallint и занимает в SQL 2 байта, в Cache это будет занимать 5 байт.

Сергей, если я в чем то не прав, то пожалуйста подправь меня.

http://www.sql.ru/articles/mssql/03013101Indexes.shtml#1 Индексы в SQL

MX -- ALEX Iura pavelvp IuraПавел, как я и раньше писал, пробелма у Кеши не в поиске, а впредставлении данных. Если он реально хранит double в формате строки, то перед каждым вычислением, он должен переводить число из строки в double а потом выполнять операции. Ну и прикинь сколько это времени займет. Какое отношение тип double имеет к count(*) ??? Да я и не о поиске, а о размере БД и о фулл-скане - о том, что чудес не бывает...

Но кроме Count ты указал avg, sum, min, max
Поиск ведется у тебя по числам 10000 по 100000, которые в кеше представлены как строки. Если я не прав, то пусть Сергей поправит меня.

и то что у кеша файл был длинее - это также причина в формате хранения чисел!

число 10000 - это smallint и занимает в SQL 2 байта, в Cache это будет занимать 5 байт.

Сергей, если я в чем то не прав, то пожалуйста подправь меня.

Сергей гуляет до 10
пока я за него :)

если искать числа мерселя - то лучше не на мумпсе

но если задачи асуп - разница в зависимости от способа хранения чисел
практически неуловима

потому как основное время тратится на поиск

90 % инфы в таких задачах - текст
как хранить 10% - текстом или сжато - почти не влияет

для Вашей задачи - перевод текста -
вообще зачем на числа заморачиваться?

Мне нужно будет мучаться с числами только для статистики. Типа какая фраза сколько раз использовалсь у каждого пользователя и так далее.