Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 29   вперед  Ctrl
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
А еще представьте, что есть в наличии идеальные средства коммуникации.
Тогда установив мэппинг на уровне администраторов программист совершенно не меняя строки представленного кода будет получать данные, которые реально хранятся в разных городах, скажем Украины.

Это все заложено в М-технологию и реализовано во многих М-системах.
21 фев 06, 11:08    [2377041]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
MX -- ALEX
iliker
Не тот пример но все равно спасибо.
Sql мне нравится больше.
не полезу в норамилизацию, в sql это примерно так

create table t1(parent c(20),child c(20),age n(10)

select child from t1 where parent="Иванов " and age=16

Хоть и длиннее, но в вашем коде усматривается 2 момента чреватые ошибками
это
1 set d=20060202-.1 --- установим индекс на начало просмотра
и
quit:'d --- закончить просмотр : если больше нет детей
quit:d>20060227.9 --- закончить просмотр: если этот и все за ним слишком юные

IMHO.

согласен - отладка у нас требует внимания
но автопилот SQL тоже может не на тот радиомаяк пойти если курс
задать неправильно :)

еще момент -
у нас ВСЕ запросы ( коды mumps типа вышеприведенного )
сидят в ячейках EXCEL-листов
и поэтому желательно чтоб короткий код
пока по краткости альтернативы MUMPSу не вижу..

кстати что будет если повторить запрос (age=16) через год .. дети растут..
Чё-то я не пойму, как строка
s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d
длиной 65 знаков вдруг считается короче строки
select child from t1 where parent="Иванов " and age=16
длиной 54 знака?

И про "автопилот SQL" тоже не понял, нельзя ли поподробнее?

P.S. У нас тоже SQL-запросы сидят в ячейках Excel и что теперь? Мы же себя пяткой в грудь не бьем И БОЛЬШИМИ БУКВАМИ ПРО ЭТО НЕ ПИШЕМ.
21 фев 06, 12:00    [2377326]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
dvm
Guest
Sergo Gromov
Я дополню, если позволите ....

Последний пример НЕ_ЕСТЬ_ЗАПРОС в понимании SQL потому как происходит ПОЛУЧЕНИЕ или НЕ ПОЛУЧЕНИЕ данных по требуемым параметрам БЕЗ_КАКОГО_БЫ_ТО_НИ_БЫЛО поиска(?????) в базе, поэтому результат предложенного примера по скорости НЕ_ЗАВИСИТ от размеров базы, из которой берутся данные. Как впрочем и в примере с близнецами ...

Это как? Без поиска?
21 фев 06, 12:09    [2377396]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Sergo Gromov
Я дополню, если позволите ....
Последний пример НЕ_ЕСТЬ_ЗАПРОС в понимании SQL потому как происходит ПОЛУЧЕНИЕ или НЕ ПОЛУЧЕНИЕ данных по требуемым параметрам БЕЗ_КАКОГО_БЫ_ТО_НИ_БЫЛО поиска в базе, поэтому результат предложенного примера по скорости НЕ_ЗАВИСИТ от размеров базы, из которой берутся данные. Как впрочем и в примере с близнецами ...
Интересно. Не могли бы вы пояснить детальнее, как данные извлекаются "БЕЗ_КАКОГО_БЫ_ТО_НИ_БЫЛО поиска в базе", и что тогда вы понимаете под поиском в базе? Кстати, что вы понимаете под "запросом в понимании SQL" и чем он отличается от запросов в другом (в каком?) понимании?

AlexKB
А еще представьте, что есть в наличии идеальные средства коммуникации.Тогда установив мэппинг на уровне администраторов программист совершенно не меняя строки представленного кода будет получать данные, которые реально хранятся в разных городах, скажем Украины.
Это все заложено в М-технологию и реализовано во многих М-системах.
Вспомнилось "а если бы у бабушки был @#%, это была бы уже не бабушка, а дедушка." Это про всякие "если..."
21 фев 06, 12:09    [2377399]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
dvm
Guest
mir

Чё-то я не пойму, как строка
s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d
длиной 65 знаков вдруг считается короче строки
select child from t1 where parent="Иванов " and age=16
длиной 54 знака?


Дык пример без нормализации, а делать по букварю так и длиннее получится(хотя можно через view)
21 фев 06, 12:17    [2377469]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
dvm
Guest
AlexKB
А еще представьте, что есть в наличии идеальные средства коммуникации.
Тогда установив мэппинг на уровне администраторов программист совершенно не меняя строки представленного кода будет получать данные, которые реально хранятся в разных городах, скажем Украины.

Это все заложено в М-технологию и реализовано во многих М-системах.

Идеальные средства коммуникации - это утопия с учетом природных катаклизмов и человеческих ошибок. А DB2 и ASA без идеальных средств коммуникации позволяют реплицировать данные, хоть дискетой.Без единой строчки кода.Только указать куда, что и как.
21 фев 06, 12:24    [2377521]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
mir
Sergo Gromov
Я дополню, если позволите ....
Последний пример НЕ_ЕСТЬ_ЗАПРОС в понимании SQL потому как происходит ПОЛУЧЕНИЕ или НЕ ПОЛУЧЕНИЕ данных по требуемым параметрам БЕЗ_КАКОГО_БЫ_ТО_НИ_БЫЛО поиска в базе, поэтому результат предложенного примера по скорости НЕ_ЗАВИСИТ от размеров базы, из которой берутся данные. Как впрочем и в примере с близнецами ...
Интересно. Не могли бы вы пояснить детальнее, как данные извлекаются "БЕЗ_КАКОГО_БЫ_ТО_НИ_БЫЛО поиска в базе", и что тогда вы понимаете под поиском в базе? Кстати, что вы понимаете под "запросом в понимании SQL" и чем он отличается от запросов в другом (в каком?) понимании?

AlexKB
А еще представьте, что есть в наличии идеальные средства коммуникации.Тогда установив мэппинг на уровне администраторов программист совершенно не меняя строки представленного кода будет получать данные, которые реально хранятся в разных городах, скажем Украины.
Это все заложено в М-технологию и реализовано во многих М-системах.
Вспомнилось "а если бы у бабушки был @#%, это была бы уже не бабушка, а дедушка." Это про всякие "если..."


В предложенном примере данные максимально размещены в индексах, посему не происходит переборки данных. Создание нового индекса(ов) в М построено довольно мудро, что не требует перестроения всего индексного масива.

Из этих двух фраз получаем: поиска как такового нет, есть проверка наличия или отсутствие данных по указанному условию, а создание новых записей требует минимум времени, меньше чем при полной пересортировке
21 фев 06, 12:40    [2377628]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Sergo Gromov

В предложенном примере данные максимально размещены в индексах, посему не происходит переборки данных. Создание нового индекса(ов) в М построено довольно мудро, что не требует перестроения всего индексного масива.

А мужики то (в MS , Oracle, IBM) и не знают...
21 фев 06, 12:55    [2377725]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Sergo Gromov

В предложенном примере данные максимально размещены в индексах, посему не происходит переборки данных.

Если данные размещены в индексах, то это КАКОЙ_НИ_НАЕСЬ поиск в базе, потому что "переборка" данных ни единственное что предполагает поиск в базе. В индексах тоже нуно поискать ишо.
21 фев 06, 13:26    [2377921]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
vadiminfo
Sergo Gromov

В предложенном примере данные максимально размещены в индексах, посему не происходит переборки данных.

Если данные размещены в индексах, то это КАКОЙ_НИ_НАЕСЬ поиск в базе, потому что "переборка" данных ни единственное что предполагает поиск в базе. В индексах тоже нуно поискать ишо.


В иднексах опять же не ищется потому как структура индексов - дерево указателей, просто выборка обращается к данным через 1-5 блоков 500-байтных, количество перебираемых блоков зависит от размера глобала(базы), 5 блоков - это база больше 1,6Г ... или около
21 фев 06, 13:30    [2377946]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Дельфийская убогость
Guest
автор
В иднексах опять же не ищется потому как структура индексов - дерево указателей, просто выборка обращается к данным через 1-5 блоков 500-байтных, количество перебираемых блоков зависит от размера глобала(базы), 5 блоков - это база больше 1,6Г ... или около

А это что - не поиск? Еще скажите, что Волга впадает в Каспийскре море.
21 фев 06, 13:37    [2377988]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
dvm
Это как? Без поиска?


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

Реплика на дискету - да пожалуйста. Опять же, программист об этом может и не подозревать. А может указывать явно, в одном запросе, что откуда брать и куда потом складывать.
21 фев 06, 13:37    [2377991]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
Я пожалуй уйду из ЭТОГО обсуждения, потому что я НЕ_ПОЛЬЗУЮ Кашу, а программирую в MSM - тот что съеден лет 7 назад в пользу Каши, и моё мнение - незаслуженно.

Меня только удивляют нападки типа: - "А наше лучше вашего !!!"

Могу сравнить у себя. Стоит MSM с общим числом баз на 17Г, данные от 1994-го года и по текущий день, в прямом доступе постоянно. На той же тачке стоит MySQL с базой 4М - только один из массивов MSM-овской базы. MySQL не конкурент - отстой. Ещё раз повторюсь - это моё мнение.

Кого реально заинтересует - открываем виртуальные курсы или ещё какую школу .....
21 фев 06, 13:39    [2377998]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Дельфийская убогость
Guest
Меня только удивляют нападки типа: - "А наше лучше вашего !!!"
А я отвечу Я завела этот топик в период паралельного существования двух обсуждений типа "Fox vs. ALL" и "Cashe vs. ALL". Причем оба этих топика были инициированы сторонниками соотвесвенно Fox и Cashe по агрессивному сценарию "вы все г...., а мы белые и пушистые". Это топик был всего лишь провокационной попыткой свести две группы "белых и пушистых", что бы между собой рубились. Но удивительно! находятся люди, которые начинают здесь на полном серьезе пытаться загасить соперника, хотя ИМХО далековаты они друг от друга, что бы быть соперниками.
21 фев 06, 13:48    [2378058]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
И действительно.
"Если я этого не умею - значит этого не может быть".

А вот еще.

Эй, мужик, ты что рыбу ловишь?
Нет, я рыбу ловлю.
А я думал, ты рыбу оловишь.
Да нет, я рыбу ловлю.

Но почему так?
21 фев 06, 13:49    [2378061]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Sergo Gromov
поэтому результат предложенного примера по скорости НЕ_ЗАВИСИТ от размеров базы, из которой берутся данные.

Кстати при индексном поиске время доступа пропорционально логарифму размера. Т.е. время конечно растёт не сильно, но писать что не зависит и большими буквами - лукавство
21 фев 06, 13:53    [2378091]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Sergo Gromov

а программирую в MSM - тот что съеден лет 7 назад в пользу Каши



Sergo Gromov

Кого реально заинтересует - открываем виртуальные курсы или ещё какую школу .....

Т.е. продукт съеден 7 лет назад, а Вы собираетесь ему учить? Как Вы тада относитесь к будущему этих парней?
21 фев 06, 14:00    [2378149]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
mir
MX -- ALEX
iliker
Не тот пример но все равно спасибо.
Sql мне нравится больше.
не полезу в норамилизацию, в sql это примерно так

create table t1(parent c(20),child c(20),age n(10)

select child from t1 where parent="Иванов " and age=16

Хоть и длиннее, но в вашем коде усматривается 2 момента чреватые ошибками
это
1 set d=20060202-.1 --- установим индекс на начало просмотра
и
quit:'d --- закончить просмотр : если больше нет детей
quit:d>20060227.9 --- закончить просмотр: если этот и все за ним слишком юные

IMHO.

согласен - отладка у нас требует внимания
но автопилот SQL тоже может не на тот радиомаяк пойти если курс
задать неправильно :)

еще момент -
у нас ВСЕ запросы ( коды mumps типа вышеприведенного )
сидят в ячейках EXCEL-листов
и поэтому желательно чтоб короткий код
пока по краткости альтернативы MUMPSу не вижу..

кстати что будет если повторить запрос (age=16) через год .. дети растут..
Чё-то я не пойму, как строка
s d=20060202-.1 f s d=$o(A(d)) q:'d q:d>20060227.9 w !,A(d),?20,d
длиной 65 знаков вдруг считается короче строки
select child from t1 where parent="Иванов " and age=16
длиной 54 знака?

И про "автопилот SQL" тоже не понял, нельзя ли поподробнее?

P.S. У нас тоже SQL-запросы сидят в ячейках Excel и что теперь? Мы же себя пяткой в грудь не бьем И БОЛЬШИМИ БУКВАМИ ПРО ЭТО НЕ ПИШЕМ.


Очень заинтересовала Ваша система
"У нас тоже SQL-запросы сидят в ячейках Excel .."
хотел бы более подробно с Вами поговорить
Если не затруднит пришлите письмецо
kosinec@metalurgs.LV
Возможно будет взаимная польза
==========
Алексей
21 фев 06, 17:00    [2379209]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
vadiminfo
Sergo Gromov

а программирую в MSM - тот что съеден лет 7 назад в пользу Каши



Sergo Gromov

Кого реально заинтересует - открываем виртуальные курсы или ещё какую школу .....

Т.е. продукт съеден 7 лет назад, а Вы собираетесь ему учить? Как Вы тада относитесь к будущему этих парней?

Фирма IS сьела фирму M ( M-которая сделала MSM)
права на MSM перешли к IS
выпущен CACHE - продолжение MSM
то есть изобретение - колесо -
никто не отменял и никогда не отменит

но сейчас CACHE: лицензии на 30 % дешевле
и скорость повыше чем MSM
а система команд в принципе одна и та же
=======================
21 фев 06, 17:12    [2379266]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
MX -- ALEX

Фирма IS сьела фирму M ( M-которая сделала MSM)
права на MSM перешли к IS
выпущен CACHE - продолжение MSM
то есть изобретение - колесо -
никто не отменял и никогда не отменит

но сейчас CACHE: лицензии на 30 % дешевле
и скорость повыше чем MSM
а система команд в принципе одна и та же
=======================

Теперь совсем непонятно. М - язык программирования. Каша - СУБД. У нее COS.
Хде теперь М? Тока в Каше? И чему Sergo Gromov собирается учить? Развивает ли кто либо М? Тем более, что Каша как СУБД менее известна чем М. Последний среди упоминания языков программирования нет нет да проскочит в литре по БД. А Каша в общей литре пока не встречалась. Не ясно даже к каим СУБД ее относят. То она ООСУБД, то нет.
21 фев 06, 19:03    [2379758]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Sergo Gromov

Могу сравнить у себя. Стоит MSM с общим числом баз на 17Г, данные от 1994-го года и по текущий день, в прямом доступе постоянно. На той же тачке стоит MySQL с базой 4М - только один из массивов MSM-овской базы. MySQL не конкурент - отстой. Ещё раз повторюсь - это моё мнение.

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

Sergo Gromov

В иднексах опять же не ищется потому как структура индексов - дерево указателей, просто выборка обращается к данным через 1-5 блоков 500-байтных, количество перебираемых блоков зависит от размера глобала(базы), 5 блоков - это база больше 1,6Г ... или около

Это и есть поиск.

SergSuper

Кстати при индексном поиске время доступа пропорционально логарифму размера. Т.е. время конечно растёт не сильно, но писать что не зависит и большими буквами - лукавство

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

Но это не важно, важно другое. В кеше, пике и прочих передовых системах в принципе все делается так же как в РСУБД. Тот же диск, такие же массивы данных, только в РСУБД они имеют более простую структуру, а у других они для хранения на диске все равно разбиваются на элементы простой структуры. Поэтому не может там быть никаких чудес, типа "вообще без поиска", поиск есть, может по индексу, но это все равно поиск. Более того, индексы там такие же, как в РСУБД, ничего нового человечество пока не придумало, а если вдруг придумало то можно не сомневаться что оно уже перекочевало в РСУБД. Либо же абсолютно вся информация об объекте-субъекте или что там у них лежит в одном блоке (условно). Но это работает в очень частном теоретическом случае, а на практике превращается в большой недостаток и проблему, думаю что производители так вряд ли поступают.
21 фев 06, 23:01    [2380188]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
c127

SergSuper

Кстати при индексном поиске время доступа пропорционально логарифму размера. Т.е. время конечно растёт не сильно, но писать что не зависит и большими буквами - лукавство

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

А что такое тогда хеш индекс? Я считал что это когда ключом для индекса выступает не само значение аттрибута, а его хэш функция. Тогда остаются те же уровни в Б-дереве, количество которых и определяет время поиска.
А на самом деле что это тогда?
22 фев 06, 01:02    [2380366]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
vadiminfo
MX -- ALEX

Фирма IS сьела фирму M ( M-которая сделала MSM)
права на MSM перешли к IS
выпущен CACHE - продолжение MSM
то есть изобретение - колесо -
никто не отменял и никогда не отменит

но сейчас CACHE: лицензии на 30 % дешевле
и скорость повыше чем MSM
а система команд в принципе одна и та же
=======================

Теперь совсем непонятно. М - язык программирования. Каша - СУБД. У нее COS.
Хде теперь М? Тока в Каше? И чему Sergo Gromov собирается учить? Развивает ли кто либо М? Тем более, что Каша как СУБД менее известна чем М. Последний среди упоминания языков программирования нет нет да проскочит в литре по БД. А Каша в общей литре пока не встречалась. Не ясно даже к каим СУБД ее относят. То она ООСУБД, то нет.

---------------
Фирмы-разработчики:
IS=InterSystems
M=Micronetics (до 1997. затем была проглочена фирмой IS)
..и другие помельче
---------------
Язык:
MUMPS
---------------
системы: (язык+диалект+базаданных)
DSM=ISM=DIAMS(CCCP)=M3-LITE=GTM=MSM=CACHE
системы совместимы и все на одном языке - mumps
---------------
с какого то момента (1995 примерно) пользователи и разработчики
договорились все это называть попроще:
"M-технология"
или просто "M"
============================
сейчас все это забывается и уже не понятно кто кого победил
в последней мировой войне
кашисты (CACHE) убеждены что до них ничего не было
22 фев 06, 09:38    [2380732]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Хе-хе..
Guest
Более того, индексы там такие же, как в РСУБД, ничего нового человечество пока не придумало

Вот так и рождаются мифы. Осталось добавить для полноты гармонии, что MUMPS написан на SQL. И что до SQL ничего не было, и писали программисты чепуху, и было сотворение мира, и SQL велик, акбар, аминь и все такое. В хумор.
22 фев 06, 14:18    [2382262]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Хе-хе..
Более того, индексы там такие же, как в РСУБД, ничего нового человечество пока не придумало

Вот так и рождаются мифы. Осталось добавить для полноты гармонии, что MUMPS написан на SQL. И что до SQL ничего не было, и писали программисты чепуху, и было сотворение мира, и SQL велик, акбар, аминь и все такое. В хумор.
Тогда, видимо, очень просто назвать виды индексов, которые есть в M и которых нет в существующих РСУБД. Развенчайте миф.
22 фев 06, 15:05    [2382578]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить