Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 19   вперед  Ctrl
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267

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


Posted via ActualForum NNTP Server 1.3

6 май 06, 18:03    [2640483]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
yww@escape.ru

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

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

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



Разве у оракла нет ООП?
6 май 06, 18:04    [2640485]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
неважно
Guest
ЛП
Изопропил
Синтаксис "птичий" у вашего Cache-языка .

Это не каше-язык птичий, это M (насколько я понял)

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

Pathologically Eclectic Rubbish Lister ?
6 май 06, 18:08    [2640499]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Изопропил
Member

Откуда:
Сообщений: 31629
Не надо на Perl гнать :) - у него операции приоритеты имеют.

и с бейсиком никто его не скрещивал и embedded SQL не пришивал.
6 май 06, 18:17    [2640519]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
Народ,

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

Они должны же признатся в своей беспомощности!
6 май 06, 18:17    [2640521]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Официльный ответ будет.
Уважаемые есть тест TPC на котором если хотите можете сравнится с нами.
Он между прочим в себя включает не только производительность, но проверку работы транзакций и восстановления после сбоя.
Утверждения cache являются голословными.tpc.org это независимый аудитор результатов.
6 май 06, 18:47    [2640620]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
yww@escape.ru

Слепо отвергая Каше, его противники могут потерять (для себя, конечно) действительно мощное средство разработки.

Во-первых не отвергая, а игнорируя. До сих пор ничего на форуме про его достоинства как СУБД того или иного типа никто на прояснил. Зато было что до РУСБД он не дорос. ООСУБД-шники, например, от версанта его за ООСУБД не признали. Многомерность сегодня реализуетися лидирующими производителями через ОЛАП. И тоже ничего не известно, чтобы он с ними сравнивался реально. Ить это системы поддержки принятия решения, а не оперативный обработки транзакций. А Кэш как бы в оперативной обработке многомерный. Т.е. не понятно хде он с точки зрения сегодняшних технологий БД. Про то шо там делает МУМПС вообще загадка.
Во-вторых не противники, а скептически к не му относящиеся. Противники будут када он чего-то добьется.

yww@escape.ru

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

Сомнеия про SQL и ООП выше писал. А COS с какой стати записался в мощь? Он уже тоже вошел в десятку наиболее продвинутых языков? Или чем он знаменит? Мож без него луче? Кто знает?

yww@escape.ru

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

Думаете он выглядит как шедевр? Или что?

yww@escape.ru

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

Если не нравится, то какие с этим могут быть проблемы? Взяли уже. Скока инсталяций у Кэша? Все остальные, а это более 90% взяли то, что по душе, а не Кэша.

Iura

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

Кто такой intersystems для Oracle и Micrososft, чтобы они тратили веремя на комментарии? Када добьется чего-то стоящего тада и прокомментируют. Наличие комментария от них это один из признаков успешности.
6 май 06, 19:15    [2640691]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
vadiminfo

Iura

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

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


Знаю одно - Майкрософт и Оракле на пару опасаются MySQL.
Он становится популярным
6 май 06, 19:57    [2640778]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Изопропил
Member

Откуда:
Сообщений: 31629
Iura
...
Знаю одно - Майкрософт и Оракле на пару опасаются MySQL.
...


Источником знаний поделись
6 май 06, 20:00    [2640782]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
Изопропил
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 ?

Я знаю что существуют "базы данных" на прологе, но это еще ни о чем не говорит!
6 май 06, 20:47    [2640835]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
http://pr.cnews.ru/pr_body.shtml?cid=10161&pr=2005/05/04/33279
6 май 06, 20:55    [2640845]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
DB2
Guest
Iura
Данные будут занимать больше чем 1000 GB :( но не сразу :)
1000Gb это смешно для конторы. У меня дома 500 Gb. Скоро может быть 1000 Gb сделаю.
6 май 06, 21:40    [2640898]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
tygra
автор
хочешь универсальности
и удобств - оставайся на том, на чем работаешь, но смирись с ограничениями.

А с какими ограничениями? По сравнению с Кэш например

с обычными для всех РСУБД. объем и скорость.

Sergei Obrastsov

не знаю, может и нормально.
но если 4Gb и 1.15Gb - фигня, то 40 и 11 - уже заметно, а 400Gb и 115Gb - просто две большие разницы, не находишь?
а в моем случае, при малом объеме винта - страшно существенно.

Итак. Имеем следующее:
- Cache 5.1.0.826.1.SU;
- ЛИНТЕР 6.1.6.12.
Создаём таблицу. Реальная табла, из реальной системы. В таблице 59 полей, из которых 50 - varchar(40). Заливаем миллион записей в которых все последние 50 полей NULL-значения. Скорость загрузки комментировать не буду (т.к. SQL-ем в Cache грузил, а не COS), да я и не засекал.
Что получилось:
Cache - 234М
ЛИНТЕР - 220М :-)))
Разница по сравнению с ЛИНТЕР в 14М видимо тот самый индекс по ID :-)

Вопрос - что я делал не так?

Ещё пара слов про 210М в ЛИНТЕР. У нас есть параметр у таблицы PCTFILL - процент сжатия данных. Этот параметр подсказывает субд насколько, в среднем исходные данные могут быть сжаты. По-умолчанию, при создании таблицы, этот параметр считается равным 100. Если его поставить, например, равным 30, то 220М превратятся уже 117М :-) Т.е. в два раза меньше, чем у Каше :-) У MS SQL, кстати, эта таблица будет занимать тоже уколо сотни метров... У ЛИНТЕР чуть больше из-за секьюрити - на каждую строку несколько байт с метками доступа хранится.

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

После каждого запроса делал рестарт серверов дабы не брать во внимание кеш. Результаты получил вполне предсказуемые. У Каше - скан занимет 12 секунд. У ЛИНТЕРа 7-9 секунд - файл то меньше :-))) Order by ЛИНТЕР обработал у меня примерно в два раза быстрее.
Видим, честные фуллсканы с обеих сторон и работу подсистемы ввода/ввода.
Настройки и там и там по-умолчанию. Для ЛИНТЕР это 500 страниц (4К) буферного пула, т.е. 4 метра памяти.
У Каше сначала всё стояло automatic. Потом пробовал увличивать - разницы никакой :-( На повторных выполениях запроса никак не сказывалось почему-то, непонятно почему. Это очень странно. Может ограничение демо-версии?
При нормальном размере буферного пула у ЛИНТЕР, время выполнения первого запроса колебалось в пределах 4-5 секунд, последующие меньше секунды.

В чём правда, брат? Что я делал не так? База получилась больше... Скорость ниже... Может нужно таблицу побольше взять, миллионов на 100 или 500... и тогда мы увидим фантастическую экономию дискового пространства и невероятную скорость работы...

Так что чудес не бывает :-) Если данные есть - они занимают место :-)
Записиси фиксированной длины никто уже давным-давно не хранит.
Префиксное сжатие ключей в индексах думаю тоже у всех есть.
При схожих объёмах - размер БД у всех будет примерно одинаковый (если нет компрессии данных).
Если нет индексов - фуллскан - скорость диска от СУБД не зависит :-)
Индексы у всех тож почти одинаковые (кроме экзотики, типа bit-sliced...)
И т.д. и т.п....
Всё зависит от оптимизатора, короче говоря :-))) И вот ради этой последней строчки столько фигни написал :-)
6 май 06, 22:13    [2640948]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
pavelvp

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


Павел, как я и раньше писал, пробелма у Кеши не в поиске, а впредставлении данных. Если он реально хранит double в формате строки, то перед каждым вычислением, он должен переводить число из строки в double а потом выполнять операции. Ну и прикинь сколько это времени займет.
6 май 06, 22:52    [2641034]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Iura
Павел, как я и раньше писал, пробелма у Кеши не в поиске, а впредставлении данных. Если он реально хранит double в формате строки, то перед каждым вычислением, он должен переводить число из строки в double а потом выполнять операции. Ну и прикинь сколько это времени займет.
Какое отношение тип double имеет к count(*) ??? Да я и не о поиске, а о размере БД и о фулл-скане - о том, что чудес не бывает...
6 май 06, 22:56    [2641041]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
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. Правильная такая структура или нет это не обсуждается. Я не показываю всю структуру, а просто привожу упрощеный пример. Да и сам запрос поиска написан не полностью.

Думаю суть понятна, почему так критичен объем. ЗАПРОСЫ БУДУТ СЛОЖНЫМИ. И вероятней всего только на одно предложение потребуется написать три подзапроса.
6 май 06, 23:06    [2641054]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
pavelvp
Итак. Имеем следующее:
- Cache 5.1.0.826.1.SU;

Вопрос - что я делал не так?

У Каше сначала всё стояло automatic. Потом пробовал увличивать - разницы никакой :-( На повторных выполениях запроса никак не сказывалось почему-то, непонятно почему. Это очень странно. Может ограничение демо-версии?

Именно. У версии, которая SU, кеш ограничен.
6 май 06, 23:15    [2641069]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

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


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

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

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

Сергей, если я в чем то не прав, то пожалуйста подправь меня.
6 май 06, 23:19    [2641078]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Изопропил
Синтаксис "птичий" у вашего Cache-языка .


Тот Cache язык - COS
Если он вас неустраивает, можете использовать Cache Basic..
7 май 06, 01:25    [2641235]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
ЛП
yww@escape.ru
mir
У нас есть теория проектирования БД, худо бедно да основанная на формальных критериях качества, а у вас ничего подобного и близко нет. И не будет никогда.


Вот здесь то и кроется Ваша принципиальная ошибка. А возможно, это не ошибка, а сознательное замалчивание (или непонимание) факта - В Каше, SQL присутствует как равноправная составляюшая в наборе средств разработки.

Это у Вас принципиальная ошибка
Вам говорят, что у вас нет теории - Вы отвечаете, что у вас есть SQL, как-то сбоку прикрученный :)

SQL не заменяет ни реляционную алгебру, ни РМД.
SQL - это всего лишь язык заточенный для работы с РСУБД. Язык далеко не единственный, и, наверное, не самый лучший (хотя и самый распространенный).
С помощью SQL можно хоть с экселем работать, хоть с LDAP-овскими хранилищами, хоть со списком win32-процессов, хоть с объектными базами данных от какого-нибудь Versant. От поддержки SQL ни Excel, ни MS Exchange, ни WMI, ни Versant не станут реляционными базами.

Вот и Каше - он хоть как может себе поддержку SQL может сбоку прикрутить, к реляционной алгебре и РМД ближе он не станет. А своего теоретического фундамента у него нет (о чем Вам и пытались сказать).



Несколько раз прочитал.. ничего не понял..
Что сказать то хотите? товариш Инкогнито!
7 май 06, 01:44    [2641266]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
https://www.sql.ru/articles/mssql/03013101Indexes.shtml#1 Индексы в SQL
7 май 06, 12:56    [2641578]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MX -- ALEX
Guest
Iura
pavelvp
Iura
Павел, как я и раньше писал, пробелма у Кеши не в поиске, а впредставлении данных. Если он реально хранит double в формате строки, то перед каждым вычислением, он должен переводить число из строки в double а потом выполнять операции. Ну и прикинь сколько это времени займет.
Какое отношение тип double имеет к count(*) ??? Да я и не о поиске, а о размере БД и о фулл-скане - о том, что чудес не бывает...


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

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

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

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


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

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

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

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

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

для Вашей задачи - перевод текста -
вообще зачем на числа заморачиваться?
8 май 06, 10:11    [2642679]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
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% - текстом или сжато - почти не влияет

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


Мне нужно будет мучаться с числами только для статистики. Типа какая фраза сколько раз использовалсь у каждого пользователя и так далее.
8 май 06, 10:22    [2642691]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MX -- ALEX
Guest
ЛП
Изопропил
Синтаксис "птичий" у вашего Cache-языка .

Это не каше-язык птичий, это M (насколько я понял)

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


в армии сержант дико орал услыша нерусскую речь среднеазиатов-

"Говорите по русски !!!"

и терпеливо пояснял "тупоголовым чуркам"-
"Русский - это природный язык - не то что ваш собачий !! "

но по поводу перла я и с Вами, и с сержантом, согласен
-------------------------------------------------------------------
итак-
МUMPS - природный язык !
все другие - неправильные.
8 май 06, 10:31    [2642699]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MX -- ALEX
Guest
Iura
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% - текстом или сжато - почти не влияет

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


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


думаю до статистики дело не дойдет ..
8 май 06, 10:34    [2642705]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 19   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить