ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
457 сообщений из 457, показаны все 19 страниц
  все  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33699701
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Привет всем!

Пожалуйста, люди, которые работали с SQL 2005, Oracle 10G, Cache 5, MySQL
укажите 5 сильных и 5 слабых сторон каждого продукта.

С уважением,
Юрий
...
Рейтинг: 0 / 0
30.04.2006, 15:28
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700011
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
товарищщ Юра, сначала объясни пожалуйста зачем этому человеку (интересно есть такие?) писать про 40 разных сторон?
Я понимаю если помочь кому надо, но не удовлетворять же чьё-то празное любопытство
...
Рейтинг: 0 / 0
01.05.2006, 00:48
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700067
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Мне нужно выбрать оптимальную с точки зрения разработки и быстродействия базу данных.
...
Рейтинг: 0 / 0
01.05.2006, 08:18
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700073
Lepsik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lepsik
Участник
на чем умеете на том и пишите. Это самый оптимальный вариант обычно оказывается.
...
Рейтинг: 0 / 0
01.05.2006, 08:46
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700125
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
Iura . Если бы была одна оптимальная база, то все другие вымерли бы.
Сильная сторона MS SQL - я его хорошо знаю!
...
Рейтинг: 0 / 0
01.05.2006, 11:23
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700150
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Мне нужен совет человека, который имел опыт написания баз данных на всех этих продуктах. Я уверен что их немного, но их мнение имеет большой вес.
...
Рейтинг: 0 / 0
01.05.2006, 11:53
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700161
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
Iura. Нет таких наверное. Хотя бы из-за того, что SQL 2005 и Oracle 10G довольно свежие продукты и вряд-ли кто-то успел изучить все их тонкости одновременно.
...
Рейтинг: 0 / 0
01.05.2006, 12:05
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700202
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
IuraМне нужно выбрать оптимальную с точки зрения разработки и быстродействия базу данных.

А почему хотите выбирать только по этим критериям?

Например, сколько заказчик готов заплатить за СУБД, хардварь и разработку БД?

Или, для начинающего разработчика, должен быть важен такой вопрос: разработчики для каких СУБД более всего востребованы? а какие получают наивысшую зарплату?
...
Рейтинг: 0 / 0
01.05.2006, 13:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700207
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Так, я предполагаю (не знаю, на самом деле, просто предполагаю), что ораклисты получают больше, чем мс-скулисты, а те намного больше, чем май-скулисты. Cache' - жуткая экзотика, труднее будет сменить работу на другую с Cache', а знания приобретаются не за один день и не за один год.

Это весьма важные соображения для программиста и админа.
...
Рейтинг: 0 / 0
01.05.2006, 13:21
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700278
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
Victor Metelitsa . Вы правы
...
Рейтинг: 0 / 0
01.05.2006, 15:11
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700487
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
И почему только я работаю по большей части с DB2?
;-)
...
Рейтинг: 0 / 0
01.05.2006, 20:27
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700567
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Я не могу создать оптимальную структуру базы даннах на Oracle & SQL,
но полагаю, что ее возможно сделать на Cache.

То есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит.
...
Рейтинг: 0 / 0
01.05.2006, 22:05
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700610
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
Iura. Никто не запрещает Вам сделать таблицы без явно определенного индекса в MS SQL. Только вот выйдет вам это боком, когда вы соберетесь редактировать одну запись из "группы". Не путайте индексы и ключи! Ключ - это набор полей, который уникально определяет запись. Индекс - это структура, которая позволяет быстро найти запись по ключу. Бывают случаи, когда построение индекса невыгодно.
Миллион записей - это семечки.
...
Рейтинг: 0 / 0
01.05.2006, 23:02
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700615
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
IuraТо есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит.

А за каждый сэкономленный мегабайт и ускорение на микросекунду дадут премию ;-)
...
Рейтинг: 0 / 0
01.05.2006, 23:11
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700620
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
Ой-ой! Надо быстро написать, пока пинать не начали! Это про индекс по первичному ключу. Можно ведь и другие индексы сделать.
...
Рейтинг: 0 / 0
01.05.2006, 23:19
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700647
serg_seak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
serg_seak
Гость
IuraЯ не могу создать оптимальную структуру базы даннах на Oracle & SQL,
но полагаю, что ее возможно сделать на Cache.

То есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит.

Насколько я читал, что сама база Кэш не оптимальна, те занимает места намного больше чем РСУБД при наличии того объема данных... Это если разговор идет именно о критичности расхода памяти (места на дисках)...
...
Рейтинг: 0 / 0
01.05.2006, 23:45
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700669
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Cat2Ой-ой! Надо быстро написать, пока пинать не начали! Это про индекс по первичному ключу. Можно ведь и другие индексы сделать.

Как я понимаю, он про индексы и не писал, а речь шла о схеме вида master-slave (мощности 1:n),
create table master(
master_id primary key
...
)
create table slave(
slave_id primary key.
master_id foreign key
...
)
и он хотел сэкономить байты на master_id в таблице slave.

Правда ли удастся сэкономить? На SQL это может выглядеть как
1) для каждого master_id (XXX) отдельная таблица slave_xxx
или
2) таблица slave исчезает и возникает поле slaves типа BLOB или (в тех СУБД, где поддерживается) ARRAY в таблице MASTERS.

Оба варианта выглядят не слишком хорошо.

Ближе всего к пожеланию выглядело бы (на DB2) что-нибудь типа MDC (многомерный кластер) на таблице slave по master_id, но так, чтобы значение master_id в строке не хранилось, а только в специальном индексе, по которому организуется MDC. Это интересная мысль, надо перечитать текст про устройство MDC, есть ли там такая компрессия. Пока кажется, что всё же нет. Но это мне напомнило, что в Viper'е обещают гораздо более серьёзную компрессию .
...
Рейтинг: 0 / 0
02.05.2006, 00:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33700942
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Victor Metelitsa Cat2Ой-ой! Надо быстро написать, пока пинать не начали! Это про индекс по первичному ключу. Можно ведь и другие индексы сделать.

Как я понимаю, он про индексы и не писал, а речь шла о схеме вида master-slave (мощности 1:n),
create table master(
master_id primary key
...
)
create table slave(
slave_id primary key.
master_id foreign key
...
)
и он хотел сэкономить байты на master_id в таблице slave.

Правда ли удастся сэкономить? На SQL это может выглядеть как
1) для каждого master_id (XXX) отдельная таблица slave_xxx
или
2) таблица slave исчезает и возникает поле slaves типа BLOB или (в тех СУБД, где поддерживается) ARRAY в таблице MASTERS.

Оба варианта выглядят не слишком хорошо.

Ближе всего к пожеланию выглядело бы (на DB2) что-нибудь типа MDC (многомерный кластер) на таблице slave по master_id, но так, чтобы значение master_id в строке не хранилось, а только в специальном индексе, по которому организуется MDC. Это интересная мысль, надо перечитать текст про устройство MDC, есть ли там такая компрессия. Пока кажется, что всё же нет. Но это мне напомнило, что в Viper'е обещают гораздо более серьёзную компрессию .

Абсолютно правильно вы поняли идею.

Из описания Cache я понял, что он позволяет эту проблему решить проще и красивее. Но я не могу использовать всего лишь этот единственный аргумент для выбора этой платформы в качестве среды разработки.

Кажись есть похожая возможность у Oracle. Пока ничего незнаю на счет MySQL.
...
Рейтинг: 0 / 0
02.05.2006, 10:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33701767
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
luraТо есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит.
У меня тока 2 вопроса
1. Вы давно ли начали этим делом баловаться? В смысле - проектированием БД :)
2. Кто вам сказал, что так, как вы почему-то не хотите, делать нельзя? Сон был в четверг? Или кто есть еще умнее вас? :))

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

Давайте лучше постановку задачи опишите чтоли, сколько записей, сколько сущностей, чего делать и т.д. А то сразу - кэш, оракл, массивы.... :))

-- Tygra's --
...
Рейтинг: 0 / 0
02.05.2006, 14:18
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33701918
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
tygraЯ боюсь подумать, но вы что, вправду считаете, что если вы явно не задаете ссылку на родительский объект для каждой записи, ее там и нет? А как тогда записи выбираются - чудо каждый раз БД творит?


Не нужно чудес. Схема
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
create table master(
master_id primary key
...
)
create table slave(
slave_id primary key.
master_id foreign key
...
)
может быть представлена и по-другому. Вместо того, чтобы каждая запись slave ссылалась на запись в master посредством master_id, (master:1 <- slave:N), запись в master может ссылаться на массив записей slaves (master:1 -> slaves:1). Это легко вообразить для не-SQL-СУБД.

Хотя... экономия места всё равно весьма спорна. Если упаковывать массив плотно для всей таблицы, можно замучаться с управлением памятью, а если для каждого master_id выделять минимум экстент для его массива slaves, для выигрыша надо, чтобы эти массивы были весьма и весьма большие, а тогда, наверное, и записи в массивах будут достаточно широкие, и выигрыш на отсутствии "master_id foreign key" грошовый.
...
Рейтинг: 0 / 0
02.05.2006, 15:00
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33702122
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Victor Metelitsa
Это легко вообразить для не-SQL-СУБД.


Да и в Оракле представить моно легко (вложенные таблицы). Хуже представить как это потом запросы это прокорявит, када надо будет с этой инфой работать. Не та эта плата за экономию на диске. Логикой платить за физику что-то ломает без каких-то особых причин.
...
Рейтинг: 0 / 0
02.05.2006, 16:01
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33702233
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
vadiminfo
Да и в Оракле представить моно легко (вложенные таблицы). Хуже представить как это потом запросы это прокорявит, када надо будет с этой инфой работать.

А ты реально это пробывал делать?
...
Рейтинг: 0 / 0
02.05.2006, 16:34
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33702304
гость гостевый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
гость гостевый
Гость
Victor Metelitsa
Хотя... экономия места всё равно весьма спорна. Если упаковывать массив плотно для всей таблицы, можно замучаться с управлением памятью, а если для каждого master_id выделять минимум экстент для его массива slaves, для выигрыша надо, чтобы эти массивы были весьма и весьма большие, а тогда, наверное, и записи в массивах будут достаточно широкие, и выигрыш на отсутствии "master_id foreign key" грошовый.

на специально подобранных задачах выигрыш может быть очень заметным.

в доке на один из модулей такого сорта для Informix дается модельная оценка - два раза по размеру дискового пространства и 4 раза по операциям чтения (индекса) при поиске (~ время поиска).
http://publib.boulder.ibm.com/epubs/pdf/6577a.pdf
Overview->Case Studies Showing the Benefits...
...
Рейтинг: 0 / 0
02.05.2006, 17:02
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33702718
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Iuraи он хотел сэкономить байты на master_id в таблице slave.

Кажись есть похожая возможность у Oracle.
Если не ошибаюсь, у Oracle есть даже два варианта для этой возможности. Можно сделать INDEX CLUSTER, а можно - INDEX-ORGANIZED TABLE с ключом COMPRESS. Хотя лень лезть в доку проверять :)
...
Рейтинг: 0 / 0
02.05.2006, 21:30
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33702745
Фотография S.G.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
S.G.
Участник
Iura Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти.

Оптимизация - это в принципе хорошо. Оптимизация ради оптимизации- это плохо. Например:
- Нам достаточно, чтобы запрос выполнялся за секунду- две. Он выполняется за полсекунды, на реальных данных. Незачем его оптимизировать, чтобы он выполнялся быстрее.
- У нас диск в 40 ГБ, а БД занимает около 1 ГБ. Тогда нам незачем экономить на индексах, байтах или указателях. Что мы будем делать с оставшейся памятью? Унесем домой?

В таких случаях как выше- имхо надо сосредоточиться не на экономии которая достигается за счет усложнения, а на понятных, стандартных решениях.
...
Рейтинг: 0 / 0
02.05.2006, 22:02
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703109
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Данные будут занимать больше чем 1000 GB :( но не сразу :)

На серваке будут храниться тексты, введеные пользователями (в большом количестве). Для каждого слова из текста будет хранится дополнительная служебная информация. Если оставить все как есть, то эта служебная инфа может занимать до 100 байт на слово. :(
...
Рейтинг: 0 / 0
03.05.2006, 08:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703116
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Iura
А ты реально это пробывал делать?

Тока учебно. Реанально отклониться от реляционности я не готов - мы создаем БД, чтобы информацию было легко извлекть, а не тока чтобы экономить место на дисках (хотя я не уверен, что вложенные таблы или массивы это обеспечат). А извлечение ухудшится и, возможно, не тока в написании запросов, но и их оптимизации. И мне кажется Вы легко начинаете думать о Кэше ради экономии место на диске. Есть все-таки кое-что поважнее на сегодня при выборе СУБД.
...
Рейтинг: 0 / 0
03.05.2006, 08:44
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703156
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Летом (по-видимому) будет новая версия DB2 (Viper). Одна из обещанных фич - компрессия данных. Это реальный и серьёзный выигрыш (больше чем в два раза, полагаю). А на отказе от foreign key в Кэшэ сколько вы могли бы сэкономить? Лично я полагаю, что там будет даже проигрыш, хотя бы за счёт неиспользуемых "хвостов" на страницах БД.
...
Рейтинг: 0 / 0
03.05.2006, 09:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703161
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
vadiminfo Victor Metelitsa
Это легко вообразить для не-SQL-СУБД.


Да и в Оракле представить моно легко (вложенные таблицы). Хуже представить как это потом запросы это прокорявит, када надо будет с этой инфой работать. Не та эта плата за экономию на диске. Логикой платить за физику что-то ломает без каких-то особых причин.
Я помню, Кайт показывал, что вложенные таблицы в Oracle реально реализованы при помощи foreign key, и расход памяти/дисков даже потенциально больше приведённой мной master->slave.
...
Рейтинг: 0 / 0
03.05.2006, 09:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703166
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
softwarer уже сказал
IOT+Compress на detail экономия может выйти вполне приличная,
но за счет большей нагрузки на CPU

Nested Table - от лукавого и в данном контексте напоминает позицию страуса
...
Рейтинг: 0 / 0
03.05.2006, 09:23
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703203
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
Вы посчитайте, что дороже - усложнить разработку/сопровождение или добить один диск в массив?

В некоторых случаях, оказывается, что увеличить мощность железа - намного дешевле
...
Рейтинг: 0 / 0
03.05.2006, 09:43
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703245
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
luraДанные будут занимать больше чем 1000 GB :( но не сразу :)
Уже вышли в свет террабайтные диски - так что ваш объем это семечки

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

-- Tygra's --
...
Рейтинг: 0 / 0
03.05.2006, 09:58
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703316
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
tygra luraДанные будут занимать больше чем 1000 GB :( но не сразу :)
Уже вышли в свет террабайтные диски - так что ваш объем это семечки

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

-- Tygra's --

В планах создать онлайн сервер для перевода текстов по технологии Translation Memory. Стоит это делать или не стоит - здесь не обсуждается.

Я решил это делать и готовлю пока схему будущей базы данных SQL 2005 Express .
Для каждого слова или фразы, из текста мне в некоторых случаях нужно будет хранить дополнительную информацию. Как часто это потребуется, пока не могу сказать. Предполагаю, что очень часто. В 60-70% случаях.
...
Рейтинг: 0 / 0
03.05.2006, 10:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703530
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
IuraВ планах создать онлайн сервер для перевода текстов по технологии Translation Memory. Стоит это делать или не стоит - здесь не обсуждается.

Я решил это делать и готовлю пока схему будущей базы данных SQL 2005 Express .
Для каждого слова или фразы, из текста мне в некоторых случаях нужно будет хранить дополнительную информацию. Как часто это потребуется, пока не могу сказать. Предполагаю, что очень часто. В 60-70% случаях.А в ограничения SQL 2005 Express укладываетесь?
И возможно стоит сделать набор тестов, для определения подходит система/ СУБД для решения задачи или нет.

Всего...
...
Рейтинг: 0 / 0
03.05.2006, 11:29
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703599
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
VoDAА в ограничения SQL 2005 Express укладываетесь?
И возможно стоит сделать набор тестов, для определения подходит система/ СУБД для решения задачи или нет.

Всего...

Пока так и делаю. Microsoft сделала многое, чтобы облегчить участь программиста.
...
Рейтинг: 0 / 0
03.05.2006, 11:50
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703672
sever_5
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sever_5
Участник
Iura
Microsoft сделала многое, чтобы облегчить участь программиста.

Хе... :) :(

На прошлой неделе в вашей москве проходила конференция мелгкомягких - и там они заявляли, что цитирую: " ... В скором будущем неподготовленный пользователь сможет создавать аналитические модули с помощью специальной БД модулей, а БД программирование сведёться к "вставь туда"...
Труд программиста перестанет быть достоянием хорошо подготовленных людей...

Вот так, бабуины и так уже на бейсике не плохо пишут (достоверный факт), сроко они возьмуться и за нашу с вами работу...
...
Рейтинг: 0 / 0
03.05.2006, 12:27
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703683
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Iura VoDAА в ограничения SQL 2005 Express укладываетесь?
И возможно стоит сделать набор тестов, для определения подходит система/ СУБД для решения задачи или нет.Пока так и делаю. Microsoft сделала многое, чтобы облегчить участь программиста.
Особенно облегчает лимит на 4 гига данных ;-).
...
Рейтинг: 0 / 0
03.05.2006, 12:29
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703716
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Victor MetelitsaОсобенно облегчает лимит на 4 гига данных ;-).

Я пока рисую таблички для базы:) Но это не значит, что я буду использовать SQL 2005 для законченого решения. Я пока определяюсь с выбором базы данных для реализации.
...
Рейтинг: 0 / 0
03.05.2006, 12:40
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703770
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Я полагаю, что из бесплатных для терабайта данных только DB2 Express-C и подойдёт.
...
Рейтинг: 0 / 0
03.05.2006, 12:53
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703833
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Пока вопрос не стоит - в платной или бесплатной базе данных.
Вопрос стоит, что лучше для моего решения?

Мне нужно сделать всю логику на серваке + хранить и постоянно анализировать данные. Думаю, что в будущем потребуется использовать кластер. + на нем же должна висеть логика Web интерфейса пользователя. А она будет очень тяжелой :(

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

Вот мысли склоняются в пользу Oracle, по той причине, что его можно установить на любой платформе + есть поддержка ООП + Java.

Есть интерес к Cache. Его cache-исты сильно хвалят. SQL 2005 - понятный и простой удобный продукт. Но в случае перехода на несколько серваков - думаю столкнусь с проблемой :(
...
Рейтинг: 0 / 0
03.05.2006, 13:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33703888
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
IuraПока так и делаю. Microsoft сделала многое, чтобы облегчить участь программиста.Точнее программиста начального уровня.

А для более высокогограблей понатыкало... наверное чтобы не расли
...
Рейтинг: 0 / 0
03.05.2006, 13:22
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704010
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
IuraПока вопрос не стоит - в платной или бесплатной базе данных.
Вопрос стоит, что лучше для моего решения?


А бюджет, надо думать, безграничен?

Iura
Мне нужно сделать всю логику на серваке + хранить и постоянно анализировать данные. Думаю, что в будущем потребуется использовать кластер. + на нем же должна висеть логика Web интерфейса пользователя. А она будет очень тяжелой :(

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


Как-то подозрительно звучит. Особенно "качественный перевод" - разве такое бывает? ;-). Что там на сайте будет происходить? Это особый вебсайт для всех профессиональных переводчиков России? И сколько их всего наберётся, которые будут посещать? И ради них несколько десятков и даже сотню тысяч долларов не жалко?

Iura
Вот мысли склоняются в пользу Oracle, по той причине, что его можно установить на любой платформе + есть поддержка ООП + Java.


Но надо ли его ставить "на любую платформу" (отличную от виндов)?

Iura
Есть интерес к Cache. Его cache-исты сильно хвалят. SQL 2005 - понятный и простой удобный продукт. Но в случае перехода на несколько серваков - думаю столкнусь с проблемой :(

На всякий случай: у MS SQL и IBM DB2 кластеры Shared Nothing (иными словами, у каждого узла свой набор дисков, и он может обращаться непосредственно только к своему), у Oracle - Shared All (все узлы используют диски совместно). Мне (умозрительно) представляется, что Oracle здесь окажется надёжнее, а MS SQL и DB2 - производительнее.
...
Рейтинг: 0 / 0
03.05.2006, 13:45
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704037
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
IuraПока вопрос не стоит - в платной или бесплатной базе данных.
Вопрос стоит, что лучше для моего решения?
Кроме Вас этого ни кто оценить не может
IuraМне нужно сделать всю логику на серваке + хранить и постоянно анализировать данные. Думаю, что в будущем потребуется использовать кластер. + на нем же должна висеть логика Web интерфейса пользователя. А она будет очень тяжелой :(

В идее, пользователь с любого браузера должен получить удобный интерфес с возможностью качественого перевода + возможностью вносить измнения в перевод, а также пополнять и редактировать свой словарь.
Трех-звенка? наверное это более правильно, чем городить логику уровня представления на сервере БД.
IuraВот мысли склоняются в пользу Oracle, по той причине, что его можно установить на любой платформе + есть поддержка ООП + Java.

Есть интерес к Cache. Его cache-исты сильно хвалят. SQL 2005 - понятный и простой удобный продукт. Но в случае перехода на несколько серваков - думаю столкнусь с проблемой :(
Каждый кулик хвалит свое болото.

PS без реального ТЗ грамотно выбрать все равно не получится. ИМХО.
...
Рейтинг: 0 / 0
03.05.2006, 13:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704071
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Я так понимаю, что речь идет уже о тиражируемой системе?
Это откуль столько переводчиков то? ;)

И чем данная задача отличается от какой другой - ну есть список слов, ну есть список параметров слов. Ну и что?

По поводу того, что некоторые СУБД подо все ставятся - нужно сначала хотя бы под что-то одно написать. И это одно сделать нормально. И остановиться - потому что окажется, что под много чего оно и работать не так будет, да и не нужно будет оно все. Или еще к БД набор из движков сайтов будете поставлять - php? asp.net, java, .....?

-- Tygra's --
...
Рейтинг: 0 / 0
03.05.2006, 14:00
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704142
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
serg_seak
Насколько я читал, что сама база Кэш не оптимальна, те занимает места намного больше чем РСУБД при наличии того объема данных... Это если разговор идет именно о критичности расхода памяти (места на дисках)...
Интересно было бы узнать источник этой информации. :)
Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом. Ну, например, 15,000,000 записей в MS SQL занимают 3.5 Gb
(19 полей переменной длины). Cache в этом объеме умещает 30,000,000
таких записей + 240,000,000 дополнительных индексов для быстрой
выборки. Ну, там еще стандартный кашовский перехлест в опережающем увеличении размера файла в несколько сотен мегабайт, да это мелочи. :)
А, ну да, в MS SQL ни ключей, ни индексов не делал, просто оценивал
размерность.

С уважением. Сергей
...
Рейтинг: 0 / 0
03.05.2006, 14:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704167
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
автор+ 240,000,000 дополнительных индексов для быстрой
выборки.
Мне это больше всего понравилось!!! :)

ЗЫ Это так, не по делу :))

-- Tygra's --
...
Рейтинг: 0 / 0
03.05.2006, 14:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704200
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Iura
Есть интерес к Cache. Его cache-исты сильно хвалят. SQL 2005 - понятный и простой удобный продукт. Но в случае перехода на несколько серваков - думаю столкнусь с проблемой :(
Я бы его и порекомендовал. Мне, конечно, как хардкорщику, эмулирование
SQL и втягивание в систему всего, на что упал взгляд, сильно не нравится,
но я понимаю их политику и даже могу согласиться с осмысленностью такого
подхода. А при использовании Web-интерфейса ты вообще ничего не потеряешь при этом выборе. Одно большое НО: желательно все-таки
хорошо разобраться в языке и системе хранения данных, иначе ты
получишь просто быстрый и компактный SQL. Хотя, большинству ничего
другого и не надо. :)

С уважением. Сергей
...
Рейтинг: 0 / 0
03.05.2006, 14:32
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704224
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Sergei Obrastsovбыстрый и компактный SQL.

ню ню
...
Рейтинг: 0 / 0
03.05.2006, 14:41
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704233
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
про это то-же не забудьте
...
Рейтинг: 0 / 0
03.05.2006, 14:43
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704247
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Sergei ObrastsovИнтересно было бы узнать источник этой информации. :)
Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом. Ну, например, 15,000,000 записей в MS SQL занимают 3.5 Gb
(19 полей переменной длины). Cache в этом объеме умещает 30,000,000
таких записей + 240,000,000 дополнительных индексов для быстрой
выборки. Сергей
Каким же образом это возможно? У Кэшэ байт из 16 битов?
...
Рейтинг: 0 / 0
03.05.2006, 14:46
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704342
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
ТЗ ставить не буду. Это другой раздел.

Может сравним БД по гибкости языка TSQL, PLSQL и Cache ?

Ну есть тут человек, который реально писал серьезные проги на всех этих трех языках?

Я лично немного работал с PLSQL и писал проги на TSQL.

Юрий
...
Рейтинг: 0 / 0
03.05.2006, 15:12
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704354
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Victor Metelitsa Sergei ObrastsovИнтересно было бы узнать источник этой информации. :)
Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом. Ну, например, 15,000,000 записей в MS SQL занимают 3.5 Gb
(19 полей переменной длины). Cache в этом объеме умещает 30,000,000
таких записей + 240,000,000 дополнительных индексов для быстрой
выборки. Сергей
Каким же образом это возможно? У Кэшэ байт из 16 битов?
Что именно тебя смущает? Как уместилось? Ты лучше спроси - а как оно
пишется. Данные переменной длины, разреженные массивы, сжатие
сходных индексов. Вот и умещается.

С уважением. Сергей
...
Рейтинг: 0 / 0
03.05.2006, 15:18
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704370
Yo.!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!!
Участник
Iura
Ну есть тут человек, который реально писал серьезные проги на всех этих трех языках?


сравнивать нада платформы т.е. sql+язык процедур+фичи субд
t-sql это процедурное расширение к языку sql, там нет неймспейса, нет масивов, рекурсия только 32 вызова и т.п.
оракловый pl/sql это почти полноценный язык с тучей стандратных библиотек.
...
Рейтинг: 0 / 0
03.05.2006, 15:22
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704386
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
IuraТЗ ставить не буду. Это другой раздел.
Может сравним БД по гибкости языка TSQL, PLSQL и Cache ?
Ну есть тут человек, который реально писал серьезные проги на всех этих трех языках?
Я лично немного работал с PLSQL и писал проги на TSQL.
Юрий
Я хорошо знаю M (это оригинал COS) и похуже SQL.
Но ты, похоже, хочешь сравнивать эмулированный в Cache SQL?
Тогда я не помощник. А если чистый язык, то сравнивать просто нельзя,
M - язык прямого доступа, что называется "низкого уровня".

С уважением. Сергей
...
Рейтинг: 0 / 0
03.05.2006, 15:25
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704430
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Sergei Obrastsov Victor Metelitsa Sergei ObrastsovИнтересно было бы узнать источник этой информации. :)
Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом. Ну, например, 15,000,000 записей в MS SQL занимают 3.5 Gb
(19 полей переменной длины). Cache в этом объеме умещает 30,000,000
таких записей + 240,000,000 дополнительных индексов для быстрой
выборки. Сергей
Каким же образом это возможно? У Кэшэ байт из 16 битов?
Что именно тебя смущает? Как уместилось? Ты лучше спроси - а как оно
пишется. Данные переменной длины, разреженные массивы, сжатие
сходных индексов. Вот и умещается.Сергей

Что криминального в "данных переменой длины" для MS SQL? Или "данные переменной длины" - это когда в MS SQL записывается строка 100 байтов, а в Кэшэ 50? Или когда в MS SQL вместо VARCHAR используется CHAR? С какой стати MS SQL должен так сильно проигрывать?
...
Рейтинг: 0 / 0
03.05.2006, 15:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704440
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Sergei Obrastsov
Я хорошо знаю M (это оригинал COS) и похуже SQL.
Но ты, похоже, хочешь сравнивать эмулированный в Cache SQL?
Тогда я не помощник. А если чистый язык, то сравнивать просто нельзя,
M - язык прямого доступа, что называется "низкого уровня".

С уважением. Сергей

Почему он менее популярен чем SQL ?
Я пытался разобраться с Cache - но Help ужасно поставлена, как и у Oracle.
...
Рейтинг: 0 / 0
03.05.2006, 15:40
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704465
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
2 Victor Metelitsa
Что криминального в "данных переменой длины" для MS SQL? Или "данные переменной длины" - это когда в MS SQL записывается строка 100 байтов, а в Кэшэ 50? Или когда в MS SQL вместо VARCHAR используется CHAR? С какой стати MS SQL должен так сильно проигрывать?
У Каше видать встроенный архиватор, который все сожмет, да еще и 240000000 индексов туда же впендюрит :)

2 Sergei Obrastsov
Шоб не быть голословным пиздаболом - выложили бы тестовые скрипты на создание тех самых 15 миллионов записей из 19 полей переменной длины, для сиквела и для каши. Ну а мы бы поглядели на это чудо, как это в "разреженных массивах" данные почему-то в два раза меньше места занимают, да еще и место для 240 миллионов индексов остается.
...
Рейтинг: 0 / 0
03.05.2006, 15:50
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704503
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
У меня есть предложение, чтобы решить вопрос

Давайте поставим простую задачку

нашим процедуры на трех языках
и заполним ее одинаковыми данными
и сравним возможности языка, объем базы данных и производительность.
...
Рейтинг: 0 / 0
03.05.2006, 16:01
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704521
jvv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jvv
Участник
Глобалы Cache не используют место на диске если в них не внесены данные, а если данные внесены, то используется ровно столько места, сколько байт "присутствует" во внесенных данных (плюс небольшие издержки на структуру хранения).

Этот эффект проявляется и при использовании Cache как реляционной СУБД (данные то будут всё равно храниться в глобалах).

Тоесь, для Cache , если в поле FLD записано ноль байт - то в дисковом пространстве так же будет израсходовано ноль байт. А если в него записано 10 байт, то 10 байт будет занято на диске.

Вот поэтому и получаются меньший объём. Ничего особенного, как видите.
...
Рейтинг: 0 / 0
03.05.2006, 16:05
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704533
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Нормальная литература на русском по Cache 5 есть ?
...
Рейтинг: 0 / 0
03.05.2006, 16:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704544
jvv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jvv
Участник
IuraНормальная литература на русском по Cache 5 есть ?

Книжка одна, похоже что и есть.. называется так:
"Субд Cache объектно-ориентированная разработка приложений"
...
Рейтинг: 0 / 0
03.05.2006, 16:09
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704550
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
2 Iura
нашим процедуры на трех языках
Что, простите, сделаем на трех языках?

и заполним ее одинаковыми данными
и сравним возможности языка, объем базы данных и производительность.
Возможности языка - какие? По вставке данных? Афигенные возможности наверное требуются...
Производительность - чего? Вставки данных по одной записи в цикле? Тут всех фокспро да аксес уделают :)
Единственное, что имеет смысл таким образом сравнивать, так это действительно объемы данных. И то исключительно в контексте рассмотрения весьма забавного утверждения о том, что каша в разреженных массивах данные умудряется в два раза плотнее хранить :)
...
Рейтинг: 0 / 0
03.05.2006, 16:10
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704555
book
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
book
Гость
jvv IuraНормальная литература на русском по Cache 5 есть ?

Книжка одна, похоже что и есть.. называется так:
"Субд Cache объектно-ориентированная разработка приложений"

http://www.ozon.ru/context/detail/id/2386194/
...
Рейтинг: 0 / 0
03.05.2006, 16:13
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704573
jvv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jvv
Участник
book jvv IuraНормальная литература на русском по Cache 5 есть ?

Книжка одна, похоже что и есть.. называется так:
"Субд Cache объектно-ориентированная разработка приложений"

http://www.ozon.ru/context/detail/id/2386194/

Ну, да.. вот про неё я и говорю.. других вроде как нет..
...
Рейтинг: 0 / 0
03.05.2006, 16:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704578
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
2 jvv
Глобалы Cache не используют место на диске если в них не внесены данные, а если данные внесены, то используется ровно столько места, сколько байт "присутствует" во внесенных данных (плюс небольшие издержки на структуру хранения). .
Ну и? В чем принципиальное отличие от сиквела, например? Настолько принципиальное, что на тех же самых данных получилось различие в два раза (и даже больше, чем в два раза, если вспомнить про 240 миллионов индексов)?

Тоесь, для Cache , если в поле FLD записано ноль байт - то в дисковом пространстве так же будет израсходовано ноль байт. А если в него записано 10 байт, то 10 байт будет занято на диске.
Ну и? Что, в сиквеле (в оракле, в дибиту, где-нить еще) по другому? Типа если в поле переменной длины записано 0 байт, то на диске оно займет 100 байт, а если в поле записано 10 байт, то на диске оно займет килобайт? Так что ли?

Вот поэтому и получаются меньший объём. Ничего особенного, как видите
Не видим, если честно. Расшифруйте.
...
Рейтинг: 0 / 0
03.05.2006, 16:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704609
jvv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jvv
Участник
>> Не видим, если честно. Расшифруйте.

А что тут расшифровывать то?
Я пояснил почему в разреженном масиве (так почему то глобалы называют) данные занимают места на диске меньше, чем, ну , например в "DBF формате"..
Если Вы рассмотрите, структуру DBF файла, то увидите что место на диске будет занято вне зависимости от того внесены ли значащие данные в то самое поле FLD.. Если оно предполагает хранение 100 символьной строки, то и будет занимать 100 байтов. Причем, всегда.. А в Cache - не так.

Что касается Oracle и MSSQL - я не знаю, как там данные хранятся на диске.. может быть Вы разберётесь и сравните.
...
Рейтинг: 0 / 0
03.05.2006, 16:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704615
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 ЛП
Ну просто человек про varchar не слышал :))

-- Tygra's --
...
Рейтинг: 0 / 0
03.05.2006, 16:27
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704621
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
jvv>> Не видим, если честно. Расшифруйте.

А что тут расшифровывать то?
Я пояснил почему в разреженном масиве (так почему то глобалы называют) данные занимают места на диске меньше, чем, ну , например в "DBF формате"..
Если Вы рассмотрите, структуру DBF файла, то увидите что место на диске будет занято вне зависимости от того внесены ли значащие данные в то самое поле FLD.. Если оно предполагает хранение 100 символьной строки, то и будет занимать 100 байтов. Причем, всегда.. А в Cache - не так.

Что касается Oracle и MSSQL - я не знаю, как там данные хранятся на диске.. может быть Вы разберётесь и сравните.
Понятно
Бдительные кашисты проспали тот факт, что человечество уже изобрело два типа данных -char(максимальная_длина) и varchar(максимальная_длина)
...
Рейтинг: 0 / 0
03.05.2006, 16:29
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704626
jvv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jvv
Участник
Ну поясните.. как они хранятся на диске?
Я не знаю этого. Это действительно так.
...
Рейтинг: 0 / 0
03.05.2006, 16:31
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704641
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
То есть если у меня есть структура на SQL

Table(
Col1 Bigint
Col2 int
Col3 varchar(max)
)


и вовсе три поля я запишу NULL, то в файле базы данных под сами данные будет отведено 0 байт, а под ссылку на строку будет отведено N байт. Верно?
...
Рейтинг: 0 / 0
03.05.2006, 16:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704652
jvv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jvv
Участник
К кому вопрос?
...
Рейтинг: 0 / 0
03.05.2006, 16:39
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704689
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
Верно?
Нет.
...
Рейтинг: 0 / 0
03.05.2006, 16:48
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704704
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
jvvК кому вопрос?

К знающим людям!
...
Рейтинг: 0 / 0
03.05.2006, 16:51
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704729
jvv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jvv
Участник
Iura jvvК кому вопрос?
К знающим людям!

Ну тогда сравнивать то нужно то, что можно сравнить..

вот этот вопрос "и вовсе три поля я запишу NULL, то в файле базы данных под сами данные будет отведено 0 байт, а под ссылку на строку будет отведено N байт. Верно?" - для Cache не имеет смысла, потому что "ссылок на строку" там нет вообще..
...
Рейтинг: 0 / 0
03.05.2006, 16:56
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704832
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
секрет каша в том что таблицу вида

ABC CDE 123
ABC CDE 456
ABC HRT 789
ABC HRT 123

каша хранит примерно вот так

ABC CDE 123 456 HRT 789 123

при этом ABC CDE HRT это индекс а 123 456 789 123 данные
...
Рейтинг: 0 / 0
03.05.2006, 17:18
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704855
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
модсекрет каша в том что таблицу вида

ABC CDE 123
ABC CDE 456
ABC HRT 789
ABC HRT 123

каша хранит примерно вот так

ABC CDE 123 456 HRT 789 123

при этом ABC CDE HRT это индекс а 123 456 789 123 данные

и как он понимает какие данные какому индексу принадлежат?
...
Рейтинг: 0 / 0
03.05.2006, 17:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704871
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Iura модсекрет каша в том что таблицу вида

ABC CDE 123
ABC CDE 456
ABC HRT 789
ABC HRT 123

каша хранит примерно вот так

ABC CDE 123 456 HRT 789 123

при этом ABC CDE HRT это индекс а 123 456 789 123 данные

и как он понимает какие данные какому индексу принадлежат?

Сорри, понял.
...
Рейтинг: 0 / 0
03.05.2006, 17:28
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704882
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
модсекрет каша в том что таблицу вида

каша хранит примерно вот так
То есть тот самый COMPRESS, который я упоминал еще на первой странице в отношении Oracle.
...
Рейтинг: 0 / 0
03.05.2006, 17:33
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33704900
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
softwarerТо есть тот самый COMPRESS, который я упоминал еще на первой странице в отношении Oracle.
Да, конечно
...
Рейтинг: 0 / 0
03.05.2006, 17:41
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705103
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
модсекрет каша в том что таблицу вида

ABC CDE 123
ABC CDE 456
ABC HRT 789
ABC HRT 123

каша хранит примерно вот так

ABC CDE 123 456 HRT 789 123

при этом ABC CDE HRT это индекс а 123 456 789 123 данные
А вот такую таблицу он в таком же виде будет хранить?
ABC
CDE
123
456
HRT
789
123
Если нет, то в каком?, если да - то значит есть дополнительные данные о структуре данных
luraТо есть если у меня есть структура на SQL

Table(
Col1 Bigint
Col2 int
Col3 varchar(max)
)


и вовсе три поля я запишу NULL, то в файле базы данных под сами данные будет отведено 0 байт, а под ссылку на строку будет отведено N байт. Верно?
Вобще-то Вы в такую таблицу не вставите поля Col1 и Col2 с null-ом :)
Надо у типа поля указать что может быть нулл.
А хранит MSSQL данные довольно сложно, надо читать спициальные книжки. Если в двух словах то имеется небольшой заголовок записи, потом идут поля фиксированного размера(если есть нулл - то оно нефиксированного размера), потом поля нефиксированного размера с указанием сколько место оно занимает. К томуже надо учесть что имеется страничная организация.
Вобщем пустая запись сколько-то места занимать будет, но запись с данными будет занимать еще больше места.

Но только вот объясните(интересно) - как Вы словарями 1000Г хотите забить? Я сомневаюсь что самый полный словарь может занимать больше 1Г, а тысячи языков то наверное в мире и нету
...
Рейтинг: 0 / 0
03.05.2006, 18:51
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705151
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
SergSuper wrote:
> Но только вот объясните(интересно) - как Вы словарями 1000Г хотите
> забить? Я сомневаюсь что самый полный словарь может занимать больше 1Г,
> а тысячи языков то наверное в мире и нету
гадкий лингво - 40 метров. помножим для полноты на... 3. Будет 120 метров.
на терабайт выходит - 8 тыщ словарей? или де-то соврал? :-(


--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
03.05.2006, 19:07
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705301
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Словарь слов + словарь предложений на всех языках + во всех фомах (как правильные так и не правильный)

Соотвествие слова или предложение одного языка - на другой и так далее + нагрузка смыславая. Одно и тоже слово или предложение может иметь различный перевод в зависимости от контекста. Эту информацию мне тоже нужно будет хранить. Есть чем место забивать. Для каждого пользователя будет создаватся собственый словарь, но при переводе он сможет использовать и свой и глобальный.
...
Рейтинг: 0 / 0
03.05.2006, 20:47
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705303
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
модсекрет каша в том что таблицу вида

ABC CDE 123
ABC CDE 456
ABC HRT 789
ABC HRT 123

каша хранит примерно вот так

ABC CDE 123 456 HRT 789 123

при этом ABC CDE HRT это индекс а 123 456 789 123 данные


Как он хранит данные вида

ABC CDE 123
ABC Null 456
ABC HRT 789
Null HRT 123
Null Null Null
ABC CDE Null
...
Рейтинг: 0 / 0
03.05.2006, 20:50
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705427
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
jvvНу поясните.. как они хранятся на диске?
Я не знаю этого. Это действительно так.
Вот это самая большая беда как я понимаю MUMPS и Cache - это его специалисты, которые не стесняются сравнивать их с РСУБД, при этом абсолютно ничего не зная о последних.

jvv, если Вы ничего не знаете, то какого тут высказывались о том, что Cache данные оптимальнее других РСУБД хранит ? Я признаю Ваши глубокие познания в DBF, но ... ?
...
Рейтинг: 0 / 0
03.05.2006, 23:34
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705434
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
IuraСловарь слов + словарь предложений на всех языках + во всех фомах (как правильные так и не правильный)

Соотвествие слова или предложение одного языка - на другой и так далее + нагрузка смыславая. Одно и тоже слово или предложение может иметь различный перевод в зависимости от контекста. Эту информацию мне тоже нужно будет хранить. Есть чем место забивать. Для каждого пользователя будет создаватся собственый словарь, но при переводе он сможет использовать и свой и глобальный.
В лингво тоже есть предложения и формы... Я в этом ничего не понимаю - но всё-таки разница в 25000 раз... Наверное у вас есть какая-то новая информация по сравнению с той которая уже заведена в лингво, но неужели в таких объёмах?
Интересно как Вы получили цифру в 1000Г?
...
Рейтинг: 0 / 0
03.05.2006, 23:47
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705505
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пьяный Лох
Участник
ASCRUSВот это самая большая беда как я понимаю MUMPS и Cache - это его специалисты, которые не стесняются сравнивать их с РСУБД, при этом абсолютно ничего не зная о последних.
ASCRUS, положа руку на сердце, признайте - "шпецыалистов" по обе стороны баррикад хватает :).
РСУБД-шники в большинстве своем тоже абсолютно ничего не знают о МУМПСе (итдитп), что не мешает им высказывать мнение о превосходстве РСУБД по всем параметрам. Видать потому, что "в большинстве".

Точно такая же картина во время споров "ФС vs КС". Плюсы и минусы есть и у КС, и у ФС, но именно для КС-ников характерно поведение, когда будучи ни в зуб ногой (ни в один зуб ни единой ногой) - априори считать себя лучче фсехъ.

Разруха - она не в сортирах. И не в используемых СУБД.

"Какие такие ошибки округления чисел с плавающей точкой? У нас же ОРАКЛ!!!" (с) не моё
...
Рейтинг: 0 / 0
04.05.2006, 04:05
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705518
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Пьяный Лох: ну когда некоторые ораклисты думают, что все, что сотворил господь бог есть у них, причем свято верят, что самое лучшее - я даже не обижаюсь, просто знаю, что у человека на изучение сего чуда уходит слишком много времени, чтобы еще с чем то ознакомится, это так сказать вынужденное невежество. Но приравнивать РСУБД с DBF и на базе этого выдумывать доказательства эффективности M-систем - по моему вверх невежества. Я лично сам с MUMPS или CACHE дела не имел, однако имел дело с специалистами, которые долго с ними работают. В первом случае банк спит и видит, чтобы перейти c MUMPS на РСУБД, во втором случае CACHE использовали не только на полную катушку, но еще и расширяли собственными библиотеками, написанными на Си для создания более скоростных решений по обработке групповых запросов, расчету аггрегатов и т.д. Вот от них я и наслышался про слабые и сильные черты таких систем, лично у меня сложилось мнение, что по парадигме они немного другое, чем привыкли понимать мы под понятием серверов баз данных с точки зрения ФС и КС, что Cache все таки сыроват и медленно развивается и что 30 тонн за сервак слишком дорогое удовольствие для конечного покупателя продукта на нем.
...
Рейтинг: 0 / 0
04.05.2006, 05:32
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705523
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пьяный Лох
Участник
2 ASCRUS
ну когда некоторые ораклисты думают, что все, что сотворил господь бог есть у них, причем свято верят, что самое лучшее - я даже не обижаюсь, просто знаю, что у человека на изучение сего чуда уходит слишком много времени, чтобы еще с чем то ознакомится, это так сказать вынужденное невежество.
Типа ораклоидам можно быть невежественными относительно других баз, патамушта у них чудо "струдомизучабельное", а мумпсистам быть невежественными нельзя. Что, изучабельность ихнего "чуда" намного выше?

Но приравнивать РСУБД с DBF и на базе этого выдумывать доказательства эффективности M-систем - по моему вверх невежества.
Человек поделился наблюдением о том, что каша способна хранить данные в меньшем (по сравнению с сиквелом) объеме, но объяснить это явление - не сумел. Ну ниасилил он структуру хранения данных в сиквеле, что дальше то? Я, например, тоже ниасилил :).
Если факт экономии пространства имеет место быть (а судя по объяснению мод'а он вполне может иметь место быть), то он не перестанет быть от того, что имеет место быть неправильное объяснение.
...
Рейтинг: 0 / 0
04.05.2006, 05:53
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705529
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пьяный Лох
Участник
Кстати, несколько вопросов к мод'у

модсекрет каша в том что таблицу вида

ABC CDE 123
ABC CDE 456
ABC HRT 789
ABC HRT 123

каша хранит примерно вот так

ABC CDE 123 456 HRT 789 123

при этом ABC CDE HRT это индекс а 123 456 789 123 данные
правильно ли я понимаю, что "секрет каша" - это есть хранение данных непосредственно в индексе... ээээ.... как бы это сказать... без хранения их где-либо еще?
Т.е. если я в сиквеле сделаю индекс наподобие такого:
Код: plaintext
create index [indexname] on [tablename] (field1, field2) include (field3)
то полученный индекс будет по структуре напоминать кешовое хранилище? Однако сиквел будет хранить и индекс, и данные, и за счет этого проигрывать?

Если я правильно понял, то интересно было бы оценить накладные расходы. В сиквеле такие индексы вроде как место хорошо кушают.

Что делать, если помимо "ABC CDE HRT это индекс а 123 456 789 123 данные" потребуется иметь еще и "123 456 789 АВС это индекс а CDE HRT это данные" ? Как в этом случае хранится все будет?
...
Рейтинг: 0 / 0
04.05.2006, 06:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33705602
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
SergSuper IuraСловарь слов + словарь предложений на всех языках + во всех фомах (как правильные так и не правильный)

Соотвествие слова или предложение одного языка - на другой и так далее + нагрузка смыславая. Одно и тоже слово или предложение может иметь различный перевод в зависимости от контекста. Эту информацию мне тоже нужно будет хранить. Есть чем место забивать. Для каждого пользователя будет создаватся собственый словарь, но при переводе он сможет использовать и свой и глобальный.
В лингво тоже есть предложения и формы... Я в этом ничего не понимаю - но всё-таки разница в 25000 раз... Наверное у вас есть какая-то новая информация по сравнению с той которая уже заведена в лингво, но неужели в таких объёмах?
Интересно как Вы получили цифру в 1000Г?


SergSuper
Подсчитай кол-во возможных направления перевода для 50 языков, а таковых будет больше. Для всех направлений нужно создавать свой словарь. Учти, я в отличии от лингво буду использовать словари, созданые пользователями. Меня не будет волновать, сделали они правильный или не правильный перевод. Будет два правила. То, что чаще встречается - то правильней. Все пользователи будут делиться по уровню "образования". Чем выше уровень, тем более правильный перевод можно ожидать от пользователя и поэтому его перевод слова или фразы будет иметь больший вес в оценочной функции, которая будет выбирать из возможных вариантов перевода.

Будут хранится как все исходные тексты + переводы, чтобы система на базе статистики могла сама делать предположения и обучаться.

Фразы типа
Колл ме бэк или Mi segodnia bili v kino :-p
Так же будут храниться, и если пользователь для этих фраз создаст перевод, то он будут также использоваться.
...
Рейтинг: 0 / 0
04.05.2006, 08:14
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706044
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
ЛПШоб не быть голословным пиздаболом - выложили бы тестовые скрипты на создание тех самых 15 миллионов записей из 19 полей переменной длины, для сиквела и для каши. Ну а мы бы поглядели на это чудо, как это в "разреженных массивах" данные почему-то в два раза меньше места занимают, да еще и место для 240 миллионов индексов остается.
"Голословным", да еще и "пиздаболом", быть совсем не хочется, поэтому
поговорим немного детальнее (интересно, письмо лимитировано по размеру?)
Во-первых, я сначала объясню, откуда взялись такие числа: 250,000 - это
среднее число телефонных разговоров по нашей станции в день, множим
на 30 - получаем 7,5 млн. Фактически, это не совсем так, в разные месяцы
нагрузка скачет и например, данные, которые я использовал вчера для офф.тестирования, в сумме составляют 18 млн. записей за 3 месяца.
За это - Sorry. А ситуация выглядела так: данные за 2 месяца в MS SQL - 3.5Gb, данные за те же 2 месяца + еще 2 месяца (ну и + доп.индексы) -
3.7 Gb (сейчас в базе 16 месяцев, размер 15.336 Gb, в среднем на месяц ~5,700,000 записей).
Ну, а теперь к делу. Имеются тарификационные записи за 3 месяца вида:
---
0 010 ......1111111111 111111................ 030506 220939 000118 000006 00 00 0 0 0000 0019 3 0003 0164 0423 0007
---
сведены в plain файл, "." в 3,4 полях убраны
число строк - 18,047,848
размер файла - 1.521 Gb
---
Теперь дело за SQL. В наличии оказался только My SQL (ну, что есть).
Создаем таблицу, 19 полей, по типам:
v1 - tinyint
v2 - int(3)
v3 - varchar(16)
v4 - varchar(16)
v5 - data
v6 - time
v7 - int(6)
v8 - int(8)
v9 - int(2)
v10 - int(2)
v11 - tinyint
v12 - tinyint
v13 - int(4)
v14 - int(4)
v15 - tinyint
v16 - int(4)
v17 - int(4)
v18 - int(4)
v19 - int(4)
(null везде разрешен)
индексов нет... пока :)
---
шаг 2 - Import
ага, обычный импорт plain файла с разделителем (ну и какой скрипт от меня нужен?)
время не считал, а нафига? результат - 1.970 Gb

Передохнем. Выходит, снова я приврал. Не получается на 15 млн. записей
3.5 Gb. Значитца, индекс все же был. Ну вот, снова Sorry.
---
шаг 3 - Indexing
вводим индекс по полю v5 (data)
SQL резво начинает индексировать таблицу, шустро доводит ее до 4Gb
и сдыхает (у меня FAT32 дома). Так что свое заявление подкорректирую:
не 15 млн. записей в 3.5Gb, а скорее ~13 млн. + индекс по v5.

Так, с SQL вроде все. В следующем письме расскажу про Cache.

P.S. Просьба не пинать ногами и громко не смеяться, я никогда и не
называл себя специалистом по SQL.
P.P.S. Не уверен, что изменение типов данных с int на varchar даст
серьезные изменения в размере DB.

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 10:50
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706078
jvv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jvv
Участник
ASCRUS jvvНу поясните.. как они хранятся на диске?
Я не знаю этого. Это действительно так.
Вот это самая большая беда как я понимаю MUMPS и Cache - это его специалисты, которые не стесняются сравнивать их с РСУБД, при этом абсолютно ничего не зная о последних.

jvv, если Вы ничего не знаете, то какого тут высказывались о том, что Cache данные оптимальнее других РСУБД хранит ? Я признаю Ваши глубокие познания в DBF, но ... ?


То что я ничего не знаю - это продукт вашего воображения.. не нужно передёргивать, товаришч! Здесь не митинг Ампилова...

Мои реплики связаны с вот такими вопросами:
"Каким же образом это возможно? У Кэшэ байт из 16 битов?"
"Или "данные переменной длины" - это когда в MS SQL записывается строка 100 байтов, а в Кэшэ 50?"

Я и пояснил, каким это образом, при умножении предполагаемых 100 байтов (длина поля) на миллион записей, на диск будет писаться меньше ста миллионов байт. Разумеется , при условии, что пишутся строки переменной длины, а не все по сто.


А вот это "Ну поясните.. как они хранятся на диске?
Я не знаю этого. Это действительно так." - чистая правда.. я понятия не имею как ORACLE и MSSQL хранит на дике данные. И отмечаю для себя - оно мне и на х.. не нужно.. как впрочем и сами эти ORACLE и MSSQL.. ;))
...
Рейтинг: 0 / 0
04.05.2006, 10:58
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706132
jvv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jvv
Участник
Для ASCRUS

Да, кстати, а где это я сравниваю Cache с какой то РСУБД?
Самому интересно стало.. стал искать.. и, что то, не нашел я в своих репликах выражений типа "вот давайте сравним Cache и ORACLE".. Это Вы, батенька всё сравниваете. А я просто высказываю своё мнение.
...
Рейтинг: 0 / 0
04.05.2006, 11:11
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706141
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
модсекрет каша в том что таблицу вида

ABC CDE 123
ABC CDE 456
ABC HRT 789
ABC HRT 123

каша хранит примерно вот так

ABC CDE 123 456 HRT 789 123

при этом ABC CDE HRT это индекс а 123 456 789 123 данные
немного не так:

a b reference d data
---------------------
0 7 "ABC CDE" 3 123
7 0 3 123
4 3 HRT 3 789
7 0 3 123

a - кол-во совпадающих символов с предыдущей ссылкой
b - кол-во несовпадающих символов с предыдущей ссылкой
reference - глобальная ссылка
d - количество символов в данных при индексе
data - строка данных

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 11:12
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706352
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
jvvДля ASCRUS

Да, кстати, а где это я сравниваю Cache с какой то РСУБД?
Самому интересно стало.. стал искать.. и, что то, не нашел я в своих репликах выражений типа "вот давайте сравним Cache и ORACLE".. Это Вы, батенька всё сравниваете. А я просто высказываю своё мнение.
Извините, я просто топик читал, ориентируясь на его заголовок, поэтому сделал вывод, что фраза насчет "Обьем занимаемых в Cache меньше" относится как сравнение к перечисленным РСУБД топика.
...
Рейтинг: 0 / 0
04.05.2006, 11:51
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706368
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Пьяный Лохправильно ли я понимаю, что "секрет каша" - это есть хранение данных непосредственно в индексе... ээээ.... как бы это сказать... без хранения их где-либо еще?
секрет cache (вернее M) в произвольном структурировании массивов.
вот смотри:
я могу организовать хранение данных вида

a_b_date_time_... в виде "плоской таблицы", как

^dat(1)=a_";"_b_";"_date1_";"_...
^dat(2)=a_";"_b_";"_date2_";"_...
^dat(3)=a_";"_b_";"_date1_";"_...
^dat(4)=a_";"_b_";"_date2_";"_...

а индексов к ней как

^ind(date1,1)=
^ind(date1,3)=
^ind(date2,2)=
^ind(date2,4)=

а можно "совместить полезное с приятным":

^dat(date1,1)=a_";"_b_";"_date1_";"_...
^dat(date1,3)=a_";"_b_";"_date1_";"_...
^dat(date2,2)=a_";"_b_";"_date2_";"_...
^dat(date2,4)=a_";"_b_";"_date2_";"_...

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

Пьяный Лох
Т.е. если я в сиквеле сделаю индекс наподобие такого:
Код: plaintext
create index [indexname] on [tablename] (field1, field2) include (field3)
то полученный индекс будет по структуре напоминать кешовое хранилище? Однако сиквел будет хранить и индекс, и данные, и за счет этого проигрывать?

за счет того, что индексы не интегрированы в таблицу с данными - да.

Пьяный Лох
Если я правильно понял, то интересно было бы оценить накладные расходы. В сиквеле такие индексы вроде как место хорошо кушают.

сейчас перекурю и допишу письмо про Cache, там как раз об этом.

Пьяный Лох
Что делать, если помимо "ABC CDE HRT это индекс а 123 456 789 123 данные" потребуется иметь еще и "123 456 789 АВС это индекс а CDE HRT это данные" ? Как в этом случае хранится все будет?
как скажешь, так и будет :)
если это индексы разного логического уровня, то развешивай на разные ветки

^a("index type 1","ABC CDE")=123
...
^a("index type 1","ABC HRT")=789

^a("index type 2",123)="CDE HRT"

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 11:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706377
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Транзакционная Многомерная Модель Данных (TMDM)

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

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

Доступ к постреляционной базе данных Caché осуществляется любым из трех способов:

1. Caché Direct Access — прямой доступ к данным, обеспечивает максимальную производительность и полный контроль со стороны программиста.
2. Caché SQL — реляционный доступ, обеспечивающий межсистемное взаимодействие (ODBC) и максимальную производительность реляционных приложений с использованием встроенного SQL.
3. Caché Objects — объектный доступ, для максимальной продуктивности разработки при использовании Java, ActiveX, C++ и других объектных технологий.

Как показывают тесты, производительность Caché SQL как минимум в три раза выше, чем у традиционных реляционных СУБД, использующих реляционное ядро.
...
Рейтинг: 0 / 0
04.05.2006, 11:54
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706387
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Caché Server Pages

Для разработки Web-приложений в Caché используется технология серверных страниц, т.е. создаются специальные страницы, которые заполняются данными немедленно ("on-the-fly"), как только они запрашиваются браузером. Отличие серверных страниц Caché (Caché Server Pages) от других технологий разработки Web-приложений состоит в том, что они хранятся на сервере данных Caché, так сказать, рядом с используемыми данными. При обращении к CSP-странице выполняются методы, генерирующие HTML или XML. Чтобы подсоединиться к Web-серверу, используется стандарт API, обеспечивающий высокую скорость. Такая архитектура позволяет создавать высокопроизводительные Internet- или Intranet-приложения.

Сравнение архитектур для Web-приложений

Стандарты HTML или XML, на основе которых созданы серверные страницы Caché, обеспечивают легкое создание и редактирование страниц с помощью готовых инструментов разработки Web-страниц или выбранного пользователем текстового редактора. Расширение функциональности осуществляется путем внедрения Caché Application Tags (CAT) или Hyper-Events™.

Caché Application Tags

Caché Applications Tags (CAT или теги приложений Caché) действуют подобно тегам HTML с той разницей, что вместо форматирования текста они исполняют функции на сервере данных Caché и/или в браузере. Таги приложений Caché используются для записи и считывания из базы данных, расчетов, организации циклов, регистрации, мульти-фреймовой координации и т.д. Дополнительное преимущество состоит в том, что набор стандартных CAT может быть расширен. Разработчики могут создавать теги самостоятельно для собственных приложений.

Гипер-события (Hyper-Events™)

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

Технология Гипер-событий (Hyper-Events) позволяет изменять содержимое страницы без ее перезагрузки, причем эти изменения будут оперировать данными, динамически получаемыми с сервера базы данных.
...
Рейтинг: 0 / 0
04.05.2006, 11:55
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706453
jvv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
jvv
Участник
ASCRUS jvvДля ASCRUS

Да, кстати, а где это я сравниваю Cache с какой то РСУБД?
Самому интересно стало.. стал искать.. и, что то, не нашел я в своих репликах выражений типа "вот давайте сравним Cache и ORACLE".. Это Вы, батенька всё сравниваете. А я просто высказываю своё мнение.
Извините, я просто топик читал, ориентируясь на его заголовок, поэтому сделал вывод, что фраза насчет "Обьем занимаемых в Cache меньше" относится как сравнение к перечисленным РСУБД топика.

Ваша способность отказаться от выводов, основанных на ошибочном предположении, говорит о том, что Вы трезво мыслящий человек.
...
Рейтинг: 0 / 0
04.05.2006, 12:05
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706469
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 Iura
А можно узнать, для чего тут маркетинговые листовки про Кэш??? :))

Ничего общего с реальной жизнью они не имеют. Уж не говорю про web.

-- Tygra's --
...
Рейтинг: 0 / 0
04.05.2006, 12:08
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706493
FreemanZAV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FreemanZAV
Участник
IuraКак показывают тесты, производительность Cach? SQL как минимум в три раза выше, чем у традиционных реляционных СУБД, использующих реляционное ядро.
Очинно сумлеваюсь
IuraТехнология Гипер-событий (Hyper-Events) позволяет изменять содержимое страницы без ее перезагрузки, причем эти изменения будут оперировать данными, динамически получаемыми с сервера базы данных.
Для того, чтобы изменять содержимое страницы без ее перезагрузки Cache не нужен. Есть ajax например.
...
Рейтинг: 0 / 0
04.05.2006, 12:14
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706601
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
IuraСловарь слов + словарь предложений на всех языках + во всех фомах (как правильные так и не правильный)

Соотвествие слова или предложение одного языка - на другой и так далее + нагрузка смыславая. Одно и тоже слово или предложение может иметь различный перевод в зависимости от контекста. Эту информацию мне тоже нужно будет хранить. Есть чем место забивать. Для каждого пользователя будет создаватся собственый словарь, но при переводе он сможет использовать и свой и глобальный.

Вот для этой задачки древовидная структура будет идеальной. ИМХО, конечно.
Возможный глобал:
^Словарь(слово,код_раздела,вариант_значения_слова)=перевод^значение

Пример:

^Словарь("word","словарь_общей_лексики",1)=слово^слово
...
^Словарь("word","словарь_общей_лексики",6)=слово^приказ, приказание, распоряжение, команда
...
^Словарь("word","технический_словарь",1)=слово^набор из 2-х 4-х или 8-ми последовательных байтов, обрабатываемый аппаратной
...
Рейтинг: 0 / 0
04.05.2006, 12:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706635
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
>>Для того, чтобы изменять содержимое страницы без ее перезагрузки Cache не нужен. Есть ajax например.

Ну что вы бодаться то сразу? Каше то, сам по себе тоже не нужен :)) Нужны программы, которые решают задачи заказчика.
А здесь всего лишь говорится что в Каше УЖЕ присутствуют механизмы, которые в других местах называются ajax. И всё.. ничего личного, как говорится.
...
Рейтинг: 0 / 0
04.05.2006, 12:40
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706678
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Однако иметь сервер БД в открытом доступе для всего инета - это умно, ничего не скажешь :))

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

-- Tygra's --
...
Рейтинг: 0 / 0
04.05.2006, 12:53
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706690
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Переписываю Cache 5.1

Буду ковырять его.

Все кто за SQL - просмотрите сайт http://www.intersystems.ru
Интересны Ваши мнения по каждому конкретному факту.


Пошел искать в интернет официальные результаты сравнения производительности MS SQL, Oracle, Cache
...
Рейтинг: 0 / 0
04.05.2006, 12:55
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706709
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
tygraОднако иметь сервер БД в открытом доступе для всего инета - это умно, ничего не скажешь :))

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

-- Tygra's --

Каше в качестве вэб сервера?... я не понял о чём Вы говорите.

Вэб сервер будет тот, который Вам больше нравится.. далее - CSP Gateway, далее CSP server... и только потом БД
...
Рейтинг: 0 / 0
04.05.2006, 13:00
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706764
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
Iura
Пошел искать в интернет официальные результаты сравнения производительности MS SQL, Oracle, Cache

Долгая дорога... много трудностей Вас поджидает :)

Есть другой путь:
- рассмотреть возможность реализации пилотного проекта для вашей фирмы :)
...
Рейтинг: 0 / 0
04.05.2006, 13:14
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706808
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Ну что ж, продолжим. Итак те же данные + Cache:
Структура массива следующая, раз уж кого-то интересует (переменные
даны в именах SQL таблицы):

^dft(v5,"idx",idx)=v1_v2_v3_v4_v6...v19
^dft(v5,"cat",v2,idx)=
^dft(v5,"tr",v1,idx)=
^dft(v5,"pa",v3,v4,idx)=
^dft(v5,"pb",v4,v3,idx)=
^dft(v5,"mda",v16,v17,idx)=
^dft(v5,"mdb",v18,v19,idx)=
^dft(v5,"ti",v14,idx)=
^dft(v5,"to",v15,idx)=

idx - формируемый 4-х значный индекс из диапазона "1...0a...zA...Z"
для позиции. получается компактней, конечно, чем 18000001 :)

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

так, закачали. размер файла cache.dat - 2.958 Gb
кстати, без доп.индексов размер файла - 1.155 Gb (это я так :) )

ну, насчет 30 млн. записей в 3.5 Gb я уже извинился, ага.
впрочем, MS SQL 15 млн. записей с индексацией по дате в 3.5 Gb тоже
не запишет. :))

итог: 164,430,632 узла (сиречь индекса, записи, прочее... здесь это одно и то же)

я, правда, схитрил, признаюсь честно. хитростей несколько:
1. я пакую поля 2 и 3, получается примерно пополам.
2. я обрезаю остаток строки с данными до последнего значимого поля
ну понятно, что поля виртуальные, я их разделителем делаю
3. про индекс я уже упомянул

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

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

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 13:25
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706862
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
IuraПереписываю Cache 5.1

Буду ковырять его.

Все кто за SQL - просмотрите сайт http://www.intersystems.ru
Интересны Ваши мнения по каждому конкретному факту.
100 раз перетиралось - маркетинговая шелуха.

yww@escape.ru Каше в качестве вэб сервера?... я не понял о чём Вы говорите.

Вэб сервер будет тот, который Вам больше нравится.. далее - CSP Gateway, далее CSP server... и только потом БД
Читаем маркетинговый материал
IuraCaché Server Pages

Для разработки Web-приложений в Caché используется технология серверных страниц, т.е. создаются специальные страницы, которые заполняются данными немедленно ("on-the-fly"), как только они запрашиваются браузером. Отличие серверных страниц Caché (Caché Server Pages) от других технологий разработки Web-приложений состоит в том, что они хранятся на сервере данных Caché, так сказать, рядом с используемыми данными. При обращении к CSP-странице выполняются методы, генерирующие HTML или XML. Чтобы подсоединиться к Web-серверу, используется стандарт API, обеспечивающий высокую скорость. Такая архитектура позволяет создавать высокопроизводительные Internet- или Intranet-приложения.

Сравнение архитектур для Web-приложений

Стандарты HTML или XML, на основе которых созданы серверные страницы Caché, обеспечивают легкое создание и редактирование страниц с помощью готовых инструментов разработки Web-страниц или выбранного пользователем текстового редактора. Расширение функциональности осуществляется путем внедрения Caché Application Tags (CAT) или Hyper-Events™.

Caché Application Tags

Caché Applications Tags (CAT или теги приложений Caché) действуют подобно тегам HTML с той разницей, что вместо форматирования текста они исполняют функции на сервере данных Caché и/или в браузере. Таги приложений Caché используются для записи и считывания из базы данных, расчетов, организации циклов, регистрации, мульти-фреймовой координации и т.д. Дополнительное преимущество состоит в том, что набор стандартных CAT может быть расширен. Разработчики могут создавать теги самостоятельно для собственных приложений.

Гипер-события (Hyper-Events™)

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

Технология Гипер-событий (Hyper-Events) позволяет изменять содержимое страницы без ее перезагрузки, причем эти изменения будут оперировать данными, динамически получаемыми с сервера базы данных .
Подчеркиваем красным то, что особенно пугает.
Понимаем, что: если это не вебсервер самого кэша, то вся эта брехня - брехня втройне, особенно последний абзац - жирный и красный - будет почище лининских лозунгов "земля народу ..."

-- Tygra's --
...
Рейтинг: 0 / 0
04.05.2006, 13:45
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706927
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Стороник Cache могут показать живую страничку с ее кодом, с возможностями осмеяными Tygra's ?
...
Рейтинг: 0 / 0
04.05.2006, 13:59
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706931
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
Для tygra

Да.. написано так, что можно подумать всё что угодно.. это к переводчикам претензия.

Может вот эти пара фраз упростит понимание:
1. CSP страницы - это удобный способ для совмещения HTML разметки и кода COS. Можно говорить ( с некоторй условностью ) что формат CSP это ещё один "язык программирования", присутсвующий в Каше (помимо COS и BASIC)

2. CSP страницы компилируются и в результате получается только лишь код COS. После компиляции , можете их просто стереть, если они Вас смущают.

Вопрос:
- а что именно Вас смущает в жирном и последнем абзаце? Я не знаю о чём вы подумали, прочитав его, но то что там написано - правда....

Предложение:
- если вас действительно интересует Каше ( для практического применения ), приходите к нам на фирму http://www.escape.ru . Здесь, на месте сможете во всём разобраться.
...
Рейтинг: 0 / 0
04.05.2006, 13:59
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706933
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
IuraСтороник Cache могут показать живую страничку с ее кодом, с возможностями осмеяными Tygra's ?

Ну вот, например http://www.marcogroup.ch
...
Рейтинг: 0 / 0
04.05.2006, 14:01
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706936
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
IuraСтороник Cache могут показать живую страничку с ее кодом, с возможностями осмеяными Tygra's ?

А коды страничек Вы увидите, когда скачаете и установите Cache.
Там есть раздел с примерами.
...
Рейтинг: 0 / 0
04.05.2006, 14:02
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706940
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
yww@escape.ru IuraСтороник Cache могут показать живую страничку с ее кодом, с возможностями осмеяными Tygra's ?

Ну вот, например http://www.marcogroup.ch

На какую ссылку кликать, чтобы увидеть "эффект" динамической подгрузки и обновления части страницы ?
...
Рейтинг: 0 / 0
04.05.2006, 14:03
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706962
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
Iura yww@escape.ru IuraСтороник Cache могут показать живую страничку с ее кодом, с возможностями осмеяными Tygra's ?

Ну вот, например http://www.marcogroup.ch

На какую ссылку кликать, чтобы увидеть "эффект" динамической подгрузки и обновления части страницы ?

Ааа.. это Вы имеете в виду.. да, там эти фукции в открытом доступе не используются.. только для авторизованных пользователей..
Приходите к нам фирму ( если действительно имеете намерения реализовать свой проект ) - здесь Вам всё покажем.

Но, тем не менее, Вы увидите всё в примерах Каше... если установите его.
...
Рейтинг: 0 / 0
04.05.2006, 14:10
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706971
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
где-то ужа такое звучало - "при личной встрече я смогу убедить"
а вот это я точно помню - "Если бы сейчас была здесь дискуссия..."
...
Рейтинг: 0 / 0
04.05.2006, 14:12
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706982
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
Глупость сказал, уважаемый..
Мне не нужно Вас ни в чём убеждать..
Мне задают вопросы, я отвечаю.. причём так, как могу ответить в данной ситуации..

Удовлетворять Ваши потребности, только потому что Вам хочется - я не намерен. Так что - самоудовлетворяйтесь
...
Рейтинг: 0 / 0
04.05.2006, 14:14
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706988
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
и вот еще интересные цитаты
авторУникальная платформа интеграции и разработки приложений, объединяющая в себе функциональность сервера интеграции, сервера приложений, высокопроизводительную объектную базу данных и тесно интегрированную среду разработки и управления в виде единого надежного продукта, который позволяет быстро и эффективно выполнять интеграционные проекты любой сложности.

И пзвольте полюбопытсвовать - интеграцию чего с чем?
Или просто интеграцию ради интеграции?

Глупо не глупо, а прецендент был. Есть человек, который утверждает, что при личной встрече всех сможет убедить.
До сих пор ждет официального приглашения на уже закончившийся форум.
...
Рейтинг: 0 / 0
04.05.2006, 14:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706998
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Gluk (Kazan)про это то-же не забудьте
прочитал. и предыдущее тоже. знаешь, если требуется уж такая офигенная
закрученность, про которую они там талдычат, то надо или оставаться
на SQL, или уходить на свои структуры в Cache. совмещать, знаешь ли, надо
с умом. :) об этом я и говорю. а на простых запросах эмуляция Cache SQL
побыстрее и покомпатнее.

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 14:19
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33706999
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
Пьяный Лохправильно ли я понимаю, что "секрет каша" - это есть хранение данных непосредственно в индексе... ээээ.... как бы это сказать... без хранения их где-либо еще?
Sergei Obrastsov детально объяснил ст-ру хранения в каше. Но основная идея именно такая: данные либо в индексе, либо в данных. Это принципиальная разница с РБД где данные отдельно а индексы отдельно. РБД платит за гибкость и эффективность дисковой памятью (и это правильно !), а в каше любой запрос, не совпадающий со структурой индекса - это фулскан всего глобала. А перестроить индекс уже нельзя ! Приходится строить отдельные глобалы=вторичные индексы вручную с дублированием данных и весь выигрыш сразу пропадает.
...
Рейтинг: 0 / 0
04.05.2006, 14:19
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707003
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
о, нашел.
http://www.escape.ru/technologies/ensemble.html
ну посмотрим, когда gartner обратит внимание на сию передовую технологию - тема то модная, интеграция и управление бизнес процессами.
Только почему-то там игроки другие.
...
Рейтинг: 0 / 0
04.05.2006, 14:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707004
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
YWW

Подскажи русский сайт, где на примере создания базы данных c web сервером обучают Cache.
...
Рейтинг: 0 / 0
04.05.2006, 14:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707011
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
>>>Глупо не глупо, а прецендент был. Есть человек, который утверждает, что при личной встрече всех сможет убедить.

Я то тут причем? Это какой то другой человек.

Скачайте Каше да и попробуйте CSP. Что тут сложного то?

Или Вы стали на позицию "Я считаю что Каше - г...о! Попробуйте меня разубедить!" ?

Я не буду этого делать.
Но, если у Вас есть реальный проект, и Вы примеряете Каше для его реалицации, то можно разговаривать конструктивно. А для этого необходимо увидеть Вас в лицо. Приходите, приносите проект, разбирайтесь с сомнениями.. мы поможем.
...
Рейтинг: 0 / 0
04.05.2006, 14:23
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707016
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
lura
Да лукавство сплошное
Двумерные реляционные таблицы используют простую для понимания математическую модель, пригодную для достаточно простых приложений и запросов. Однако, в реальной ситуации представляемая в базе данных информация многомерна. Попытки обрабатывать такую информацию в реляционных СУБД неизбежно ведут к неудовлетворительной производительности.
Ну и что предлагается взамен? Вообще отказ от какой-либо модели и работать циклами на низком уровне.
Там даже индексов нету в обычном понимании - если надо еще дополнительный индекс по какому-то полю, то придётся паралельно делать еще одну структуру и модифицировать их параллельно.
Т.е. по рабочекрестьянски: если Вы к примеру на РСУБД сделали таблицу с англорусским словарём, то вы автоматически получили и русскоанглийский. В кэше вам придётся делать две структуры.
Хотя если нравится работать с циклами и вам достаточного одного индекса на таблицу - вполне возможно вам это и подойдёт
Если Вам нужно работать именно с массивами данных, нужны агрегатные функции и т.д. - то лучше не связываться с многомерной информацией

Ну и кстати - не думайте Вы пока про объём - когда Вы это реализуете и всё это промышленно заработает у любого ноутбута будет винчесте по 1000Г :)
...
Рейтинг: 0 / 0
04.05.2006, 14:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707021
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
IuraYWW
Подскажи русский сайт, где на примере создания базы данных c web сервером обучают Cache.

Я не знаю такого сайта..
...
Рейтинг: 0 / 0
04.05.2006, 14:25
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707034
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
странно. Единственный случай, когда действительно надо увидеть лицо, это когда его надо набить.
А о технологиях можно говорить и находясь на разных континентах.
Таки это наверное такая технология зомбирования, которая по nickname еще не работает.

А вот термин у вас вычитал странный - "координация данных" (http://www.intersystems.ru/ensemble/technology/solutions/solutions-ai.html)
Я не понял, что это?
Вроде я и не полный профан в вопросах интеграции...
Может, это тоже неудачный перевод?
...
Рейтинг: 0 / 0
04.05.2006, 14:27
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707074
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
мод Пьяный Лохправильно ли я понимаю, что "секрет каша" - это есть хранение данных непосредственно в индексе... ээээ.... как бы это сказать... без хранения их где-либо еще?
Sergei Obrastsov детально объяснил ст-ру хранения в каше. Но основная идея именно такая: данные либо в индексе, либо в данных.
нет, немного не так. данные там, где я их помещаю. можно только в индексах,
можно только в данных, можно и там, и там.

Пьяный Лох Это принципиальная разница с РБД где данные отдельно а индексы отдельно. РБД платит за гибкость и эффективность дисковой памятью (и это правильно !), а в каше любой запрос, не совпадающий со структурой индекса - это фулскан всего глобала. А перестроить индекс уже нельзя ! Приходится строить отдельные глобалы=вторичные индексы вручную с дублированием данных и весь выигрыш сразу пропадает.
когда я проектирую БД, я сразу предсматриваю весь спектр запросов к ней.
и на основе этого формирую массивы. если есть вариант нефиксированных
запросов, то я буду подстраивать структуру и под них. а уж как это будет
реализовываться на практике - дело техническое. это я к тому, что
ситуации "запрос, не совпадающий со структурой индекса" быть (при
нормальной работе программиста) просто не должно.

впрочем, да, бывают варианты, когда индексирование по определенному
полю просто невозможно. скажем, индексировать время по каждой секунде -
кхгм, неразумно. значит пользователь сам должен осознавать, что запрос
такого вида "time > 12:04 and (time < 12:15)" на неограниченном другими
условиями пространстве данных, будет идти достаточно долго, тут уж
ничего не поделаешь.

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 14:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707091
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Проблема не в том, что нет устройств, которые могут хранить большой объем информации. Проблема в том, что поиск в этом объеме будет значительным.

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


Как будет выглядеть таже схема на Cache ?
...
Рейтинг: 0 / 0
04.05.2006, 14:39
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707095
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Проблема не в том, что нет устройств, которые могут хранить большой объем информации. Проблема в том, что поиск в этом объеме будет значительным.

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


Как будет выглядеть таже схема на Cache ?
...
Рейтинг: 0 / 0
04.05.2006, 14:41
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707110
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
Sergei Obrastsovвыбор индексации объясняется критичностью этих полей для последующих выборок. дата, естественно, основной критерий, учитывая объем данных

То есть если со временем критичными будут другие поля то придется переделывать приложение???


так, закачали. размер файла cache.dat - 2.958 Gb
кстати, без доп.индексов размер файла - 1.155 Gb (это я так :) )

Возникает вопрос, сколько журналов транзакций тебе потребовалось для того чтобы залить эти данные?
...
Рейтинг: 0 / 0
04.05.2006, 14:43
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707140
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
FreemanZAVДля того, чтобы изменять содержимое страницы без ее перезагрузки Cache не нужен. Есть ajax например.
Что-то я не понял. До того, как эту фичу кто-то назвал ajax, ей никто не пользовался? Или с момента как кто-то дал фиче свое собственное название далее ее называть только так? И вы серьезно полагаете что асинхронными вызовами с транспортом в xml до этого никто не пользовался?

До чего странные бывают люди! Придумает кто-нибудь слово SOAP для того чем пользовались лет 5 и плевали на то как это кто-то назовет и все, теперь только soap. Придумали название xml-rpc, и все теперь все кто этим пользовался никак не называя должны переделывать все под новое название?
...
Рейтинг: 0 / 0
04.05.2006, 14:51
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707153
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
IuraЯ привожу в качестве примера схему свой базы данных. Она не полная, и скорее всего будет меняться. Но для обсуждения вопроса SQL или Cache думаю она подойдет. Повторяю - эта схема просто набросок. Ее правильность не обсуждается.
Как будет выглядеть таже схема на Cache ?
Если именно схема, то так же. :) Я имею в виду логику связей, конечно.
Как структура - надо подумать. Этой информации недостаточно.

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 14:53
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707178
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
tygra Технология Гипер-событий (Hyper-Events) позволяет изменять содержимое страницы без ее перезагрузки, причем эти изменения будут оперировать данными, динамически получаемыми с сервера базы данных .
Подчеркиваем красным то, что особенно пугает.
Понимаем, что: если это не вебсервер самого кэша, то вся эта брехня - брехня втройне, особенно последний абзац - жирный и красный - будет почище лининских лозунгов "земля народу ..."

-- Tygra's --

Обломись, тигра. Поведение страницы ограничено лишь фантазией программиста.

Introduction to Cache Server Pages
http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=GCSP_intro
Это начало учебных материалов

Tutorial
http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TWEB_Part1
Это начало простенького учебничка

Само учебное приложение
http://platinum.intersystems.com/csp/samples/cinema/cinema.csp

Вот в нем и используются гиперивенты.
<script language="JavaScript" src="/csp/broker/cspxmlhttp.js"></script>
<script language="JavaScript" src="/csp/broker/cspbroker.js"></script>
Это жаваскрипты от гиперивентов. Там где в html коде стоит
onClick="cspHttpServerMethod это вызов гиперивентов.

А что там с данными делать и как страницей рулить - ну, в принципе, как угодно можно.
...
Рейтинг: 0 / 0
04.05.2006, 14:56
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707236
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
Sergei Obrastsovкогда я проектирую БД, я сразу предсматриваю весь спектр запросов к ней.и на основе этого формирую массивы.
Вот в этом и есть основное отличие подходов ! РБД проектируется сама по себе, без оглядки на приложения. И это огромный шаг вперед. А на "правильной" структуре можно запустить много разных приложений и при желании подстроить структуру БД под новые приложения (перестроить индексы, ввести партиции, изменить размещение и пр.).
...
Рейтинг: 0 / 0
04.05.2006, 15:07
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707303
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Nikolay Kulikov
То есть если со временем критичными будут другие поля то придется переделывать приложение???

А почему они должны поменяться? В смысле критичности-то? Просто
потому, что так хочется тебе? Если бы такая возможность была, то
я бы структурировал базу с учетом этого. :)


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

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 15:21
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707349
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
ппмстранно. Единственный случай, когда действительно надо увидеть лицо, это когда его надо набить.
А о технологиях можно говорить и находясь на разных континентах.
Таки это наверное такая технология зомбирования, которая по nickname еще не работает.


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


ппмА вот термин у вас вычитал странный - "координация данных" (http://www.intersystems.ru/ensemble/technology/solutions/solutions-ai.html)
Я не понял, что это?
Вроде я и не полный профан в вопросах интеграции...
Может, это тоже неудачный перевод?

Этот термин относится не собственно к Cache, а к интеграционной платформе Ensemble, которая является вторым продуктом InterSystems http://www.intersystems.ru/ensemble/index.html

Ensemble написан на Cache.... это некоторый намёк для тех, кто сомневается что на Каше можно создавать серьёзные проекты. :))

В связи с тем что я лично не занимаюсь Ensemble, я не смогу дать исчерпывющий ответ.

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

Попробую пример изложить:
- допустим, что задача интеграции заключается в сборе сведений о клиенте, физически расположенных в разных прикладных системах (бухгалтерия. склад, CRM, ..) Так вот координация - это :
1. процес распознавания и извлечения этих вседений в среду интеграционной платформы
2. процесс внесения согласованных изменений в те самые прикладные системы..

Для доступа к данным используются адаптеры.. а вообще, почитайте лучше собственнолично :) http://www.intersystems.ru/ensemble/index.html .. я не хочу исказить что либо в данной теме.
...
Рейтинг: 0 / 0
04.05.2006, 15:33
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707381
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
мод Sergei Obrastsovкогда я проектирую БД, я сразу предсматриваю весь спектр запросов к ней.и на основе этого формирую массивы.
Вот в этом и есть основное отличие подходов ! РБД проектируется сама по себе, без оглядки на приложения. И это огромный шаг вперед. А на "правильной" структуре можно запустить много разных приложений и при желании подстроить структуру БД под новые приложения (перестроить индексы, ввести партиции, изменить размещение и пр.).
все правильно, "универсальность" - вещь хорошая. но есть и свои минусы.
объем навешиваемой на исходные данные технической информации, зачастую
превышающий объем оной и предел скорости доступа к данным.
только, умоляю, не надо рассуждать в стиле "а сделай-ка мне запрос вида 'select ...' и я тогда может быть и поверю". с какого перепугу эмулированный в интерпретаторе SQL будет в 6-8 раз быстрее заточенной
под это дело компилированной системы?!
M-подход - это специализированные БД. Разницу в размерности я уже
продемонстрировал. Насчет скорости доступа и обработки информации можем поговорить, ежели захочешь.

С уважением. Сергей

P.S. Сколько всего можно сделать ножом, а вот для хирургических
операций скальпель лучше подходит. Но колбасу им резать неудобно, правда? Может и не стоит? :)
...
Рейтинг: 0 / 0
04.05.2006, 15:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707388
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
для Iura

Вот, очень кстати, выше приведен адресочек странички с теми самыми возможностями изменения части страницы..
http://platinum.intersystems.com/csp/samples/cinema/cinema.csp
...
Рейтинг: 0 / 0
04.05.2006, 15:40
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707415
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Читаю http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=GSTD_Intro

На сколько ООП Oracle уступает ООП Cache ?
...
Рейтинг: 0 / 0
04.05.2006, 15:45
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707421
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
yww@escape.ruдля Iura

Вот, очень кстати, выше приведен адресочек странички с теми самыми возможностями изменения части страницы..
http://platinum.intersystems.com/csp/samples/cinema/cinema.csp

Круто
...
Рейтинг: 0 / 0
04.05.2006, 15:46
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707439
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
2Sergei Obrastsov: то есть ты хочешь сказать что функциональность твоего приложения с течением времени неизменна, ничего не добавляется приоритеты у бизнеса не меняются?
...
Рейтинг: 0 / 0
04.05.2006, 15:49
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707452
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
В чем причина, что Cache менее популярен чем другие продукты?
...
Рейтинг: 0 / 0
04.05.2006, 15:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707453
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
IuraКруто

Ну что круто то? Там просто пример небольшой. на деле то это гораздо красивее получается..

Ладно , прямой вопрос:
- пилот будем делать?

Если да, то давайте его обсуждать..
Если нет, тогда я про вас забываю
...
Рейтинг: 0 / 0
04.05.2006, 15:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707459
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
yww@escape.ru IuraКруто

Ну что круто то? Там просто пример небольшой. на деле то это гораздо красивее получается..

Ладно , прямой вопрос:
- пилот будем делать?

Если да, то давайте его обсуждать..
Если нет, тогда я про вас забываю

Что значит создавать пилот?
Вы хотите тоже участвовать в создании проект Translation Memory?
...
Рейтинг: 0 / 0
04.05.2006, 15:54
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707497
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
Iura
Что значит создавать пилот?
Вы хотите тоже участвовать в создании проект Translation Memory?

Я не знаю что такое Translation Memory... но понял, это среда для работы переводчиков.

Возможно я ошибся в оценке ситуации.. проверьте, пожалуйста..

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

Моё предложение следующее:
- при условии, что в дальнейшем предполагается заключение договора, я предлагаю рассмотреть возможность решения вашей задачи (в том числе и снять сомнения) путём разработки пилотного проекта силами нашей фирмы.
...
Рейтинг: 0 / 0
04.05.2006, 16:03
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707508
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
IuraПроблема не в том, что нет устройств, которые могут хранить большой объем информации. Проблема в том, что поиск в этом объеме будет значительным.

Вовсе нет, обычно проигрываем в объёме - выигрываем во времени. И вообще при правильно спроектированной системе время поиска пропорционально логарифму размера

В любом случае: объём это тот критерий который надо рассматривать в последнюю очередь.
...
Рейтинг: 0 / 0
04.05.2006, 16:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707513
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
yww@escape.ru
Моё предложение следующее:
- при условии, что в дальнейшем предполагается заключение договора, я предлагаю рассмотреть возможность решения вашей задачи (в том числе и снять сомнения) путём разработки пилотного проекта силами нашей фирмы.

Об этом мне пока рано говорить. Я хочу пока сам создать пилотный проект, чтобы оценить все возможные траблы. В добавок, я частное лицо и не могу финансировать пока проект.
...
Рейтинг: 0 / 0
04.05.2006, 16:08
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707531
FreemanZAV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FreemanZAV
Участник
ну яЧто-то я не понял. До того, как эту фичу кто-то назвал ajax, ей никто не пользовался? Или с момента как кто-то дал фиче свое собственное название далее ее называть только так? И вы серьезно полагаете что асинхронными вызовами с транспортом в xml до этого никто не пользовался?

До чего странные бывают люди! Придумает кто-нибудь слово SOAP для того чем пользовались лет 5 и плевали на то как это кто-то назовет и все, теперь только soap. Придумали название xml-rpc, и все теперь все кто этим пользовался никак не называя должны переделывать все под новое название?
Афигеть фантазия. Яж про эту технологию только три слова сказал
FreemanZAV Есть ajax например
В этих словах нет моего мнения о том кто и когда этим пользовался, как эту фичу называть, и плевков на что либо и куда либо.
...
Рейтинг: 0 / 0
04.05.2006, 16:12
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707535
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
Iura yww@escape.ru
Моё предложение следующее:
- при условии, что в дальнейшем предполагается заключение договора, я предлагаю рассмотреть возможность решения вашей задачи (в том числе и снять сомнения) путём разработки пилотного проекта силами нашей фирмы.

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

Ну, ладно, тогда... желаю Вам творческих успехов .
...
Рейтинг: 0 / 0
04.05.2006, 16:13
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707594
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Ну и что предлагается взамен? Вообще отказ от какой-либо модели и работать циклами на низком уровне.
Там даже индексов нету в обычном понимании - если надо еще дополнительный индекс по какому-то полю, то придётся паралельно делать еще одну структуру и модифицировать их параллельно.

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

свобода пугает, правда? как и необходимость делать что-то самому, вместо
заботливой няни в лице MS SQL, Oracle и иже с ними. что тут скажешь?
можешь налепить таких же таблиц. :)


Т.е. по рабочекрестьянски: если Вы к примеру на РСУБД сделали таблицу с англорусским словарём, то вы автоматически получили и русскоанглийский. В кэше вам придётся делать две структуры.

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


Хотя если нравится работать с циклами и вам достаточного одного индекса на таблицу - вполне возможно вам это и подойдёт

тебя кто-то ограничивает количеством индексов? что-то я такого не заметил.

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


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

правильно. "Не ходите, дети, в Африку гулять!"


Ну и кстати - не думайте Вы пока про объём - когда Вы это реализуете и всё это промышленно заработает у любого ноутбута будет винчесте по 1000Г :)
я все ждал, когда же мне выдвинут такой аргумент. ура, дождался.
ну что ж, к этому все и идет. ну а я выдвину свой:

а ведь никого и не заставляют, правда?

Пока. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 16:26
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707603
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Nikolay Kulikov2Sergei Obrastsov: то есть ты хочешь сказать что функциональность твоего приложения с течением времени неизменна, ничего не добавляется приоритеты у бизнеса не меняются?
странный вопрос. пока станцию не сменят, информация, которую она
выдает, не изменится. так с какой радости изменятся критерии ее оценки?

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 16:30
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707618
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
FreemanZAV ну яЧто-то я не понял.
Афигеть фантазия. Яж про эту технологию только три слова сказал

Сорри, вырвалось. Ничего личного.
...
Рейтинг: 0 / 0
04.05.2006, 16:34
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707623
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
IuraВ чем причина, что Cache менее популярен чем другие продукты?
ты все еще хочешь узнать ответ на этот вопрос? :)

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 16:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707654
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Sergei Obrastsov IuraВ чем причина, что Cache менее популярен чем другие продукты?
ты все еще хочешь узнать ответ на этот вопрос? :)

С уважением. Сергей

Да! Только конкретно!
...
Рейтинг: 0 / 0
04.05.2006, 16:42
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707667
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
Популяризация продукта - это часть бизнес-модели компании и / или ее партнеров. Можно с ней, можно без нее, это зависит от выбранной компаниями модели бизнеса. К самому продукту это мало относится.

Если яйца продаются без рекламы, зачем их рекламировать?
...
Рейтинг: 0 / 0
04.05.2006, 16:47
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707685
цццццццццц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
цццццццццц
Гость
ну яПопуляризация продукта - это часть бизнес-модели компании и / или ее партнеров. Можно с ней, можно без нее, это зависит от выбранной компаниями модели бизнеса. К самому продукту это мало относится.

Если яйца продаются без рекламы, зачем их рекламировать?
Т.е. Cache - продается как яйца?
...
Рейтинг: 0 / 0
04.05.2006, 16:53
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707699
ужжжас
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ужжжас
Гость
Яйца не продаются..!!
Эт - святое!!
...
Рейтинг: 0 / 0
04.05.2006, 16:57
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707711
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Iura Sergei Obrastsov[quot Iura]В чем причина, что Cache менее популярен чем другие продукты?
ты все еще хочешь узнать ответ на этот вопрос? :)

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

в Cache решили, что это дело надо поправить и насовали все, что
смогли насовать. теперь тут и объекты, и эмуляция SQL, и CSP, и Java,
и Basic, и прочая, прочая... может оно и правильно, может и давно надо
было. только вот я никак не могу отделаться от мысли, что мы уж так
хотим угодить всем сразу. как старая шлюха... обидно, ага. :)

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

С уважением. Сергей
...
Рейтинг: 0 / 0
04.05.2006, 17:00
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707725
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Sergei Obrastsov Iura Sergei Obrastsov[quot Iura]В чем причина, что Cache менее популярен чем другие продукты?
ты все еще хочешь узнать ответ на этот вопрос? :)

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

в Cache решили, что это дело надо поправить и насовали все, что
смогли насовать. теперь тут и объекты, и эмуляция SQL, и CSP, и Java,
и Basic, и прочая, прочая... может оно и правильно, может и давно надо
было. только вот я никак не могу отделаться от мысли, что мы уж так
хотим угодить всем сразу. как старая шлюха... обидно, ага. :)

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

С уважением. Сергей

Сергей
Какие 3 крупных проекта в мире сделано на Cache ?
Какова его доля на рынке по отношению MySQL, Oracle, MSSQL ?
...
Рейтинг: 0 / 0
04.05.2006, 17:03
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707729
ппм
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ппм
Гость
я уже как-то спросил - чем каше лучше того же BerkeleyDB, который дает еще большую гибкость?
И что интересно - это востребовано!
Куча продуктов, включая коммерческие, используют BerkeleyDB для хранения данных.
Перечилсять не буду.
Но очень просто выяснить, что эта куча больше, чум куча, в которой используется М подобные вещи.
Свобода - так неограниченная.
...
Рейтинг: 0 / 0
04.05.2006, 17:05
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707746
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
цццццццццц ну яПопуляризация продукта - это часть бизнес-модели компании и / или ее партнеров. Можно с ней, можно без нее, это зависит от выбранной компаниями модели бизнеса. К самому продукту это мало относится.

Если яйца продаются без рекламы, зачем их рекламировать?
Т.е. Cache - продается как яйца?
Не вижу разницы. Те кто знает зачем нужны яйца, те идут и покупают яйца. Так же и с каше - если кто знает зачем оно нужно, те берут. А если берут, зачем рекламировать?
...
Рейтинг: 0 / 0
04.05.2006, 17:11
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707770
цццццццццц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
цццццццццц
Гость
ну я цццццццццц ну яПопуляризация продукта - это часть бизнес-модели компании и / или ее партнеров. Можно с ней, можно без нее, это зависит от выбранной компаниями модели бизнеса. К самому продукту это мало относится.

Если яйца продаются без рекламы, зачем их рекламировать?
Т.е. Cache - продается как яйца?
Не вижу разницы. Те кто знает зачем нужны яйца, те идут и покупают яйца. Так же и с каше - если кто знает зачем оно нужно, те берут. А если берут, зачем рекламировать?
Демагогия чистой воды.... Так можно про что угодно сказать: "кто знает зачем нужно, тот берет". Никогда не покупали что-нибудь ненужное (или хотя бы не знаете таких людей, которые покупают ненужное) и всегда находили, то что нужно? А если кто не знает, то пусть и дальше не знает?
...
Рейтинг: 0 / 0
04.05.2006, 17:18
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707794
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
ну я tygra Технология Гипер-событий (Hyper-Events) позволяет изменять содержимое страницы без ее перезагрузки, причем эти изменения будут оперировать данными, динамически получаемыми с сервера базы данных .
Подчеркиваем красным то, что особенно пугает.
Понимаем, что: если это не вебсервер самого кэша, то вся эта брехня - брехня втройне, особенно последний абзац - жирный и красный - будет почище лининских лозунгов "земля народу ..."

-- Tygra's --

Обломись, тигра. Поведение страницы ограничено лишь фантазией программиста.
......

Вот в нем и используются гиперивенты.
<script language="JavaScript" src="/csp/broker/cspxmlhttp.js"></script>
<script language="JavaScript" src="/csp/broker/cspbroker.js"></script>
Это жаваскрипты от гиперивентов. Там где в html коде стоит
onClick="cspHttpServerMethod это вызов гиперивентов.

А что там с данными делать и как страницей рулить - ну, в принципе, как угодно можно.
Итить....!!!!
И где тут Кэш? Неужели дернуть xml из джаваскрипта можно только если данные будут из Кэша браться???!!!
Ахренеть!!! Может разработчики Кэша и сам джаваскрипт придумали, и xml? И вебсервер они?

А если я буду делать все тоже самое, но страницы будут asp.net и дергать я буду MS SQL - работать наверное не будет, так? Или назвать супер-гипер-пупер-эвенты - и тогда наверное заработает?


-- Tygra's --
...
Рейтинг: 0 / 0
04.05.2006, 17:22
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33707888
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
tygra ну я tygra Технология Гипер-событий (Hyper-Events) позволяет изменять содержимое страницы без ее перезагрузки, причем эти изменения будут оперировать данными, динамически получаемыми с сервера базы данных .
Подчеркиваем красным то, что особенно пугает.
Понимаем, что: если это не вебсервер самого кэша, то вся эта брехня - брехня втройне, особенно последний абзац - жирный и красный - будет почище лининских лозунгов "земля народу ..."

-- Tygra's --

Обломись, тигра. Поведение страницы ограничено лишь фантазией программиста.
......

Вот в нем и используются гиперивенты.
<script language="JavaScript" src="/csp/broker/cspxmlhttp.js"></script>
<script language="JavaScript" src="/csp/broker/cspbroker.js"></script>
Это жаваскрипты от гиперивентов. Там где в html коде стоит
onClick="cspHttpServerMethod это вызов гиперивентов.

А что там с данными делать и как страницей рулить - ну, в принципе, как угодно можно.
Итить....!!!!
И где тут Кэш? Неужели дернуть xml из джаваскрипта можно только если данные будут из Кэша браться???!!!
Ахренеть!!! Может разработчики Кэша и сам джаваскрипт придумали, и xml? И вебсервер они?

А если я буду делать все тоже самое, но страницы будут asp.net и дергать я буду MS SQL - работать наверное не будет, так? Или назвать супер-гипер-пупер-эвенты - и тогда наверное заработает?


-- Tygra's --
Не вижу логической связи между первым посылом и выводом. Какие-то пропущенные мысли?
...
Рейтинг: 0 / 0
04.05.2006, 17:40
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708006
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
>>>И где тут Кэш? Неужели дернуть xml из джаваскрипта можно только если данные будут из Кэша браться???!!!

Роль Каше заключается лишь в том, что программисту не нужно самому что-то писать на javascript для того что бы дёрнуть данные с сервера.. тексты необходимых вызовов, будут созданы во время компиляции страницы и (ессно) вставлены в поток HTML.

А вообще то, вопросы какие то чуднЫе Вы задаёте..
...
Рейтинг: 0 / 0
04.05.2006, 18:10
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708023
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
У вас еще и логика хромает? :)

Ну на пальцах тогда
В маркетинговом материале было заявлено в таком духе: товарищи, только Кэш умеет обрабатывать тэги в вебстранице и уж точно только Кэш умеет делать веб-страницы с обновлением данных без перезагрузки - и даже у Кэш есть название этому, гиперэвенты!!!
Из чего вывод: никто больше так не умеет, а если и умеет, то криво и вообще не так, а потому Кэш не только супер БД, которая в 3 раза круче всех, а еще и веб-портал!

Далее было представлено аж несколько ссылок на сие чудо - там были html-странички, что конечно никто более делать не может!!!

Далее на вопрос - это веб-сервер в Кэше встроен, что такие штуки умеет или просто понты :) - типа непонимание вопроса, уход в несознанку и вообще отсутствие логики :))

=========

Получилось объяснить или как?
Или Кэш настолько осчатсливил некоторых людей, что они кроме "одобрямс" больше ничего не слышат и не понимают? :)

-- Tygra's --
...
Рейтинг: 0 / 0
04.05.2006, 18:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708044
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Предыдущее ответ для ну я

yww@escape.ru Роль Каше заключается лишь в том, что программисту не нужно самому что-то писать на javascript для того что бы дёрнуть данные с сервера.. тексты необходимых вызовов, будут созданы во время компиляции страницы и (ессно) вставлены в поток HTML.

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

Кстати, при компиляции страницы - при чем тут Кэш? Можно сделать кучу компонентов на asp.net, которые будут вставлять в страницу чего хошь независимо ни от чего - Кэш, Оракл, dbf...
Т.е. русским языком, СУБД тут ни при чем, совершенно :)

-- Tygra's --
...
Рейтинг: 0 / 0
04.05.2006, 18:23
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708145
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Sergei Obrastsov
надоели мне эти страдания про "циклы". обожаемые тобой РСУБД читают
все даные за один раз, правда? ах, в запросах нет слова "цикл", значит
никаких циклов и нет? это откровение, я запомню.

я все ждал, когда же мне выдвинут такой аргумент. ура, дождался.
ну что ж, к этому все и идет. ну а я выдвину свой:

а ведь никого и не заставляют, правда?

Пока. СергейДа будет откровение:
дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном).

в М-системах, как я понял, хорошо работают запросы работающие в соответствии с деревом объектов.
если запрос не попадает (не соответствует) дереву, то требуется полный-скан или ЗАРАНЕЕ построенное дерево (т.е. нужно поддерживать 2 или n деревьев для быстрой работы на различных запросах)
...
Рейтинг: 0 / 0
04.05.2006, 19:00
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708283
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
tygraКонечно чудные - в листовках указано, что только с Кэш вы можете это сделать и еще много бла-бла, а многие люди в это верят и думают, что так и есть, что кроме Кэша то никто это делать не умеет, и того же Аякса нет в природе и т.д. и т.п.

Я понял. Аякс есть. Ты (или Вы) приписали лишнее слово. Но это уже самовнушение. Нет там слова "только". А что касается аякса - так ему без году неделя, а csp работает уже сколько лет. Поясню - для кашистов просто странно слышать про аякс как про нечто новое. Дело не в том, лучше это или хуже, а в том что сильно ломает кидаться на альтернативы если они не дают ничего нового. А переплюнуть возможности csp (это сокращение от cache server pages) будет тяжеловато.

tygraКстати, при компиляции страницы - при чем тут Кэш? Можно сделать кучу компонентов на asp.net, которые будут вставлять в страницу чего хошь независимо ни от чего - Кэш, Оракл, dbf...
Т.е. русским языком, СУБД тут ни при чем, совершенно :)

-- Tygra's --
Гыыы. :-)))
Ну, это старый вопрос. Что там считать сервером СУБД а что сервером приложений. Кашистам также странно прикручивать к каше еще какие-то хреновины, дотнет, дотда или какие там еще появятся. А СУБД тут действительно ни при чем, кашевый движок необязательно использовать как СУБД. У нас например в отдельных случаях каше запускается также для того чтобы отработать поставленные на событие старта сервера запуски других хреновин. Ломало просто настраивать штатные утили операционки и разбираться в нюансах батников или других языков.
...
Рейтинг: 0 / 0
04.05.2006, 20:14
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708382
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
ну я tygraКонечно чудные - в листовках указано, что только с Кэш вы можете это сделать и еще много бла-бла, а многие люди в это верят и думают, что так и есть, что кроме Кэша то никто это делать не умеет, и того же Аякса нет в природе и т.д. и т.п.

Я понял. Аякс есть. Ты (или Вы) приписали лишнее слово. Но это уже самовнушение. Нет там слова "только".

Слова "только" нет, но смысл такой есть:
Один из основных недостатков традиционных средств разработки Web-приложений - необходимость перезагрузки всей страницы, если нужно измененить содержимое ее части. JavaScript, Объектная модель документа и Динамический HTML решают эту проблему, но только отчасти . Они позволяют изменять содержимое страницы динамически, но не избавляют от необходимости полной перезагрузки страницы в случае, когда необходимо отобразить в браузере данные из СУБД.
...
Рейтинг: 0 / 0
04.05.2006, 20:56
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708462
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
ну я
Популяризация продукта - это часть бизнес-модели компании и / или ее партнеров. Можно с ней, можно без нее, это зависит от выбранной компаниями модели бизнеса.
К самому продукту это мало относится.

Т.е. Оракл и Скуль зря парятся со своими продуктами, ночами не спят? Впендюривают в продукты все самое передовое. А можно было просто заниматься бизнес-моделью компании?
Все-таки иногда имеет значение и сам продукт.

Iura
Какова его доля на рынке по отношению MySQL, Oracle, MSSQL ?

В прошлом году доля на рынке прримерно: 37% - DB2, 36% - Оракл, 20% - MSSQL. Остальное на всех остальных. Но среди них есть Сибэйс. Вот и считайте.
Вообще не понятно почему Вы рядом с Oracle, MSSQL ставите MSSQL и КЭШ.
Обычно рядом красуются DB2, Сибэс и от ООСУБД Версант, Гемстоун, Онтос.
А у вас какая-то пестрая компания получается.
...
Рейтинг: 0 / 0
04.05.2006, 21:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708528
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
SergSuperСлова "только" нет, но смысл такой есть:
Один из основных недостатков традиционных средств разработки Web-приложений - необходимость перезагрузки всей страницы, если нужно измененить содержимое ее части. JavaScript, Объектная модель документа и Динамический HTML решают эту проблему, но только отчасти . Они позволяют изменять содержимое страницы динамически, но не избавляют от необходимости полной перезагрузки страницы в случае, когда необходимо отобразить в браузере данные из СУБД.
Согласен, тут они лажанули. Гонят. Особенно в выделенном жирным. И к серверу это никак не относится.
...
Рейтинг: 0 / 0
04.05.2006, 22:41
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708532
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
vadiminfo ну я
Популяризация продукта - это часть бизнес-модели компании и / или ее партнеров. Можно с ней, можно без нее, это зависит от выбранной компаниями модели бизнеса.
К самому продукту это мало относится.

Т.е. Оракл и Скуль зря парятся со своими продуктами, ночами не спят? Впендюривают в продукты все самое передовое. А можно было просто заниматься бизнес-моделью компании?
Все-таки иногда имеет значение и сам продукт.
Опа. Опять передовое и опять парятся? Да ладно вам, они же уже сделали поддержку sql, что же еще серверу СУБД (по понятиям Майкрософт и Оракл) нужно? Или есть, оказывается, сервера попередовее, которым SQL недостаточно? А про самое передовое (гыыы, ну понравилось слово) они каждый год твердят, и каждый год у них опять новости. Ну или каждые два. Пройдет год и они опять скажут что все это было фигня, вот вам настоящее передовое. Что-то нет желания им верить.

А бизнес-моделью они занимаются, и очень хорошо, это вы зря так их подозреваете. За такой функционал берут такие бабки что обзавидоваться можно. Вот как раз с бизнесом у них все в порядке. А продукт? А что продукт, ну возьмите к примеру тот же mssql. Мощь Майкрософт совершенно несравнима с Интерсистемс. Небольшой функционал у крупнейшей корпорации и сильный функционал у маленькой, по-моему, как раз показывают кто занимается продуктом, а кто бизнесом.
...
Рейтинг: 0 / 0
04.05.2006, 22:44
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708576
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
ну я
Да ладно вам, они же уже сделали поддержку sql, что же еще серверу СУБД (по понятиям Майкрософт и Оракл) нужно?

Ну поддержка sql поддержке sql - рознь. Например, аналитические ф-ии или там иерархические или рекурсивные запросы. Несколько типов таблов. ООП - ОРСУБД. Посмотрите хотя бы на объемы последних стандартов SQL.
Кроме поддержки SQL нужно еще там всякое разное. Модели транзакций, восстановление. Распределенные БД, всякик фичи. ОЛАПы, Датаминги. Про XML, Джавы, сишарпы, Корбы, EJB я не гавару. Всякие шифрования, алгоритмы оптимизации запросов. У Оракла, к примеру, 10 версия содержит заявку на новую технологию - Грид. Наверное, што-то передовое. Пока не в курсе. Доки более чем на 10 000 старниц. А Вы говорите, что нужно по понятиям Майкрософт и Оракл? Все передовое нужно в технологиях БД. Иначе продукт проиграет конкуренту, несмотря на бизнес-модель компании.
Они скорее всего купили бы КЭШа или что стоящего у него есть, если бы нашли там таковое.

ну я
А что продукт, ну возьмите к примеру тот же mssql. Мощь Майкрософт совершенно несравнима с Интерсистемс. Небольшой функционал у крупнейшей корпорации и сильный функционал у маленькой, по-моему, как раз показывают кто занимается продуктом, а кто бизнесом.

Мощь Майкрософт совершенно несравнима с Интерсистемс. Если это в пользу Майкрософт, то это распространенное мнение и потому и не сравнивают их.
А вот то, что Вы говорите все еще звучит сенсационно.
В общей литературе про БД Кеша не встречал. А здесь на форуме за все время что известно? Он на М. В каком смысле? Скуль и все лидирующие СУБД и не тока лидирующие как и положено системному программному обеспечению на С. Или Кэш тоже на С? Тада М там в каком качестве упоминается?
Долго вообще не могли сказать к какому типу СУБД он относится. Говорили ООСУБД. Но ООСУБДшники от Версанта здесь его таковым не признали.
ОРСУБД он? Или иерахичекий с некоторой подержкой ООП?
Теперь тут была ссылка он РСУБД и Объектная и Многомерная там модель (типа ОЛАП поддерживает?). Как РСУБД он вряд ли Майкрософт превзойдет. Или превзойдет? Как многомерный? Олап у Майкрософт есть, хотя может и как отдельный сервер. Но, возможно, даже лидирует на рынке. Как объектный? Но сеня рано про успешность объектных БД говорить. Они типа еще в процессе становления, если вообще реально встанут. Здесь, наверное, как бы те кто похитрей выжидают, чтобы лучшее потом втюхать себе.
Так что про превосходство мощи Кэша над Майкрософт пока трудно представить даже что Вы имеете ввиду.
...
Рейтинг: 0 / 0
04.05.2006, 23:47
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708675
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
IuraКакие 3 крупных проекта в мире сделано на Cache ?
Какова его доля на рынке по отношению MySQL, Oracle, MSSQL ?
я что, похож на рекламного агента? :) на www.intersystems.ru тебе
напоют намного больше и лучше. тебе что нужно-то "шашечки или ехать"? :)
С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 03:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708676
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
VoDAДа будет откровение:
дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном).

я тебя правильно понял? то есть даже после моего намека предыдущему
оппоненту ты утверждаешь, что "циклов нет"? :)


в М-системах, как я понял, хорошо работают запросы работающие в соответствии с деревом объектов.
если запрос не попадает (не соответствует) дереву, то требуется полный-скан или ЗАРАНЕЕ построенное дерево (т.е. нужно поддерживать 2 или n деревьев для быстрой работы на различных запросах)
народ, надо все-таки внимательнее читать, ага. который раз повторяю, что
в M-системах нет фиксированных моделей структур. как и языка запросов
к ним. все что нужно программисту - он делает самостоятельно. как он
сформирует интерфейс между пользователем и БД, как спроектирует саму
БД - так все это дело и будет работать.

теперь о деревьях. в принципе, "реляционные модели" - тоже деревья.
только двухуровневые. поэтому не надо ахать "ой, 2 или n деревьев",
в РСУБД та же фигня. :)

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 03:50
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33708974
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Опять не понимаю, почему тогда не BerkeleyDB - там тоже программист делает все самостоятельно!
И не обязан работать на птичьих языках с дурацкой нотацией!
Получается, что если BerkeleyDB добавить хороший инструмент (а M системы без "хорошего инструмента" не очень-то и нужны, как нам пояснили) - то спрашивается, нафик нам М системы за такие бабки, которые просят за кашэ???
А инструментов специализированных для BerkeleyDB есть, да и наделать по потребности можно, да и на разных языках.
Прелесть просто, неограниченная свобода!
Любую модель данных!
Таблицы - да не проблема!
Деревья - легко!
Сетевую - влет!
Вывод - соотношение цена/свобода просто замечательное!
...
Рейтинг: 0 / 0
05.05.2006, 09:56
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709005
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
ну я SergSuperСлова "только" нет, но смысл такой есть:
Один из основных недостатков традиционных средств разработки Web-приложений - необходимость перезагрузки всей страницы, если нужно измененить содержимое ее части. JavaScript, Объектная модель документа и Динамический HTML решают эту проблему, но только отчасти . Они позволяют изменять содержимое страницы динамически, но не избавляют от необходимости полной перезагрузки страницы в случае, когда необходимо отобразить в браузере данные из СУБД.
Согласен, тут они лажанули. Гонят. Особенно в выделенном жирным. И к серверу это никак не относится.
Ну как же не относится?
Вот абзац оттуда же
авторДля разработки Web-приложений в Caché используется технология серверных страниц, т.е. создаются специальные страницы, которые заполняются данными немедленно ("on-the-fly"), как только они запрашиваются браузером. Отличие серверных страниц Caché (Caché Server Pages) от других технологий разработки Web-приложений состоит в том, что они хранятся на сервере данных Caché, так сказать, рядом с используемыми данными.
Т.е. явно говорится, что без Кэша это все гроша ломаного не стоит.

авторЯ понял. Аякс есть. Ты (или Вы) приписали лишнее слово. Но это уже самовнушение. Нет там слова "только". А что касается аякса - так ему без году неделя, а csp работает уже сколько лет.
Сколько работает csp - никто не знает. Никто вообще не слышал об этом чуде.
авторПоясню - для кашистов просто странно слышать про аякс как про нечто новое. Дело не в том, лучше это или хуже, а в том что сильно ломает кидаться на альтернативы если они не дают ничего нового. А переплюнуть возможности csp (это сокращение от cache server pages) будет тяжеловато.
А для не-кашистов - слышать вообще про кэш и csp это что-то новое и переплюнуть csp тяжело, потому что никто их не видел. И, как вы и сказали, сильно ломает кидаться на альтернативы если они не дают ничего нового
Или это такая навороченная программа распротсранения продукта - чтобы никто ничего не знал, а кто как-то узнает, тот и купит может быть :) Программа удачная надо сказать - мало кто слышал про Кэш вообще а про csp уж вообще никто наверное, кроме нескольких человек :)

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

======
Еще вернемся к маркетинговым материалам - добьем собачку :)
авторВ основе Caché лежит транзакционная многомерная модель данных (TMDMTM), которая позволяет хранить и представлять данные так, как они чаще всего используются. TMDM снимает все ограничения, накладываемые двумерными реляционными моделями данных, ведь если реляционная модель состоит из большого количества таблиц, что необходимо при работе со сложными структурами данных, это существенно усложняет и замедляет выполнение сложных транзакций и ведет к хранению излишней информации.
Огласите весь список пожалста того, что выделено красным - а то я работаю и не знаю, что можно еще во-много раз быстрее и проще и что щастте где-то рядом :)
Если конечно кто знает, о чем говорится

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

Пример.
Есть Клиент, Заказ, Адрес, Товары вообще, Товары заказа.
Если я храню это все в отдельных пяти таблицах - это плохо
Если я храню это в пяти объектах Кэша - это хорошо.
Вопрос - чем это хорошо?
И еще вопрос - найти клиентов у которых заказы имеют такие-то товары мне раз плюнуть.
Как это делать в Кэшэ? Придется строить обратные индексы?

=======

Весело тут у нас :)

-- Tygra's --
...
Рейтинг: 0 / 0
05.05.2006, 10:04
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709019
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Sergei Obrastsov VoDAДа будет откровение:
дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном).

я тебя правильно понял? то есть даже после моего намека предыдущему
оппоненту ты утверждаешь, что "циклов нет"? :)


НАМЕК: Помимо Nested Loops есть еще много интересных и полезных способов выполнения join. Да даже если по одной таблице, могу навскидку назвать 3 прынцыпивльно разных методов доступа
...
Рейтинг: 0 / 0
05.05.2006, 10:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709120
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
ggvОпять не понимаю, почему тогда не BerkeleyDB - там тоже программист делает все самостоятельно!
И не обязан работать на птичьих языках с дурацкой нотацией!
Получается, что если BerkeleyDB добавить хороший инструмент (а M системы без "хорошего инструмента" не очень-то и нужны, как нам пояснили) - то спрашивается, нафик нам М системы за такие бабки, которые просят за кашэ???
А инструментов специализированных для BerkeleyDB есть, да и наделать по потребности можно, да и на разных языках.
Прелесть просто, неограниченная свобода!
Любую модель данных!
Таблицы - да не проблема!
Деревья - легко!
Сетевую - влет!
Вывод - соотношение цена/свобода просто замечательное!

хотелось бы из чисто маркетных соображений
сделать вариант нашего МХ еще на чем нибудь
кроме мумпса - например на BerkeleyDB

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

в ячейку много не запихнешь - лучше не вылезать за 255 знаков
мумпс как раз подходит - компактный
он кроме того - интерпретатор и очень быстрый
все работает красиво и просто
НО
минус - дороговато за лицензии MSM-CACHE
(на бесплатном GTM-мумпсе работа только через линукс
а бесплатный М3-мумпс - медленнее чем CACHE-MSM)

Как Вы считаете - подойдет ли BerkeleyDB ?
можно ли его разложить по ячейкам ексцел ?

Спасибо
=====================
...
Рейтинг: 0 / 0
05.05.2006, 10:30
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709169
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
tygra
Сколько работает csp - никто не знает. Никто вообще не слышал об этом чуде.
Опять же смотря где. ;-))) Это вопрос распространенности и известности технологии. Где-то известна, где-то нет. Ничуть не сомневаюсь, что например в вашей конторе много лет используется какая-нибудь технология, о которой в нашей конторе никто даже названия не слышал. А с csp я работал, помнится, еще в 99-м.
...
Рейтинг: 0 / 0
05.05.2006, 10:36
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709182
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Gluk (Kazan) Sergei Obrastsov VoDAДа будет откровение:
дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном).

я тебя правильно понял? то есть даже после моего намека предыдущему
оппоненту ты утверждаешь, что "циклов нет"? :)


НАМЕК: Помимо Nested Loops есть еще много интересных и полезных способов выполнения join. Да даже если по одной таблице, могу навскидку назвать 3 прынцыпивльно разных методов доступа
забавно. "а он все не понимает и не понимает..." :)
ну хорошо:

шаг № 1:
я убираю все циклы по БД в программы

шаг № 2:
теперь запрос выглядит так:
Код: plaintext
1.
     s Result = $$Select^server(x1,x2...)

шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 10:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709244
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
ggvОпять не понимаю, почему тогда не BerkeleyDB - там тоже программист делает все самостоятельно!


Вот по этой ссылочке есть критика Каше ..
http://www.dimas.ru/ic/ic084.htm
и в том числе про BerkeleyDB упоминается..
...
Рейтинг: 0 / 0
05.05.2006, 10:47
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709255
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
>>Т.е. явно говорится, что без Кэша это все гроша ломаного не стоит.

Вы совершенно правы - CSP (Cache Servers Pages) без Каше не может использоваться. Что Вас удивляет то?
...
Рейтинг: 0 / 0
05.05.2006, 10:50
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709263
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
Sergei Obrastsov,шаг № 3:
я гордо заявляю: у меня в БД циклов нет!
Дык и функционала теперь нет.

Я чесно говоря, намёка не понял

Если я пишу на SQL то чтоб выбрать данные циклы, как правило, не использую. Как и чего делает сервер - меня не волнует. В М же вся работа разработчика основана на написании циклов

Вы с этим не согласны?

С приветом Сергей
...
Рейтинг: 0 / 0
05.05.2006, 10:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709335
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
SergSuper Sergei Obrastsov,шаг № 3:
я гордо заявляю: у меня в БД циклов нет!
Дык и функционала теперь нет.

Какого функционала?! Все на месте.


Я чесно говоря, намёка не понял
Если я пишу на SQL то чтоб выбрать данные циклы, как правило, не использую. Как и чего делает сервер - меня не волнует. В М же вся работа разработчика основана на написании циклов

Вижу, что не понял. Не используешь. Используешь "мой вариант".
Что тебе сказать? Один мой знакомый считает, что никакого "машинного
кода" не существует и Windows - это самый нижний уровень. :)

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 11:09
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709359
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Sergei Obrastsov Gluk (Kazan) Sergei Obrastsov VoDAДа будет откровение:
дело в том, что в ПРАВИЛЬНО спроектированной БД в РСУБД при использовании SQL - нет циклов (в основном).

я тебя правильно понял? то есть даже после моего намека предыдущему
оппоненту ты утверждаешь, что "циклов нет"? :)


НАМЕК: Помимо Nested Loops есть еще много интересных и полезных способов выполнения join. Да даже если по одной таблице, могу навскидку назвать 3 прынцыпивльно разных методов доступа
забавно. "а он все не понимает и не понимает..." :)
ну хорошо:

шаг № 1:
я убираю все циклы по БД в программы

шаг № 2:
теперь запрос выглядит так:
Код: plaintext
1.
     s Result = $$Select^server(x1,x2...)

шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

С уважением. Сергей

НАМЕК2: Оптимизатор сам решает (хотя разработчик может подсказать, ежели он мазохист) какой способ выбрать в конкретном случае. То что он выберет зависит от очччень многих факторов, которые средний разработчик учесть не в состоянии (например от того как данные физически лежат в таблицах).
Вывод => среднему разработчику не нужно забивать голову "циклами" используемыми для получения данных. Не его скудного ума это дело.
...
Рейтинг: 0 / 0
05.05.2006, 11:13
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709399
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Gluk (Kazanшаг № 1:
НАМЕК2: Оптимизатор сам решает (хотя разработчик может подсказать, ежели он мазохист) какой способ выбрать в конкретном случае. То что он выберет зависит от очччень многих факторов, которые средний разработчик учесть не в состоянии (например от того как данные физически лежат в таблицах).
Вывод => среднему разработчику не нужно забивать голову "циклами" используемыми для получения данных. Не его скудного ума это дело.
Среднему разработчику и не надо хвататься за M, ему хватит того, что
настроено вокруг "реляционных таблиц". Он, кстати, и не лезет.

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 11:19
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709438
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Sergei Obrastsov
я тебя правильно понял? то есть даже после моего намека предыдущему
оппоненту ты утверждаешь, что "циклов нет"? :)

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

теперь о деревьях. в принципе, "реляционные модели" - тоже деревья.
только двухуровневые. поэтому не надо ахать "ой, 2 или n деревьев",
в РСУБД та же фигня. :)

С уважением. СергейМожно повторить намек?

И будьте добры объясните "реляционные модели" - тоже деревья,
только двухуровневые . В каком смысле деревья? И что означает двухуровневые?

PS спрашиваю не из стеба, просто интересно
...
Рейтинг: 0 / 0
05.05.2006, 11:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709443
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
SergSuper Sergei Obrastsov,шаг № 3:
я гордо заявляю: у меня в БД циклов нет!
Дык и функционала теперь нет.

Я чесно говоря, намёка не понял

Если я пишу на SQL то чтоб выбрать данные циклы, как правило, не использую. Как и чего делает сервер - меня не волнует. В М же вся работа разработчика основана на написании циклов

Вы с этим не согласны?

С приветом Сергей

нет

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

(к разработчику м-инструментария конечно это не относится)

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

действительно не существует универсального бесплатного
м-инструмента, но есть несколько специализированых,
хорошо заточеных для своих областей.
(А специальное разве не предпочтительнее универсального
для серьезных дел :)
например, наш MX заточен для задач класса "1с-предприятие"
(циклов рисовать там вовсе не обязательно )
...
Рейтинг: 0 / 0
05.05.2006, 11:25
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709449
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Народ тут идея появилась как хранить таблицы внутри таблиц на SQL для решения проблемы MS SQL.

На самом деле это афера. Хочу услышать конструктивную критику по предложению.

Создается две базы данных.
Первая - обычная и основная - где выполняется вся логика программы.
Вторая для хранения "вложеных таблиц".

DB1.

table1
id_row int
id_data данные
id_table_name имя таблицы в которой хранятся данные вложеной таблицы.

DB2
id_table_name названия таблицы на котороу ссылается запись из первой базы и первой таблицы. Для каждой записи название будет генерироваться и оно будет уникальным
потом сама струтктура таблицы.

По логике, в этом случае вложеная таблица по структуре может отличаться от каждой записи masterid.

Согласен - что выглядит все как-то криво, но думаю будет работать.
Интересно какое ограничени на число таблиц в SQL ?
...
Рейтинг: 0 / 0
05.05.2006, 11:27
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709461
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Sergei ObrastsovСреднему разработчику и не надо хвататься за M, ему хватит того, что
настроено вокруг "реляционных таблиц". Он, кстати, и не лезет.


Мним себя богами ???
ну ну, это бывает :)
...
Рейтинг: 0 / 0
05.05.2006, 11:29
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709537
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
Sergei Obrastsov SergSuper Sergei Obrastsov,шаг № 3:
я гордо заявляю: у меня в БД циклов нет!
Дык и функционала теперь нет.

Какого функционала?! Все на месте.


Я чесно говоря, намёка не понял
Если я пишу на SQL то чтоб выбрать данные циклы, как правило, не использую. Как и чего делает сервер - меня не волнует. В М же вся работа разработчика основана на написании циклов

Вижу, что не понял. Не используешь. Используешь "мой вариант".
Что тебе сказать? Один мой знакомый считает, что никакого "машинного
кода" не существует и Windows - это самый нижний уровень. :)

С уважением. Сергей
Какие-то детские замашки спуститься на уровень пониже... У меня это лет 10 назад прошло

MX -- ALEX разработчик приложений на базе нормального м-инструментария может обходится без написания циклов
Уточните пожалуйста: "может обходится" или "обычно обходится"?

Iura
Народ тут идея появилась как хранить таблицы внутри таблиц на SQL для решения проблемы MS SQL.
Я бы посоветовал пообщаться со специалистами по БД или дать задание на разработку БД кому-то другому.
Идея спорная
...
Рейтинг: 0 / 0
05.05.2006, 11:47
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709578
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
Gluk (Kazan) Sergei ObrastsovСреднему разработчику и не надо хвататься за M, ему хватит того, что
настроено вокруг "реляционных таблиц". Он, кстати, и не лезет.


Мним себя богами ???
ну ну, это бывает :)

думаю Сергей имел в виду следующее

1- начать работать на мумпсе с нуля сложнее - мало литературы
мало где используется
гораздо чаще студент натыкается на SQL и пошло - поехало на всю
оставшуюся жизнь - эффект вылупившегося утенка - кого
первым увидел - тот и родитель
применить нестандарное решение - мумпс -
отважится только матерый программист
(и не пожалеет)

2- все программисты - умные
но есть многодетные матери которым глубоко копать
просто нет времени
им лучше что попроще

(хотя повторяю- с хорошим м-инструментом прекрасно
работают даже начинающие и многодетные)
...
Рейтинг: 0 / 0
05.05.2006, 11:54
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709637
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
SergSuper
MX -- ALEX -
разработчик приложений на базе нормального м-инструментария может обходится без написания циклов

Уточните пожалуйста: "может обходится" или "обычно обходится"?


у нас в М есть встроенный генератор отчетов и поисковик
90 % задач решается путем составления запросов
без циклов

нестандартные задачи - например увязка с АСУТП
потребовали спец програмирования с циклами опроса датчиков
...
Рейтинг: 0 / 0
05.05.2006, 12:02
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709661
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
VoDAМожно повторить намек?
проще его прочитать в моем письме где-то выше.
впрочем, повторюсь: есть там циклы, никуда они не денутся, только
этим занимается сервер. но это же не повод гордиться "отсутствием
циклов", ага :)


И будьте добры объясните "реляционные модели" - тоже деревья,
только двухуровневые . В каком смысле деревья? И что означает двухуровневые?
PS спрашиваю не из стеба, просто интересно
верю. таблицы легко представляются в "деревьях", первый уровень - индекс, второй - номер записи. почему "дерево"? потому что похоже на елку, если
нарисовать (особенно отношение "1:any"). :)
почему только два уровня? потому что такие таблицы, там только
одно отношение. если индекс составной, то он скомбинирован.
так он выглядит логически, так он сделан и физически.
за исключением исходных данных, там только один уровень (номер записи)

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 12:07
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709679
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
MX -- ALEX
у нас в М есть встроенный генератор отчетов и поисковик
90 % задач решается путем составления запросов
без циклов

нестандартные задачи - например увязка с АСУТП
потребовали спец програмирования с циклами опроса датчиков
Странно
Вот приводились решения простых задач, в частности и Вами - и все сплошь на циклах...

Т.е. у вас есть какие-то наработки и вы с уровня писания циклов ушли. Но ведь можно было бы и начинать с более высокого уровня...
...
Рейтинг: 0 / 0
05.05.2006, 12:10
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709710
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Sergei Obrastsov
шаг № 1:
я убираю все циклы по БД в программы

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

Sergei Obrastsov
шаг № 2:
теперь запрос выглядит так:

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

Sergei Obrastsov
шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

А они у Вас были в БД? Обыкновенно в БД данные. Ну ХП там хранятся. Ну даже сами проги, но тока хранятся. Нужно теперь уточнять чем Вы гордитесь теперь.
...
Рейтинг: 0 / 0
05.05.2006, 12:16
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709792
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
SergSuperКакие-то детские замашки спуститься на уровень пониже... У меня это лет 10 назад прошло

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

SergSuper
MX -- ALEX разработчик приложений на базе нормального м-инструментария может обходится без написания циклов
Уточните пожалуйста: "может обходится" или "обычно обходится"?

может. если инструментарий есть. но это не значит, что циклов нет вообще.
они просто проходят по уровню инструментария. :)

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 12:30
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709799
Andreww
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andreww
Участник
2 Sergei Obrastsov
>>верю. таблицы легко представляются в "деревьях",

Было уже, проходили и не раз. И даже на этом форуме.
Если всё так легко, то представте мне пожалуйста таблицу с тремы столбцами (остальные можно опустить как несущественные)

1. ТИП ДОКУМЕНТА
2. ДАТА ОПЕРАЦИИ
3. СУММА

ИМХО, типичный набор для любой учётной задачи.
Ессс-но нужно что бы поиск по ЛЮБОМУ из полей или ЛЮБОЙ ИХ КОМБИНАЦИИ был оптимальным и не сильно зависел от кардинальности.


>>первый уровень - индекс, второй - номер записи.

А что такое "НОМЕР ЗАПИСИ" ?

>>почему "дерево"? потому что похоже на елку, если
нарисовать (особенно отношение "1:any"). :)
почему только два уровня? потому что такие таблицы, там только
одно отношение. если индекс составной, то он скомбинирован.

Нифига не понял почему уровня 2, и кому такое дерево нафиг нужно....

>>так он выглядит логически, так он сделан и физически.

Как ТАК ? Физически похожим на ёлку ?

>>за исключением исходных данных, там только один уровень (номер записи)

Если уровень в дереве только ОДИН это уже список а не дерево.
...
Рейтинг: 0 / 0
05.05.2006, 12:31
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709844
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
У меня складывается впечатление, что все недопонимания из за разного трактования смысловой нагрузки слова "Программист". Если рассматривать программист в контексте кодера, то наверное все присутствующие проектировщики БД на РСУБД не являются программистами и уж тем более матерыми - лет 10-15 назад может быть и было интересно код ручками писать, сейчас же необходимость писать какой либо код, не являющейся бизнес-логикой (куда уж впервую очередь входит понятие циклов), для меня только означает, что проект (не обязательно БД, все части) криво спроектирован.

Так что IMHO MUMPS, CACHE, всякие ООСУБД - это не для нас, нет никакого желания кодировать и быть матерыми программистами, есть желание побольше работать головой и поменьше руками. Сам по себе с моей точки зрения SQL по синтаксису кривоват, однако удивляет постоянное аппелирование противников РСУБД к самому языку запросов SQL, когда это всего лишь верхнеуровневой скриптовый язык обращения к мощным механизмам хранения и обработки данных РСУБД. Для меня это чисто кодерская позиция - сравнивать продукты с точки зрения синтаксиса (аля Pascal vs C) вместо того, чтобы сравнивать парадигмы разработки приложений.
...
Рейтинг: 0 / 0
05.05.2006, 12:39
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709850
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
vadiminfo
1 Раз циклы написал проггер, разрабатывающий логику приложения, а не само СУБД, то этот факт не уберешь.

почему бы это? или СУБД у нас пишут уже не программисты? :)


2 Циклы по БД в программе - нужно уточнять хде они были раньше (они вседа в той или иной программе).

а какая разница "хде"?

vadiminfo
Sergei Obrastsov
шаг № 2:
теперь запрос выглядит так:

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

это именно вызов проги.
нет, ну ты посмотри, опять "на SQL"... а он-то здесь причем? вселенский
критерий? или "почему - Воркута? а я там сидел"?

Sergei Obrastsov
шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

vadiminfo
А они у Вас были в БД? Обыкновенно в БД данные. Ну ХП там хранятся. Ну даже сами проги, но тока хранятся. Нужно теперь уточнять чем Вы гордитесь теперь.
теперь будем придираться к словам? а циклы вокруг чего, уж не БД ли?
уточняю, отсутствием циклов в запросах

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 12:41
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709879
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
SergSuper MX -- ALEX
у нас в М есть встроенный генератор отчетов и поисковик
90 % задач решается путем составления запросов
без циклов

нестандартные задачи - например увязка с АСУТП
потребовали спец програмирования с циклами опроса датчиков
Странно
Вот приводились решения простых задач, в частности и Вами - и все сплошь на циклах...

Т.е. у вас есть какие-то наработки и вы с уровня писания циклов ушли. Но ведь можно было бы и начинать с более высокого уровня...

задачку Эйнштейна проще решить пятью строчками м-кода
с циклами чем составлять сложный запрос
он сложный как в SQL так и у нас в м-генераторе отчетов

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

мы ушли от написания циклов в обычных асуповских задачах
лет 15 назад
- не знаю был ли тогда SQL
но иногда хочется поразмять извилины на чистом мумпсе
и показать принцип работы м-движка
...
Рейтинг: 0 / 0
05.05.2006, 12:47
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709903
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Давайте я Вам реальный пример приведу задачи, а вы просто скажите как это будет выглядеть в Cache. Бессмыслен спор людей, которые реально не работали на двух языках. Пока собственными ручками не сделаешь проект там и там не поймешь все прелесть каждого продукта.

Если честно, меня Кеша сильно оталкивает тем, что онам менее распространеная.
Если предположить, что MySQL в 10 раз хуже чем MSSQL и ORACLE, то не смотря на это про это продукт многие занют. им многие пользуются По нему есть куча документация на разных языках + книги. Что имеет большое значение.

А по Cache есть единственная книжка на русском. Маркетинг очень хреновый у Cache, если продукт и правдо хорош.

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

tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)


tb_text(
id_text bigint,
text nvarchar(max)
)

tb_predlojenie(
id_predlojenie int,
id_text bigint,
positsia int)


tb_slova(
id_slovo bigint,
id_predlojenie int,
id_text bigint,
positsia smalint)


У меня душа не лежит для каждого слова предложения из текста хранить информацию id_predlojenie int + id_text bigint = 12 bait + 8 bait id samogo slova - 20 bait инфы на слово из текста. А это очень и очень много. Как эту структуру можно представить оптимально на Кеше ?
...
Рейтинг: 0 / 0
05.05.2006, 12:53
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33709919
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Andreww
Было уже, проходили и не раз. И даже на этом форуме.
Если всё так легко, то представте мне пожалуйста таблицу с тремы столбцами (остальные можно опустить как несущественные)

1. ТИП ДОКУМЕНТА
2. ДАТА ОПЕРАЦИИ
3. СУММА
ИМХО, типичный набор для любой учётной задачи.
Ессс-но нужно что бы поиск по ЛЮБОМУ из полей или ЛЮБОЙ ИХ КОМБИНАЦИИ был оптимальным и не сильно зависел от кардинальности.

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


>>первый уровень - индекс, второй - номер записи.
А что такое "НОМЕР ЗАПИСИ" ?

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


Нифига не понял почему уровня 2, и кому такое дерево нафиг нужно....

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


Если уровень в дереве только ОДИН это уже список а не дерево.

правильно. такой вот частный случай.

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 12:57
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710012
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Sergei Obrastsov
почему бы это? или СУБД у нас пишут уже не программисты? :)

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

Sergei Obrastsov
а какая разница "хде"?

Если никакой разницы, то зачем Вы их "убирали в программу"? Ить разницы же нет?

Sergei Obrastsov
это именно вызов проги.
нет, ну ты посмотри, опять "на SQL"... а он-то здесь причем? вселенский
критерий? или "почему - Воркута? а я там сидел"?

Он декларативный - инфа из БД без циклов. А Вы про циклы. При этом он здесь.

Sergei Obrastsov
теперь будем придираться к словам? а циклы вокруг чего, уж не БД ли?
уточняю, отсутствием циклов в запросах

Отсутствовать циклы в запросах стали из-за того что Вы их "убрали в программу"? Сами говорите нет никакой разницы. Их написали Вы. Вот када проггер, пишущий СУБД уберет их в программу СУБД, тада другое дело. Тада запросы без циклов. А так просто структурное программирование. Разбил большую процедуру на мелкие и вызывает их. Вы сами выше писали, что это просто вызов Вашей же или Вашего коллеги проги. Это не запрос на декларативном языке БД. Две большие разницы. На Вашем языке писать циклы и их вызовы, а там запрос без циклов на основе содержания данных (ассоциативно).
...
Рейтинг: 0 / 0
05.05.2006, 13:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710024
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
IuraБессмыслен спор людей, которые реально не работали на двух языках. Пока собственными ручками не сделаешь проект там и там не поймешь все прелесть каждого продукта.

не очень хороший аргумент. М-щики, в основной своей массе, как раз и
работали с РСУБД. а куда было деваться? я, например, с 91-го работаю
с Clarion. а дальше были и InterBase, и MSSQL, и DB2.
как-то раз пришлось восстанавливать убитый mdf-файл.
ага, с помощью M. такая вот дружба родов войск :)

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 13:19
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710055
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Sergei Obrastsovверю. таблицы легко представляются в "деревьях", первый уровень - индекс, второй - номер записи. почему "дерево"? потому что похоже на елку, если
нарисовать (особенно отношение "1:any"). :)
почему только два уровня? потому что такие таблицы, там только
одно отношение. если индекс составной, то он скомбинирован.
так он выглядит логически, так он сделан и физически.
за исключением исходных данных, там только один уровень (номер записи)

С уважением. СергейИдем дальше.

Данные в М: родитель1 -> родитель2 -> лист дерева3
Даныне в РСУБД: таблица1, таблица2, таблица3.

номера сущьностей в М и РСУБД совпадают.

Запрос на получение 3 через известные 2 и 1 в М испольует доступ через 1->2->3, в Р 1->2->3.

Запрос на получение всех 1, у которых есть только требуемые 3 (пример: вывести счета по которым у компании покупали продукцию 3)
Р ищем (сканируем) 3, затем БЕЗ ЦИКЛОВ из связки 3->2->1 получаем 1.

А как в М?


ЗЫ 1,2,3 - это различные сущьности, связанные отношением см. выше.
...
Рейтинг: 0 / 0
05.05.2006, 13:26
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710065
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Sergei Obrastsov IuraБессмыслен спор людей, которые реально не работали на двух языках. Пока собственными ручками не сделаешь проект там и там не поймешь все прелесть каждого продукта.

не очень хороший аргумент. М-щики, в основной своей массе, как раз и
работали с РСУБД. а куда было деваться? я, например, с 91-го работаю
с Clarion. а дальше были и InterBase, и MSSQL, и DB2.
как-то раз пришлось восстанавливать убитый mdf-файл.
ага, с помощью M. такая вот дружба родов войск :)

С уважением. Сергей

Сергей как моя структура выглядела бы в Cache если бы потребовалось оптимизировать ее? Все также ?

Сижу тихо тихо качаю Cache думаю начать и Oracle качать, а пока использую MS SQL. С базой пока не определился :(
...
Рейтинг: 0 / 0
05.05.2006, 13:27
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710090
Andreww
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andreww
Участник
2 Sergei Obrastsov

Ну во-первых я вам не ТЫ-кал.

Про "деревья похожие на ёлки" :

...а, извини, как представить? три поля в записи тебя устроят?
вот именно эти, тобой указанные?

Т.е. дерево с одним уровнем , т.е. СПИСОК :)

Забавно, вы не находите ?

Получается так :

>>>таблицы легко представляются в "деревьях"

>> А представьте-ка мне простую (синтетический тестик) табличку

> Ээээ а как ? Может вот такой случай - и рисуется простой связный список.

Теперь оказывается, что даже простой синтетический тестик не нарисовался "похожим на ёлку", а превратился в банальный связный список.

Что будет когда данные будут сложными, декомпозированными на десяток-другой таблиц, нормализованными - лучше даже и не рассматривать, хотя иногда (в1-2%) случаев данные может быть действительно оптимально хранить данные в виде деревьев.

>>а он самый и есть. впрочем, да, его же не видно.

А что такое НОМЕР ?

А ОН САМЫЙ И ЕСТЬ.

Это сильно ! Мощь ответа и глубина поражают :) Воистину с МУ-МУ технологиями работают не просто знатные специалисты, а настоящий мастера ДЗЕН !

>>хотя если просматривать любую таблицу средствами самой СУБД, то он
рисуется в первом столбике (это, конечно, не совсем он, но
в принципе - да) :)

Oracle 9.2 (Субд такая) + sqlplus(w) (родное его средство)
делаем select * from user_tables; Хмммм. Первым столбцом идёт Table_name :)

>>верю. потому что таблица плоская.

Стараюсь при работе с РСУБД не оперировать понятиями типа "таблица" и вам не советую, так проще, поскольку в реляционной модели таблиц нету.

>>не знаю, оно просто есть. можешь на него не смотреть. :)

Да я вобщем-то и не собирался :) Просто спросил, для расширения кругозора, для чего существует такая структура, оказывается ПРОСТО ЕСТЬ.
Хммм. Ёмкий ответ.


>>а если серьезно, то это просто визуальное представление

Так что же вы сразу не сказали !!! Я тут о базах данных о структурах об оптимальности, а это просто ВИЗУАЛЬНОЕ ПРЕДСТАВЛЕНИЕ :)
Т.е. берёте пару опытных кодировщиков и они вам ИЗ ЛЮБЫХ ДАННЫХ могут наваять ТАКОЕ ВИЗУАЛЬНОЕ ПРЕДСТАВЛЕНИЕ, хошь с трёхмерной графикой хошь со звуком и не надо НИКАКИХ МУМУ и ОРАКЕЛОВ и дешевле кстати выйдет.

>>правильно. такой вот частный случай.

Есс-но правильно, т.к. это был не ответ а утверждение :)
...
Рейтинг: 0 / 0
05.05.2006, 13:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710113
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
IuraСергей как моя структура выглядела бы в Cache если бы потребовалось оптимизировать ее? Все также ?

если переносить в лоб то, что ты нарисовал, то она примерно так же
и перенесется. надо подняться немного выше и посмотреть, что ты
все-таки хочешь. напиши мне в email, обсудим, я денег за помощь
не беру. :)


С базой пока не определился :(
понимаю. и опять скажу: не рисуй ты эти таблицы. нарисуй алгоритм
обработки информации каким ты его видишь. или опиши. так
будет проще и правильнее. а от этого уже можно толкнуться к
структурам

С уважением. Сергей

P.S. И все же я не уверен, что тебе нужен Cache.
...
Рейтинг: 0 / 0
05.05.2006, 13:39
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710200
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Andreww
Ну во-первых я вам не ТЫ-кал.

что ж, перейдем на Вы


Т.е. дерево с одним уровнем , т.е. СПИСОК :)
Забавно, вы не находите ?

нет. а "плоская таблица" выглядит по-другому?


Теперь оказывается, что даже простой синтетический тестик не нарисовался "похожим на ёлку", а превратился в банальный связный список.

не увидел я в нем ничего связного, ну да ладно.
может быть это трехмерная таблица, а я и не заметил?


Что будет когда данные будут сложными, декомпозированными на десяток-другой таблиц, нормализованными - лучше даже и не рассматривать, хотя иногда (в1-2%) случаев данные может быть действительно оптимально хранить данные в виде деревьев.

"товарищ не понимает". :)
этот "десяток-другой таблиц" не будет выглядеть как
"индекс->ссылка на запись в другой таблице"? ах ну да, это же не дерево,
это - ТАБЛИЦА, да? ну, все понятно


А что такое НОМЕР ?
А ОН САМЫЙ И ЕСТЬ.
Это сильно ! Мощь ответа и глубина поражают :) Воистину с МУ-МУ технологиями работают не просто знатные специалисты, а настоящий мастера ДЗЕН !

каков вопрос - таков и ответ.
индексные таблицы ссылаются на номер записи


Oracle 9.2 (Субд такая) + sqlplus(w) (родное его средство)
делаем select * from user_tables; Хмммм. Первым столбцом идёт Table_name :)

может проще сделать по одной таблице?


>>верю. потому что таблица плоская.
Стараюсь при работе с РСУБД не оперировать понятиями типа "таблица" и вам не советую, так проще, поскольку в реляционной модели таблиц нету.

"select * from user_tables" - видимо, tables теперь переводят по-другому


>>правильно. такой вот частный случай.
Есс-но правильно, т.к. это был не ответ а утверждение :)
наверное должно было быть "не вопрос". впрочем, неважно

Пока. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 13:58
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710205
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
VoDA Идем дальше.

Данные в М: родитель1 -> родитель2 -> лист дерева3
Даныне в РСУБД: таблица1, таблица2, таблица3.

номера сущьностей в М и РСУБД совпадают.

Запрос на получение 3 через известные 2 и 1 в М испольует доступ через 1->2->3, в Р 1->2->3.

Запрос на получение всех 1, у которых есть только требуемые 3 (пример: вывести счета по которым у компании покупали продукцию 3)
Р ищем (сканируем) 3, затем БЕЗ ЦИКЛОВ из связки 3->2->1 получаем 1.

А как в М?


ЗЫ 1,2,3 - это различные сущьности, связанные отношением см. выше.
Я малость выше об этом же спрашивал - нет ответа, не слышуть, когда конкретика начинается :)
А хотелось бы все же узнать - в цикле по всем 1 будете идти и проверять, есть ли там 3???

-- Tygra's --
...
Рейтинг: 0 / 0
05.05.2006, 13:59
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710240
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
IuraЕсть четыре таблицы: Текст, предложения, слова, словарь
вот их описания. Таблицы не имеют отношение к самой реализации проекта, но я передам суть вопроса на их примере еще раз

tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)

tb_text(
id_text bigint,
text nvarchar(max)
)


Это оригинальные содержательные данные, видимо. Как вариант мог бы быть такой:
^tbslovar(idslovo)=slovo
Ну и наверно обратный индекс чтобы найти ид слова
^itbslovar(slovo,idslovo)=""

^tbtext(idtext)=text
Тут лимит 32 кила на длину строки, если нужно больше то надо раскладывать по частям или использовать классы потоков (что технически то же самое).

Iuratb_predlojenie(
id_predlojenie int,
id_text bigint,
positsia int)


tb_slova(
id_slovo bigint,
id_predlojenie int,
id_text bigint,
positsia smalint)

А это уже видимо для поиска. Если нужно брать позицию предложения в тексте, то могло бы быть так
^itbpredlojenie(idpredlojenie,idtext,positsia)=""
Если нужно брать позицию слова в тексте и в предложении, то наверно так
^itbslova(idslovo,idtext,idpredlojenie,positsia)=""

Например, если задано слово то по ^itbslovar(slovo) берем idslovo, и по ^itbslova(idslovo,idtext,idpredlojenie,positsia)=""
получаем сначала тексты, в которых оно есть, по текстам - предложения, по предложению - позицию.

Имея только таблицы, тут можно оперировать разве что как sql-щики, больше пока ничего не задано. Если есть уточнения насчет операций со словами - предложениями, то можно уточнить и схему. А пока вы от sql недалеко ушли.
...
Рейтинг: 0 / 0
05.05.2006, 14:04
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710293
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
ну я IuraЕсть четыре таблицы: Текст, предложения, слова, словарь
вот их описания. Таблицы не имеют отношение к самой реализации проекта, но я передам суть вопроса на их примере еще раз

tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)

tb_text(
id_text bigint,
text nvarchar(max)
)


Это оригинальные содержательные данные, видимо. Как вариант мог бы быть такой:
^tbslovar(idslovo)=slovo
Ну и наверно обратный индекс чтобы найти ид слова
^itbslovar(slovo,idslovo)=""

^tbtext(idtext)=text
Тут лимит 32 кила на длину строки, если нужно больше то надо раскладывать по частям или использовать классы потоков (что технически то же самое).

Iuratb_predlojenie(
id_predlojenie int,
id_text bigint,
positsia int)


tb_slova(
id_slovo bigint,
id_predlojenie int,
id_text bigint,
positsia smalint)

А это уже видимо для поиска. Если нужно брать позицию предложения в тексте, то могло бы быть так
^itbpredlojenie(idpredlojenie,idtext,positsia)=""
Если нужно брать позицию слова в тексте и в предложении, то наверно так
^itbslova(idslovo,idtext,idpredlojenie,positsia)=""

Например, если задано слово то по ^itbslovar(slovo) берем idslovo, и по ^itbslova(idslovo,idtext,idpredlojenie,positsia)=""
получаем сначала тексты, в которых оно есть, по текстам - предложения, по предложению - позицию.

Имея только таблицы, тут можно оперировать разве что как sql-щики, больше пока ничего не задано. Если есть уточнения насчет операций со словами - предложениями, то можно уточнить и схему. А пока вы от sql недалеко ушли.


Поиск фразы будет вестись по таблице slova.
При переводе берется исходная фраза и ищется в таблице переведеных фраз (predlojenia). Пусть пока поиск ведется только по исходному тексту, без перевода. Искать по словам в таблице slova будет быстрее, чем сканировать весь тексты.

Можно получить все предложения, которые содержат слова
select pid_predlojenia
from slova
where id_slova in ( id_искомых слов)


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

Так вот этот алгоритм легко реализовать SQL, но тот факт что на слово в предложении приходится 20 байт - очень огорчает. Вроде бу немного. Но если подсчитать, сколько слов в тексте, а сколько будет текстов то получается очень и очень много. :(
...
Рейтинг: 0 / 0
05.05.2006, 14:14
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710310
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
Iura, уже написали что структуры в кеше нет. Полная свобода. Делайте деревья, по которым надо будет искать. Сколько надо видов поиска - столько и деревьев. Т.е. данные будут дублироваться в разных деревьях и их синхронность надо поддерживать самостоятельно. Для настоящего программиста есть где развернуться. И еще учтите что Int-ов там нету, всё хранится строчками, что тоже несколько длиннее.
...
Рейтинг: 0 / 0
05.05.2006, 14:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710326
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
SergSuperIura, уже написали что структуры в кеше нет. Полная свобода. Делайте деревья, по которым надо будет искать. Сколько надо видов поиска - столько и деревьев. Т.е. данные будут дублироваться в разных деревьях и их синхронность надо поддерживать самостоятельно. Для настоящего программиста есть где развернуться. И еще учтите что Int-ов там нету, всё хранится строчками, что тоже несколько длиннее.

Хм. Мда. Строчками хранится ?
Как с целочисленой матетматикой в Cache ? С каким максимальным числом он работает ?
...
Рейтинг: 0 / 0
05.05.2006, 14:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710331
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
VoDAИдем дальше.
Данные в М: родитель1 -> родитель2 -> лист дерева3
Даныне в РСУБД: таблица1, таблица2, таблица3.
номера сущьностей в М и РСУБД совпадают.
Запрос на получение 3 через известные 2 и 1 в М испольует доступ через 1->2->3, в Р 1->2->3.
Запрос на получение всех 1, у которых есть только требуемые 3 (пример: вывести счета по которым у компании покупали продукцию 3)
Р ищем (сканируем) 3, затем БЕЗ ЦИКЛОВ из связки 3->2->1 получаем 1.
А как в М?
ЗЫ 1,2,3 - это различные сущьности, связанные отношением см. выше.
небольшое уточнение: ты говоришь о том как это получается у тебя, с учетом
всего инструментария РСУБД, а от меня требуешь, чтобы я тебе показал это
БЕЗ ЦИКЛОВ на уровня языка. честно ли это? :) как это реализовано на
уровне объектов и псевдо-SQL в Cache - не знаю, мне это как-то неинтересно.
а хардкорно - без циклов не обойтись, кто же мне выбирать-то будет? :)

ну а если вопрос по структурам и, надеюсь, без дураков, то такая
связка реализуется в виде:

^x(i1,i2,i3) - удобнее, правда? то есть под каждым уровнем есть только
связанные с ним уровни и "листья дерева" (можно конечно и так сказать).

а можно и реализовать точь в точь как у тебя, через "двойки":

^x1(i1,i2)
^x2(i2,i3)

можно, но непрактично.

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 14:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710338
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
IuraДавайте я Вам реальный пример приведу задачи, а вы просто скажите как это будет выглядеть в Cache. Бессмыслен спор людей, которые реально не работали на двух языках. Пока собственными ручками не сделаешь проект там и там не поймешь все прелесть каждого продукта.

Если честно, меня Кеша сильно оталкивает тем, что онам менее распространеная.
Если предположить, что MySQL в 10 раз хуже чем MSSQL и ORACLE, то не смотря на это про это продукт многие занют. им многие пользуются По нему есть куча документация на разных языках + книги. Что имеет большое значение.

А по Cache есть единственная книжка на русском. Маркетинг очень хреновый у Cache, если продукт и правдо хорош.

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

tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)


tb_text(
id_text bigint,
text nvarchar(max)
)

tb_predlojenie(
id_predlojenie int,
id_text bigint,
positsia int)


tb_slova(
id_slovo bigint,
id_predlojenie int,
id_text bigint,
positsia smalint)


У меня душа не лежит для каждого слова предложения из текста хранить информацию id_predlojenie int + id_text bigint = 12 bait + 8 bait id samogo slova - 20 bait инфы на слово из текста. А это очень и очень много. Как эту структуру можно представить оптимально на Кеше ?

tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)

например словарь - это будет одномерное дерево
^slova("книг")
^slova("книга")
^slova("книголюб")

заранее ничего декларировать не надо
другие структуры тоже не декларируются
поэтому нет точного эквивалента Вашего представления в чистом мумпс
(если не использовать специальный SQL-наворот cache)

идентификаторов не надо - само слово является идентификатором
как будет организован ввод данных - неважно
(это зависит от м-инструмента)
главное что после ввода - корректировки появится это дерево

экономия например за счет того что совпадающаая часть индекса
"^slova("кни"
хранится один раз
- излагаю упрощенно

хотя это не существенно и не сильно повлияет на скорость и обьем
...
Рейтинг: 0 / 0
05.05.2006, 14:22
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710375
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
SergSuperИ еще учтите что Int-ов там нету, всё хранится строчками, что тоже несколько длиннее.
Это в стандарте на М не регламентировано. А что касается именно каше, то если значение получено в результате числовой операции то оно остается числом и во внутреннем представлении. И пишется как число.

2 lura
Как с целочисленой матетматикой в Cache ? С каким максимальным числом он работает ?

Целые числа - 2 в степени 63 максимум если гарантированно.
...
Рейтинг: 0 / 0
05.05.2006, 14:28
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710377
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Iura SergSuperIura, уже написали что структуры в кеше нет. Полная свобода. Делайте деревья, по которым надо будет искать. Сколько надо видов поиска - столько и деревьев. Т.е. данные будут дублироваться в разных деревьях и их синхронность надо поддерживать самостоятельно. Для настоящего программиста есть где развернуться. И еще учтите что Int-ов там нету, всё хранится строчками, что тоже несколько длиннее.

Хм. Мда. Строчками хранится ?
Как с целочисленой матетматикой в Cache ? С каким максимальным числом он работает ?
"он над нами издевался..." да пусть порезвится. :)
строками. да нормально вроде, хватает. 1e18
...
Рейтинг: 0 / 0
05.05.2006, 14:28
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710383
Hima
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hima
Гость
SergSuperIura, уже написали что структуры в кеше нет. Полная свобода. Делайте деревья, по которым надо будет искать. Сколько надо видов поиска - столько и деревьев. Т.е. данные будут дублироваться в разных деревьях и их синхронность надо поддерживать самостоятельно. Для настоящего программиста есть где развернуться. И еще учтите что Int-ов там нету, всё хранится строчками, что тоже несколько длиннее.

Ну а как же %Library.Integer? ... в итоге конечно же всеравно храниться строкой, но индексируется числа же все-таки лучше....
...
Рейтинг: 0 / 0
05.05.2006, 14:29
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710393
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Sergei Obrastsov небольшое уточнение: ты говоришь о том как это получается у тебя, с учетом
всего инструментария РСУБД, а от меня требуешь, чтобы я тебе показал это
БЕЗ ЦИКЛОВ на уровня языка. честно ли это? :) как это реализовано на
уровне объектов и псевдо-SQL в Cache - не знаю, мне это как-то неинтересно.
а хардкорно - без циклов не обойтись, кто же мне выбирать-то будет? :)

ну а если вопрос по структурам и, надеюсь, без дураков, то такая
связка реализуется в виде:

^x(i1,i2,i3) - удобнее, правда? то есть под каждым уровнем есть только
связанные с ним уровни и "листья дерева" (можно конечно и так сказать).

а можно и реализовать точь в точь как у тебя, через "двойки":

^x1(i1,i2)
^x2(i2,i3)

можно, но непрактично.

С уважением. Сергей
А можно для меня решение, хоть с циклами, хоть без - вообще решение?
А то так и не понятно - есть ли оно, решение, или нет :)

-- Tygra's --
...
Рейтинг: 0 / 0
05.05.2006, 14:32
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710408
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
MX -- ALEX

tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)

например словарь - это будет одномерное дерево
^slova("книг")
^slova("книга")
^slova("книголюб")

заранее ничего декларировать не надо
другие структуры тоже не декларируются
поэтому нет точного эквивалента Вашего представления в чистом мумпс
(если не использовать специальный SQL-наворот cache)

идентификаторов не надо - само слово является идентификатором
как будет организован ввод данных - неважно
(это зависит от м-инструмента)
главное что после ввода - корректировки появится это дерево

экономия например за счет того что совпадающаая часть индекса
"^slova("кни"
хранится один раз
- излагаю упрощенно

хотя это не существенно и не сильно повлияет на скорость и обьем

Люди кто-то знаком с Прологом? Мне чем-то это дело напоминает концепцию Пролога.
...
Рейтинг: 0 / 0
05.05.2006, 14:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710468
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
IuraПоиск фразы будет вестись по таблице slova.
При переводе берется исходная фраза и ищется в таблице переведеных фраз (predlojenia).

а зачем, если не секрет? почему бы не сделать перевод строки?
это не так страшно как может показаться. иначе ты рискуешь завалить
базу переводами схожих предложений с переставленными словами. :)


Так вот этот алгоритм легко реализовать SQL, но тот факт что на слово в предложении приходится 20 байт - очень огорчает. Вроде бу немного. Но если подсчитать, сколько слов в тексте, а сколько будет текстов то получается очень и очень много. :(
тут можно подумать о некоей "математике" над словами. скажем приведение
к виду: fn(приставка) + fn(корень) + fn(суффикс) + fn(окончание). в результате можно приводить его к числу размером, скажем, в 4 байта. ну
и конечно справочники частей слова. и все же выигрыш будет достаточный

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 14:48
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710515
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
tygra VoDA Идем дальше.

Данные в М: родитель1 -> родитель2 -> лист дерева3
Даныне в РСУБД: таблица1, таблица2, таблица3.

номера сущьностей в М и РСУБД совпадают.

Запрос на получение 3 через известные 2 и 1 в М испольует доступ через 1->2->3, в Р 1->2->3.

Запрос на получение всех 1, у которых есть только требуемые 3 (пример: вывести счета по которым у компании покупали продукцию 3)
Р ищем (сканируем) 3, затем БЕЗ ЦИКЛОВ из связки 3->2->1 получаем 1.

А как в М?


ЗЫ 1,2,3 - это различные сущьности, связанные отношением см. выше.
Я малость выше об этом же спрашивал - нет ответа, не слышуть, когда конкретика начинается :)
А хотелось бы все же узнать - в цикле по всем 1 будете идти и проверять, есть ли там 3???

-- Tygra's --

Р ищем (сканируем) 3,
вот здесь и крутит невидимый для Вас цикл - только за счет
скорости Вы это не ощущаете

в М тоже все быстро крутит
но циклы при наличии м-инструмента
явно прописывать не надо
хотя на нижнем уровне точно они есть
- сам создавал инструмент поэтому знаю :)

в конечном счете разница - небольшая

нам интереснее с М
прикладуха на инструменте рисуется не быстро - а очень быстро
работает - не догонишь
что еще клиенту надо ?
...
Рейтинг: 0 / 0
05.05.2006, 14:58
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710525
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
tygraА можно для меня решение, хоть с циклами, хоть без - вообще решение?
А то так и не понятно - есть ли оно, решение, или нет :)

е-мое. чего ты от меня хочешь? строку вида:
Код: plaintext
1.
s ind="" f  s ind=$o(^x(i1,i2,ind)) q:ind=""  d write
и что это тебе даст, интересно? :)

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 14:59
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710535
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Sergei Obrastsov
а зачем, если не секрет? почему бы не сделать перевод строки?
это не так страшно как может показаться. иначе ты рискуешь завалить
базу переводами схожих предложений с переставленными словами. :)


Для перевода будет использоватся промежуточная таблица

tb_perevod
{
id_zapisi
id_predlojenie_isxodnogo
id_predlojenia_perevedenogo
}

ясно дело что перед тем как добавить новый перевод строки в базу данных перевода, то система будет проверять, а есть такой перевод уже? если нет, то данные занесутся в таблицу tb_perevod, иначе никакие действий не предпримутся.

Что касается слов. то там все сложенее.
Мне нужно хранить все виды написания слова. Система не будет делать грамматический и стилестический анализ. Она будет принимать перевод как есть. Одно элементу соотвествует одного множества, будет соотвествовать другой элемент другого множества. Мне сам "язык" будет по барабану. Я буду заниматся статистикой и множествами + самообучением.
...
Рейтинг: 0 / 0
05.05.2006, 15:02
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710559
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 MX -- ALEX
Т.е. если мы имеем 3 миллиона (1), 5 миллионов (2) и 10 миллионов (3), то в итоге ходя по ним в цикле чего мы получаем? 100 миллионов оборотов, так чтоли? Это называется быстро и оптимально?

Или есть еще одно чудо, которое осталось за кадром?

Sergei Obrastsov tygraА можно для меня решение, хоть с циклами, хоть без - вообще решение?
А то так и не понятно - есть ли оно, решение, или нет :)

е-мое. чего ты от меня хочешь? строку вида:
Код: plaintext
1.
s ind="" f  s ind=$o(^x(i1,i2,ind)) q:ind=""  d write
и что это тебе даст, интересно? :)

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



-- Tygra's --
...
Рейтинг: 0 / 0
05.05.2006, 15:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710573
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
MX -- ALEX
Как Вы считаете - подойдет ли BerkeleyDB ?
можно ли его разложить по ячейкам ексцел ?

Понятия не имею - ни excel, ни windows не пользую.
...
Рейтинг: 0 / 0
05.05.2006, 15:09
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710583
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
tygraА хотелось бы все же узнать - в цикле по всем 1 будете идти и проверять, есть ли там 3???

вот, наконец-то хороший вопрос. :)
пишутся только существующие узлы
то есть:
i1 = 1
i2 = 2
i3 = 3

дадут ^x(1,2,3)=<чему-то там, а может и ничему>

i1=1
i2=3
i3="x"

дадут ^x(1,3,"x")=...

ну и так далее, по списку i1,i2 и i3
когда производится выборка, конкретные значения i1 и i2 сужают область
выбора

то есть если я задам выбор i3 при i1=1 и i2=2, то я получу только
фактически прописанные на уровне i3 узлы. в нашем случае - i3=3.
i3="x", i2=3 даже не будут затрагиваться.

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 15:11
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710606
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
tygra
Т.е. если мы имеем 3 миллиона (1), 5 миллионов (2) и 10 миллионов (3), то в итоге ходя по ним в цикле чего мы получаем? 100 миллионов оборотов, так чтоли? Это называется быстро и оптимально?

выдумываешь, ага. фактический индекс - он только один.
то есть 1 раз =1, 1 раз =2, 1 раз =3 :)

ну а если ты имеешь в виду что под 1,2 должны сидеть еще 100 других,
кроме =3, то они и будут там сидеть. итого 100 на выборке и будет (101,
если считать =3) :)


Или есть еще одно чудо, которое осталось за кадром?

может это оно и есть?

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 15:16
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710613
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Ааа, мы то хотим наоборот:
i1=х
i2=х
i3=набор значений

тогда хошь-нехошь придется по всем i1 i2 идти. Или нет? А как тогда?

-- Tygra's --
...
Рейтинг: 0 / 0
05.05.2006, 15:19
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710626
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
tygra2 MX -- ALEX
Т.е. если мы имеем 3 миллиона (1), 5 миллионов (2) и 10 миллионов (3), то в итоге ходя по ним в цикле чего мы получаем? 100 миллионов оборотов, так чтоли? Это называется быстро и оптимально?

Или есть еще одно чудо, которое осталось за кадром?

Sergei Obrastsov tygraА можно для меня решение, хоть с циклами, хоть без - вообще решение?
А то так и не понятно - есть ли оно, решение, или нет :)

е-мое. чего ты от меня хочешь? строку вида:
Код: plaintext
1.
s ind="" f  s ind=$o(^x(i1,i2,ind)) q:ind=""  d write
и что это тебе даст, интересно? :)

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



-- Tygra's --

Или есть еще одно чудо, которое осталось за кадром?

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

думаю то же самое делает реляционка - невидимо за кадром
...
Рейтинг: 0 / 0
05.05.2006, 15:22
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710630
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Iura
Для перевода будет использоватся промежуточная таблица
tb_perevod
{
id_zapisi
id_predlojenie_isxodnogo
id_predlojenia_perevedenogo
}

по-моему, это неудачное решение.


ясно дело что перед тем как добавить новый перевод строки в базу данных перевода, то система будет проверять, а есть такой перевод уже? если нет, то данные занесутся в таблицу tb_perevod, иначе никакие действий не предпримутся.

"Вася идет домой", "Домой идет Вася", "Идет Вася домой" - это разные
переводы или одинаковые?


Мне нужно хранить все виды написания слова. Система не будет делать грамматический и стилестический анализ. Она будет принимать перевод как есть. Одно элементу соотвествует одного множества, будет соотвествовать другой элемент другого множества. Мне сам "язык" будет по барабану. Я буду заниматся статистикой и множествами + самообучением.

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

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 15:23
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710637
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
yww@escape.ru ggvОпять не понимаю, почему тогда не BerkeleyDB - там тоже программист делает все самостоятельно!


Вот по этой ссылочке есть критика Каше ..
http://www.dimas.ru/ic/ic084.htm
и в том числе про BerkeleyDB упоминается..
Прочитал - не впечатлили ассоциации.
Ну в общем, там тоже косвенно утверждается, что BerkeleyDB дает еще больше свободы, утверждается, что и каше, и BerkeleyDB используют одинаковый способ хранения данных.
А в таком случае BerkeleyDB лучше - по соотношению цена/свобода - несоизмеримо, и не привязывает к языку с дурацкой нотацией.
Хоть статья и дурацкая, то мое мнение она подтвердила.
...
Рейтинг: 0 / 0
05.05.2006, 15:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710664
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
ggv MX -- ALEX
Как Вы считаете - подойдет ли BerkeleyDB ?
можно ли его разложить по ячейкам ексцел ?

Понятия не имею - ни excel, ни windows не пользую.

Спасибо

я то думал -
если база данных - то только через SQL
если OS - то только Windows
если программа - то Excel
...
Рейтинг: 0 / 0
05.05.2006, 15:30
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710689
-------------
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-------------
Участник
1. Насколько я понял, то основные данные для задачи автора темы можно в первом прибижении описать следующим отношением:
Код: plaintext
TranslationMemory(фрагмент_текста, исходный_язык, язык_перевода, контекст, автор, ссылка_на_источник_фргамента)

2. Во втором приближении - провести нормализацию.
3. В третьем - соорудить прототип и прогонять его на тестовых наборах данных:
a) реальные осмысленные данные, возможно не столь большого объема -- выявление типичных запросов, доопределение структур данных, доводка и отладка корректности алгоритмов (где-то автор что-то говорил о качестве?), и уже после этого:
b) случайные "мусорные" тестовые данные, объем сравним с планируемым для реальной работы - можно набрать из /dev/random :) -- поиск "узких мест" (bottlenecks) производительности и объемов данных на типичных запросах, оптимизация структур данных, алгоритмов, методов хранения (включая индексы). Не надо угадывать где тормозит, надо просто грамотно проводить timing, profiling, benchmarking.

4. Пока программа работает неудовлетворительно - повторять Пп. 2-3.

Это конечно все грубо и упрощенно, а смысл следующий: “Premature optimisation is the root of all evil"(Tony Hoare) , поэтому разработку советуют вести в последовательности Make it work. Make it right. Make it fast

А выбор на чем делать - MSSQL, Oracle, Cache и т.д. -- т.к. автора пугают 20 байт на слово -- это и есть преждевременное решение еще не существующей проблемы

PS щас меня запинают
...
Рейтинг: 0 / 0
05.05.2006, 15:34
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710693
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
tygraАаа, мы то хотим наоборот:
i1=х
i2=х
i3=набор значений
тогда хошь-нехошь придется по всем i1 i2 идти. Или нет? А как тогда?

я, видимо, плохо объясняю. :(
как работает SQL в этом случае? видимо, выбирая первичным индексом
для выборки то поле, которое позволит сузить количество обращений к базе.
ну а почему я должен действовать по-другому?

в этом случае структура превращается в вариант:

^x("d",n)=данные
^x("i1",i1,i2,i3)=n
^x("i2",i2,i1,i3)=n
^x("i3",i3,i1,i2)=n

что позволяет делать то, что хочешь ты, но неоптимально по размеру
ok, предложим другой:

^x("d",n)=данные
^x("i1",i1,n)=
^x("i2",i2,n)=
^x("i3",i3,n)=

в результате выборка сводится к варианту:
при известном i3 выбрать все n относящиеся к нему
если понадобится добавить условия на i1 и i2, тогда к предыдущему
действию добавляется проверка на наличие n по веткам "i1",i1 и
"i2",i2

С уважением. Сергей

P.S. Можно еще поразмыслить над структурой, но для этого надо
увидеть весь спектр желаемых тобой запросов. :)
...
Рейтинг: 0 / 0
05.05.2006, 15:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710700
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
ggv[quot yww@escape.ru]
Хоть статья и дурацкая, то мое мнение она подтвердила.

Ндя.. купите себе зеркало.
...
Рейтинг: 0 / 0
05.05.2006, 15:37
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710711
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
-------------А выбор на чем делать - MSSQL, Oracle, Cache и т.д. -- т.к. автора пугают 20 байт на слово -- это и есть преждевременное решение еще не существующей проблемы
PS щас меня запинают
да не за что. наоборот, спасибо за свежий взгляд. :)

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 15:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710722
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Sergei Obrastsov "Вася идет домой", "Домой идет Вася", "Идет Вася домой" - это разные переводы или одинаковые?

Это разные предложения. И перевестись они могут по разному.
Более того слова Домой и домоЙ это будут два разных слова

Мышь и Мышь - тоже два разных слова, все зависит от контекста.
Теперь понятно почему я для словаря слов и фраз использую Bigint ?

Эти три варианта перевода тоже будут приниматся так как есть
This is a computer - Это компьютер
This is a computer - Это есть компьютер
This is a computer - Это долбаная бандура есть компьютер.

This is camputer - Это компьютер. Этот перевод тоже имеет право на жизнь. Да исходное предложение не правильное. Но оно понятно для переводчика.
This is camputer - Это кампутер.


Оптимально или не оптимально это отдельный вопрос. Поскольку помимо статистики на серваке должна быть еще и надстройка "свод правил" "AI", который должен делать предположения, а человек их должен принимать или отклонять.

Система должна будет как ребенок с нуля обучатся языкам. У нее будет несколько учителей. Но она как и ребенок будет принимать "неправильные" обороты учась у пользователей. Но при переводе всегда будет использоватся оценочная функция, которая будет учитывать "мнения" всех пользователей учитывая их "уровень знаний".
...
Рейтинг: 0 / 0
05.05.2006, 15:41
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710773
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Ну... Понятно.
Явно Кэш для программиста технологии доступа, скажем так, а не для программиста бизнес-логики.

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

Потрясающе!!!

Спасибо, не надо. Я уж как нибудь по-старинке :))

-- Tygra's --
...
Рейтинг: 0 / 0
05.05.2006, 15:54
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710787
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Iura
Более того слова Домой и домоЙ это будут два разных слова

наверно, домОй? :)
и как ты собираешься это обыгрывать? запрашивать ударение?


Мышь и Мышь - тоже два разных слова, все зависит от контекста.

и как ты собираешься их записывать? мышь компьютерная и мышь домашняя?


This is camputer - Это компьютер. Этот перевод тоже имеет право на жизнь.

перевод - да, слово - нет. :) может лучше проверять синтаксис?


Да исходное предложение не правильное. Но оно понятно для переводчика.
This is camputer - Это кампутер.

и в этом случае - тоже. или ты предлагаешь подстраиваться под пользователя?
как быстро ты дойдешь до "Превед"? :)


Оптимально или не оптимально это отдельный вопрос. Поскольку помимо статистики на серваке должна быть еще и надстройка "свод правил" "AI", который должен делать предположения, а человек их должен принимать или отклонять.

"воровать так миллионы..."? серьезный замах. :)


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

С уважением. Сергей
...
Рейтинг: 0 / 0
05.05.2006, 15:58
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33710828
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
tygra
Явно Кэш для программиста технологии доступа, скажем так, а не для программиста бизнес-логики.

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

Потрясающе!!!

Спасибо, не надо. Я уж как нибудь по-старинке :))

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

и еще. разве я тебя зову переселяться в Cache? хочешь универсальности
и удобств - оставайся на том, на чем работаешь, но смирись с ограничениями.

С уважением. Сергей

P.S. "бизнес-логика" - надо же. можно подумать, что мы используем M
для ковыряния в носу. :)
...
Рейтинг: 0 / 0
05.05.2006, 16:09
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33711015
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторхочешь универсальности
и удобств - оставайся на том, на чем работаешь, но смирись с ограничениями.
А с какими ограничениями? По сравнению с Кэш например

-- Tygra's --
...
Рейтинг: 0 / 0
05.05.2006, 16:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33711102
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
tygra авторхочешь универсальности
и удобств - оставайся на том, на чем работаешь, но смирись с ограничениями.
А с какими ограничениями? По сравнению с Кэш например

-- Tygra's --

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

а у Сергея - получится - на М
даже с такой суровой постановкой задачи
(типа Окно и окнО - разные слова)
...
Рейтинг: 0 / 0
05.05.2006, 17:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33711173
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
MX -- ALEXпарень хочет супер-переводчик самообучающийся забацать
не получится на SQL
завязнет по скорости


Вот тока не надо так категорично.
Я же про M [censored] всякую не пишу
...
Рейтинг: 0 / 0
05.05.2006, 17:30
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33711318
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
MX -- ALEXпарень хочет супер-переводчик самообучающийся забацать
не получится на SQL
завязнет по скорости

а у Сергея - получится - на М
даже с такой суровой постановкой задачи
(типа Окно и окнО - разные слова)
утверждение, достойное ЧАЛа

т.е. вы не зная какие требования по скорости, не зная алгоритмов работы, не зная объёмов можете уже вынести решение?

браво, больше вопросов не имею
...
Рейтинг: 0 / 0
05.05.2006, 18:16
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33711609
Фотография S.G.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
S.G.
Участник
Скорость СУБД тут, имхо, последнее дело. Не знаю, знаком ли автор с проблемами машинного перевода. И в частности, с неоднозначностями естественных языков. У меня тут статья, линк к которой я в инете, к сожалению, не нашел, поэтому, просто перепишу пару абзацев:
1. "лексикальная" неоднозначность. слово имеет более одного значения. Например, "Stay away from the bank", может означать совет инвестору стоять подальше от банка, или совет ребенка стоять подальше от берега.
2. "структурная" неоднозначность. - неоднозначность скрыта в комбинации слов. Например: "He saw that gasoline can explode" - "Он увидел, что бензин может взорваться", или "он увидел, что тот бидон с бензином взорвался".
3. "глубинная неоднозначность". Два предложения могут иметь одну и ту же грамматическую структуру, но иметь разный смысл. Например: "The chickens are ready to eat". Понятно что кто-то готов съесть что-то, но цыплята здесь- это кто-то или что-то?
И так далее, пять типов неоднозначностей.
Кроме того, при реальных переводах никогда не переводится дословно. некоторые слова могут выпасть, другие- добавиться. Кто- то поставит лишний пробел, запятую и т.д
Все это может привести к тому, что на каждое предложение будет выдано несколько десятков, а может и сотня вариантов, включая ошибочные, включая скажем и те в которых кириллическая буква "а" заменена латинской буквой "a". И может оказаться что хорошему переводчику легче перевести самому, а средние и плохие будут заполнять базу плохими переводами.

Ну, а так, конечно, всяческих успехов :)
...
Рейтинг: 0 / 0
05.05.2006, 21:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33711971
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
S.G.Скорость СУБД тут, имхо, последнее дело. Не знаю, знаком ли автор с проблемами машинного перевода. И в частности, с неоднозначностями естественных языков. У меня тут статья, линк к которой я в инете, к сожалению, не нашел, поэтому, просто перепишу пару абзацев:
1. "лексикальная" неоднозначность. слово имеет более одного значения. Например, "Stay away from the bank", может означать совет инвестору стоять подальше от банка, или совет ребенка стоять подальше от берега.
2. "структурная" неоднозначность. - неоднозначность скрыта в комбинации слов. Например: "He saw that gasoline can explode" - "Он увидел, что бензин может взорваться", или "он увидел, что тот бидон с бензином взорвался".
3. "глубинная неоднозначность". Два предложения могут иметь одну и ту же грамматическую структуру, но иметь разный смысл. Например: "The chickens are ready to eat". Понятно что кто-то готов съесть что-то, но цыплята здесь- это кто-то или что-то?
И так далее, пять типов неоднозначностей.
Кроме того, при реальных переводах никогда не переводится дословно. некоторые слова могут выпасть, другие- добавиться. Кто- то поставит лишний пробел, запятую и т.д
Все это может привести к тому, что на каждое предложение будет выдано несколько десятков, а может и сотня вариантов, включая ошибочные, включая скажем и те в которых кириллическая буква "а" заменена латинской буквой "a". И может оказаться что хорошему переводчику легче перевести самому, а средние и плохие будут заполнять базу плохими переводами.

Ну, а так, конечно, всяческих успехов :)


Вот это все будет учитывать программа. Только она не будет вдаватся в смысл предложений, а будет использовать статистику. Она будет хранить все варианты переводов, которые когда либо будут вносится Пользователями.
Например:
This is a computer - Булочная есть сегодня быТь закрыт.

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

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

1. Например, исходный текст нужно будт привести в нормальный текстовой формат, а после разбить его на абзацы, предложения, слова и разделительные знаки.
2. По словам и фразам нужно будет определить тематику более вероятную.
3. Составить план перевода каждого предложения. (Тут очень много сложностей)
4. Выбрать наиболее подходящие слова по оценочной функции и сделать перевод.
5. Дать самому пользователю внести необхдимые измнения как в оригинале так и в переводе и все пустить по новой.
...
Рейтинг: 0 / 0
06.05.2006, 08:19
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33711980
LittleCat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LittleCat
Участник
Victor Metelitsa Sergei ObrastsovИнтересно было бы узнать источник этой информации. :)
Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом. Ну, например, 15,000,000 записей в MS SQL занимают 3.5 Gb
(19 полей переменной длины). Cache в этом объеме умещает 30,000,000
таких записей + 240,000,000 дополнительных индексов для быстрой
выборки. Сергей
Каким же образом это возможно? У Кэшэ байт из 16 битов?
Нет, у каше технология сжатия ключей ;-)
...
Рейтинг: 0 / 0
06.05.2006, 08:30
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33711987
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
автор
...
Рейтинг: 0 / 0
06.05.2006, 08:34
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33711991
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
У меня еще один вопрос.

По большей части я думаю, этот вопрос относится к Web возможностям, но и SQL часть тоже присуствует.

На странице два текстовых поля. В первом оригинал - во втором перевод.
В случае если пользователь вделяет предложение в оригинале целиком, то его перевод в о втором текстовом поле также выделяется цветом.

Эту вещь можно написать на JavaScript, но есть одно но. Для каждого предложения нужно будет передавать всю служебную информацию. А это будет очень много если текст большой.

Можно ли сделать красиво на базе SQL 2005, Oracle, Cache, что когда пользователь выделяет одно предложение, то web страничка отправляет запрос, получает всю необходимую инфу по оригиналу и переводу предложения и сама выделяет переведенное предложение, но без перегрузки всей страницы?
...
Рейтинг: 0 / 0
06.05.2006, 08:36
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712037
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
Несколько реплик и вопросов.
luraTMDM снимает все ограничения, накладываемые двумерными реляционными моделями данных, ведь если реляционная модель состоит из большого количества таблиц, что необходимо при работе со сложными структурами данных, это существенно усложняет и замедляет выполнение сложных транзакций и ведет к хранению излишней информации.

Двумерные реляционные таблицы используют простую для понимания математическую модель, пригодную для достаточно простых приложений и запросов. Однако, в реальной ситуации представляемая в базе данных информация многомернаБезграмотная писанина. Фраза «двумерными реляционными моделями данных» говорит о многом. Во-первых, писавший уверен, что реляционных моделей данных много. Во-вторых, он думает, что к понятию «модель данных» приложимо понятие «измерение/размерность». И при этом РМД почему-то именно двумерная. Автор непостижимым образом уверен, что количество таблиц каким-то образом влияет на транзакции. Что «большое количество таблиц» ведет к «хранению излишней информации».
Фраза про «двумерные»/«плоские» реляционные таблицы вообще традиционный показатель слабого понимания. Да, физически нарисованная на бумаге таблица — плоская, потому, что плоский лист бумаги. Но логическая R-таблица , а точнее отношение вообще не имеет измерений, ни двух, ни одного, ни двухсот. И, кстати, если уж приспичит говорить про многомерность, то кортежи отношения с N атрибутами представляют точки N -мерного пространства. Говорить же, что «информация многомерна» — в общем случае бессмыслица. Короче, несмотря на утверждение про «простую для понимания математическую модель», для авторов она оказалась слишком сложной, не осилили.

Sergei Obrastsovтеперь о деревьях. в принципе, "реляционные модели" - тоже деревья. Только двухуровневые. поэтому не надо ахать "ой, 2 или n деревьев", в РСУБД та же фигня. :)
Sergei Obrastsovтаблицы легко представляются в "деревьях", первый уровень - индекс, второй - номер записи. почему "дерево"? потому что похоже на елку, если нарисовать (особенно отношение "1:any"). :) почему только два уровня? потому что такие таблицы, там только одно отношение. если индекс составной, то он скомбинирован. так он выглядит логически, так он сделан и физически. за исключением исходных данных, там только один уровень (номер записи)Читая эти вещи так ничего и не понял. Ведь в отношениях нет ни индексов, ни номеров записей. Не могли бы вы изложить свою мысль более формально? Для начала пояснить, что вы понимаете под деревом? Если это то, что понимается в математике (теории графов), то опишите строгое соответствие между понятиями из РМД (домен, атрибут, кортеж, отношение) и из теории графов (вершина, ребро). Сразу станет ясна ваша мысль.
Укажу лишь, что в таком аспекте любое дерево и вообще любой граф представляется одним отношением (таблицей смежности).
...
Рейтинг: 0 / 0
06.05.2006, 09:10
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712222
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
tygra авторхочешь универсальности
и удобств - оставайся на том, на чем работаешь, но смирись с ограничениями.
А с какими ограничениями? По сравнению с Кэш например

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

С уважением. Сергей
...
Рейтинг: 0 / 0
06.05.2006, 10:13
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712273
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Sergei Obrastsov tygra авторхочешь универсальности
и удобств - оставайся на том, на чем работаешь, но смирись с ограничениями.
А с какими ограничениями? По сравнению с Кэш например

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

С уважением. Сергей
Вау, как доказательно то! И не опровергнуть
Хотя многие пытались доказать это, но не смогли - плохо знали РСУБД

-- Tygra's --
...
Рейтинг: 0 / 0
06.05.2006, 10:25
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712295
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
IuraВот это все будет учитывать программа. Только она не будет вдаватся в смысл предложений, а будет использовать статистику. Она будет хранить все варианты переводов, которые когда либо будут вносится Пользователями.

ты вот зря его не слушаешь, он дело говорит.


2. По словам и фразам нужно будет определить тематику более вероятную.
3. Составить план перевода каждого предложения. (Тут очень много сложностей)
4. Выбрать наиболее подходящие слова по оценочной функции и сделать перевод.

ты все-таки собираешься делать переводы по словам?
"Я ты давать курить"?

Ты просто убъешь лишней информацией базу.

С уважением. Сергей
...
Рейтинг: 0 / 0
06.05.2006, 10:28
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712307
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
По поводу самой технологии системы перевода - действительно, чудовищно все задумано. Так, как представлено, работать не будет, даже сейчас видно.
Невозможно правильно перевести по словам - но в смысле предложения.
Особенно невозможно перевести предложение и разбить его на слова с переводом - потому что перевод не обязательно совпадет по количеству слов и уж тем более редко совпадет по распложению.
Ну и много всего такого

Утопическая задача.

-- Tygra's --
...
Рейтинг: 0 / 0
06.05.2006, 10:32
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712312
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
tygra Sergei Obrastsov tygra авторхочешь универсальности
и удобств - оставайся на том, на чем работаешь, но смирись с ограничениями.
А с какими ограничениями? По сравнению с Кэш например

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

С уважением. Сергей
Вау, как доказательно то! И не опровергнуть
Хотя многие пытались доказать это, но не смогли - плохо знали РСУБД

-- Tygra's --
без эмоций не получается? :) значит доказать не смогли? ладно, я тут
недавно давал расклад, во что превращается 18 млн. записей с одним
индексом в SQL и Cache. теперь твоя очередь доказывать мне, что я
не прав.

С уважением. Сергей
...
Рейтинг: 0 / 0
06.05.2006, 10:32
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712333
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Sergei Obrastsov IuraВот это все будет учитывать программа. Только она не будет вдаватся в смысл предложений, а будет использовать статистику. Она будет хранить все варианты переводов, которые когда либо будут вносится Пользователями.

ты вот зря его не слушаешь, он дело говорит.


2. По словам и фразам нужно будет определить тематику более вероятную.
3. Составить план перевода каждого предложения. (Тут очень много сложностей)
4. Выбрать наиболее подходящие слова по оценочной функции и сделать перевод.

ты все-таки собираешься делать переводы по словам?
"Я ты давать курить"?

Ты просто убъешь лишней информацией базу.

С уважением. Сергей

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

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

Сергей, а как на счет последнего вопроса по Web страничкам?
Возможно это сделать на Cache ?
...
Рейтинг: 0 / 0
06.05.2006, 10:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712422
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
mirБезграмотная писанина. Фраза «двумерными реляционными моделями данных» говорит о многом. Во-первых, писавший уверен, что реляционных моделей данных много. Во-вторых, он думает, что к понятию «модель данных» приложимо понятие «измерение/размерность». И при этом РМД почему-то именно двумерная. Автор непостижимым образом уверен, что количество таблиц каким-то образом влияет на транзакции. Что «большое количество таблиц» ведет к «хранению излишней информации».

видимо не ведет? или это считается "неизбежным"?


Фраза про «двумерные»/«плоские» реляционные таблицы вообще традиционный показатель слабого понимания. Да, физически нарисованная на бумаге таблица — плоская, потому, что плоский лист бумаги. Но логическая R-таблица , а точнее отношение вообще не имеет измерений, ни двух, ни одного, ни двухсот. И, кстати, если уж приспичит говорить про многомерность, то кортежи отношения с N атрибутами представляют точки N -мерного пространства. Говорить же, что «информация многомерна» — в общем случае бессмыслица. Короче, несмотря на утверждение про «простую для понимания математическую модель», для авторов она оказалась слишком сложной, не осилили.

что ж, действительно "ниасилил".

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

серьезно? а что там есть? там есть только X и Y? мы говорим о практической
реализации, если это не видно с первого раза


Для начала пояснить, что вы понимаете под деревом? Если это то, что понимается в математике (теории графов), то опишите строгое соответствие между понятиями из РМД (домен, атрибут, кортеж, отношение) и из теории графов (вершина, ребро). Сразу станет ясна ваша мысль.
Укажу лишь, что в таком аспекте любое дерево и вообще любой граф представляется одним отношением (таблицей смежности).
давай я не буду этого делать. теорию я оставляю тебе. я - практик, и
говорю о таких же вещах. если тебе что-то не нравится - можешь
сказать, я приму к сведению, ага
(только умствований мне для полного счастья не хватало)
...
Рейтинг: 0 / 0
06.05.2006, 11:00
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712467
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
IuraСергей - я не исключаю, что в базе будет 90% ерунды.
Поэтому я полагю разделить базу данных на две части

и это тебя спасет? 32 Tb пополам - это 2 раза по 16 Tb. :)


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

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


Сергей, а как на счет последнего вопроса по Web страничкам?
Возможно это сделать на Cache ?
это не ко мне, я не занимаюсь Web-интерфейсами. но если
это вообще можно сделать, то в Cache это тоже получится.

С уважением. Сергей
...
Рейтинг: 0 / 0
06.05.2006, 11:11
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712496
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Sergei Obrastsovбез эмоций не получается? :) значит доказать не смогли? ладно, я тут
недавно давал расклад, во что превращается 18 млн. записей с одним
индексом в SQL и Cache. теперь твоя очередь доказывать мне, что я
не прав.

С уважением. Сергей
Это не эмоции, это факты.
Я почитал про 18 млн. записей - вывода только не нашел.
У нас вот полтора миллиона записей занимают почти 2 гига, и еще почти гиг индексы - это плохо или хорошо? По вашему наверное плохо - сильно много. А по мне хорошо - скорость выборок данных не напрягает.
Но одна фраза была интересна:
авторТеперь дело за SQL. В наличии оказался только My SQL (ну, что есть).
Т.е. если например я начну сравнивать MS SQL с Кэшом, то это будет так:
т.к. у меня Кэша нет, я возьму Excel вместо него (ну что уж есть)
Ооооо!!!! Кошмар!!! Эксел больше 64000 строк не дает залить!!! Ну, все понятно с вашим Кэшом, г.... он, больше 64000 строк не может осилить.

Но даже и это не важно.
Результат, который должен быть - это не количество индексов, строк, деревьев, объем и т.д. Результат - это скорость получения данных оттуда, где они хранятся.
Такого сравнения нет. И обычно не бывает - ООБД-исты сразу забывают русский язык и все остальное, добиться от них алгоритма и теста на скорость разных выборок невозможно. Уже несколько раз пробовали - не получилось, молчат, как партизаны, только бубнят: а у нас лучше в n раз, но не покажем как это выглядит.

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

======

Меня вот чего мучает :)
Sergei Obrastsovнарод, надо все-таки внимательнее читать, ага. который раз повторяю, что
в M-системах нет фиксированных моделей структур. как и языка запросов
к ним. все что нужно программисту - он делает самостоятельно. как он
сформирует интерфейс между пользователем и БД, как спроектирует саму
БД - так все это дело и будет работать.
Sergei ObrastsovP.S. Можно еще поразмыслить над структурой, но для этого надо
увидеть весь спектр желаемых тобой запросов. :)
Т.е. я правильно понимаю, что под каждый вариант запросов нужно делать еще одну структуру куда дублировать все данные, что есть?
Это называется круто?
Вы с обычными РСУБД когда-нибудь работали по-настоящему?

-- Tygra's --
...
Рейтинг: 0 / 0
06.05.2006, 11:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712516
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
tygra Sergei Obrastsovбез эмоций не получается? :) значит доказать не смогли? ладно, я тут
недавно давал расклад, во что превращается 18 млн. записей с одним
индексом в SQL и Cache. теперь твоя очередь доказывать мне, что я
не прав.

С уважением. Сергей
Это не эмоции, это факты.
Я почитал про 18 млн. записей - вывода только не нашел.
У нас вот полтора миллиона записей занимают почти 2 гига, и еще почти гиг индексы - это плохо или хорошо? По вашему наверное плохо - сильно много. А по мне хорошо - скорость выборок данных не напрягает.
Но одна фраза была интересна:
авторТеперь дело за SQL. В наличии оказался только My SQL (ну, что есть).
Т.е. если например я начну сравнивать MS SQL с Кэшом, то это будет так:
т.к. у меня Кэша нет, я возьму Excel вместо него (ну что уж есть)
Ооооо!!!! Кошмар!!! Эксел больше 64000 строк не дает залить!!! Ну, все понятно с вашим Кэшом, г.... он, больше 64000 строк не может осилить.

Но даже и это не важно.
Результат, который должен быть - это не количество индексов, строк, деревьев, объем и т.д. Результат - это скорость получения данных оттуда, где они хранятся.
Такого сравнения нет. И обычно не бывает - ООБД-исты сразу забывают русский язык и все остальное, добиться от них алгоритма и теста на скорость разных выборок невозможно. Уже несколько раз пробовали - не получилось, молчат, как партизаны, только бубнят: а у нас лучше в n раз, но не покажем как это выглядит.

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

======

Меня вот чего мучает :)
Sergei Obrastsovнарод, надо все-таки внимательнее читать, ага. который раз повторяю, что
в M-системах нет фиксированных моделей структур. как и языка запросов
к ним. все что нужно программисту - он делает самостоятельно. как он
сформирует интерфейс между пользователем и БД, как спроектирует саму
БД - так все это дело и будет работать.
Sergei ObrastsovP.S. Можно еще поразмыслить над структурой, но для этого надо
увидеть весь спектр желаемых тобой запросов. :)
Т.е. я правильно понимаю, что под каждый вариант запросов нужно делать еще одну структуру куда дублировать все данные, что есть?
Это называется круто?
Вы с обычными РСУБД когда-нибудь работали по-настоящему?

-- Tygra's --

Тигра - форму- это не подиум, где восхваляют свои знания.

Давай сам сделай реальный маленький проект на Cache и SQL и сравни результаты. А то ты слишком перегибаешь в критике. Может быть ты и прав, но манера говорить добавляет в бочку меда ведро дегтя.
...
Рейтинг: 0 / 0
06.05.2006, 11:27
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712538
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Sergei Obrastsovбез эмоций не получается? :) значит доказать не смогли? ладно, я тут
недавно давал расклад, во что превращается 18 млн. записей с одним
индексом в SQL и Cache. теперь твоя очередь доказывать мне, что я
не прав.

С уважением. СергейВроде Вы показали размер БД в MS SQL server'e, а это ДАЛЕКО не все представители рода SQL-ного.

Причем во-первых, её также можно сжать (сделать денормализацию) и свести к одному столбцу.
Во-вторых MS SQL server ОЧЕНЬ не оптимально хранит данные. По месту стоит сравнивать с Sybase ASA. вроде примерно в 2-3 раза меньше места занимают, чем в MS SQL-e.

И вообще главное это отношение место (объем требуемых носителей и их цена) / скорость (как быстро мы можем получить/ изменить данные)
...
Рейтинг: 0 / 0
06.05.2006, 11:33
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712569
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
ошибся не MS SQL, а MySQL.

принцип не меняется
...
Рейтинг: 0 / 0
06.05.2006, 11:39
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712583
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
авторя, видимо, плохо объясняю. :(
как работает SQL в этом случае? видимо, выбирая первичным индексом
для выборки то поле, которое позволит сузить количество обращений к базе.
ну а почему я должен действовать по-другому?

в этом случае структура превращается в вариант:

^x("d",n)=данные
^x("i1",i1,i2,i3)=n
^x("i2",i2,i1,i3)=n
^x("i3",i3,i1,i2)=n

что позволяет делать то, что хочешь ты, но неоптимально по размеру
ok, предложим другой:

^x("d",n)=данные
^x("i1",i1,n)=
^x("i2",i2,n)=
^x("i3",i3,n)=

в результате выборка сводится к варианту:
при известном i3 выбрать все n относящиеся к нему
если понадобится добавить условия на i1 и i2, тогда к предыдущему
действию добавляется проверка на наличие n по веткам "i1",i1 и
"i2",i2

С уважением. Сергей

P.S. Можно еще поразмыслить над структурой, но для этого надо
увидеть весь спектр желаемых тобой запросов. :)



Помнишь на странице 4-6 я тебя спрашивал что данные или запросы пользоватлей могут изменится и тебе придется переписывать код добавлять новые структуры.

Ты сам это подтверждаешь.

В случае с реляционной БД, нужно будет построить еще один индекс который позволит иметь мне необходимую производительность на новом классе запросов.
И не надо. Глупо переписывать код когда можно поменять административно в одном месте. Да это будет затратно с точки зрения места на диске. Но любую ситуацию можно рассматривать применяя к ней фразу
Nothing free, nothing new, no magic.
И реляционный подход позволят достичь приемлемый результат бестрее в разы.
Ты с каше возможно сделашь, что это будет быстрее работать быстрее. Только тебе времении в разы больше потребуются.
...
Рейтинг: 0 / 0
06.05.2006, 11:44
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712596
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Уж до кучи: на ASA так же встроенный веб-сервер, который к примеру вешается на 80-ый порт и спокойно позволяет организовать работу с HTML (сайты) и XML (SOAP). Логика управления работой веб-сервера находится прямо в базе на языке хранимых процедур ASA, так что спокойно можно делать свои сайты и веб-сервисы, а так же работать с чужими веб-сервисами. Причем поддерживается все - от управления HTTP-заголовков, работой с HTTP-переменными, передачей данных через POST/GET/RCP/DOC до встроенных авторизации и поддержкой сертификатов для создания защищенных каналов. Это при том, что сам Engine ASA весит 10 мб и стоит по процессорным лицензиям копейки по сравнению с другими СУБД. Так что если и хочется сравниваться с РСУБД, welcome to ASA, особенно с новой 10-ой версией - тут мы готовы и веб и версионность и мат представления и кластеры и скорость - все что угодно сравниваться, для сервера это только на пользу :)
...
Рейтинг: 0 / 0
06.05.2006, 11:48
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712648
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
tygraЭто не эмоции, это факты.

okey-dokey, оценим факты.


Я почитал про 18 млн. записей - вывода только не нашел.

вывод там был, просто я не рисовал его гигантскими буквами и в цвете.
зачем?
18 млн.записей c одним индексом в My SQL уходят за 4Gb, в Cache - 1.15Gb


У нас вот полтора миллиона записей занимают почти 2 гига, и еще почти гиг индексы - это плохо или хорошо? По вашему наверное плохо - сильно много. А по мне хорошо - скорость выборок данных не напрягает.

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


Т.е. если например я начну сравнивать MS SQL с Кэшом, то это будет так:
т.к. у меня Кэша нет, я возьму Excel вместо него (ну что уж есть)
Ооооо!!!! Кошмар!!! Эксел больше 64000 строк не дает залить!!! Ну, все понятно с вашим Кэшом, г.... он, больше 64000 строк не может осилить.

знаешь, даже не смешно, а просто глупо. тогда уж возьми Access, он хоть
где-то на БД похож. My SQL - это тоже SQL, хоть и простенький. нижний
уровень у них примерно одинаковый. если хочешь меня опровергнуть -
растиражируй данную мной строку 18 млн. раз и засунь в таблицу.
получишь 2-3 гига вместе с индексом, я извинюсь перед всеми за дезу
и попрошу научить меня так делать.


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

речь ИЗНАЧАЛЬНО шла об объеме хранимой информации. поэтому не надо
меня обвинять в том, чего я не делал.


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

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


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

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


Т.е. я правильно понимаю, что под каждый вариант запросов нужно делать еще одну структуру куда дублировать все данные, что есть?
Это называется круто?

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


Вы с обычными РСУБД когда-нибудь работали по-настоящему?

да, много. работаю и сейчас

С уважением. Сергей
...
Рейтинг: 0 / 0
06.05.2006, 12:00
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712663
Andreww
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andreww
Участник
2 Sergei Obrastsov

>>Вы с обычными РСУБД когда-нибудь работали по-настоящему?

>да, много. работаю и сейчас

И как там "номера" ?

На ёлку похожи ?

))))))))))))))))))))))))

Работайте на здоровье, с такими "конкурентами" в лице КЭША и прочих МУМУ никаких препядствий для РСУБД пока не видно.
...
Рейтинг: 0 / 0
06.05.2006, 12:05
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712669
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Nikolay KulikovПомнишь на странице 4-6 я тебя спрашивал что данные или запросы пользоватлей могут изменится и тебе придется переписывать код добавлять новые структуры.
Ты сам это подтверждаешь.
В случае с реляционной БД, нужно будет построить еще один индекс который позволит иметь мне необходимую производительность на новом классе запросов.
И не надо. Глупо переписывать код когда можно поменять административно в одном месте. Да это будет затратно с точки зрения места на диске. Но любую ситуацию можно рассматривать применяя к ней фразу
Nothing free, nothing new, no magic.
И реляционный подход позволят достичь приемлемый результат бестрее в разы.
Ты с каше возможно сделашь, что это будет быстрее работать быстрее. Только тебе времении в разы больше потребуются.
смешной ты. я просто реализую в этом случае "реляционный подход"
и получу уже абасолютно индексированную базу данных, не требующую
никакой корректировки и способную на отработку любых запросов.
и даже в этом случае она будет весить намного меньше и работать
быстрее.

ну что вы как дети, ей богу? :))

С уважением. Сергей
...
Рейтинг: 0 / 0
06.05.2006, 12:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712675
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
>>Т.е. я правильно понимаю, что под каждый вариант запросов нужно делать еще одну структуру куда дублировать все данные, что есть?

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

Ответы то ведь Вам простые и ясные дают.
Вот давайте проверим, что будет непонятно в следующем ответе?

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

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

А что, при проектировании реляционных баз всё иначе?
...
Рейтинг: 0 / 0
06.05.2006, 12:07
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712710
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
ASCRUSУж до кучи: на ASA так же встроенный веб-сервер, который к примеру вешается на 80-ый порт и спокойно позволяет организовать работу с HTML (сайты) и XML (SOAP).

А вот из вашего лагеря вам же ответ :)

tygraОднако иметь сервер БД в открытом доступе для всего инета - это умно, ничего не скажешь :))

-- Tygra's --


Если это про Каше - значит плохо
Если это же самое про ASA - значит хорошо
Ситуация понятна.. - "ворон ворону глаз не выклюет"
...
Рейтинг: 0 / 0
06.05.2006, 12:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712723
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
yww@escape.ru ASCRUSУж до кучи: на ASA так же встроенный веб-сервер, который к примеру вешается на 80-ый порт и спокойно позволяет организовать работу с HTML (сайты) и XML (SOAP).

А вот из вашего лагеря вам же ответ :)

tygraОднако иметь сервер БД в открытом доступе для всего инета - это умно, ничего не скажешь :))

-- Tygra's --


Если это про Каше - значит плохо
Если это же самое про ASA - значит хорошо
Ситуация понятна.. - "ворон ворону глаз не выклюет"
Это где это там наш лагерь ? Я с MSSQL не работаю уже давно, но могу твердо подтвердить слова Тигры - иметь в открытом доступе БД на MSSQL для всего интернета - это умно, ничего не скажешь. Однако ... для всех остальных эти слова будут интерпретироваться в зависимости от того, для чего сервер открыт в интернете и какой это сервер.
...
Рейтинг: 0 / 0
06.05.2006, 12:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712737
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
Вот такое вот размышление на тему "как устроена секта?"

Составляющие секты:
1. Основатель - "Батя"
2. Учение - "Батя сказал"
3. Деятельность - "Мы делаем как Батя сказал"
4. Логика - "Правильно только то, что Батя сказал. Потому - что так сказал Батя"

Если посмотреть с такой точки зрения на ругательства типа "МАМПСИСТЫ - сектанты", то видно, что кроме эмоций в нём ничего нет.. потому что нет Бати, и нет догматического учения. Есть только практическая деятельность, которая логически приводит М-программистов к выводу что их технологии и эффективны и оправданы..

Если же такое ругательство применить к фанатам SQL, то найдётся всё, от Бати, до Логики.. тогда кто тут сектанты?
...
Рейтинг: 0 / 0
06.05.2006, 12:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712768
Hima
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hima
Гость
стоит добавить, что Cache позволяет работать с различными web-серверами(что по моему мнению больше плюс, чем минус), но может работать и без них, используя собственный (по умолчанию он на 1972 порту, но кто вам мешает настроить на 80?).



2Iura: насчет web'а...можно пойти двумя путями:
1) писать csp страничку, используя гиперивенты (которые вызываться будут при выделении текста будут вызывать cos'овские обработчики)

2) писать csp страничку и , скажем используя ту же технологию ajax, JavaScript'ом обращаться к другой csp-страничке, в которой будет находиться нужный обработчик.
...
Рейтинг: 0 / 0
06.05.2006, 12:31
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712784
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
ASCRUSУж до кучи: на ASA так же встроенный веб-сервер, который к примеру вешается на 80-ый порт и спокойно позволяет организовать работу с HTML (сайты) и XML (SOAP). Логика управления работой веб-сервера находится прямо в базе на языке хранимых процедур ASA, так что спокойно можно делать свои сайты и веб-сервисы, а так же работать с чужими веб-сервисами. Причем поддерживается все - от управления HTTP-заголовков, работой с HTTP-переменными, передачей данных через POST/GET/RCP/DOC до встроенных авторизации и поддержкой сертификатов для создания защищенных каналов. Это при том, что сам Engine ASA весит 10 мб и стоит по процессорным лицензиям копейки по сравнению с другими СУБД. Так что если и хочется сравниваться с РСУБД, welcome to ASA, особенно с новой 10-ой версией - тут мы готовы и веб и версионность и мат представления и кластеры и скорость - все что угодно сравниваться, для сервера это только на пользу :)

Что за зверь АСА?
Дай больше инфы.
...
Рейтинг: 0 / 0
06.05.2006, 12:34
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712814
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Himaстоит добавить, что Cache позволяет работать с различными web-серверами(что по моему мнению больше плюс, чем минус), но может работать и без них, используя собственный (по умолчанию он на 1972 порту, но кто вам мешает настроить на 80?).



2Iura: насчет web'а...можно пойти двумя путями:
1) писать csp страничку, используя гиперивенты (которые вызываться будут при выделении текста будут вызывать cos'овские обработчики)

2) писать csp страничку и , скажем используя ту же технологию ajax, JavaScript'ом обращаться к другой csp-страничке, в которой будет находиться нужный обработчик.


Пожалуйста, если возможно дай побольше инфы по CSP и ajax. Сайт с описанием (желательно на русском).
...
Рейтинг: 0 / 0
06.05.2006, 12:40
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712831
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
IuraЧто за зверь АСА?
Дай больше инфы.
Вот про ASA
http://www.sybase.ru/Syb/products/databases/asa.htm
ASA поставляется в составе пакета Sybase SQL Anywhere Studio.

Вот рядом есть форум
http://www.sql.ru/forum/actualtopics.aspx?bid=30
...
Рейтинг: 0 / 0
06.05.2006, 12:44
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712867
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Таки я не понимаю - на чем основывается утверждение, что Кэш быстрее РСУБД (некоторые счиатют, что аж в разы)?

Есть такие, кто сравнивал?

Я ж не говорю, что РСУБД в разы быстрее Кэша и т.п.
Но пока что я вижу, что в Кэше от запроса зависит структура хранения данных. Сказки про оптимальную структуру не надо рассказывать - если есть заведомо 3 разных запроса, которые заведомо требуют разную структуру, то никакой оптимальной структуры вы не построите. Может построите индексы? Ну тады чем хуже индексы РСУБД?

Эх, сравнить бы.....
Да как сравнишь - нужна боевая нагрузка.

-- Tygra's --
...
Рейтинг: 0 / 0
06.05.2006, 12:51
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712881
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
вообще-то, митрополит Кирил давал другое определение секты.
Дословно приводить не берусь, но смысл - различие в методах.

А вы сами определение придумали?

Методы мумпсистов очень похожи, включая знаменитое "А вот при личной встрече"
Вот и выходит, что если результатами - никак, то будем зомбированием.
...
Рейтинг: 0 / 0
06.05.2006, 12:55
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712886
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
tygraТаки я не понимаю - на чем основывается утверждение, что Кэш быстрее РСУБД (некоторые счиатют, что аж в разы)?

Есть такие, кто сравнивал?

-- Tygra's --

Ну вот сравнение http://www.intersystems.ru/cache/analysts/reviews/cache_vs_rdbms.html
ясное дело, что лично Вас оно ни вчём не убедит.
...
Рейтинг: 0 / 0
06.05.2006, 12:56
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712898
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
ggvвообще-то, митрополит Кирил давал другое определение секты.
Дословно приводить не берусь, но смысл - различие в методах.

А вы сами определение придумали?

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

Ну конечно сам.. Батя - митрополит Киррил тут не причём..

Но, Вы слишком серьёзно к определению то не относитесь.. это я так.. что бы люди следили за словами.. всё таки аргументация здесь (на этом форуме) больше пользы бы приносила чем ругань.
...
Рейтинг: 0 / 0
06.05.2006, 12:59
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712909
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
tygra - дык чал на любой вопрос, что вы будете делать в такой ситуации и как извлекать такие данные, неизменно отвечал - ну кто же этого не знает, это же общеизветсно, и не может не быть не отражено в структуре данных! Конечно эе это у меня будет отражено в структуре данных!
И нтересные они люди - они ВСЕ способны описать в своей структуре, это же какая силища!
Только мир у них какой-то статичный получается.
Зато никаких алгоритмов анализа не надо, ведь мир описан, и так все известно...
Хм, написал, и сам удивился - может, поэтому и нет на М аналитических систем?
В которых применяются всяческие статистические алгоритмы поиска информации из данных, заранее неизвестной информации...
Наверное да, не нужны такие М системы - у ник просто нет заранее неизвестных данных, уже все известно и описано.
А вот чудаки из ритейловых сетей делают анализ поведения покупателей, из банковской сферы - анализ рисков выдачи кредитов, в машиностроительной отрасли - анализ рисков получения брака....
И, что интересно, делают анализ реляционных данных...
...
Рейтинг: 0 / 0
06.05.2006, 13:01
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712912
Hima
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hima
Гость
Iura
Пожалуйста, если возможно дай побольше инфы по CSP и ajax. Сайт с описанием (желательно на русском).
У Cache инфы на русском очень мало. Могу посоветовать обзоры от разработчиков . А csp и ajax работает точно также как и ajax с любым другим языком.
...
Рейтинг: 0 / 0
06.05.2006, 13:01
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712916
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
yww@escape.ru tygraТаки я не понимаю - на чем основывается утверждение, что Кэш быстрее РСУБД (некоторые счиатют, что аж в разы)?

Есть такие, кто сравнивал?

-- Tygra's --

Ну вот сравнение http://www.intersystems.ru/cache/analysts/reviews/cache_vs_rdbms.html
ясное дело, что лично Вас оно ни вчём не убедит.

Я тут как-то утром к зеркалу подошел - ну не иначе олимпийский чемпион!

А по делу - где результаты формальных общепризнанных тестов?
TPC-C, TPC-H, SAP?
Я понимаю, эти вопросы уже оскомину набили, но вы сами с "результатами тестов" начали.
...
Рейтинг: 0 / 0
06.05.2006, 13:03
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712937
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
tygraТаки я не понимаю - на чем основывается утверждение, что Кэш быстрее РСУБД (некоторые счиатют, что аж в разы)?

на фактах, которые есть вещь упрямая. причем чем больше размер базы, тем
заметнее будет опережение Cache.


Есть такие, кто сравнивал?

я. но ты же мне верить не будешь. :)


Но пока что я вижу, что в Кэше от запроса зависит структура хранения данных. Сказки про оптимальную структуру не надо рассказывать - если есть заведомо 3 разных запроса, которые заведомо требуют разную структуру, то никакой оптимальной структуры вы не построите. Может построите индексы? Ну тады чем хуже индексы РСУБД?

ррр.. не надо путать горячее с зеленым. или мягким? :)
оптимальная структура - это такая, которая позволит всем существующим
запросам получать нужную информацию за минимальное количество времени.
да, есть разновидность запросов, которые будут шерстить всю базу, в любом
ее воплощении, что SQL, что M, но на них и не ориентируются.

если я знаю, что запрос A требует одну структуру, запрос B - другую, а
запрос C - третью, я их все и совмещу в БД. и что тут непонятного?
с учетом вышеупомянутых обще-информационных запросов, я получу
оптимальную для данных мне запросов базу.


Эх, сравнить бы.....
Да как сравнишь - нужна боевая нагрузка.

сравни. у меня уже есть эта база. тебе я посоветовал как получить
такую же. что мешает? потом оценим скорости доступа и выборки.

С уважением. Сергей
...
Рейтинг: 0 / 0
06.05.2006, 13:12
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712950
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Да, тесты потрясающи.

Чего только стоит "одна известная РСУБД"!
Судя по примеру в этом топике, это вполне могла быть MySQL.
Но название привести не могут понятно почему - эта известная субд порвет Кэш на нормальных тестах как тузик грелку :)

Далее.
Я таки не понял - что за тесты такие: загрузка данных, создание таблиц....
Что за система такая, что в ней все юзеры только и загружают данные - но с ними не работают. Это в txt вообще быстро загрузить можно.

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

Еще добило это:
Код: plaintext
1.
2.
3.
4.
5.
Поиск по имени и улице  0 , 33  с  0 , 07  с  4  :  1  
Поиск по имени  0 , 46  с  0 , 02  с  23  :  1  
Поиск по имени, улице и почтовому индексу  0 , 76  с  0 , 04  с  19  :  1  
Поиск по номеру дома  0 , 14  с  0 , 02  с  7  :  1  
Поиск по имени, фамилии, улице и почтовому индексу  0 , 01  с  0 , 01  с  1  :  1  
Поиск по административно-территориальной единице  0 , 02  с  0 , 01  с  2  :  1
Далее нагло утверждается, что Для повышения скорости выполнения запросов в обеих базах данных использовались индексы
Ребяты, это уже не смешно, если есть индексы по каждому запросу, то время почти не будет меняться. Я вот проверил на 8 миллионах записей - 0.016 сек.

В общем, как же верить "тестам", которые писались маркетологами?

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

-- Tygra's --
...
Рейтинг: 0 / 0
06.05.2006, 13:16
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712954
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
ggv yww@escape.ru tygraТаки я не понимаю - на чем основывается утверждение, что Кэш быстрее РСУБД (некоторые счиатют, что аж в разы)?

Есть такие, кто сравнивал?

-- Tygra's --

Ну вот сравнение http://www.intersystems.ru/cache/analysts/reviews/cache_vs_rdbms.html
ясное дело, что лично Вас оно ни вчём не убедит.

Я тут как-то утром к зеркалу подошел - ну не иначе олимпийский чемпион!

А по делу - где результаты формальных общепризнанных тестов?
TPC-C, TPC-H, SAP?
Я понимаю, эти вопросы уже оскомину набили, но вы сами с "результатами тестов" начали.

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

А вот результаты формальных тестов я бы и сам с великим интересом посмотрел.. но не знаю. где их найти.
...
Рейтинг: 0 / 0
06.05.2006, 13:18
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712968
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
tygraЭх, сравнить бы.....
Да как сравнишь - нужна боевая нагрузка.

-- Tygra's --

Сотрудники Интерсистемс совсем недавно заявляли что готовы проводить такие сравнения.. да и вот это с их сайта
" Проведите собственный тест
InterSystems часто помогает клиентам и заинтересованным компаниям в проведении тестов, подобных упомянутым в данном обзоре. Если вы заинтересованы в тестировании Caché на предмет производительности или масштабируемости, InterSystems поможет Вам в проведении теста и бесплатно предоставит временные лицензии на Caché. За дополнительной информацией обращайтесь по телефону +7 (495) 967 00 88. "

могло бы Вам помочь разобраться с вопросом.. но ведь Вы не станете этого делать? Правда? Вам эе не нужно этого?
...
Рейтинг: 0 / 0
06.05.2006, 13:22
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712986
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
tygraДа, тесты потрясающи.

Чего только стоит "одна известная РСУБД"!

-- Tygra's --

Ну вот здесь одна из известных явно указана http://www.intersystems.ru/cache/analysts/analyst-reviews.html

хотя.. зачем это Вам? У Вас уже мнение сложилось.. единственное и правильное..
...
Рейтинг: 0 / 0
06.05.2006, 13:29
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33712997
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
автор
ррр.. не надо путать горячее с зеленым. или мягким? :)
оптимальная структура - это такая, которая позволит всем существующим
запросам получать нужную информацию за минимальное количество времени.
да, есть разновидность запросов, которые будут шерстить всю базу, в любом
ее воплощении, что SQL, что M, но на них и не ориентируются.

если я знаю, что запрос A требует одну структуру, запрос B - другую, а
запрос C - третью, я их все и совмещу в БД. и что тут непонятного?
с учетом вышеупомянутых обще-информационных запросов, я получу
оптимальную для данных мне запросов базу.




Упертый ты, до глупости... Я тебе говорю про то, что ты заранее предусматриваешь все возможные ситуации, я говорю что если появится ситуация которую ты не предусмотрел, то тебе все это менять будет сложнее чем в реляционке.
...
Рейтинг: 0 / 0
06.05.2006, 13:37
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713030
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Упертый ты, до глупости... Я тебе говорю про то, что ты заранее предусматриваешь все возможные ситуации, я говорю что если появится ситуация которую ты не предусмотрел, то тебе все это менять будет сложнее чем в реляционке.
уф, трудно... я же русским языком написал, что в случае "вариативных"
запросов, то есть когда может понадобиться ВСЕ и В ЛЮБОМ разрезе, я
и проиндексирую все. получится подобие "реляционной" БД. а когда я
говорил, что это плохо? :) она будет выглядеть, конечно, по-другому и
обрабатываться не похоже, но будет "идеологически" такой же.
ну что? снова непонятно? почему я изучаю запросы? чтобы сделать БД
более удобной для их обработки. и все-равно почему? потому что
M-система позволяет мне строить различные структуры. и все-равно
почему, если есть более быстрые машины и более толстые диски?
ну тогда мне остается только махнуть рукой и уйти до 10-го числа,
что я и делаю. :)

С уважением. Сергей
...
Рейтинг: 0 / 0
06.05.2006, 13:48
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713048
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
yww@escape.ru
Ну тогда, раз чемпион, воздерживайтесь от слов типа "дурацкие" и неаргументированных высказываний, типа "чистая ложь".. не по чемпионски как то это..

А вот результаты формальных тестов я бы и сам с великим интересом посмотрел.. но не знаю. где их найти.
1) Я такой же чемпион как и каше
2) Исходя из 1) я могу говорить и писать что угодно - (звиздеть не мешки ворочать)
3) И не будет результатов независимого тестирования.

Но мы всемерно выражаем радость и признательность за подвиги в информатизации зимбабве, уругвая, и прочих банановых республик, где результат систем на каше превзошел результаты на известных РДБМС в 20 и более раз.
...
Рейтинг: 0 / 0
06.05.2006, 13:51
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713066
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
Ладно не буду спорить, почитай про то что является проблемой
Американского здравоохранения.

http://www.developerdotstar.com/community/node/279
...
Рейтинг: 0 / 0
06.05.2006, 13:57
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713116
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
Sergei Obrastsov mirБезграмотная писанина. [...] Автор непостижимым образом уверен, что количество таблиц каким-то образом влияет на транзакции. Что «большое количество таблиц» ведет к «хранению излишней информации».видимо не ведет? или это считается "неизбежным"?А вы тоже считаете, что ведет?
Sergei Obrastsov mirФраза про «двумерные»/«плоские» реляционные таблицы вообще традиционный показатель слабого понимания. Да, физически нарисованная на бумаге таблица — плоская, потому, что плоский лист бумаги. Но логическая R-таблица , а точнее отношение вообще не имеет измерений, ни двух, ни одного, ни двухсот. И, кстати, если уж приспичит говорить про многомерность, то кортежи отношения с N атрибутами представляют точки N -мерного пространства. Говорить же, что «информация многомерна» — в общем случае бессмыслица. Короче, несмотря на утверждение про «простую для понимания математическую модель», для авторов она оказалась слишком сложной, не осилили.
что ж, действительно "ниасилил".Не очень понял ответ. Вы согласились, что автор текста неправ или вы не поняли, что я сказал?
Sergei Obrastsov mirЧитая эти вещи так ничего и не понял. Ведь в отношениях нет ни индексов, ни номеров записей. Не могли бы вы изложить свою мысль более формально?серьезно? а что там есть? там есть только X и Y? мы говорим о практической реализации, если это не видно с первого разаПро X и Y не понял. А если мы говорим о реализации, то пользователю СУБД по большому счету все равно, как там физическое хранение внутри устроено. Для РСУБД есть куча способов: хранение по строкам, хранение по столбцам, модель TransRelational, Index-organized tables, кластеризованное/некластеризованное хранение... Индексы тоже всякие. И еще что-нибудь изобретут, прогресс не стоит на месте. Но на логическом, более высоком уровне работать удобнее. К этому вроде вся история вычислительной техники идет: повышение уровня абстракции.

Sergei Obrastsovтеорию я оставляю тебе. я - практик, и говорю о таких же вещах. если тебе что-то не нравится - можешь сказать, я приму к сведению, ага (только умствований мне для полного счастья не хватало)Да я тоже практик, это тут не при чем. Ладно, бог с ним.
...
Рейтинг: 0 / 0
06.05.2006, 14:09
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713139
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
yww@escape.ruВот такое вот размышление на тему "как устроена секта?"

Составляющие секты:
1. Основатель - "Батя"
2. Учение - "Батя сказал"
3. Деятельность - "Мы делаем как Батя сказал"
4. Логика - "Правильно только то, что Батя сказал. Потому - что так сказал Батя"

Если посмотреть с такой точки зрения на ругательства типа "МАМПСИСТЫ - сектанты", то видно, что кроме эмоций в нём ничего нет.. потому что нет Бати, и нет догматического учения. Есть только практическая деятельность, которая логически приводит М-программистов к выводу что их технологии и эффективны и оправданы..

Если же такое ругательство применить к фанатам SQL, то найдётся всё, от Бати, до Логики.. тогда кто тут сектанты?А можно все же расшифровочку, что у вас там "найдется" применительно к РМД? По всем пунктам?
Особенно если вспомнить, что "догматическое" реляционное "учение" не более и не менее чем приложение математики и логики. Хороша "догматика". А кто, интересно, "Батя"?
...
Рейтинг: 0 / 0
06.05.2006, 14:18
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713153
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
Nikolay KulikovЛадно не буду спорить, почитай про то что является проблемой
Американского здравоохранения.
http://www.developerdotstar.com/community/node/279
Суперски написано, давно и с удовольствием почитываю этот текст, время от времени доставая из закладок. Очередные SQLоки.

авторWeakly-typed languages cause unnecessary bugs because the compiler cannot prevent meaningless combinations of operations and data...
Один умник (Эдгар Дейкстра) как-то влип в историю (влип к моему большому сожалению, толковый малый был) с отрицанием goto. Теперь тут некоторые посетители форума хотят влипнуть в историю с отрицанием циклов. Этот видимо захотел влипнуть с отрицанием языков которые он плохо понимает. По меньшей мере внимание к своему блогу он уже заслужил.

Читаю и перечитываю. И тащусь.
...
Рейтинг: 0 / 0
06.05.2006, 14:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713158
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Ужасть, так никакой конкретики и нет.

yww@escape.ru tygraДа, тесты потрясающи.

Чего только стоит "одна известная РСУБД"!

-- Tygra's --

Ну вот здесь одна из известных явно указана http://www.intersystems.ru/cache/analysts/analyst-reviews.html

хотя.. зачем это Вам? У Вас уже мнение сложилось.. единственное и правильное..
Я даже и эти тесты почитал.
1. Нигде не указано, на каком железе все это крутится
2. Нигде не указан объем данных и количество запросов.
3. Нигде не указано, кто и как обслуживает системы и железо и что такое "незапланированный простой" в разных случаях.
......
98. Удовлетворенность скоростью и масштабируемостью БД (по шкале от 1 до 9) - у пользователей про масштабируемость? У тети Маши?
99. Время отклика при выполнении наиболее типичных транзакций - это как же оценивали по 9-бальной шкале время отклика да еще транзакций? Да еще пользователи. Ну и т.д. про шкалу :)
100. Выяснилось, что, в частности, в 37% учреждений, где установлена система на базе Caché, система регистрации врачебных предписаний используется полностью, в то время как подобная система на базе Oracle полностью не используется нигде. - а причем тут Кэш вообще? Может в Оракловой системе столько всего есть, что полностью воспользоваться здоровья не хватит а Кэш имеет три формы ввода и ничего более. К тому же зависит это не от СУБД, а от кривизны рук разработчика приложения.

Эпилог:
автор Пользователи Caché сообщили о том, что требования к аппаратному обеспечению этой системы в 2,1 раза ниже по сравнению с СУБД Oracle. Для работы с Caché требуется в два с половиной раза меньше администраторов БД по сравнению с СУБД Oracle .

Присылайте еще тесты, будет весело :)


-- Tygra's --
...
Рейтинг: 0 / 0
06.05.2006, 14:26
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713187
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
ну я...
Один умник (Эдгар Дейкстра) как-то влип в историю (влип к моему большому сожалению, толковый малый был) с отрицанием goto. Теперь тут некоторые посетители форума хотят влипнуть в историю с отрицанием циклов. ...


Ну почему так сразу "влип" ?
...
Рейтинг: 0 / 0
06.05.2006, 14:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713193
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
tygra
Присылайте еще тесты, будет весело :)

-- Tygra's --

Пришлю без проблем.. жалко мне что ли. Только когда сам найду..

А пока вот этим развлекитесь http://www.developerdotstar.com/community/node/279 .. оно Вам, скорее всего, по душе придётся.
...
Рейтинг: 0 / 0
06.05.2006, 14:37
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713196
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
Изопропил ну я...
Один умник (Эдгар Дейкстра) как-то влип в историю (влип к моему большому сожалению, толковый малый был) с отрицанием goto. Теперь тут некоторые посетители форума хотят влипнуть в историю с отрицанием циклов. ...


Ну почему так сразу "влип" ?
Дык склоняют его теперь на каждом углу на эту тему, значит влип. В некоторых языках даже отказывались от поддержки goto.
...
Рейтинг: 0 / 0
06.05.2006, 14:37
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713207
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
ну я Nikolay KulikovЛадно не буду спорить, почитай про то что является проблемой
Американского здравоохранения.
http://www.developerdotstar.com/community/node/279
Суперски написано, давно и с удовольствием почитываю этот текст, время от времени доставая из закладок. Очередные SQLоки.

авторWeakly-typed languages cause unnecessary bugs because the compiler cannot prevent meaningless combinations of operations and data...
Один умник (Эдгар Дейкстра) как-то влип в историю (влип к моему большому сожалению, толковый малый был) с отрицанием goto. Теперь тут некоторые посетители форума хотят влипнуть в историю с отрицанием циклов. Этот видимо захотел влипнуть с отрицанием языков которые он плохо понимает. По меньшей мере внимание к своему блогу он уже заслужил.

Читаю и перечитываю. И тащусь.

А конкретно - что автор соврал?
Раз вы давно читаете, то, наверное, и проанализировали? А ссылочку на ваши комментарии можно?
Что, не комментировали?
Просто тащитесь?
Экий вы эстет...
...
Рейтинг: 0 / 0
06.05.2006, 14:39
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713220
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
mir yww@escape.ruВот такое вот размышление на тему "как устроена секта?"

Составляющие секты:
1. Основатель - "Батя"
2. Учение - "Батя сказал"
3. Деятельность - "Мы делаем как Батя сказал"
4. Логика - "Правильно только то, что Батя сказал. Потому - что так сказал Батя"

Если посмотреть с такой точки зрения на ругательства типа "МАМПСИСТЫ - сектанты", то видно, что кроме эмоций в нём ничего нет.. потому что нет Бати, и нет догматического учения. Есть только практическая деятельность, которая логически приводит М-программистов к выводу что их технологии и эффективны и оправданы..

Если же такое ругательство применить к фанатам SQL, то найдётся всё, от Бати, до Логики.. тогда кто тут сектанты?А можно все же расшифровочку, что у вас там "найдется" применительно к РМД? По всем пунктам?
Особенно если вспомнить, что "догматическое" реляционное "учение" не более и не менее чем приложение математики и логики. Хороша "догматика". А кто, интересно, "Батя"?

А попробуйте сами.. может что и получится.. мне-то оно как то без интереса. Это же из вашего монастыря должно "найтись"..
...
Рейтинг: 0 / 0
06.05.2006, 14:41
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713228
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
ggvА конкретно - что автор соврал?
Раз вы давно читаете, то, наверное, и проанализировали? А ссылочку на ваши комментарии можно?
Что, не комментировали?
Просто тащитесь?
Экий вы эстет...
Не, ссылочку не могу дать. Не записывал. Комментировал только устно. Когда плохое настроение, хорошо взять с любого места почитать. Настроение поднимает. Хотя мысль давно была о переводе и комментировании. В аглицком я не силен, чтобы в его блоге писать.
...
Рейтинг: 0 / 0
06.05.2006, 14:44
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713232
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
yww@escape.ru
А попробуйте сами.. может что и получится.. мне-то оно как то без интереса. Это же из вашего монастыря должно "найтись"..

Ах, ну да, вы же специалист по "личным встречам".
То ли психоаналитик, то ли боксер, но явно не технарь - технари могут обмениваться документами.
...
Рейтинг: 0 / 0
06.05.2006, 14:44
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713243
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
ну я ggvА конкретно - что автор соврал?
Раз вы давно читаете, то, наверное, и проанализировали? А ссылочку на ваши комментарии можно?
Что, не комментировали?
Просто тащитесь?
Экий вы эстет...
Не, ссылочку не могу дать. Не записывал. Комментировал только устно. Когда плохое настроение, хорошо взять с любого места почитать. Настроение поднимает. Хотя мысль давно была о переводе и комментировании. В аглицком я не силен, чтобы в его блоге писать.
Да вы хоть и руским языком, и нам сюда, мы уж как-нибудь сопоставим, анализируемый вами материал и результат вашего анализа.
А наиболее удачные места, возможно автору анализируемого материала (Edward G Nilges) отправим.
Ну правда, пусть человек тоже "по-тащится".
...
Рейтинг: 0 / 0
06.05.2006, 14:47
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713257
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
ggvДа вы хоть и руским языком, и нам сюда, мы уж как-нибудь сопоставим, анализируемый вами материал и результат вашего анализа.
А наиболее удачные места, возможно автору анализируемого материала (Edward G Nilges) отправим.
Ну правда, пусть человек тоже "по-тащится".
Ничего не обещаю. Если будет то будет. А сами-то не хотите "нам сюда" подкинуть? А мы бы сопоставили.
...
Рейтинг: 0 / 0
06.05.2006, 14:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713271
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
ggv yww@escape.ru
А попробуйте сами.. может что и получится.. мне-то оно как то без интереса. Это же из вашего монастыря должно "найтись"..

Ах, ну да, вы же специалист по "личным встречам".
То ли психоаналитик, то ли боксер, но явно не технарь - технари могут обмениваться документами.

Да ну.. домыслы это.. просто то, что здесь обсуждается, и вид, в котором это обсуждается - выглядит как межконфессионные распри.. Попытки обращения в веру.. споры о самом "понятном языке".. потрясание наилучшими пониманиями сути всего и вся.. и после всего этого попытки спровоцировать оппонента на грубость..

А если мои реплики не нравятся - так не читайте.
...
Рейтинг: 0 / 0
06.05.2006, 14:57
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713301
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
ну я
Ничего не обещаю. Если будет то будет. А сами-то не хотите "нам сюда" подкинуть? А мы бы сопоставили.
Не понял, подкинуть чего?
реальной инфы о каше?
Положительной нет, а отрицательной - не могу, положение не позволяет.
...
Рейтинг: 0 / 0
06.05.2006, 15:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713350
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
ggv ну я
Ничего не обещаю. Если будет то будет. А сами-то не хотите "нам сюда" подкинуть? А мы бы сопоставили.
Не понял, подкинуть чего?
реальной инфы о каше?
Положительной нет, а отрицательной - не могу, положение не позволяет.
Ну, именно каше необязательно упоминать, можно просто про MUMPS. Edward G Nilges вот к примеру ни разу не упомянул ни Cache ни Intersystems. Зато есть вот такое просто блестящее утверждение:
авторeach and every Mumps installation should be replaced by Oracle or SQL Server

Кстати, судя по его тексту он или знаком с MUMPS, или некоторое время посвятил его изучению самостоятельно, или справлялся о деталях у специалистов. По крайней мере товарищ подготовился. Хотя, по-моему, он слабо представляет что есть кроме мампса для CP/M еще и ECP кластеры.
...
Рейтинг: 0 / 0
06.05.2006, 15:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713391
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Ну багливые поделия не грех и заменить...
...
Рейтинг: 0 / 0
06.05.2006, 15:32
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713515
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Насчет методики сравнения.
Любое сравнение должно проводиться независимой компанией, которая никак не заинтересована в лидерстве какого либо участника.

Теперь насчет результата сравнения http://www.intersystems.ru/cache/analysts/reviews/cache_vs_rdbms.html

Это сравнение не вызывает доверия по следующим причинам.
1. В каком году проводилось сравнение?
2. Какие версии продуктов использовались? Oracle 1.0 сравнивался с Cache 5.1 ?
3. Какие операционки и какой хард использовался.
4. Принципиально значение имеет и настройки самих баз данных. Производительность одной и той же базы данных может сильно варьировать в зависимости от уровня знаний Администратора. Еще нужно учесть качество кода, используемого там и там. А если программист Оракла на Оракле криво написал прогу, это не значит что Оракл плох!
5. Там и там использовался журнал транзакций? Если в базу данных SQL закидывать текст, то производительность и размер базы данных SQL будет сильно зависеть от того, включена транзакция или нет. Еще если вы закидываете данные в таблицу у которой стоит Cluster Index то это может замедлить импорт до 10 раз. После того как данные закинуты, надо для правдивости сделать truncate transaction log + shrink database, а потом сравнивать объемы базы данных на SQL и Cache.
Учитывая что Cache хранит число как строку, я могу поверить, что он делает импорт быстрее. Поскольку у SQL каждый вводимый элемент из текстового файла типа int + real, перед тем как впихнуть его в базу данных, надо проверить, конвертировать и лишь потом запихивать в базу данных.

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

Существует ли хоть один крупный поисковый сервер или почтовый сервер на базе Cache ?

на чем сделаны движки Yahoo, Yahoo Mail, Google, Gmail, Hotmail, Live.com ?

Думаю, многие со мной согласятся.
...
Рейтинг: 0 / 0
06.05.2006, 16:10
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713545
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
Iura Производительность одной и той же базы данных может сильно варьировать в зависимости от уровня знаний Администратора. Еще нужно учесть качество кода, используемого там и там. А если программист Оракла на Оракле криво написал прогу, это не значит что Оракл плох!

есть специальная организация, которая занимается измерением производительности серваков - tpc.org
...
Рейтинг: 0 / 0
06.05.2006, 16:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713549
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
yww@escape.ru ggv yww@escape.ru
А попробуйте сами.. может что и получится.. мне-то оно как то без интереса. Это же из вашего монастыря должно "найтись"..

Ах, ну да, вы же специалист по "личным встречам".
То ли психоаналитик, то ли боксер, но явно не технарь - технари могут обмениваться документами.

Да ну.. домыслы это.. просто то, что здесь обсуждается, и вид, в котором это обсуждается - выглядит как межконфессионные распри.. Попытки обращения в веру.. споры о самом "понятном языке".. потрясание наилучшими пониманиями сути всего и вся.. и после всего этого попытки спровоцировать оппонента на грубость..

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

Всё вровень? Всё да не всё. За нами и наука и практика, а за вами лишь практика. У нас есть теория проектирования БД, худо бедно да основанная на формальных критериях качества, а у вас ничего подобного и близко нет. И не будет никогда.
...
Рейтинг: 0 / 0
06.05.2006, 16:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713587
Yo.!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!!
Участник
Iura
Теперь насчет результата сравнения http://www.intersystems.ru/cache/analysts/reviews/cache_vs_rdbms.html


да лажа там, попробывал почитать это , на первых же строках плюнул, обычный развод. sqlddr закачивает со скоростью близкой к обычному копированию, время тратится разве, что на разбор строки c разделителем (sqlddr может писать прямо в файл данных по сути минуя движек субд). т.е. чтоб 120 минут закачивать пару милионов записей реально нада руками держать головки винта иначе никак :)
...
Рейтинг: 0 / 0
06.05.2006, 16:29
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713601
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Немного не в тему, но посмотрите
http://download.microsoft.com/download/8/5/8/85803fdd-fe9a-4783-ab37-e0c565172ffd/asp_net_atlas.wmv

Вот чем хорош Microsoft, он думает и денм и ночью о своих потребителях и делает максимум, чтобы помочь производителям!
...
Рейтинг: 0 / 0
06.05.2006, 16:33
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713607
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
Iuraна чем сделаны движки Yahoo, Yahoo Mail, Google, Gmail, Hotmail, Live.com ?
Это обычно обсуждают тут:
http://www.searchengines.ru
...
Рейтинг: 0 / 0
06.05.2006, 16:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713662
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
mir У нас есть теория проектирования БД, худо бедно да основанная на формальных критериях качества, а у вас ничего подобного и близко нет. И не будет никогда.

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

MUMPS - это язык программирования, который присутствует в Cache, но COS (Cache Object Script), включая в себя MUMPS, давно вышел за его границы. Поэтому доводы о "птичьем языке" - не катят.

Если же вы сравниваете возможности разработки на Cache и РСУБД, то и сравнивайте тогда Cache SQL и SQL той самой РСУБД.

Сравнивать же Cache (подразумевая MUMPS) и Oracle (подразумевая его собственный SQL) - это или сознательное желание запутать оппонента, или нежелание вникнуть в предмет спора.

Что касается таких критериев как сложность (или простота) разработки , быстродействие получившегося продукта, его надёжность, простота сопровождения, понятность другим программистом.. и т.д. - так это вопросы не теории, а практики. И здесь (увы :) ) имеют значение те самые параметры, которые приводятся в тестах, опубликованных Интерсистемс. Даже если это вам и не нравится.
...
Рейтинг: 0 / 0
06.05.2006, 16:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713737
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
yww@escape.ru mir У нас есть теория проектирования БД, худо бедно да основанная на формальных критериях качества, а у вас ничего подобного и близко нет. И не будет никогда.

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

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

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

Вот и Каше - он хоть как может себе поддержку SQL может сбоку прикрутить, к реляционной алгебре и РМД ближе он не станет. А своего теоретического фундамента у него нет (о чем Вам и пытались сказать).
...
Рейтинг: 0 / 0
06.05.2006, 17:12
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713745
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
автор

/// Адресуемый объект
Class ca.CA Extends %Persistent [ ClassType = persistent, Not ProcedureBlock ]
{

/// Код прикладного типа
Property caType As %String(MAXLEN = 2) [ Required ];

Index caTypeIndex On caType;

/// Прикладной идентификатор
Property caI As %String [ Required ];

Index caIIndex On caI [ Unique ];

/// Имя файла короткой ссылки
Property caLinkFile As %String;

Index caLinkFileIndex On caLinkFile [ Unique ];
/// Признак обязательного наличия SSL-шифрования канала
Property caOnlyHTTPS As %Boolean [ InitialExpression = 0, Required ];

/// Признак допустимости межсистемноо взаимодействия
Property caCrossSsystem As %String [ InitialExpression = 0 ];

/// Состояние адресуемого объекта
Property caStatus As %String [ Calculated, SqlComputeCode = { Set {caStatus}=##class(ca.CA).caGetStatusValue({caI})
}, SqlComputed, SqlComputeOnChange = caI ];

// =======================================================

}

ClassMethod %OnDelete(oid As %ObjectIdentity) As %Status [ Private ]
{
q:'$IsObject(oid) $$$OK
n q s q=..caOnDelete($g(oid)) q:'q q
k ^caTree("caI",oid.caI)
k ^caTree("caDI",oid.caI)
k:$g(oid.caDescriptor)'="" ^caTree("caD",oid.caDescriptor)
q q
}

// =======================================================

/// Вычисление локального ранга пользователя относительно
/// экземпляра данного объекта
Method caLocalRange() As %String
{
i $g(caUser)="" q 0
i caUser.Range=5 q 5
n u,i,r
s u=caUser.caI s i=..caI
&sql(SELECT Range INTO :r FROM ca.UserObject WHERE caUser=:u AND caObject=:i )
i +$G(r)>(+caUser.Range) q +$g(r)
q:+$G(r)>0 1
q 0
}

/// Этот метод вычисляет значение вычисляемого свойства caStatus для SQL
ClassMethod caGetStatusValue(caI) As %String
{
q:$g(^caTree("caI",caI,"caStatus"))="" "UNDEFINED"
q $g(^caTree("caI",caI,"caStatus"))
}


}



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

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

Вам это может не нравиться, но это ваши проблемы. Не нравится - возьмите то, что вам по душе.
...
Рейтинг: 0 / 0
06.05.2006, 17:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713758
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
ЛП[quot yww@escape.ru][quot mir]

Я не понял о чём вы хотели сказать.. прочитаю ещё раз после праздников.
...
Рейтинг: 0 / 0
06.05.2006, 17:19
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713795
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
Синтаксис "птичий" у вашего Cache-языка .
...
Рейтинг: 0 / 0
06.05.2006, 17:33
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713812
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
ИзопропилСинтаксис "птичий" у вашего Cache-языка .
Это не каше-язык птичий, это M (насколько я понял)

Когда смотрю на примеры на М - постоянно вспоминаю Perl, который у меня вызывал искреннее восхищение своей ублюдочностью...
...
Рейтинг: 0 / 0
06.05.2006, 17:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713857
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
это не ублюдочность, это пример эволюционного добавления новых фич в течении
большого периода времени. Теперь это больше похоже на большой бесформенный
комок а не на язык


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
06.05.2006, 18:03
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713859
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
yww@escape.ru
Слепо отвергая Каше, его противники могут потерять (для себя, конечно) действительно мощное средство разработки. И мощь эта (по моему личному мнению), заключается в возможности совместного использования и ООП и SQL, и COS в приложениях, создаваемых в рамках одной и той же среды разработки .

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

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


Разве у оракла нет ООП?
...
Рейтинг: 0 / 0
06.05.2006, 18:04
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713867
неважно
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
неважно
Гость
ЛП ИзопропилСинтаксис "птичий" у вашего Cache-языка .
Это не каше-язык птичий, это M (насколько я понял)

Когда смотрю на примеры на М - постоянно вспоминаю Perl, который у меня вызывал искреннее восхищение своей ублюдочностью...
Pathologically Eclectic Rubbish Lister ?
...
Рейтинг: 0 / 0
06.05.2006, 18:08
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713877
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
Не надо на Perl гнать :) - у него операции приоритеты имеют.

и с бейсиком никто его не скрещивал и embedded SQL не пришивал.
...
Рейтинг: 0 / 0
06.05.2006, 18:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713879
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Народ,

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

Они должны же признатся в своей беспомощности!
...
Рейтинг: 0 / 0
06.05.2006, 18:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713936
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
Официльный ответ будет.
Уважаемые есть тест TPC на котором если хотите можете сравнится с нами.
Он между прочим в себя включает не только производительность, но проверку работы транзакций и восстановления после сбоя.
Утверждения cache являются голословными.tpc.org это независимый аудитор результатов.
...
Рейтинг: 0 / 0
06.05.2006, 18:47
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33713981
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
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, чтобы они тратили веремя на комментарии? Када добьется чего-то стоящего тада и прокомментируют. Наличие комментария от них это один из признаков успешности.
...
Рейтинг: 0 / 0
06.05.2006, 19:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714037
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
vadiminfo
Iura
Как вы относитесь к Идее отправить результат сравнения с intersystems в центральный офис Oracle и Micrososft и попросить их прокомментировать результат?

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

Знаю одно - Майкрософт и Оракле на пару опасаются MySQL.
Он становится популярным
...
Рейтинг: 0 / 0
06.05.2006, 19:57
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714040
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
Iura...
Знаю одно - Майкрософт и Оракле на пару опасаются MySQL.
...

Источником знаний поделись
...
Рейтинг: 0 / 0
06.05.2006, 20:00
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714079
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
Изопропил 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 ?

Я знаю что существуют "базы данных" на прологе, но это еще ни о чем не говорит!
...
Рейтинг: 0 / 0
06.05.2006, 20:47
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714085
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
http://pr.cnews.ru/pr_body.shtml?cid=10161&pr=2005/05/04/33279
...
Рейтинг: 0 / 0
06.05.2006, 20:55
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714111
db2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2
Участник
IuraДанные будут занимать больше чем 1000 GB :( но не сразу :)
1000Gb это смешно для конторы. У меня дома 500 Gb. Скоро может быть 1000 Gb сделаю.
...
Рейтинг: 0 / 0
06.05.2006, 21:40
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714137
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
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...)
И т.д. и т.п....
Всё зависит от оптимизатора, короче говоря :-))) И вот ради этой последней строчки столько фигни написал :-)
...
Рейтинг: 0 / 0
06.05.2006, 22:13
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714170
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
pavelvp
Ну и ещё пара экспериментов в догонку. По скорости. Тут говорили, что даже SQL в Каше офигенный просто, а уж напрямую так вообще улёт.
Вот такие нехитрые вещи я попробовал:
1) count(*)
2) max
3) min
4) avg
5) sum
6) between 10000 and 100000
7) order by
По полю типа double.
Как видно, никакой "реляционщиной" здесь и не пахнет (может быть за исключением последнего :-)). Вроде как Каше должен на них просто летать. Индексов, естественно, никаких не строилось.

Павел, как я и раньше писал, пробелма у Кеши не в поиске, а впредставлении данных. Если он реально хранит double в формате строки, то перед каждым вычислением, он должен переводить число из строки в double а потом выполнять операции. Ну и прикинь сколько это времени займет.
...
Рейтинг: 0 / 0
06.05.2006, 22:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714174
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
IuraПавел, как я и раньше писал, пробелма у Кеши не в поиске, а впредставлении данных. Если он реально хранит double в формате строки, то перед каждым вычислением, он должен переводить число из строки в double а потом выполнять операции. Ну и прикинь сколько это времени займет. Какое отношение тип double имеет к count(*) ??? Да я и не о поиске, а о размере БД и о фулл-скане - о том, что чудес не бывает...
...
Рейтинг: 0 / 0
06.05.2006, 22:56
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714183
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
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. Правильная такая структура или нет это не обсуждается. Я не показываю всю структуру, а просто привожу упрощеный пример. Да и сам запрос поиска написан не полностью.

Думаю суть понятна, почему так критичен объем. ЗАПРОСЫ БУДУТ СЛОЖНЫМИ. И вероятней всего только на одно предложение потребуется написать три подзапроса.
...
Рейтинг: 0 / 0
06.05.2006, 23:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714192
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
pavelvpИтак. Имеем следующее:
- Cache 5.1.0.826.1.SU;

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

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

Именно. У версии, которая SU, кеш ограничен.
...
Рейтинг: 0 / 0
06.05.2006, 23:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714197
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
pavelvp IuraПавел, как я и раньше писал, пробелма у Кеши не в поиске, а впредставлении данных. Если он реально хранит double в формате строки, то перед каждым вычислением, он должен переводить число из строки в double а потом выполнять операции. Ну и прикинь сколько это времени займет. Какое отношение тип double имеет к count(*) ??? Да я и не о поиске, а о размере БД и о фулл-скане - о том, что чудес не бывает...

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

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

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

Сергей, если я в чем то не прав, то пожалуйста подправь меня.
...
Рейтинг: 0 / 0
06.05.2006, 23:19
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714261
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
ИзопропилСинтаксис "птичий" у вашего Cache-языка .

Тот Cache язык - COS
Если он вас неустраивает, можете использовать Cache Basic..
...
Рейтинг: 0 / 0
07.05.2006, 01:25
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714263
yww@escape.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
yww@escape.ru
Гость
ЛП yww@escape.ru mir У нас есть теория проектирования БД, худо бедно да основанная на формальных критериях качества, а у вас ничего подобного и близко нет. И не будет никогда.

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

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

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

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


Несколько раз прочитал.. ничего не понял..
Что сказать то хотите? товариш Инкогнито!
...
Рейтинг: 0 / 0
07.05.2006, 01:44
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714440
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
http://www.sql.ru/articles/mssql/03013101Indexes.shtml#1 Индексы в SQL
...
Рейтинг: 0 / 0
07.05.2006, 12:56
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714947
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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% - текстом или сжато - почти не влияет

для Вашей задачи - перевод текста -
вообще зачем на числа заморачиваться?
...
Рейтинг: 0 / 0
08.05.2006, 10:11
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714958
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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% - текстом или сжато - почти не влияет

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

Мне нужно будет мучаться с числами только для статистики. Типа какая фраза сколько раз использовалсь у каждого пользователя и так далее.
...
Рейтинг: 0 / 0
08.05.2006, 10:22
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714965
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
ЛП ИзопропилСинтаксис "птичий" у вашего Cache-языка .
Это не каше-язык птичий, это M (насколько я понял)

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

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

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

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

но по поводу перла я и с Вами, и с сержантом, согласен
-------------------------------------------------------------------
итак-
МUMPS - природный язык !
все другие - неправильные.
...
Рейтинг: 0 / 0
08.05.2006, 10:31
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33714970
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
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% - текстом или сжато - почти не влияет

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

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

думаю до статистики дело не дойдет ..
...
Рейтинг: 0 / 0
08.05.2006, 10:34
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33715023
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
MX -- ALEX
думаю до статистики дело не дойдет ..

Я тоже склонен разделить этот скепсис. В постановке задачи видны признаки задач понимания естественного языка. Тада до БД еще далеко: там есь траблы с тем как вообще решать задачи и преодоление, которых в общем случае не очень известо. Это задачи ИИ - алгоритмов собсно хороших там не известно. Мож там не то шо БД, но и БЗ нарисуется, но не поможет. Смотря до какой степени качества нуно переводить.
Мож я не до конца понял, что хочет автор топика. Но пока такое впечатление присутствует.
...
Рейтинг: 0 / 0
08.05.2006, 12:01
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33715082
Iura
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Iura
Гость
vadiminfo MX -- ALEX
думаю до статистики дело не дойдет ..

Я тоже склонен разделить этот скепсис. В постановке задачи видны признаки задач понимания естественного языка. Тада до БД еще далеко: там есь траблы с тем как вообще решать задачи и преодоление, которых в общем случае не очень известо. Это задачи ИИ - алгоритмов собсно хороших там не известно. Мож там не то шо БД, но и БЗ нарисуется, но не поможет. Смотря до какой степени качества нуно переводить.
Мож я не до конца понял, что хочет автор топика. Но пока такое впечатление присутствует.

Процесс на стадии разработки. Есть концепция, но пока нет детального алгоритма.
Все решается поэтапно.
...
Рейтинг: 0 / 0
08.05.2006, 13:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33715114
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
ну яИменно. У версии, которая SU, кеш ограничен. На фига же такая демо-версия...
...
Рейтинг: 0 / 0
08.05.2006, 13:57
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33715147
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
pavelvp ну яИменно. У версии, которая SU, кеш ограничен. На фига же такая демо-версия...
Вот такая вот у Интерсистемс бизнес-политика.
...
Рейтинг: 0 / 0
08.05.2006, 14:49
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33715170
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
ну я pavelvp ну яИменно. У версии, которая SU, кеш ограничен. На фига же такая демо-версия...
Вот такая вот у Интерсистемс бизнес-политика.

типа наш муму даже связаный и с камнем на шее
вашего тузика порвет..

горячие американские парни..
...
Рейтинг: 0 / 0
08.05.2006, 15:10
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33715586
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anton Demidov
Участник
pavelvp...
Записиси фиксированной длины никто уже давным-давно не хранит.
...
Ошибаешься, Павел.
IBM DB2 занимает примерно треть рынка БД. Из них 85% - это AS/400 DB2 (iSeries) , которая не умеет нормально работать с VARCHAR, да и традиционно используемый на этой платформе COBOL не силён в этой области. Как итог - поголовно используются записи фиксированной длины. Спасает только мощная дисковая система :[
...
Рейтинг: 0 / 0
08.05.2006, 22:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33716299
Rus000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Rus000
Гость
Anton Demidov
IBM DB2 занимает примерно треть рынка БД. Из них 85% - это AS/400 DB2 (iSeries) , которая не умеет нормально работать с VARCHAR, да и традиционно используемый на этой платформе COBOL не силён в этой области. Как итог - поголовно используются записи фиксированной длины. Спасает только мощная дисковая система :[

опа! вот это новость ... про кобол на as400 я слышал, но какое отношение он имеет к varchar? Информация точная?
...
Рейтинг: 0 / 0
09.05.2006, 20:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33717314
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/db2/rbafzmstch2data.htm
...
Рейтинг: 0 / 0
10.05.2006, 12:23
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33717341
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
pavelvpИтак. Имеем следующее:
- 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 :-)
Вопрос - что я делал не так?

нда... подход. а ведь я говорил же, что SQL в Cache боковой, на коленке
сделанный, в псевдо-компилятор засунутый... что же ты сравниваешь-то?

ну да ладно. пара пояснений. реализация "реляционного" подхода в
Cache аналогична по идеологии с РСУБД. это значит, что будут эмулироваться
фиксированные размеры полей. это значит, что будут имитироваться
"плоские" таблицы. это значит, что все будет медленнее, чем хотелось
и толще, чем моглось... только не надо ловить меня на словах, ладно? я обещал "быстрый и компактный SQL на простых запросах", ага,
но я с ним не работаю (да и не буду).
наверно тебе могут что-то подсказать другие здешние M-щики.
свой подход я объяснил на пальцах и по мере возможности
показал. я могу оценить примерную загруженность нормального M-массива,
если ты все-таки расскажешь про размер оставшихся 9-ти полей. :)


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

должен ли я полагать, что 100 - означает 100% сжатия данных? :)
как-то слабо верится, ага. причем сжатие данных - вещь, конечно
реальная до определенной степени, пока не начинает сурово влиять
на скорость обработки.


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

тут, видимо, я должен извиниться? нет уж, не буду. пусть тебе ответят те,
кто занимается SQL в Cache, это не моя специфика.


В чём правда, брат?

в честных сравнениях, брат.


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

нет, нужно просто воспользоваться "природными возможностями" системы,
а не пытаться заставить радио показывать кино и возмущаться плохим
изображением. давай просто повторим твой тест в равных условиях, ага.


Так что чудес не бывает :-) Если данные есть - они занимают место :-)
Записиси фиксированной длины никто уже давным-давно не хранит.
Префиксное сжатие ключей в индексах думаю тоже у всех есть.
При схожих объёмах - размер БД у всех будет примерно одинаковый (если нет компрессии данных).

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


Если нет индексов - фуллскан - скорость диска от СУБД не зависит :-)

скорость диска - конечно же не зависит. но на одном и том же винте
разные СУБД будут обрабатываться по-разному


Всё зависит от оптимизатора, короче говоря :-))) И вот ради этой последней строчки столько фигни написал :-)
ну почему же сразу "фигни"? твое право. просто возможности оптимизации
РСУБД заканчиваются, если уже не закончились.

С уважением. Сергей
...
Рейтинг: 0 / 0
10.05.2006, 12:31
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33717375
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
ну и как всегда вызывают сомнения цифири распределения баз по типам.
Anton - есть ссылочка, или это ваше IMHO?
которое почему-то не указано...
...
Рейтинг: 0 / 0
10.05.2006, 12:39
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33717619
Rus000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Rus000
Гость
Anton Demidov pavelvp...
Записиси фиксированной длины никто уже давным-давно не хранит.
...
Ошибаешься, Павел.
IBM DB2 занимает примерно треть рынка БД. Из них 85% - это AS/400 DB2 (iSeries) , которая не умеет нормально работать с VARCHAR, да и традиционно используемый на этой платформе COBOL не силён в этой области. Как итог - поголовно используются записи фиксированной длины. Спасает только мощная дисковая система :[

да, а как же приведенная ggv ссылка относительно кобола и varchar?

VARCHAR varying-length character-string variables can be used in C, COBOL, PL/I, REXX, and RPG:

...
* In COBOL and C, varying-length character strings are represented as structures.
...
...
Рейтинг: 0 / 0
10.05.2006, 13:26
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33717710
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
Sergei Obrastsovнда... подход. а ведь я говорил же, что SQL в Cache боковой, на коленке сделанный, в псевдо-компилятор засунутый... что же ты сравниваешь-то? Сравниваю подсистему хранения данных. Какое оно имеет отношение к SQL не понимаю...

ну да ладно. пара пояснений. реализация "реляционного" подхода в
Cache аналогична по идеологии с РСУБД. это значит, что будут эмулироваться
фиксированные размеры полей.Зачем??? И какой идеологии? Пока мы выяснили, что фиксированные размеры полей у DBF (причём здесь РСУБД?) и у одной из версий DB2. это значит, что будут имитироваться
"плоские" таблицы. это значит, что все будет медленнее, чем хотелось
и толще, чем моглось... Т.е. по каким-то непонятным причинам Каше специально делает чтобы работало медленно???только не надо ловить меня на словах, ладно? Никого я не собирался ловить на словах. Только и тебя за язык никто не тянул.

я могу оценить примерную загруженность нормального M-массива,
если ты все-таки расскажешь про размер оставшихся 9-ти полей. :)
Да не смеши ты людей :-) Знаю я сколько он будет занимать - чуть больше 100 метров, никуда ты данные не выкинешь...
Если тебе не сложно - расскажи как мне создать глобал и загрузить данные "честно". Попробую.

есть параметр у таблицы PCTFILL - процент сжатия данных.

должен ли я полагать, что 100 - означает 100% сжатия данных? :)
как-то слабо верится, ага. PCTFILL - процент заполнения. 100 - данные не сжимаются.
Ну и ещё пара экспериментов в догонку. По скорости.

тут, видимо, я должен извиниться? нет уж, не буду. пусть тебе ответят те,
кто занимается SQL в Cache, это не моя специфика.

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


В чём правда, брат?

в честных сравнениях, брат.
... нет, нужно просто воспользоваться "природными возможностями" системы,
а не пытаться заставить радио показывать кино и возмущаться плохим
изображением. давай просто повторим твой тест в равных условиях, ага.
Вот два утверждения двух разных людей:
Sergei Obrastsov Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом. IuraКак показывают тесты, производительность Cache SQL как минимум в три раза выше,
чем у традиционных реляционных СУБД, использующих реляционное ядро.

В моём тесте оба этих утверждения оказались неверными. При этом я не понимаю какое отношение SQL имеет к хранению данных, операции count(*), и вычислению простейщих агрегатов. Я же не джойны хитрые с группировками делал... Однако, если по первому пункту ты хоть как-то "прояснил" ситуацию, то то, что поведал Iura, отказалось просто неправдой.


занимают. только разное
я заметил :-)
не хранят. но хранят описание ты о чём???


скорость диска - конечно же не зависит. но на одном и том же винте
разные СУБД будут обрабатываться по-разному
и ты говоришь мне, чтобы я к словам не придирался, а сам что же :-)

просто возможности оптимизации
РСУБД заканчиваются, если уже не закончились. Ну да, конечно :-) А у М эти возможности воистину безграничны... Кстати, может подскажешь - есть ли в M возможность при программировании учесть объём данных конкретного глобала удерживаемый в данный момент в буферном пуле?

Ни в коей мере я не пытался сравнивать M-технологию и РСУБД. Но только коли речь идёт об РСУБД, то будь добр - ориентируйся на современных представителей этого семейства - всё-таки 21-ый век на дворе.
...
Рейтинг: 0 / 0
10.05.2006, 13:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33717791
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
pavelvpТ.е. по каким-то непонятным причинам Каше специально делает чтобы работало медленно???
Движок sql руководствуясь только sql не может определить как ЛУЧШЕ хранить данные, поэтому использует стратегии хранения по умолчанию. Эта стратегия примерно соответствует таблицам с кластерным первичным ключом. Тупо и в лоб.

Sergei Obrastsov Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом.
У кластерного ключа сжатию взяться неоткуда, если в нем только одно поле. Чтобы было сжатие, нужно несколько полей в ключ.

IuraКак показывают тесты, производительность Cache SQL как минимум в три раза выше,
чем у традиционных реляционных СУБД, использующих реляционное ядро.

Расскажите это фокспрошникам. Что и когда быстрее - зависит от столь большого числа факторов, что провести корректные стендовые испытания довольно сложно.
pavelpесть ли в M возможность при программировании учесть объём данных конкретного глобала удерживаемый в данный момент в буферном пуле?
По стандарту М - нет. Среди документированных возможностей каше что-то не встречал. Инфа может быть в каких-то внутренних структурах системы сбора статистики, какая-нибудь хитроумная недокументированная системная функция. Интерсистемс иногда делает спецбилды со спецвозможностями для отдельных клиентов. Если сильно нужно - могут пойти навстречу. Поэтому не могу достоверно отрицать что такой возможности совсем нет.
...
Рейтинг: 0 / 0
10.05.2006, 14:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33717861
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
ну я pavelpесть ли в M возможность при программировании учесть объём данных конкретного глобала удерживаемый в данный момент в буферном пуле?
По стандарту М - нет. Среди документированных возможностей каше что-то не встречал. Инфа может быть в каких-то внутренних структурах системы сбора статистики, какая-нибудь хитроумная недокументированная системная функция. Интерсистемс иногда делает спецбилды со спецвозможностями для отдельных клиентов. Если сильно нужно - могут пойти навстречу. Поэтому не могу достоверно отрицать что такой возможности совсем нет.
Справедливости ради должен упомянуть о системе сбора статистики ^GLOSTAT и интерфейсе к сбору статистики через классовые интерфейсы, в частности классы пакета $System.MONITOR. Но как из операционных статистик выудить итоговые - таким вопросом пока не задавался.
...
Рейтинг: 0 / 0
10.05.2006, 14:34
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33717968
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
pavelvp Sergei Obrastsovнда... подход. а ведь я говорил же, что SQL в Cache боковой, на коленке сделанный, в псевдо-компилятор засунутый... что же ты сравниваешь-то? Сравниваю подсистему хранения данных. Какое оно имеет отношение к SQL не понимаю...
не понимаешь, ага. ты берешь "эмулированную подсистему хранения данных для эмулированного SQL" и хочешь назвать это оптимальной системой.
не правильно, мягко говоря

pavelvp Sergei Obrastsovну да ладно. пара пояснений. реализация "реляционного" подхода в Cache аналогична по идеологии с РСУБД. это значит, что будут эмулироваться фиксированные размеры полей.Зачем??? И какой идеологии? Пока мы выяснили, что фиксированные размеры полей у DBF (причём здесь РСУБД?) и у одной из версий DB2.

а у тебя в РСУБД не так? или ты полагаешь, что VARCHAR(x) не есть указание
на предельный размер поля? не надо быть наивным

pavelvp Sergei Obrastsovэто значит, что будут имитироваться
"плоские" таблицы. это значит, что все будет медленнее, чем хотелось
и толще, чем моглось... Т.е. по каким-то непонятным причинам Каше специально делает чтобы работало медленно???

по вполне понятным причинам Cache тащит за собой эмулированный SQL,
подгоняя под него вполне определенного вида структуры. это не есть
язык системы, это не есть оптимальные структуры хранения данных

pavelvp Sergei Obrastsovтолько не надо ловить меня на словах, ладно? Никого я не собирался ловить на словах. Только и тебя за язык никто не тянул.

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

pavelvp Sergei Obrastsovя могу оценить примерную загруженность нормального M-массива, если ты все-таки расскажешь про размер оставшихся 9-ти полей. :) Да не смеши ты людей :-) Знаю я сколько он будет занимать - чуть больше 100 метров, никуда ты данные не выкинешь...
Если тебе не сложно - расскажи как мне создать глобал и загрузить данные "честно". Попробую.

совершенно не сложно. только я не зря спрашиваю про строку.
что она из себя представляет? если разделитель - то какой? если
по позициям, то каковы они? ну предположим, что строка следующего вида:
data1 data2 data3 ... data59
(59 полей разделены пробелами, в случае NULL так и пишется NULL)
то есть:
data1 NULL NULL data4 ... data59
Код: plaintext
\nk ^tmp\ns file="x:\\...\\xxx.xxx" ;файл и путь к нему\no file u file\ns idx= 0  ;а это индекс\nf  r str q:$zeof< 0   d  ;читаем в цикле строку из файла\n. s str=$tr(str," ","*") ;меняем пробелы в строке на *, а можно и на что другое\n. s str=$tr(str,"NULL","") ;заменяем NULL на <пусто>\n. s str=$zstrip(str,"*",">") ;обрезаем строку до последнего значимого поля\n. s idx=idx+ 1 \n. s ^tmp(idx)=str\nc file\n
(скорее всего вылетит на ошибку в конце файла, потому что не выставлено
использование $ZEOF в этом случае, меняется в конфигурации. но это уже
не играет роли, все-равно уже прочитал)
понятно, что здесь еще можно поизгаляться с оптимизацией самого кода,
но это уже мелочи, ага.
программу создаешь в Studio, запускаешь в терминале. желательно это
сделать в только что созданной базе данных.

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

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

pavelvpВот два утверждения двух разных людей:
Sergei Obrastsov Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом. IuraКак показывают тесты, производительность Cache SQL как минимум в три раза выше,
чем у традиционных реляционных СУБД, использующих реляционное ядро.

В моём тесте оба этих утверждения оказались неверными. При этом я не понимаю какое отношение SQL имеет к хранению данных, операции count(*), и вычислению простейщих агрегатов. Я же не джойны хитрые с группировками делал... Однако, если по первому пункту ты хоть как-то "прояснил" ситуацию, то то, что поведал Iura, отказалось просто неправдой.

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

pavelvp Sergei Obrastsov
занимают. только разное
я заметил :-)
не хранят. но хранят описание ты о чём???

о реляционных структурах.
где фиксированные по длине строки и описания полей

pavelvp Sergei Obrastsovскорость диска - конечно же не зависит. но на одном и том же винте разные СУБД будут обрабатываться по-разному
и ты говоришь мне, чтобы я к словам не придирался, а сам что же :-)

чтобы ты отыгрался :)

pavelvp Sergei Obrastsovпросто возможности оптимизации
РСУБД заканчиваются, если уже не закончились. Ну да, конечно :-) А у М эти возможности воистину безграничны... Кстати, может подскажешь - есть ли в M возможность при программировании учесть объём данных конкретного глобала удерживаемый в данный момент в буферном пуле?

нет ничего безграничного. но возможности M достаточно широки.
что конкретно тебя интересует? сколько именно блоков конкретного массива
там находится? можно. а зачем?

pavelvpНи в коей мере я не пытался сравнивать M-технологию и РСУБД. Но только коли речь идёт об РСУБД, то будь добр - ориентируйся на современных представителей этого семейства - всё-таки 21-ый век на дворе.
и поэтому "а сбацай-ка нам SQL запрос"? :)
я еще раз проясню свою позицию: я НЕ против РСУБД, я уважаю людей, которые их развивают и которые в них работают. я НЕ ратую за отмену
всех РСУБД и замену их M-системами. я всего лишь против оплевывания
системы, которая наконец-то начала пробиваться на этот рынок.

С уважением. Сергей
...
Рейтинг: 0 / 0
10.05.2006, 15:00
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718005
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Sergei Obrastsov Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом.
У кластерного ключа сжатию взяться неоткуда, если в нем только одно поле. Чтобы было сжатие, нужно несколько полей в ключ.

стоп-стоп. во-первых, что есть "кластерный ключ"? для тупых, уж извини.
во-вторых, сжатие работает по ссылке. то есть:

^xxx(10000)
^xxx(10001)

даст нам остаток ссылки в "1". данные конечно не жмутся, если их не жать
собственноручно. :)
но! а нафига я буду писать данные в такую тривиальную структуру?
я совмещу ее с нужным индексом сразу, ага. в РСУБД такого нет. там
индекс навешивается отдельно, а будучи навешен, увеличивает размеры БД...кхгм... сильно.

С уважением. Сергей
...
Рейтинг: 0 / 0
10.05.2006, 15:09
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718069
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
Sergei Obrastsovво-первых, что есть "кластерный ключ"? для тупых, уж извини.
во-вторых, сжатие работает по ссылке. то есть:

^xxx(10000)
^xxx(10001)

даст нам остаток ссылки в "1". данные конечно не жмутся, если их не жать
собственноручно. :)
но! а нафига я буду писать данные в такую тривиальную структуру?
я совмещу ее с нужным индексом сразу, ага. в РСУБД такого нет. там
индекс навешивается отдельно, а будучи навешен, увеличивает размеры БД...кхгм... сильно.

С уважением. Сергей
А тупых программистов не бывает. (С) полковник Борисов.

В схеме хранения ^gloname(id)=values если мы считаем id частью строки, то это ключ кластерного индекса. Если не считаем, то это автоматически заведенный некими соглашениями для целей хранения, вроде ораклового rowid.

Если посчитаем ключом не одно поле а сочетание нескольких, например
^gloname(field1,field2)=othervalues
То тут и может проявитсья сжатие ключей.

Ну, а как писать или не писать - это не технический вопрос, к сжатию отношения не имеет.
...
Рейтинг: 0 / 0
10.05.2006, 15:26
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718135
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
ну яА тупых программистов не бывает. (С) полковник Борисов.

как видишь, все же есть. :)

ну я
В схеме хранения ^gloname(id)=values если мы считаем id частью строки, то это ключ кластерного индекса. Если не считаем, то это автоматически заведенный некими соглашениями для целей хранения, вроде ораклового rowid.

угу, теперь ясно, спасибо. вот ведь, любят люди красивые слова. :)

ну я
Если посчитаем ключом не одно поле а сочетание нескольких, например
^gloname(field1,field2)=othervalues
То тут и может проявитсья сжатие ключей.

снова не понял. ты хочешь сказать "сжатие данных" за счет помещения части
из них в автоматически жмущиеся индексы?

С уважением. Сергей
...
Рейтинг: 0 / 0
10.05.2006, 15:45
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718163
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
Sergei Obrastsov ну я
Если посчитаем ключом не одно поле а сочетание нескольких, например
^gloname(field1,field2)=othervalues
То тут и может проявитсья сжатие ключей.

снова не понял. ты хочешь сказать "сжатие данных" за счет помещения части
из них в автоматически жмущиеся индексы?

С уважением. Сергей
У меня нет полной уверенности что в случае
^gloname(100)
и
^gloname(101)
хранится лишь разница в 1. Я могу не знать таких деталей. Но в случае
^gloname(123,456)
и
^gloname(123,789)
величина 123 скорее всего будет храниться только 1 раз на блок. Вот про этот случай я и писал.
...
Рейтинг: 0 / 0
10.05.2006, 15:53
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718167
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
Sergei Obrastsov
Код: plaintext
1.
. s str=$zstrip(str,"*",">") ;обрезаем строку до последнего значимого поля

черт, ошибся. вот так:
Код: plaintext
1.
. s str=$zstrip(str,">P")
извини

С уважением. Сергей
...
Рейтинг: 0 / 0
10.05.2006, 15:54
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718176
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
Sergei Obrastsov
совершенно не сложно. только я не зря спрашиваю про строку.
что она из себя представляет? если разделитель - то какой? если
по позициям, то каковы они? ну предположим, что строка следующего вида:
data1 data2 data3 ... data59
(59 полей разделены пробелами, в случае NULL так и пишется NULL)
то есть:
data1 NULL NULL data4 ... data59

Строка следующего вида:
,data1,data2,<NULL> ... data59,

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
k ^tmp
s file="x:\...\xxx.xxx" ;файл и путь к нему
o file u file
s idx= 0  ;а это индекс
f  r str q:$zeof< 0   d  ;читаем в цикле строку из файла
. s str=$tr(str," ","*") ;меняем пробелы в строке на *, а можно и на что другое
. s str=$tr(str,"NULL","") ;заменяем NULL на <пусто>
. s str=$zstrip(str,"*",">") ;обрезаем строку до последнего значимого поля
. s idx=idx+ 1 
. s ^tmp(idx)=str
c file

Возникли вопросы:
- зачем пробелы замеяются на другие символы?
- почему в индекс пихается вся строка в сыром виде?
- где собственно мои 59 полей?
- типы данных (timestamp, double и т.п.) мне потом самому интерпретировать?

Ну и собственно как мне эту программу запустить? :-)
Студия предлагает создать прграмму на COS, Cache Basic и т.п. Ни в одном из вариантов не компилится. Непонятно...
И как её потом запустить...
...
Рейтинг: 0 / 0
10.05.2006, 15:57
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718188
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
ну яУ меня нет полной уверенности что в случае
^gloname(100)
и
^gloname(101)
хранится лишь разница в 1. Я могу не знать таких деталей.

фактически - да, с учетом двух цифирь (длина совпадающей части, длина несовпадающей части). если хочешь, давай расковыряем блок и посмотрим :)

ну я
Но в случае
^gloname(123,456)
и
^gloname(123,789)
величина 123 скорее всего будет храниться только 1 раз на блок. Вот про этот случай я и писал.

да, так и есть. это вытекает как раз из принципа сжатия ссылки.

С уважением. Сергей
...
Рейтинг: 0 / 0
10.05.2006, 16:01
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718192
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
ну яА тупых программистов не бывает. (С) полковник Борисов.
Колись, "ну я", ты кто такой? :-) Безобразие - ты меня знаешь, я тебя нет :-)
Но в случае
^gloname(123,456)
и
^gloname(123,789)
величина 123 скорее всего будет храниться только 1 раз на блок. Вот про этот случай я и писал. Создаётся впечатление, как будто только Каше так поступает :-)))
...
Рейтинг: 0 / 0
10.05.2006, 16:02
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718256
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
pavelvp
Строка следующего вида:
,data1,data2,<NULL> ... data59,
[/quot ]
славно, можно не мудрить с другими разделителями

[quot pavelvp]
Возникли вопросы:
- зачем пробелы замеяются на другие символы?

привычка. можно и не менять. логически пробел не свойственен в качестве
разделителя. а вдруг в поле будет ФИО?

pavelvp
- почему в индекс пихается вся строка в сыром виде?

стоп-стоп. в данное, а не в индекс, ага

pavelvp
- где собственно мои 59 полей?

в данном, конечно :) вот эта вся твоя строка и есть строка данных, с разделителем ","

pavelvp
- типы данных (timestamp, double и т.п.) мне потом самому интерпретировать?

а зачем? здесь нет типов данных

pavelvp
Ну и собственно как мне эту программу запустить? :-)
Студия предлагает создать прграмму на COS, Cache Basic и т.п. Ни в одном из вариантов не компилится. Непонятно...
И как её потом запустить...
на COS. просто переносишь ее туда. обрати внимание, что перед каждой
строкой надо поставить <Tab>, иначе первый символ воспримется как метка.
при сохрание "Save as..." выбери Files of type -> Intermediate Routine (*.int),
имя хоть бы и tmp.
запускаешь терминал, d ^tmp

С уважением. Сергей
...
Рейтинг: 0 / 0
10.05.2006, 16:21
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718265
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
Sergei Obrastsovо реляционных структурах.
где фиксированные по длине строки и описания полей
Маленький комментарий. Реляционная модель чисто логическая и не имеет отношения к физическим структурам и принципам хранения. Хорошо бы вам сразу на берегу это признать. И конкретные структуры хранения являются особенностями реализации конкретной РСУБД. И таковых множество. Хранение по строкам, да еще и с фиксированном их размером есть только один из подходов. Есть хранение по столбцам (см. Sybase IQ), есть IOT (Oracle), есть модель TransRelational. Да и "по строкам" хранять можно по разному.

Не ясно, почему вы с таким упорством говорите о "реляционных структурах" физического хранения, ведь такого понятия просто не существует.
...
Рейтинг: 0 / 0
10.05.2006, 16:23
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718318
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
mirМаленький комментарий. Реляционная модель чисто логическая и не имеет отношения к физическим структурам и принципам хранения. Хорошо бы вам сразу на берегу это признать.

запросто. ну вот, признал. что изменилось? вот я смотрю, что в MySQL, в
MS SQL и в Clarion размер БД почти одинаков. желающие могут полезть
в Oracle, SyBase и иже с ними, и получить примерно такую же картину.
выводы?

mir
И конкретные структуры хранения являются особенностями реализации конкретной РСУБД. И таковых множество. Хранение по строкам, да еще и с фиксированном их размером есть только один из подходов. Есть хранение по столбцам (см. Sybase IQ), есть IOT (Oracle), есть модель TransRelational. Да и "по строкам" хранять можно по разному.
Не ясно, почему вы с таким упорством говорите о "реляционных структурах" физического хранения, ведь такого понятия просто не существует.
я говорю, что при одинаковом подходе к логической структуризации
данных для последующей обработки и хранения, получается примерно
одинаковый объем хранимой информации. поэтому я позволяю себе
обобщать. что вам не нравится?

С уважением. Сергей
...
Рейтинг: 0 / 0
10.05.2006, 16:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718338
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
pavelvp ну яНо в случае
^gloname(123,456)
и
^gloname(123,789)
величина 123 скорее всего будет храниться только 1 раз на блок. Вот про этот случай я и писал. Создаётся впечатление, как будто только Каше так поступает :-)))
например? я с удовольствием послушаю

С уважением. Сергей
...
Рейтинг: 0 / 0
10.05.2006, 16:39
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718402
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
pavelvp Но в случае
^gloname(123,456)
и
^gloname(123,789)
величина 123 скорее всего будет храниться только 1 раз на блок. Вот про этот случай я и писал. Создаётся впечатление, как будто только Каше так поступает :-)))
Жаль, что так получилось. Разговор же шел про каше, я про эту СУБД и писал.
...
Рейтинг: 0 / 0
10.05.2006, 16:59
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718491
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
Sergei Obrastsovзапускаешь терминал, d ^tmp Легко сказать :-) Как его запустить то. У меня создана база MMM. Как мне к этой базе прицепится?
Что и где нужно сконфигурить, чтобы вместо
USER>
я бы увидел
TRD>
...
Рейтинг: 0 / 0
10.05.2006, 17:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718503
LittleCat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LittleCat
Участник
pavelvp
Что и где нужно сконфигурить, чтобы вместо
USER>
я бы увидел
TRD>
Да можно и на ходу пеерскочить
USER>zn "TRD"
TRD>
...
Рейтинг: 0 / 0
10.05.2006, 17:28
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718543
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
pavelvp Sergei Obrastsovзапускаешь терминал, d ^tmp Легко сказать :-) Как его запустить то. У меня создана база MMM. Как мне к этой базе прицепится?
Что и где нужно сконфигурить, чтобы вместо
USER>
я бы увидел
TRD>
В трее иконка, из нее - панель управления. Там слева безопасность, в ней бюджеты пользователей, В редактировании пользователя комбобокс с областью куда его пускать по умолчанию. Локальный терминал заходит как пользователь TRM.
...
Рейтинг: 0 / 0
10.05.2006, 17:38
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718554
комментатор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
комментатор
Гость
Еще проще
USER>zn "trd"
чем
USER>zn "TRD"
...
Рейтинг: 0 / 0
10.05.2006, 17:41
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718710
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
LittleCatДа можно и на ходу пеерскочить
USER>zn "TRD" О! Спасибо! А то у меня в кешовой панели никакой безопасности и никаких бюджетов пользователей нет.
Итак, господа. По пунктам.

Sergei Obrastsov"эмулированную подсистему хранения данных для эмулированного SQL" и хочешь назвать это оптимальной системой. Система хранения данных одна. Нечего там эмулировать.

а у тебя в РСУБД не так? или ты полагаешь, что VARCHAR(x) не есть указание
на предельный размер поля? не надо быть наивным Не так. Х - это максимальный размер, а не фиксированный. Чего там для его эмуляции нужно - я не понимаю. А про какие ты описания полей твердишь, так совсем не ясно... И что это за реляционные структуры - тоже непонятно. Ты же не знаешь как в конкретных СУБД данные хранятся - о чём тогда ты говоришь?

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

А теперь результаты, которые я получил загружая не тупо, по-настоящему.
Т.е. результаты честного теста (не совсем честно, т.к. структура данных была потеряна):
- Загрузка шла весьма шустренько - ничего удивительного, т.к. фактически шло "тупое" построение деревяхи с одним ключом.
- "оптимальный" размер файла cache.dat получился 208 мегов :-)))
Разница в 26 метров, от тех "неоптимальных" 234-х, получилась видимо за счёт отсутсвия 59 полей :-)

Что же я получил. Полное отсутствие структуры данных со всеми вытекающими и почти в 2 раза больший объём БД. Выигрышь только в скорости загрузки. И тот сомнительный... Нужно попробовать грузить в ЛИНТЕР тоже одной такой строкой.

Что опять я делал не так?
...
Рейтинг: 0 / 0
10.05.2006, 18:36
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718910
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
pavelvp[quot Sergei Obrastsov]Зачем??? И какой идеологии? Пока мы выяснили, что фиксированные размеры полей у DBF (причём здесь РСУБД?) и у одной из версий DB2.
Ой. А когда мы это выяснили? Может, мы не сходили по ссылке, приведённой ggv, а просто решили, что она подтверждает слова Демидова? Или Демидов объяснил нам внятно, что он имеет в виду?
...
Рейтинг: 0 / 0
10.05.2006, 20:28
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33718961
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anton Demidov
Участник
Я немного выпал из обсуждения, за что прошу прощения.
Следуя ссылке ggv мы попадаем на доку по совсем свеженькой V5R4 (не знаю никого, у кого бы она уже стояла).
Впрочем, не важно.
Итак, номер один - лёгкость использования - читаем :
V5R4In COBOL and C, varying-length character strings are represented as structures .
In C, varying-length character-string variables can also be represented by NUL-terminated strings. - везде бы так просто реализовали
...
CLOB varying-length character-string variables can be defined in all host languages except REXX, RPG/400, and COBOL/400 .
Надеюсь, перевод не нужен? Или пространные объяснения о "простоте" сравнения двух строк VARCHAR на Коболе, которые на самом деле структуры?

Номер два: качество имплементации в БД (ладно, ладно, ожидая шквал возмущений от ggv и ко. перефразирую это в "особенности реализации")
Tips for using VARCHAR and VARGRAPHIC data types in databases
Там говорится о том, что VARCHAR это всё равно фиксированный CHAR плюс опциональный сегмент, за который вы заплатите дополнительным i/o

Код: plaintext
1.
2.
--
Антон
Per rectum ad astrum
...
Рейтинг: 0 / 0
10.05.2006, 21:10
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719212
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
pavelvp Sergei Obrastsov"эмулированную подсистему хранения данных для эмулированного SQL" и хочешь назвать это оптимальной системой. Система хранения данных одна. Нечего там эмулировать.

ай, неправ, дарагой... есть там чего эмулировать и есть там чего скривлять
и выпрямлять. :) (сейчас меня опять обвинят в голословности). ну ладно:
таблицу вида поле1_поле2_поле3_...полеN в строке, № строки в столбце,
можно записать так

^table(n_строки)=поле1*поле2*поле3...*полеN

а можно так:

^table(n_строки,1)=поле1
^table(n_строки,2)=поле2
...
^table(n_строки,N)=полеN

вторая структура, как видишь, неоптимальна. и это только данные.
об индексации стоит говорить или экстраполируешь сам? :)

pavelvp
а у тебя в РСУБД не так? или ты полагаешь, что VARCHAR(x) не есть указание
на предельный размер поля? не надо быть наивным Не так. Х - это максимальный размер, а не фиксированный. Чего там для его эмуляции нужно - я не понимаю. А про какие ты описания полей твердишь, так совсем не ясно... И что это за реляционные структуры - тоже непонятно. Ты же не знаешь как в конкретных СУБД данные хранятся - о чём тогда ты говоришь?

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

pavelvp
Создаётся впечатление, как будто только Каше так поступает :-))) например? я с удовольствием послушаю Префиксное сжатие индексов у всех нормальных СУБД. У нас есть. И никакой дурак не будт хранить повторяющиеся ключи.

у нас - это где? Linter? возможно, я не буду спорить, посмотрю, если найду.
серьезно? так вот и не будет? а куда он их денет, скажи на милость?
в структуре вида:

Код: plaintext
1.
2.
3.
ключ1_записьN
ключ2_записьX
ключ3_записьY

ты полагаешь существует запись вида:

Код: plaintext
1.
ключ2_записьA_записьB_записьC... ?

увы, ТАК не получится. а получится вот ТАК:

Код: plaintext
1.
2.
3.
4.
5.
ключ1_записьX
ключ2_записьA
ключ2_записьB
ключ2_записьС
ключ3_записьY
это, естественно, при условии разрешении дублирования ключа.
в противном случае, ключ конечно только один, но и запись только одна.

pavelvp
А теперь результаты, которые я получил загружая не тупо, по-настоящему.
Т.е. результаты честного теста (не совсем честно, т.к. структура данных была потеряна):

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

pavelvp
- Загрузка шла весьма шустренько - ничего удивительного, т.к. фактически шло "тупое" построение деревяхи с одним ключом.

нет. построение "плоской таблицы". абасалютно идентичной твоей. :)

pavelvp
- "оптимальный" размер файла cache.dat получился 208 мегов :-)))
Разница в 26 метров, от тех "неоптимальных" 234-х, получилась видимо за счёт отсутсвия 59 полей :-)

повторюсь - поля не пропали, они все есть. не выдумывай
я же сказал, структура - неоптимальна. колоссальный выигрыш на лобовом
переносе данных невозможен. выигрывается за счет выброса NULL.
кстати, было бы неплохо посмотреть, убрались ли концевые "," в данных
или все-таки болтаются в массиве. запусти, plz, ^%G и посмотри на него.

pavelvp
Что же я получил. Полное отсутствие структуры данных со всеми вытекающими и почти в 2 раза больший объём БД. Выигрышь только в скорости загрузки. И тот сомнительный... Нужно попробовать грузить в ЛИНТЕР тоже одной такой строкой.

"полное отсутствие структуры данных", надо же. будь так добр,
приведи, plz, размер исходного файла с данными и посмотри на концевые
разделители.
насчет загрузки в ЛИНТЕР - запросто, только сможешь ли потом выдергивать
поля в нужном виде? :)

pavelvp
Что опять я делал не так?
посмотрим. :)

С уважением. Сергей
...
Рейтинг: 0 / 0
11.05.2006, 06:41
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719244
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Sergei Obrastsovа ведь все очень просто: в РСУБД - ФИКСИРОВАННАЯ ДЛИНА ЗАПИСИ.
складывается она из максимальных размеров полей. почему фиксированная?
а как ты собираешься запись искать, если у тебя длины записей разные?
или у тебя где-то сидит отдельная структура, в которой записаны позиции
для записей? тут уж слово "неоптимально" не подойдет, тут надо другое
искать. :)
а куда ты денешься без описаний полей? и почему ты решил, что не знаю?
не знал бы - промолчал. :)
Ага - а параметр резервирования места на странице для таблиц сделан для красоты, И карта распределения страниц в БД тоже. И всякие процедуры дефрагментации и сжатия

P.S. И еще ... ну не собирается pavelvp записи искать, вот хоть тресни и нигде лично у него "отдельная структура не сидит". Вот запросом сказать серверу, что ему нужно найти - он сделает, а искать записи по страницам не будет, открою страшную тайну почему ... потому что не сможет этого сделать, так же как и управлять "отдельной структурой", отвечающей за распределение заполнения данных по страницам. Вот такой вот еще один "недостаток" всех РСУБД для тех, кто даже настолько ленив, что не может взять в руки книжки и прочитать элементарные основы, а так же кодеров (матерых программеров), предпочитающих все делать самим.
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
11.05.2006, 07:22
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719255
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
ASCRUSАга - а параметр резервирования места на странице для таблиц сделан для красоты, И карта распределения страниц в БД тоже. И всякие процедуры дефрагментации и сжатия

а причем тут это? особенно про "резервирование места на странице". :)
дефрагментация и сжатие - вещи хорошие, только вот первая к нашему
обсуждения не имеет ну никакого отношения, а вот сжатие - да, очень
даже имеет, с учетом того, что сжатое надо предварительно разжимать.
а то ведь прикрутить тот же zlib на строку данных и я могу, получив
офигенную компрессию. :)

ASCRUS
P.S. И еще ... ну не собирается pavelvp записи искать, вот хоть тресни и нигде лично у него "отдельная структура не сидит". Вот запросом сказать серверу, что ему нужно найти - он сделает, а искать записи по страницам не будет, открою страшную тайну почему ... потому что не сможет этого сделать, так же как и управлять "отдельной структурой", отвечающей за распределение заполнения данных по страницам. Вот такой вот еще один "недостаток" всех РСУБД для тех, кто даже настолько ленив, что не может взять в руки книжки и прочитать элементарные основы, а так же кодеров (матерых программеров), предпочитающих все делать самим.

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

тебе не кажется, что получается забавная картина: то вы с пеной у рта
уверяете меня, что "такое невозможно", "так не бывает" и "так не
хранится", но как только разговор заходит о конкретных вещах - прыг
в кусты - "а нам и не надо, у нас сервер думает"? вы уж, господа,
определитесь с направлением, ага. :)

С уважением. Сергей
...
Рейтинг: 0 / 0
11.05.2006, 07:40
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719273
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
Sergei Obrastsov mirМаленький комментарий. Реляционная модель чисто логическая и не имеет отношения к физическим структурам и принципам хранения. Хорошо бы вам сразу на берегу это признать.
запросто. ну вот, признал. что изменилось? вот я смотрю, что в MySQL, в MS SQL и в Clarion размер БД почти одинаков. желающие могут полезть в Oracle, SyBase и иже с ними, и получить примерно такую же картину. выводы? Изменилось (надеюсь) то, что вы признали свою ошибку.
Далее, аналогичный вопрос: выводы? Я лично не имею установленных на компе 5 СУБД, поэтому не могу проверить истинность ваших слов про равный размер БД. Это вообще очень сомнительно, так как даже в одной СУБД (MS SQL Server) размер одной и той же базы может существенно меняться в зависимости от SHRINKDATABASE, от настройки индексов и т.д. Но в любом случае, если не применяется сжатие, то минимальный объем данных и должен быть примерно одинаков, поскольку строка из L байт занимает L байт, а N m-байтных чисел занимают N*m байт, чудес-то не бывает. Или вы верите в магию?
Sergei Obrastsov mirИ конкретные структуры хранения являются особенностями реализации конкретной РСУБД. И таковых множество. Хранение по строкам, да еще и с фиксированном их размером есть только один из подходов. Есть хранение по столбцам (см. Sybase IQ), есть IOT (Oracle), есть модель TransRelational. Да и "по строкам" хранять можно по разному.
Не ясно, почему вы с таким упорством говорите о "реляционных структурах" физического хранения, ведь такого понятия просто не существует.я говорю, что при одинаковом подходе к логической структуризации данных для последующей обработки и хранения, получается примерно одинаковый объем хранимой информации. поэтому я позволяю себе
обобщать. что вам не нравится?Если вы хотите говорить то, что только что сказали, то так и говорите. Но зачем же говорить про другое, про "реляционные структуры физического хранения", это просто неграмотно.
Sergei Obrastsovа ведь все очень просто: в РСУБД - ФИКСИРОВАННАЯ ДЛИНА ЗАПИСИ. складывается она из максимальных размеров полей. А ведь чуть раньше вы вроде признали, что это не так («ну вот, признал. что изменилось»). Выходит, не признал. Ваше упорство достойно лучшего применения. После того, как вам указали, что вы заблуждаетесь, и даже назвали несколько различных подходов к физическому хранению в РСУБД, вы снова повторяете эту чушь. Это такой специальный вид упрямства?
...
Рейтинг: 0 / 0
11.05.2006, 07:57
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719313
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
mirИзменилось (надеюсь) то, что вы признали свою ошибку.

ошибку? это уж слишком. я просто принял к сведению вашу точку зрения.
может действительно вам станет легче.

mir
случае, если не применяется сжатие, то минимальный объем данных и должен быть примерно одинаков, поскольку строка из L байт занимает L байт, а N m-байтных чисел занимают N*m байт, чудес-то не бывает. Или вы верите в магию?

я верю в факты. а факты говорят, что если уж выделено на поле 20 байт,
то все 20 байт в любой записи и будут забиты, даже если 20-байтное
значение этого поля встречается на миллион записей всего 1 раз. я ведь приводил вполне приличный пример того, что происходит с размерами при
занесении информации в РСУБД.

Sergei Obrastsov Если вы хотите говорить то, что только что сказали, то так и говорите. Но зачем же говорить про другое, про "реляционные структуры физического хранения", это просто неграмотно.

уф... а как "грамотно"?
Код: plaintext
1.
2.
3.
физические структуры хранения данных, свойственные
большинству реляционных систем, непротиворечащих списку так называемых
"исключений", приведенных господином "mir", в адекватности коего (списка, ага) я несколько сомневаюсь?

mir
Sergei Obrastsovа ведь все очень просто: в РСУБД - ФИКСИРОВАННАЯ ДЛИНА ЗАПИСИ. складывается она из максимальных размеров полей. А ведь чуть раньше вы вроде признали, что это не так («ну вот, признал. что изменилось»). Выходит, не признал.

где это я сказал "признаю, что в РСУБД отныне - ЗАПИСИ ПЕРЕМЕННОЙ ДЛИНЫ"? да ни в жисть я такого не признаю, врать - грешно. :)
признал, да только не то. надо было поинтересоваться "а что признал?" :)

mir
Ваше упорство достойно лучшего применения. После того, как вам указали, что вы заблуждаетесь, и даже назвали несколько различных подходов к физическому хранению в РСУБД, вы снова повторяете эту чушь. Это такой специальный вид упрямства?
да мне вообще-то и так неплохо. интересно, кто мне это указал? вы?
извините, слова вроде "да это не так!" - слова и есть. запись по столбцам
вместо записи по строкам, может и помогает в поиске, да нисколько не
влияет на размеры БД. про прочие модели говорить не буду, нет у меня
времени на скрупулезный анализ физических структур всех РСУБД, да
и неинтересно мне это, но я знаю одну простую вещь - принцип организации
"в железе" структур, логически называемых "реляционными", а это ярмо,
из которого выпрыгнуть невозможно.

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

С уважением. Сергей
...
Рейтинг: 0 / 0
11.05.2006, 08:36
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719330
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
IuraВот где Cache будет сильно пасовать, так это в расчетах. Если потребуется делать множество расчетов, система будет пасовать. Поскольку ей надо будет каждое число переводить в нормальную форму, вычислять, а потом запихивать ее опять в виде числа.

может и не стоило уже на это отвечать, тем более <Iura> куда-то запропастился, но не смог удержаться.

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

С уважением. Сергей
...
Рейтинг: 0 / 0
11.05.2006, 08:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719372
andy st
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andy st
Гость
Sergei Obrastsov
а переубедить меня очень просто. надо всего лишь сказать: смотри, парень,
а вот здесь все это не так.
лови
MSSQL2000
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
create table a (f1 varchar( 1000 ),f2 varchar( 1000 ))
go

create table b (f1 varchar( 1000 ),f2 varchar( 1000 ))
go

create table c (f1 varchar( 1000 ),f2 varchar( 1000 ))
go

set nocount on
declare @i integer
set @i =  0 
while @i <  10000 
begin
 insert into a	(f1,f2) values (null,null)
 insert into b	(f1,f2) values (replicate('x', 100 ),replicate('x', 100 ))
 insert into c	(f1,f2) values (replicate('x', 1000 ),null)
 set @i=@i+ 1 
end
--drop table a
select count(*) from a
select count(*) from b
select count(*) from c
exec sp_spaceused 'a'
exec sp_spaceused 'b'
exec sp_spaceused 'c'
set nocount off
drop table a
drop table b
drop table c
и результат
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
name	rows	reserved	data	index_size	unused
a	 9940      136  KB	          120  KB	   8  KB  	 8  KB

name	rows	reserved	data	index_size	unused
b	 9972      2248  KB	         2224  KB	   8  KB	      16  KB

name	rows	reserved	data	index_size	unused
c	 9919      11400  KB	 11344  KB      8  KB  	     48  KB
...
Рейтинг: 0 / 0
11.05.2006, 09:16
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719403
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
andy st
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
name	rows	reserved	data	index_size	unused
a	 9940      136  KB	          120  KB	   8  KB  	 8  KB

name	rows	reserved	data	index_size	unused
b	 9972      2248  KB	         2224  KB	   8  KB	      16  KB

name	rows	reserved	data	index_size	unused
c	 9919      11400  KB	 11344  KB      8  KB  	     48  KB

впечатляет. маленькое уточнение можно? у меня под рукой SQL сейчас нет,
поэтому я попрошу тебя: а можно ли повторить все это дело, но обращая
внимание на размер файла БД, а не на то, что он посчитал по полям?
если прав ты, то размер файла должен меняться. если прав я - то нет.
(понятное дело, нужно для каждого случая создавать новую базу, но
ведь это не сложно, ага?)

С уважением. Сергей
...
Рейтинг: 0 / 0
11.05.2006, 09:29
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719447
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Sergei Obrastsovя вообще-то догадывался об этом, но все-равно спасибо, открыл, панимашь,
глаза. только вот что ты называешь "страницей", если не секрет? особенно
с учетом вышеупомянутого "резервирования места" на них.
Не помню, чтобы мы переходили на ты. А по существу - почему бы не почитать примитивных книжек, коих до чертиков, где все это расжевано по косточкам - и что такое страница и что такое сжатие БД и что такое дефрагментация таблиц, вместо того, чтобы выдавать свои фантазии и убогие познания РСУБД за действительность, проявив как минимум уважение к своим оппонентам в споре ? Или религия не позволяет ? Или мы такие умные, что и так все знаем и можем учить тех, кто с этим работает ? Знаете чем вы MUMPS-сты пока на этом форуме отличаетесь от РСУБД-шников - тем, что разглагольствуете о том, что не знаете и на чем не работаете, путая термины, сравнивая РСУБД с DBF-файлами, путаясь в понятиях физической и логической структуре данных, смешивая релляционную алгебру и SQL в одну кучу и поря прочую настоящую чушь. Я не помню, чтобы лично я рассуждал о принципах хранения данных в MUMPS/CACHE или с умным видом критиковал глобалы ... по простой причине, что я этого не знаю. Но ... если бы меня прижало посморить с вами, то первым бы делом я скачал и поставил Cache, прочитал входящую документацию, ознакомился с базовыми понятиями и принципами работы, провел серию тестов ... и только потом бы стал делать выводы и осторожно приступать к спору, что кстати и начал делать pavelvp, который сразу же наткнулся на несовпадение лозунгов и реальной действительности.
...
Рейтинг: 0 / 0
11.05.2006, 09:43
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719487
MGR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MGR
Участник
Sergei Obrastsovвпечатляет. маленькое уточнение можно? у меня под рукой SQL сейчас нет,
поэтому я попрошу тебя: а можно ли повторить все это дело, но обращая
внимание на размер файла БД, а не на то, что он посчитал по полям?
если прав ты, то размер файла должен меняться. если прав я - то нет.
(понятное дело, нужно для каждого случая создавать новую базу, но
ведь это не сложно, ага?)


Я провел сравнение. Машина на которой есть сервер стоит рядом, но копипест не доступен. Поэтому описательно.
Каждый раз новая база (MS SQL)
Таблица имеет одно поле varchar(1000) и вставляется 100 000 строк.

Первый случай: вставляем replicate('X', 1000).
Размер базы вырос до 120Мб

Второй случай: вставляем replicate('X', 100).
Размер базы вырос до 13Мб

Третий случай: вставляем null
Размер вырос до 2Мб

Единственное непонятно - зачем я занимался проверкой того, в чем и так был уверен?
...
Рейтинг: 0 / 0
11.05.2006, 09:56
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719559
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
MGRПервый случай: вставляем replicate('X', 1000).
Размер базы вырос до 120Мб
Второй случай: вставляем replicate('X', 100).
Размер базы вырос до 13Мб
Третий случай: вставляем null
Размер вырос до 2Мб
Единственное непонятно - зачем я занимался проверкой того, в чем и так был уверен?
наверное, чтобы убедить меня? :) ok, спасибо.
остается извиниться за свою уверенность, действительно VARCHAR поля
пишутся не на максимальную длину. SORRY, на будущее буду осторожнее
с выводами. :)

С уважением. Сергей
...
Рейтинг: 0 / 0
11.05.2006, 10:14
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719564
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Anton DemidovЯ немного выпал из обсуждения, за что прошу прощения.
Следуя ссылке ggv мы попадаем на доку по совсем свеженькой V5R4 (не знаю никого, у кого бы она уже стояла).
Впрочем, не важно.
Итак, номер один - лёгкость использования - читаем :
V5R4In COBOL and C, varying-length character strings are represented as structures .
In C, varying-length character-string variables can also be represented by NUL-terminated strings. - везде бы так просто реализовали
...
CLOB varying-length character-string variables can be defined in all host languages except REXX, RPG/400, and COBOL/400 .
Надеюсь, перевод не нужен? Или пространные объяснения о "простоте" сравнения двух строк VARCHAR на Коболе, которые на самом деле структуры?
На мой взгляд, представление VARCHAR'ов структурами правильно и естественно, а null terminated строками - нет. И это не проблемы сервера DB2. Хотя и странно, почему REXX/400 не читает CLOB'ы - под виндами-то он может.

Номер два: качество имплементации в БД (ладно, ладно, ожидая шквал возмущений от ggv и ко. перефразирую это в "особенности реализации")
Tips for using VARCHAR and VARGRAPHIC data types in databases
Там говорится о том, что VARCHAR это всё равно фиксированный CHAR плюс опциональный сегмент, за который вы заплатите дополнительным i/o

А вот это странно. Хотя, быть может, не так плохо, как кажется.
...
Рейтинг: 0 / 0
11.05.2006, 10:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719599
MGR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MGR
Участник
Sergei Obrastsovнаверное, чтобы убедить меня? :) ok, спасибо.
остается извиниться за свою уверенность, действительно VARCHAR поля
пишутся не на максимальную длину. SORRY, на будущее буду осторожнее
с выводами. :)



Убедиться проще самому.
Я убедился году так в 98ом, когда после фокспро по привычке проектировал базу с char-ами. Ну и напроектировался, база распухла до 4Г, что тогда было достаточно много.
Простое изменение большинства описательных полей типа NAME, DESCR и пр. с char(80) на varchar(80) и т.д. позволило уместить ту же базу в 0.5Г.
...
Рейтинг: 0 / 0
11.05.2006, 10:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719615
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
Sergei Obrastsov andy st
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
name	rows	reserved	data	index_size	unused
a	 9940      136  KB	          120  KB	   8  KB  	 8  KB

name	rows	reserved	data	index_size	unused
b	 9972      2248  KB	         2224  KB	   8  KB	      16  KB

name	rows	reserved	data	index_size	unused
c	 9919      11400  KB	 11344  KB      8  KB  	     48  KB

впечатляет. маленькое уточнение можно? у меня под рукой SQL сейчас нет,
поэтому я попрошу тебя: а можно ли повторить все это дело, но обращая
внимание на размер файла БД, а не на то, что он посчитал по полям?
если прав ты, то размер файла должен меняться. если прав я - то нет.
(понятное дело, нужно для каждого случая создавать новую базу, но
ведь это не сложно, ага?)

С уважением. Сергей
К сожалению, с базой сделать сложнее. В первом случае - размер таблицы 120 KB, насколько я помню - в MSSQL нельзя задать размер базы таким мелким
ну а столбец reserved - это и есть физический размер данных. Так что, разница заметна.
...
Рейтинг: 0 / 0
11.05.2006, 10:27
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719700
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
MGRУбедиться проще самому.
Я убедился году так в 98ом, когда после фокспро по привычке проектировал базу с char-ами. Ну и напроектировался, база распухла до 4Г, что тогда было достаточно много.
Простое изменение большинства описательных полей типа NAME, DESCR и пр. с char(80) на varchar(80) и т.д. позволило уместить ту же базу в 0.5Г.
логично, если есть необходимость сравнивать. в MS SQL я всегда использал
varchar, особо не задумываясь. но мои базы никогда и не отличались
объемностью, так что тут как-то и не поэскпериментируешь. обрати внимание,
что в своем тесте я, конечно, использовал именно varchar. :)

С уважением. Сергей
...
Рейтинг: 0 / 0
11.05.2006, 10:50
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33719760
MGR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MGR
Участник
Sergei Obrastsov
логично, если есть необходимость сравнивать. в MS SQL я всегда использал
varchar, особо не задумываясь. но мои базы никогда и не отличались
объемностью, так что тут как-то и не поэскпериментируешь. обрати внимание,
что в своем тесте я, конечно, использовал именно varchar. :)


Да в том случае одна таблица с клиентами состояла из 4млн записей. Ну и поля:
ФИО (я тогда 50 заложил, потом встретился товарищ, в котором около 70 было :-) ).
Адресные поля (город, страна, адрес) - в сумме под 300 наверное.
Место работы, должность (ещё около 100)

Вобщем одна эта табличка 3Г наверное весила
...
Рейтинг: 0 / 0
11.05.2006, 11:03
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33720091
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
Sergei Obrastsov mirВаше упорство достойно лучшего применения. После того, как вам указали, что вы заблуждаетесь, и даже назвали несколько различных подходов к физическому хранению в РСУБД, вы снова повторяете эту чушь. Это такой специальный вид упрямства?
да мне вообще-то и так неплохо. интересно, кто мне это указал? вы? извините, слова вроде "да это не так!" - слова и есть. К примеру, я и указал. Повторю:
mir конкретные структуры хранения являются особенностями реализации конкретной РСУБД. И таковых множество. Хранение по строкам, да еще и с фиксированном их размером есть только один из подходов. Есть хранение по столбцам (см. Sybase IQ), есть IOT (Oracle), есть модель TransRelational.Ну, и где здесь голые слова слова "да это не так"? Я перечислил не только некоторые принципы хранения, но даже и продукты, в которых они реализованы. После это вы интересуетесь "кто мне это указал". Вы читать не умеете или память короткая?
Sergei Obrastsovзапись по столбцам вместо записи по строкам, может и помогает в поиске, да нисколько не влияет на размеры БД. про прочие модели говорить не буду, нет у меня времени на скрупулезный анализ физических структур всех РСУБД, да и неинтересно мне это, но я знаю одну простую вещь - принцип организации "в железе" структур, логически называемых "реляционными", а это ярмо, из которого выпрыгнуть невозможно.Перевод на русский: "я ни черта не знаю, как на самом деле, да и знать не хочу, я просто уверен в свое правоте". Кстати, упоминание о железе меня заинтриговало. Вы полагаете, что модель данных однозначно определяет и аппаратную реализацию хранения? Я уже не удивлен.
Sergei Obrastsov
а переубедить меня очень просто. надо всего лишь сказать: смотри, парень, а вот здесь все это не так. вот тебе записи переменной длины, вот тебе нефиксированные поля, а вот тебе и "не табличная" структура записи. и я скажу - простите, мужики, урок хороший, обобщать теперь буду с умом. и мы все разойдемся довольные друг другом. но вот пока этого нет, я, уж извини, останусь при своем мнении.Вам уже все это было сказано (см. выше). Чего вы еще ждете? Огненные буквы в небе?
...
Рейтинг: 0 / 0
11.05.2006, 12:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33721449
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
Sergei Obrastsov
ай, неправ, дарагой... есть там чего эмулировать и есть там чего скривлять
и выпрямлять. :) (сейчас меня опять обвинят в голословности).

Умник :-\ О да... Я же совсем забыл, что ты там "плоскую структуру" хранишь. Я же совсем забыл, что мы не о СУБД говорим, а о системе программирования. Там же одни строки. Прям как в DBF :-), хотя это же просто CSV :-)

таблицу вида поле1_поле2_поле3_...полеN в строке, № строки в столбце,
можно записать так

^table(n_строки)=поле1*поле2*поле3...*полеN

а можно так:

^table(n_строки,1)=поле1
^table(n_строки,2)=поле2
...
^table(n_строки,N)=полеN

вторая структура, как видишь, неоптимальна. и это только данные.
Не вижу, дарагой... Вижу, что второй вариант для меня предпочтительней. Зачем мне тогда СУБД нужна? Можно просто CSV-файлик ковырять...


а ведь все очень просто: в РСУБД - ФИКСИРОВАННАЯ ДЛИНА ЗАПИСИ.
складывается она из максимальных размеров полей. почему фиксированная?
а как ты собираешься запись искать, если у тебя длины записей разные?

Я плачу... Смешной ты :-) Кстати, я тут выяснил на досуге, что в Каше фиксированная длина записи - 32К :-)
а куда ты денешься без описаний полей? и почему ты решил, что не знаю?
не знал бы - промолчал. :)
Не знаю, что ты подразумеваешь под описанием полей... Но это описание сохраняется один раз - в словаре.


[quot pavelvp]И никакой дурак не будт хранить повторяющиеся ключи.
у нас - это где? Linter? возможно, я не буду спорить, посмотрю, если найду.
серьезно? так вот и не будет? а куда он их денет, скажи на милость?
...
ты полагаешь существует запись вида:

Код: plaintext
1.
ключ2_записьA_записьB_записьC... ?

увы, ТАК не получится...

Не полагаю - я знаю!!! Именно так хранятся у нас в страницах индексные записи.
Мало того,
Код: plaintext
1.
2.
ключ1_записьА
ключ2_записьВ
ключ3_записьС
будет выглядеть вот так:
Код: plaintext
ключ1_2_3_записьА_записьВ_записьС

И я уверен почти на 100%, что и Каше так хранит. Если нет - туши свет... объём БД будет - мама не горюй.

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

нет. построение "плоской таблицы". абасалютно идентичной твоей. :) Как мне сделать не "плоскую"? Надо кого очень сильно просить?


повторюсь - поля не пропали, они все есть. не выдумывай
я же сказал, структура - неоптимальна. колоссальный выигрыш на лобовом
переносе данных невозможен. выигрывается за счет выброса NULL.
Ага, значит опять неоптимальна... Через SQL было не оптимально. Я же спрашивал - как мне загрузить данные, чтобы было оптимально. Ты мне ответил. И опять не оптимально... Прямо напасть какая-то.
Хочешь скажу почему не оптимально? На одном бинаром представлении дат и чисел экономится байт по 30 на запись. Вот уже 30 мегов нашли...

... я ведь приводил вполне приличный пример того, что происходит с размерами при
занесении информации в РСУБД. Ну да...

И снова повторяю: не ставлю целью критику подходов - не сравниваю M, Cache и другие системы. Но читать вот такую вот ахинею:
но я знаю одну простую вещь - принцип организации
"в железе" структур, логически называемых "реляционными", а это ярмо,
из которого выпрыгнуть невозможно. просто невмоготу.
...
Рейтинг: 0 / 0
11.05.2006, 20:05
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33721467
LittleCat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LittleCat
Участник
pavelvpЯ плачу... Смешной ты :-) Кстати, я тут выяснил на досуге, что в Каше фиксированная длина записи - 32К :-)

Не путайте ограничение на длину одного узла с фиксированной длиной записи.
pavelvp
Не полагаю - я знаю!!! Именно так хранятся у нас в страницах индексные записи.
Мало того,
Код: plaintext
1.
2.
ключ1_записьА
ключ2_записьВ
ключ3_записьС
будет выглядеть вот так:
Код: plaintext
ключ1_2_3_записьА_записьВ_записьС

И я уверен почти на 100%, что и Каше так хранит.

Полный бред, конечно же Каше так не хранит. Прежде чем такое утверждать, последуйте совету ASCRUS
Я не помню, чтобы лично я рассуждал о принципах хранения данных в MUMPS/CACHE или с умным видом критиковал глобалы ... по простой причине, что я этого не знаю. Но ... если бы меня прижало посморить с вами, то первым бы делом я скачал и поставил Cache, прочитал входящую документацию, ознакомился с базовыми понятиями и принципами работы, провел серию тестов ... и только потом бы стал делать выводы и осторожно приступать к спору, что кстати и начал делать pavelvp...
Увы, в том посте Вас преждевременно похвалили :-)
...
Рейтинг: 0 / 0
11.05.2006, 20:21
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33721585
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
LittleCatНе путайте ограничение на длину одного узла с фиксированной длиной записи. Требуется пояснение в чём отличие.
LittleCat pavelvp
Код: plaintext
ключ1_2_3_записьА_записьВ_записьС

И я уверен почти на 100%, что и Каше так хранит.

Полный бред, конечно же Каше так не хранит.
Ну не буквально, конечно. Имелось ввиду, что дерево
"key1","val1"
"key1","val2"
"key2","val3"
"key2","val4"
"key2","val5"
"key3","val6"
"key3","val7"
хранится следующим образом
key1_"val1"_"val2"_2_"val3"_"val4"_"val5"_3_"val6"_"val7"

Это префиксное сжатие индексов. Или Каше делает не так??? Скажете "не так" - позволю себе усомниться...
...
Рейтинг: 0 / 0
11.05.2006, 22:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33721589
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
LittleCatПолный бред, конечно же Каше так не хранит. Прежде чем такое утверждать, последуйте советуА почему бы просто, без закидонов, не пояснить на пальцах, как же он их все-таки хранит ? Вот никак не могу понять некоторых "специалистов". "Не так все" - грят, а как - как рыба об лед, или сами не знают, или очень боятся рассказать. pavelp хоть что-то попытался выжать из вас, поставил продукт, проверил некоторые утверждения, которые оказались "слегка" ложными. А в ответ - "неправильно ты все делаешь". Ну так скажите как правильно, хватит пальцами за косяки цепляться...
...
Рейтинг: 0 / 0
11.05.2006, 22:07
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33721679
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
какая разница кто как хранит без привязки к предмету. В одних случаях выгодней хранить дамп памяти, в других плоские таблицы. Это все равно, что спорить какая розетка лучше. Лучше та, к которой вилка подходит. Что лучше: джип, спортивное купе или семейный минивен. Тема примерно о том же.

авторукажите 5 сильных и 5 слабых сторон каждого продукта

Для каких задач? Иначе сильная сторона Cache - это то, что в названии меньше букв, чем в Oracle, документацию писать легче.
...
Рейтинг: 0 / 0
12.05.2006, 00:06
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33721806
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
pavelvp
Умник :-\ О да... Я же совсем забыл, что ты там "плоскую структуру" хранишь. Я же совсем забыл, что мы не о СУБД говорим, а о системе программирования. Там же одни строки. Прям как в DBF :-), хотя это же просто CSV :-)

таблицу вида поле1_поле2_поле3_...полеN в строке, № строки в столбце,
можно записать так

^table(n_строки)=поле1*поле2*поле3...*полеN

а можно так:

^table(n_строки,1)=поле1
^table(n_строки,2)=поле2
...
^table(n_строки,N)=полеN

вторая структура, как видишь, неоптимальна. и это только данные.
Не вижу, дарагой... Вижу, что второй вариант для меня предпочтительней. Зачем мне тогда СУБД нужна? Можно просто CSV-файлик ковырять...

а не надо торопиться, ага. естественно система дает возможности
работать со строкой данных. я не зря спрашивал о разделителе.
так что имеем:

в неоптимальном, на мой взгляд, варианте:
Код: plaintext
1.
2.
3.
4.
s f1=^table(n_строки, 1 )
s f2=^table(n_строки, 2 )
...
s fN=^table(n_строки,N)
что неоптимального? а лишняя индексация, увеличение объема хранения,
увеличение (N-кратно) количество чтений БД на одну запись

а вот оптимальный, на мой взгляд, вариант:
Код: plaintext
1.
2.
3.
4.
5.
6.
s data=^table(n_строки) ;взяли всю запись
s del="," ;установили разделитель
s f1=$piece(data,del, 1 )
s f2=$piece(data,del, 2 )
...
s fN=$piece(data,del,N)


Я плачу... Смешной ты :-) Кстати, я тут выяснил на досуге, что в Каше фиксированная длина записи - 32К :-)

максимальная. :)


Не полагаю - я знаю!!! Именно так хранятся у нас в страницах индексные записи.
Мало того,
Код: plaintext
1.
2.
ключ1_записьА
ключ2_записьВ
ключ3_записьС
будет выглядеть вот так:
Код: plaintext
ключ1_2_3_записьА_записьВ_записьС

хорошо, ты знаешь. в таком случае оцени, plz, трудоемкость поиска
10-тысячной записи в этом контексте. вот так, навскидку, в какой странице,
начиная от первой записи будет идти 10-тысячная?


И я уверен почти на 100%, что и Каше так хранит. Если нет - туши свет... объём БД будет - мама не горюй.

ты неправ. так - не хранит. хранит вот так:
Код: plaintext
1.
2.
3.
4.
^tabidx(idx1)=n1
^tabidx(idx1)=n2
^tabidx(idx2)=n3
...


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

демонстрирую:
дана строка данных:
Код: plaintext
1.
 1 , 2 , 3 , 4 , 5 , 6 ,NULL, 8 , 9 ,NULL,NULL,NULL
переводим ее в формат:
Код: plaintext
1.
 1 , 2 , 3 , 4 , 5 , 6 ,, 8 , 9 ,,,
почему? а зачем мне хранить "NULL"? я буду хранить <пусто>, благо
система это позволяет в данных.
теперь вопрос: а нафига нам эти ",,," в конце, если, что в случае
явно "ограниченного разделителями пустого поля", что в случае
отсутствия разделителей, система выдаст <пусто>?
то есть:
Код: plaintext
1.
2.
$piece("1,2,3,4,5,6,,8,9,,,",",", 12 ) -> ""
$piece("1,2,3,4,5,6,,8,9",",", 12 )    -> ""
вот почему не люблю "," в качестве разделителя, читать неудобно
гораздо приятнее было бы, например, "*"
Код: plaintext
1.
2.
$piece("1*2*3*4*5*6**8*9***","*", 12 ) -> ""
$piece("1*2*3*4*5*6**8*9","*", 12 )    -> ""
наличие сдвоенных разделителей для поля № 7 важно, а вот концевых - нет.
если я добавляю значение в поле, которое не определено в строке
изначально - оно определится:
Код: plaintext
1.
Set $piece("1,2,3,4,5,6,,8,9",",", 12 )= 30  -> "1,2,3,4,5,6,,8,9,,,30"

нет. построение "плоской таблицы". абасалютно идентичной твоей. :) Как мне сделать не "плоскую"? Надо кого очень сильно просить?

а что ты с ней хочешь сделать? в данном случае речь шла только о размерности, так что зачем выдумывать лишние структуры?


повторюсь - поля не пропали, они все есть. не выдумывай
я же сказал, структура - неоптимальна. колоссальный выигрыш на лобовом
переносе данных невозможен. выигрывается за счет выброса NULL.
Ага, значит опять неоптимальна... Через SQL было не оптимально. Я же спрашивал - как мне загрузить данные, чтобы было оптимально. Ты мне ответил. И опять не оптимально... Прямо напасть какая-то.
Хочешь скажу почему не оптимально? На одном бинаром представлении дат и чисел экономится байт по 30 на запись. Вот уже 30 мегов нашли...

ты мне размер исходного файла когда скажешь? :)
неоптимальна, потому что мы просто переносим данные списком.
неоптимальна, потому что работать без наличия индексов с этой структурой
очень накладно
поэтому выигрыш здесь небольшой, только за счет убирания "лишних" символов
в данном случае NULL, ну и соответствующих концевых разделителей
проявится выигрыш лишь при наличии индексов, причем мгновенно.
потому как структура вида
Код: plaintext
1.
^table(n_строки)=поле1...поле59
заменится структурой
Код: plaintext
1.
^table(полеX)=поле1...поле59 ;полеX можно выбросить из данных

С уважением. Сергей
...
Рейтинг: 0 / 0
12.05.2006, 06:54
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33721810
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
pavelvp LittleCatНе путайте ограничение на длину одного узла с фиксированной длиной записи. Требуется пояснение в чём отличие.

32k - максимальная длина данного при узле. это может быть запись,
может быть одно поле, может быть часть поля (как кому нравится)
фискированной длины записи не существует

pavelvp
Ну не буквально, конечно. Имелось ввиду, что дерево
"key1","val1"
"key1","val2"
"key2","val3"
"key2","val4"
"key2","val5"
"key3","val6"
"key3","val7"
хранится следующим образом
key1_"val1"_"val2"_2_"val3"_"val4"_"val5"_3_"val6"_"val7"

Это префиксное сжатие индексов. Или Каше делает не так??? Скажете "не так" - позволю себе усомниться...
не так. я уже четвертый раз об этом пишу. :)
Код: plaintext
1.
2.
3.
4.
5.
^array(index1)=<данное>
^array(index1,index2)=<данное>
^array(index1,index2,index3)=<данное>
^array(index2)=<данное>
^array(index2,index3)=<данное>
то есть пишется полная ссылка на узел с данным.
а жмется она по отношению к предыдущей ссылке.
поскольку в пределах блока может присутствовать только один массив,
ссылка всегда поджимается, хотя бы на длину имени массива.

С уважением. Сергей
...
Рейтинг: 0 / 0
12.05.2006, 07:03
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33724117
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
Ну наконец-то... четыре страницы потребовалось, чтобы ты сказал когда может выигрышь в хранении получиться. А то я уж сам хотел про это написать :-)
А получится он только при наличии "кластерного" индекса. Никакой другой экономии нет. Значительная экономия будет только если ключи уникальны. Если же кардинальность низкая, то экономия будет небольшой. И естественным образом вытекаующие минусы - поддержание такой структуры весьма накладно - при модификациях общая эффективность может быть значительно ниже, чем у отдельно взятых "индекс" + "данные".

Sergei Obrastsov...оцени, plz, трудоемкость поиска
10-тысячной записи в этом контексте. вот так, навскидку, в какой странице,
начиная от первой записи будет идти 10-тысячная?
Естественно я описывал стуктуру одной страницы. Не нужно буквально понимать. Так нарисовал - чтобы была наглядно видна префиксная упаковка ключей.

Sergei Obrastsov
pavelvp
key1_"val1"_"val2"_2_"val3"_"val4"_"val5"_3_"val6"_"val7"
не так. я уже четвертый раз об этом пишу. :)
Код: plaintext
1.
2.
3.
4.
5.
^array(index1)=<данное>
^array(index1,index2)=<данное>
^array(index1,index2,index3)=<данное>
^array(index2)=<данное>
^array(index2,index3)=<данное>
то есть пишется полная ссылка на узел с данным.
а жмется она по отношению к предыдущей ссылке.
поскольку в пределах блока может присутствовать только один массив,
ссылка всегда поджимается, хотя бы на длину имени массива.
Ититская сила! А я о чём! Я же то же самое написал! Только я ещё показал, что одинаковый часть(префикс) ключа не дублируется.
Узлы с данными... говори нормальным языком - листья дерева.

Мне кажется, обсуждать здесь больше нечего. У каждого подхода есть свои плюсы и минусы. Выигрывая в одном - проигрываешь в другом. Не будут M-системы выглядеть лучше РСУБД везде и всегда, как утверждают здесь некоторые товарищи.
...
Рейтинг: 0 / 0
12.05.2006, 19:53
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33724402
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
pavelvpНу наконец-то... четыре страницы потребовалось, чтобы ты сказал когда может выигрышь в хранении получиться. А то я уж сам хотел про это написать :-)
А получится он только при наличии "кластерного" индекса. Никакой другой экономии нет. Значительная экономия будет только если ключи уникальны. Если же кардинальность низкая, то экономия будет небольшой. И естественным образом вытекаующие минусы - поддержание такой структуры весьма накладно - при модификациях общая эффективность может быть значительно ниже, чем у отдельно взятых "индекс" + "данные".

е-мое, ну что ты все время вперед забегаешь? при наличии ЛЮБОГО индекса.
и чем их больше, тем заметнее. я же писал в примере, сколько индексов
влезает. а если ты предлагаешь обходиться без индексов в РСУБД, то
мы можем оценить скорость обработки данных на, скажем, 100 млн.записей. :)

Ититская сила! А я о чём! Я же то же самое написал! Только я ещё показал, что одинаковый часть(префикс) ключа не дублируется.
Узлы с данными... говори нормальным языком - листья дерева.

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

С уважением. Сергей
...
Рейтинг: 0 / 0
13.05.2006, 02:26
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33724405
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
pavelvpНу наконец-то... четыре страницы потребовалось, чтобы ты сказал когда может выигрышь в хранении получиться. А то я уж сам хотел про это написать :-)
А получится он только при наличии "кластерного" индекса. Никакой другой экономии нет. Значительная экономия будет только если ключи уникальны. Если же кардинальность низкая, то экономия будет небольшой. И естественным образом вытекаующие минусы - поддержание такой структуры весьма накладно - при модификациях общая эффективность может быть значительно ниже, чем у отдельно взятых "индекс" + "данные".

еще раз по этому поводу (ну не проснулся еще, извини). :)
что ты привязался к этому "кластерному" индексу? если тебя сбивает с толку
нарисованная структура, то извини, я уже потом подумал, что нарисовал
именно "ключ", но надеялся, что ты поймешь и простишь мою оплошность. :)
конечно, речь идет не о ключе, а об индексе.
Код: plaintext
1.
^table(полеX,n)=поле1...полеN
вот как раз при уникальности ключей экономии взяться неоткуда, жать будет
нечего, все разное. :) не понял в чем проблема с модификацией.

С уважением. Сергей
...
Рейтинг: 0 / 0
13.05.2006, 02:43
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33724877
буржуй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
буржуй
Гость
>pavelvp:
Мне кажется, обсуждать здесь больше нечего. У каждого подхода есть свои плюсы и минусы. Выигрывая в одном - проигрываешь в другом. Не будут M-системы выглядеть лучше РСУБД везде и всегда, как утверждают здесь некоторые товарищи.

Шо за плюсы могут быть у подхода, у которого меньше арсенал методов обработки данных ? М-системы лучше РСУБД везде и всегда.
...
Рейтинг: 0 / 0
13.05.2006, 21:33
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33724950
Фотография Ааз
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ааз
Участник
буржуйШо за плюсы могут быть у подхода, у которого меньше арсенал методов обработки данных ? М-системы лучше РСУБД везде и всегда.Т.е. арсенал методов обработки - единственный, надо полагать, критерий? Тогда М-системы просто отстой по сравнению с любой самописной приблудой. Типа, для любого наперед заданного кол-ва методов можно придумать N+1-ый.

Детский сад :-(
...
Рейтинг: 0 / 0
13.05.2006, 23:55
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33725198
буржуй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
буржуй
Гость
Даже на детский сад не тянет пропаганда ограниченных в представлениях о базах данных РСУБД-шников.
...
Рейтинг: 0 / 0
14.05.2006, 14:04
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33725266
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
буржуй
Шо за плюсы могут быть у подхода, у которого меньше арсенал методов обработки данных ? М-системы лучше РСУБД везде и всегда.

Ну, к примеру, сами методы в РСУБД имют плюсы. Всетаки М-системы шо-то дореляционное или какая-то попытка привиставаться к ООСУБД.

буржуй
Даже на детский сад не тянет пропаганда ограниченных в представлениях о базах данных РСУБД-шников.

С каких пор представления о базах данных М-системщиков то попали в разряд передовых? Там вообще файловыми системами попахивает - т.е. системами без СУБД. По крайней мере, пока их взгляды в литре по БД как бы не учитывались. Это все-таки какое-то левое ИТ технологиях, если не отстающее направление.
И перед кем пропагандировать РСУБД? - они и так доминируют. Хто их не знает? А М-системы именно и нуждаются в пропаганде. Их ни РСУБД-шники ни ООСУБД-шники либо не знают, либо считают чем-то несерьезным в большинстве случаев. По-крайней мере, пока такое впечетление и на этом форуме и от всех текство, кроме напичанных М-системщиками.
...
Рейтинг: 0 / 0
14.05.2006, 15:16
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33725379
Фотография Ааз
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ааз
Участник
буржуйДаже на детский сад не тянет пропаганда ограниченных в представлениях о базах данных РСУБД-шников.А чего это вы меня в [Р]СУБД-шники огульно записали? Да еще пропаганду навешиваете? Я вроде как предъявил претензии только к качеству вашего аргумента. Разве нет?

Всего
...
Рейтинг: 0 / 0
14.05.2006, 16:51
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33726411
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
to Sergei Obrastsov
Меня ничего с толку не сбивает. Если ты чего-то не понимаешь - это не моя проблема. Всё, завязываем с бестолковым флеймом.
...
Рейтинг: 0 / 0
15.05.2006, 11:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33726595
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
pavelvpto Sergei Obrastsov
Меня ничего с толку не сбивает. Если ты чего-то не понимаешь - это не моя проблема. Всё, завязываем с бестолковым флеймом.

http://kx.com/q/d/kdb+1.htm
Сергей
интересует Ваше мнение по поводу этой системы

там есть интересные вещи - например
арифметич функции работают на множествах и результат - множество
Конечно все легко эмулируется в М
но кажется эта штучка в целом весьма интересная

Вот с кем бы сравнить CACHE
==================
...
Рейтинг: 0 / 0
15.05.2006, 12:08
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33727165
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
MX -- ALEXhttp://kx.com/q/d/kdb+1.htm
Сергей
интересует Ваше мнение по поводу этой системы

там есть интересные вещи - например
арифметич функции работают на множествах и результат - множество
Насколько я там посмотрел, там не множества, а списки.
...
Рейтинг: 0 / 0
15.05.2006, 14:12
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33727515
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
MX -- ALEXhttp://kx.com/q/d/kdb+1.htm
Сергей
интересует Ваше мнение по поводу этой системы
там есть интересные вещи - например
арифметич функции работают на множествах и результат - множество
Конечно все легко эмулируется в М
но кажется эта штучка в целом весьма интересная
Вот с кем бы сравнить CACHE
==================
действительно интересно, хороший подход.
in-memory-database на M не эмулируешь, ага.
а остальное, конечно, эмулируется не сложно.
только вот обещанные скорости и помещаемость в памяти...
действительно ли это так компактно и быстро? насчет быстро я
готов поверить, сам видел похожее, но тут возникают вопросы о
подгрузке и маппировании на диске.
нет, надо щупать руками, слишком красиво пишут.
так ведь не дадут, какой из меня потенциальный клиент? :)

С уважением. Сергей

P.S. а что Cache? Я бы сравнивал с MSM и GT-M, если бы те
хоть близко подходили по скорости, про M3 я вообще молчу.
был хороший задел у O'Kane, но тот увлекся трансляцией M в C.
и что осталось? FreeM-Linux? несерьезно как-то, хоть и
реализация великолепная.
...
Рейтинг: 0 / 0
15.05.2006, 15:10
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33727971
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
Sergei Obrastsov MX -- ALEXhttp://kx.com/q/d/kdb+1.htm
Сергей
интересует Ваше мнение по поводу этой системы
там есть интересные вещи - например
арифметич функции работают на множествах и результат - множество
Конечно все легко эмулируется в М
но кажется эта штучка в целом весьма интересная
Вот с кем бы сравнить CACHE
==================
действительно интересно, хороший подход.
in-memory-database на M не эмулируешь, ага.
а остальное, конечно, эмулируется не сложно.
только вот обещанные скорости и помещаемость в памяти...
действительно ли это так компактно и быстро? насчет быстро я
готов поверить, сам видел похожее, но тут возникают вопросы о
подгрузке и маппировании на диске.
нет, надо щупать руками, слишком красиво пишут.
так ведь не дадут, какой из меня потенциальный клиент? :)

С уважением. Сергей

P.S. а что Cache? Я бы сравнивал с MSM и GT-M, если бы те
хоть близко подходили по скорости, про M3 я вообще молчу.
был хороший задел у O'Kane, но тот увлекся трансляцией M в C.
и что осталось? FreeM-Linux? несерьезно как-то, хоть и
реализация великолепная.

Пытаемся добиться ценника - как то уклончиво отписываются
хоть мы клиент не тонкий :)

Вообще то если бы удалось что-то найти подходящее
именно под наш вариант интерфейса с базой через EXCEL
(а у kdb+ есть RTD - для отображения базы на EXCEL
в реальном времени - именно так и мы работаем !! )
http://www.skelton.de/slog/Articles/ExcelRTDServer.html

то мы бы ушли с CACHE - мы не м-патриоты, а жадные,
противные дельцы с волосатыми лапами

но надо чтобы 3 условия -
- лицензия еще дешевле за соединение, чем CACHE,
- сервер отстреливал ответы еще быстрее,
- все запросы и бизнес-логика помещались в клетках excel

пока альтернативы не видим
и остаемся на CACHE

Такой вот интерес проводить сравнения..
...
Рейтинг: 0 / 0
15.05.2006, 16:48
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33728071
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
MX -- ALEXВообще то если бы удалось что-то найти подходящее
именно под наш вариант интерфейса с базой через EXCEL
(а у kdb+ есть RTD - для отображения базы на EXCEL
в реальном времени - именно так и мы работаем !! )
Кто мешает написать RTD-сервер поверх любой СУБД (а то и вообще не СУБД)? И использовать его из экселя?
...
Рейтинг: 0 / 0
15.05.2006, 17:10
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33728080
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
MX -- ALEXто мы бы ушли с CACHE - мы не м-патриоты, а жадные,
противные дельцы с волосатыми лапами

да ладно, то же мне проблема. объем и скорость - вот главное.
а там Cache или что другое - не имеет большого значения.

MX -- ALEX
но надо чтобы 3 условия -
- лицензия еще дешевле за соединение, чем CACHE,

насколько я знаю, там же есть разные варианты лицензий,
может получится подобрать что-нибудь попроще?

MX -- ALEX
- сервер отстреливал ответы еще быстрее,

уходите с SQL и объектов. чистый M - быстрее не бывает.
быстрее только C, но там нет БД :)

MX -- ALEX
- все запросы и бизнес-логика помещались в клетках excel

я конечно смутно представляю, что им там делать, когда
туда проще сгружать уже обработанные данные, ну да ладно. :)

MX -- ALEX
пока альтернативы не видим
и остаемся на CACHE

альтернатива всегда есть, ее только нужно найти.
так Cache или MSM+Cache?

MX -- ALEX
Такой вот интерес проводить сравнения..
понимаю, только вот где взять-то?

С уважением. Сергей
...
Рейтинг: 0 / 0
15.05.2006, 17:13
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33728187
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
Sergei Obrastsovальтернатива всегда есть, ее только нужно найти.
так Cache или MSM+Cache?



Cache 5.1 NT резвее чем MSM 4.4 NT
в полтора-два раза

остальные м - медленнeе чем MSM

где только можно ставим CACHE-5.1
иногда - M3, GTM, M21
все совместимо - ибо сделано на чистом MUMPS
(для скорости тоже)
...
Рейтинг: 0 / 0
15.05.2006, 17:46
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33728204
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
ЛП MX -- ALEXВообще то если бы удалось что-то найти подходящее
именно под наш вариант интерфейса с базой через EXCEL
(а у kdb+ есть RTD - для отображения базы на EXCEL
в реальном времени - именно так и мы работаем !! )
Кто мешает написать RTD-сервер поверх любой СУБД (а то и вообще не СУБД)? И использовать его из экселя?

нехватка ума и времени

и все равно вопрос
- а скорость будет выше чем "CACHE на прямом доступе" ??
...
Рейтинг: 0 / 0
15.05.2006, 17:50
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33728310
Sergei Obrastsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei Obrastsov
Участник
MX -- ALEXCache 5.1 NT резвее чем MSM 4.4 NT
в полтора-два раза

всего? странно, я полагал, что различие должно быть значимее.
я, конечно, не следил пристально за развитием MSM давно, но
зная корни MSM и учитывая упертость Micronetics, сильно
сомневаюсь даже в переписывании старого п-кода.

С уважением. Сергей
...
Рейтинг: 0 / 0
15.05.2006, 18:26
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33729251
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
MX -- ALEX все запросы и бизнес-логика помещались в клетках excel

а можно вопрос:
формула -> значение -> клетка
запрос -> произвольное число строк с произвольными столбцами -> ????
т.е. куда помещается рез-т запроса ?
...
Рейтинг: 0 / 0
16.05.2006, 11:09
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33729507
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
мод MX -- ALEX все запросы и бизнес-логика помещались в клетках excel

а можно вопрос:
формула -> значение -> клетка
запрос -> произвольное число строк с произвольными столбцами -> ????
т.е. куда помещается рез-т запроса ?

Сначала таблица-результат помещается на М-сервере
в двумерное дерево - модель excel-листа
При этом фиксируется фактическое "разбухание" по обеим координатам

затем
1.
excel-клиенту выдается предварительная команда на
подготовку площадки на его запросившем листе для приема таблицы
соответсвенно в excel-лист добавляютя строки и столбцы (упрощенно)

2.
клиенту передается сам ответ -
дерево-таблица которая быстро целым блоком
садится точно на подготовленную и отформатированную площадку
При этом отдельная ячейка может изменить лицо (цвет-шрифт-бордюр)
если на нее есть специальое указание - тег условного форматирования.
- например все ячейки где просрочена оплата товара
В таблицу сажаются также кнопки и выпадающие списки
для дальнейшей интерактивности

Все заточено на "очень быстро"
пример в приложении
(кнопы работают только в MX-системе )
...
Рейтинг: 0 / 0
16.05.2006, 12:27
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33730339
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
MX -- ALEX
понятно, спасибо.
...
Рейтинг: 0 / 0
16.05.2006, 16:18
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33742123
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Anton DemidovИтак, номер один - лёгкость использования - читаем
Опускаю легкость использования как сильно субъективную вещь.
Anton Demidov
Номер два: качество имплементации в БД (ладно, ладно, ожидая шквал возмущений от ggv и ко. перефразирую это в "особенности реализации")
Tips for using VARCHAR and VARGRAPHIC data types in databases
Там говорится о том, что VARCHAR это всё равно фиксированный CHAR плюс опциональный сегмент, за который вы заплатите дополнительным i/o
А вот отсюда можно ли по-подробнее.
Так как и фиксированный сегмент может быть 0 размера. И это указано в доке.
Да и вообще бы хотелось аргументированную критику подхода.
По мне, так представленный подход довольно неплохо справляется с задачами, и дока показывает как его использовать наилучшим образом.
Короче - и что не понравилось?
Ну и поскольку вы разработчик, то сразу с анализом в каких случаях это увеличивает I/O и почему нельзя было его улучшить (руководствуясь докой), раз вы уже с этим сталкивались.
Или опять это ваше теоритезирование? Как и с вопросом по долям распределения баз, на который вы так и не ответили?
...
Рейтинг: 0 / 0
22.05.2006, 11:57
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33746822
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anton Demidov
Участник
ggv Anton DemidovИтак, номер один - лёгкость использования - читаем Опускаю легкость использования как сильно субъективную вещь. это не субъективная вещь, это измеряется в человеко-часах и количестве багов в доморощенных методах работы со строками переменной длины. И всё из-за отсутствия родной поддержки в языке программирования. В Оракле я могу сравнить две строки как a < b, а в Коболе придётся структуры стравнивать. Конкатинация строк: a = b || \' blabla.\', в Коболе всё ручками (найти конец использованного буфера строки b; скопировать в продолжение вторую строку; вычислить новую длину строки и сохранить её; везде проверка переполнения)
ggv
Anton Demidov
Номер два: качество имплементации в БД (ладно, ладно, ожидая шквал возмущений от ggv и ко. перефразирую это в "особенности реализации")
Tips for using VARCHAR and VARGRAPHIC data types in databases
Там говорится о том, что VARCHAR это всё равно фиксированный CHAR плюс опциональный сегмент, за который вы заплатите дополнительным i/o
А вот отсюда можно ли по-подробнее.
Так как и фиксированный сегмент может быть 0 размера. И это указано в доке.
Да и вообще бы хотелось аргументированную критику подхода.
По мне, так представленный подход довольно неплохо справляется с задачами, и дока показывает как его использовать наилучшим образом.
Короче - и что не понравилось?
Ну и поскольку вы разработчик, то сразу с анализом в каких случаях это увеличивает I/O и почему нельзя было его улучшить (руководствуясь докой), раз вы уже с этим сталкивались.
Или опять это ваше теоритезирование?
Что мне не понравилось? То что в Оракле у меня всегда один io. В Дб2 это либо 1 io, но перерасход дискового пространства (ALLOCATE > 0, FIXED CHAR de facto), либо 2 io (ALLOCATE = 0 либо ALLOCATE > 0 и строка длиннее этого порога)
ggvКак и с вопросом по долям распределения баз, на который вы так и не ответили? Топик даже открыл по этому поводу, вы просто не заметили. Вот конктретная ссылка на отчет Gartner по 2005 году.
...
Рейтинг: 0 / 0
23.05.2006, 20:56
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33748211
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
1) опять же - по удобству это сильно субъективно. Фану COBOL кажется одно, а у вас другие глюки. Нужны какие-либу аргументы.
2) А вы сами то отчет читали? Мне кажется, что нет.
Потому как даже не поняли, что отчет по вашей ссылке за 2004 год.
Да и указаных вами цифирь в нем нет.
Если, конечно, мы оба сотрели один вариант отчета.

А про I/O - дык это , как я понял, опять теоретизирования...
...
Рейтинг: 0 / 0
24.05.2006, 13:05
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33749807
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anton Demidov
Участник
ggv1) опять же - по удобству это сильно субъективно. Фану COBOL кажется одно, а у вас другие глюки.Вы, похоже, себя причисляете к клану людей, которые и финансовые приложения на ассемблере писать будут

ggv2) А вы сами то отчет читали? Мне кажется, что нет.
Потому как даже не поняли, что отчет по вашей ссылке за 2004 год.
Да и указаных вами цифирь в нем нет.
Если, конечно, мы оба сотрели один вариант отчета.
Отчёт 2005 года по результатам 2004 - что тут непонятного? Или просто придратся захотелось? Зачем?
ggv
А про I/O - дык это , как я понял, опять теоретизирования... Любое чтение оригинальной документации - "теоретизирование", или вы предпочитаете сначала стукнутся лбом о проблему, а потом доку читать (теоретизировать в ваших терминах)? Не похоже на вас (судя по вашим постам и кол-ву ссылок на документацию IBM). Но что это тогда - корпоративная солидарность? Опять же - зачем? Показать, что продукт ХХХ - идеален? Такого не бывает, всегда есть какие-либо недочёты, на один из которых я и указал. Причём это проблема принципиального характера и растёт она из ориентации всей системы на обработку строк фиксированной длины.
...
Рейтинг: 0 / 0
24.05.2006, 20:24
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33750309
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Погодите - давайте по порядку.
Про цифры из отчета.
Давайте найдем указанные вами 85%
Если это ложь - то разговор закончен.
Если нет - то тогда можно и про I/O, и про удобство, про то, что финансовые приложения как раз на COBOL и писались.
...
Рейтинг: 0 / 0
25.05.2006, 09:40
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33751979
lyuda_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lyuda_
Гость
Ребята, привет!
Нужна очень ваша помощь. Вот пришла на форум ). Я работаю HR менеджером в ИТ компании. В настоящее время нашей Компании требуется Администратор Oracle. Не подскажете, кто может из вас хотел бы работать или из ваших друзей. Заработная плата до 2500 у.е.
Работа с передовыми технологиями.
Я оставляла заявку в разделе работа.

Помогите плз.
Заранее благодарю за ответ.
Мой email 095opa@mail.ru.
Спасибо!
...
Рейтинг: 0 / 0
25.05.2006, 16:15
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33752799
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anton Demidov
Участник
ggvПогодите - давайте по порядку.
Про цифры из отчета.
Давайте найдем указанные вами 85%
Если это ложь - то разговор закончен.
Если нет - то тогда можно и про I/O, и про удобство, про то, что финансовые приложения как раз на COBOL и писались.
Ну вы право ....
...
Рейтинг: 0 / 0
25.05.2006, 21:45
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33815748
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DocAl
Участник
А есть ли в SQL 2005, Oracle 10G или Cache 5 реализация юникодного аналога metaphone или soundex? Возможно, это было бы полезно для предполагаемого применения сервера.... (Да, я понимаю, что UDF в том или ином виде есть давно и везде, но это же ещё написать надо, а такой предопределённой функции было бы признаком ориентированности сервера и для подобных приложений)
...
Рейтинг: 0 / 0
27.06.2006, 07:17
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33816089
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
DocAlА есть ли в SQL 2005, Oracle 10G или Cache 5 реализация юникодного аналога metaphone или soundex? Возможно, это было бы полезно для предполагаемого применения сервера.... (Да, я понимаю, что UDF в том или ином виде есть давно и везде, но это же ещё написать надо, а такой предопределённой функции было бы признаком ориентированности сервера и для подобных приложений)В MS SQL Server давно есть.
...
Рейтинг: 0 / 0
27.06.2006, 10:58
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33816293
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DocAl
Участник
Можно ссылку на описание?
...
Рейтинг: 0 / 0
27.06.2006, 11:52
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33816395
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
DocAlМожно ссылку на описание?Да что, мне не верите? Вот цитата из BOL:

BOL
Comparing SOUNDEX and DIFFERENCE
The SOUNDEX function converts a character string to a four-digit code for use in a comparison. Vowels are ignored in the comparison. Nonalphabetic characters are used to terminate the comparison. This function always returns some value.

This example displays the results of the SOUNDEX function for the similar character strings of "Smith" and "Smythe". When character strings are similar, both strings have the same SOUNDEX codes.

SELECT SOUNDEX ('smith'), SOUNDEX ('smythe')

Here is the result set:

----- -----

S530 S530

(1 row(s) affected)

The DIFFERENCE function compares the SOUNDEX values of two strings and evaluates the similarity between them, returning a value from 0 through 4, where 4 is the best match. This example returns a DIFFERENCE of 4 for the first SELECT because "Smithers" and "Smothers" differ by only one character.

SELECT DIFFERENCE('smithers', 'smothers')

Here is the result set:

------------
4
(1 row(s) affected)

The following example returns a DIFFERENCE of 3, indicating that the two character strings have a similar sound even though they differ in several characters.

SELECT DIFFERENCE('Jeff', 'Geoffe')
...
Рейтинг: 0 / 0
27.06.2006, 12:19
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33816568
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DocAl
Участник
Да нет, почему, верю, просто хотел почитать про конкретную реализацию... Спасибо за ссылку. Вот только, есть подозрения, что нифига они не юникод, а всё для той же одной латиницы, что и у MySQL.(
Если не затруднит, проверьте это предположение? Посмотрите, что выдаёт саундекс для русских слов?
...
Рейтинг: 0 / 0
27.06.2006, 13:05
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33816573
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DocAl
Участник
Кстати, а BOL действительно онлайн где-нибудь доступна?) На МСДН, не к обеду будь помянутом?
...
Рейтинг: 0 / 0
27.06.2006, 13:07
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33816627
andy st
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andy st
Гость
DocAlДа нет, почему, верю, просто хотел почитать про конкретную реализацию... Спасибо за ссылку. Вот только, есть подозрения, что нифига они не юникод, а всё для той же одной латиницы, что и у MySQL.(
Если не затруднит, проверьте это предположение? Посмотрите, что выдаёт саундекс для русских слов?
ничего не выдает
SQL Server 2005 Books Online
Because the SOUNDEX() function is defined based on English phonetic rules , it is not meaningful on Unicode strings unless the string contains only the Latin characters A through Z and a through z.

и
SQL Server 2005 Books Online
Syntax
DIFFERENCE ( character_expression , character_expression )

Returns an integer value that indicates the difference between the SOUNDEX values of two character expressions.

так что стоит занятся поиском локализованных вариантов
...
Рейтинг: 0 / 0
27.06.2006, 13:20
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33816709
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DocAl
Участник
Вот именно поэтому я и уточнял про юникодный аналог этих функций... Что оригинальный саундекс задан только для латиницы я в курсе...(
...
Рейтинг: 0 / 0
27.06.2006, 13:40
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33945066
bug_scorobey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bug_scorobey
Гость
Господа а какие задачи вы собрались решить?
зачем soundex или метафон?
а насчет сравнения 2005 и 10G могу сказать одно к сожалению M$ катит все в одну сторону (дайте ресурсов и все будет хокей)
к примеру у меня есть приложения -экспертная система и одна из задач это к примеру сравнение строк на вход 10000 каждую строку сравниваем на совпадение %% с 10^7 вариантов )
2003 win на оракле 9i - ~25-30 мин
2003 win 2000 ~45-50 мин
2003 win 10G~ 25 мин
2003 win 2005~3 часа

Red Hat 10G~ 25 мин ~12 мин

все сандартно данные одни и те же
на одной машине P4 1ГБ SATA1-160Gb
select .... fn _jjj from ....
update ....
структура одна и таже (~ разбег сильно зависит от типа сортировки в столбце )


а вообще то интересно кто чего еще надыбал и на сравнивал
...
Рейтинг: 0 / 0
27.08.2006, 05:34
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33945072
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DocAl
Участник
А вооот как раз для подобных задач и бывает полезен саундекс или метафон.
Например, имеется база музыкальных исполнителей, дисков, треков и т.п. лабуды. Специфика подобных баз, как правило, полулюбительских, в лучшем случае, стянутых с freedb, в том, что качество информации довольно невысокое: задубления названий, отличающиеся пропущеным артиклем, банальные опечатки, всё то, что тяжело отловить в большой базе, но оставляет негативное впечатление от посещения сайта: кому же понравится, если название любимого исполнителя переврали, да и найти нужное становится тяжелее. Саундекс может помочь быстро найти проблемные места.
Или, скажем, периодическое пополнение номенклатуры товаров, плохо разбирающийся в специфике товаров оператор легко может внести дубль в базу, не чёткий, который отловит ограничение уникальности, а отличающийся на один символ. И тут саундекс может пригодиться, он, конечно, не панацея, но функция полезная.
...
Рейтинг: 0 / 0
27.08.2006, 06:44
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33945348
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
bug_scorobeyмогу сказать одно к сожалению M$ катит все в одну сторону (дайте ресурсов и все будет хокей)Остальные, надо полагать, катят в другую сторону ?
...
Рейтинг: 0 / 0
27.08.2006, 14:57
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33945479
bug_scorobey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bug_scorobey
Гость
DocAlА вооот как раз для подобных задач и бывает полезен саундекс или метафон.
Например, имеется база музыкальных исполнителей, дисков, треков и т.п. лабуды. Специфика подобных баз, как правило, полулюбительских, в лучшем случае, стянутых с freedb, в том, что качество информации довольно невысокое: задубления названий, отличающиеся пропущеным артиклем, банальные опечатки, всё то, что тяжело отловить в большой базе, но оставляет негативное впечатление от посещения сайта: кому же понравится, если название любимого исполнителя переврали, да и найти нужное становится тяжелее. Саундекс может помочь быстро найти проблемные места.
Или, скажем, периодическое пополнение номенклатуры товаров, плохо разбирающийся в специфике товаров оператор легко может внести дубль в базу, не чёткий, который отловит ограничение уникальности, а отличающийся на один символ.
--------------------------
для этого нужна толко одна функция в три строчки
это первое, а второе могу сказать только одно что при указанных мною объемах ВАШЕ решение --это уже не решение в реальное время

--------------------------

И тут саундекс может пригодиться, он, конечно, не панацея, но функция полезная.
...
Рейтинг: 0 / 0
27.08.2006, 18:01
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33945482
bug_scorobey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bug_scorobey
Гость
ChA bug_scorobeyмогу сказать одно к сожалению M$ катит все в одну сторону (дайте ресурсов и все будет хокей)Остальные, надо полагать, катят в другую сторону ?

да согласен но одни забирают ресурсы под себя а другие все таки думают о наших с Вами задачах (согласитесь разный подход)
...
Рейтинг: 0 / 0
27.08.2006, 18:04
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33945749
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DocAl
Участник
bug_scorobey
для этого нужна толко одна функция в три строчки
это первое, а второе могу сказать только одно что при указанных мною объемах ВАШЕ решение --это уже не решение в реальное время

Ну, во-первых, значение саундекса можно хранить в базе, либо иметь функциональный индекс, если СУБД позволяет, а для новых записей его посчитать недолго. А сколькистрочная реализация для меня не суть важно, хотя было бы интересно посмотреть на ваше решение.
...
Рейтинг: 0 / 0
28.08.2006, 03:14
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33946202
bug_scorobey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bug_scorobey
Гость
DocAl bug_scorobey
для этого нужна толко одна функция в три строчки
это первое, а второе могу сказать только одно что при указанных мною объемах ВАШЕ решение --это уже не решение в реальное время

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

С огромным удовольствием продемонстрирую (готов дать терминальный доступ /200-652-783 или на мыло )
...
Рейтинг: 0 / 0
28.08.2006, 11:14
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33946211
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DocAl
Участник
Да мне кажется, вполне достаточно было бы привести код той самой функции из трёх строк? Или по каким-то причинам вы этого делать не хотите?
...
Рейтинг: 0 / 0
28.08.2006, 11:16
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33946266
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
bug_scorobeyда согласен но одни забирают ресурсы под себя а другие все таки думают о наших с Вами задачах (согласитесь разный подход)Ну так пользуйте продукты только тех фирм, которые эээ... думают о Ваших задачах и забудьте MS, как страшный сон.
Мне вот, к сожалению, таких не встречалось. Всяк гад хочет денежку заработать, да ресурсов поболе отхватить.

P.S. Почему-то кажется, что Вам не больше 25 лет.
...
Рейтинг: 0 / 0
28.08.2006, 11:37
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33948074
bug_scorobey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bug_scorobey
Гость
DocAlДа мне кажется, вполне достаточно было бы привести код той самой функции из трёх строк? Или по каким-то причинам вы этого делать не хотите?
увы не хочу
...
Рейтинг: 0 / 0
28.08.2006, 20:35
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33948081
bug_scorobey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bug_scorobey
Гость
ChA bug_scorobeyда согласен но одни забирают ресурсы под себя а другие все таки думают о наших с Вами задачах (согласитесь разный подход)Ну так пользуйте продукты только тех фирм, которые эээ... думают о Ваших задачах и забудьте MS, как страшный сон.
Мне вот, к сожалению, таких не встречалось. Всяк гад хочет денежку заработать, да ресурсов поболе отхватить.

P.S. Почему-то кажется, что Вам не больше 25 лет.

увы стараюсь совсем уйти от M$ (кстати не заметили что и 1с переходит почему то на postgres и свои библиотеки написал для работы в *nix системах странно все это очень. А вам так не кажется

P.S.годков мне немного поболее
и ради любопытства вы честно все что у Вас стоит мелкософтовское купили не на рынке? Может еще их суппортом пользовались когда нибудь?
...
Рейтинг: 0 / 0
28.08.2006, 20:43
| Ответить | Цитировать | Написать  
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
    #33948089
bug_scorobey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bug_scorobey
Гость
DocAlДа мне кажется, вполне достаточно было бы привести код той самой функции из трёх строк? Или по каким-то причинам вы этого делать не хотите?

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

и еще вопрос вы не замечали такой штуки что меняется если использовать COLLATE Cyrillic_General_BIN или/и varbinary
...
Рейтинг: 0 / 0
28.08.2006, 20:53
| Ответить | Цитировать | Написать  
457 сообщений из 457, показаны все 19 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]