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


Просмотр
0 / 0
Close
Debug Console [Select Text]