Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24 .. 29   вперед  Ctrl
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Уважаемые неМАМПСисты, ведь этот спор читают и третьи люди, которые не знают досконально ни одну, ни другую сторону. Вы постоянно обвиняете МАМПСистов в том что они плохо знают предметную область SQL, но в своих возражениях Вы опираетесь только на академические взгляды о древовидных технологиях. Вы приводите такие доводы, которые вызывают просто смех у тех кто работает на М-языках и только лишний раз подтверждает Ваше невежество в этих вопросах. Вы хотя бы пишите "я так думаю", или "я так считаю", или "меня так учили".
Да будет Вам известно, что практически все программы построены на многократных перекрестных ссылках между различными индексами различной глубины. Представьте себе, выборки пяти-десяти кратной вложенности на каждые 10 строк кода - это обычное явление, в нем невозможно запутаться, все это прозрачно, легко сопровождаемое, работает с очень высокой скоростью. По поводу индексов. Индексами могут быть сами данные, полные ссылки на совсем другое дерево уже со своими индексами, даже строки исполняемого кода, имена программ (как внутренних так и внешних), и многое другое. Если жизнь потребует именно такой индексации - то нет никаких препятствий (сам видел, неоднократно такие механизмы использования индексов и не вижу в этом ничего плохого).
В конечном итоге пользователю важна скорость исполнения запроса, а не легкая жизнь программиста.

Вот пример рабочего кода, он чисто демонстрационный, но похвастайтесь чем нибудь подобным.

Init ;;;
;;Вася;Петя;Пиво;6
;;Коля;Саша;Водка;1
;;Тарас;Коля;Пиво;5
;;Иван;Вася;Вино;2

set %msql="_SYSTEM"

for i=1:1:4
{
set obj=##class(Test.Pili).%New()
set obj.KumName=$piece($text(Init+i),";",3)
set obj.MyName=$piece($text(Init+i),";",4)
set obj.Pili=$piece($text(Init+i),";",5)
do obj.%Save()
set obj=""
}
for i=1:1:4
{set litr=$piece($text(Init+i),";",6)
&sql(UPDATE Test.Pili
SET Litr = :litr where ID=:i)
}

for i=1:1:4
{do ..StringGrid1.SetRowCells(i,$list(^Test.PiliD(i),1,4))}

for i=1:1:4
{
set obj=##class(Test.Pili).%OpenId(i)
do ..StringGrid1.SetCells(4,i,obj.Pili)
set obj=""
}

set i=0
&sql(DECLARE MyCursor CURSOR FOR SELECT KumName, MyName,
Pili, Litr INTO :KumName,:MyName,:Pili,:Litr FROM Test.Pili)
&sql(OPEN MyCursor)
FOR { &sql(FETCH MyCursor)
QUIT:SQLCODE
set i=i+1
do ..StringGrid2.SetRowCells(i,$listbuild("",KumName,Litr,MyName,Pili))
}
&sql(CLOSE MyCursor)

set ..Edit1.Text=SQLCODE
14 мар 06, 09:44    [2444824]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
c127
MX -- ALEX

хотя конечно это дело удобства-неудобства модели,

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

нам повезло что мы этого не знали -
поэтому запросто вдвоем заавтоматизировали на MUMPS
несколько крупных заводов и сотню мелких-средних :)
14 мар 06, 09:52    [2444854]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
aZm
Member

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

хотя конечно это дело удобства-неудобства модели,

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

нам повезло что мы этого не знали -
поэтому запросто вдвоем заавтоматизировали на MUMPS
несколько крупных заводов и сотню мелких-средних :)


такую бы энергию, да в мирных целях :) но если серьезно - молодцы. в очередной раз доказали что даже на плохом струменте можно хорошо сыграть :)
14 мар 06, 10:05    [2444900]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
to alexKB :

извините за вторжение в разговор

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

хотя конечно, простые задачки-программки только в букваре,
а в реальной жизни (производстве) - весьма непростые
в чем Вы совершенно правы.
14 мар 06, 10:11    [2444920]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Да я и так привел очень простой пример - сочетание четырех технологий в одном модуле: ООП-программирование, SQL-программирование, М-программирование, RAID-программирование GUI-интерфейс.
Куда уж проще.

Там еще один товарищ пытался таблицу на сто индексов получить, так вот у меня в одном проекте их было около 400. Вставка данных шла каждые 50 мс (собственно сама встака не более 3-5 мс).
Ах если бы только вставка, там же еще масса вычислений.
Могу себе представить благодарные лица пользователей, если бы подобная вставка со всеми 100 индексами выполнялась на SQL после 100 млн строк таблицы.

И еще, почему же тогда ведущие разработчики систем управления производством (не предприятием) ядром своих систем ставят иерархические сервера реального времени, если в SQL - технологии так все легко, просто, безоблачно? А может это все-таки реальная необходимость, сколько можно обсчитывать только проводки. Ведь и коммунизм был довольно долго единственно правильной идеологией, а вот ведь вернулись опять к капитализму.
14 мар 06, 10:31    [2445011]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
to AlexKB
Уважаемый, признаком хорошего стиля программирования является наличие комментариев. Будьте так добры - откомментируйте Ваш код, чтобы мы могли насладиться и проникнуться. Вам Ваш коллега правильно сказал - тут практически все высококлассные профессионалы и разобраться в чужок коде смогут, только уважайте их время - облегчите им задачу.

Кстати, можно и пример попроще взять. Вот тут коллега ЧАЛ попросил решить задачу. Её решили пятью способами на SQL (дальше по ветке, долго искать). На просьбу привести решение на MUMPS ЧАЛ не откликнулся. Может покажите как оно должно быть?
14 мар 06, 10:34    [2445026]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
2 AlexKB
А что на ваша программа делает-то в итоге? Что должно получиться?
Хотелось бы также узнать, что такое упомянутое вами RAID-программирование и где оно в вашем примере?
14 мар 06, 10:41    [2445051]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Решения тут, тут, здесь и далее везде
14 мар 06, 10:47    [2445075]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

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

//участок где размещаются данные, потом они будут вычитаны
//и занесены в таблицу
Init ;;;
;;Вася;Петя;Пиво;6
;;Коля;Саша;Водка;1
;;Тарас;Коля;Пиво;5
;;Иван;Вася;Вино;2

set %msql="_SYSTEM" // служебная переменная
// участок создания таблицы он из другого модуля тут для информации
/*
&sql(CREATE TABLE Test.Pili (
KumName CHAR(30),
MyName CHAR(30),
Pili CHAR(15),
Litr INT
))
*/
// использование ООП для наполнения данными таблицы
for i=1:1:4
{
set obj=##class(Test.Pili).%New() // создали объект класса таблицы
set obj.KumName=$piece($text(Init+i),";",3) // заполняем поля данными
set obj.MyName=$piece($text(Init+i),";",4) // сами данные вынимаем из текста
set obj.Pili=$piece($text(Init+i),";",5) // программы
do obj.%Save() // сохраняем объект в базе
set obj="" // удаляем объект
}
// использование SQL технологии для дополнения таблицы новыми данными
for i=1:1:4
{set litr=$piece($text(Init+i),";",6) // взяли данные
&sql(UPDATE Test.Pili
SET Litr = :litr where ID=:i)
}
// методом прямого доступа к данным только что заполненной таблицы
// выводим их в компонент таблица
for i=1:1:4
{do ..StringGrid1.SetRowCells(i,$list(^Test.PiliD(i),1,4))}

// методом ООП доступа заполняем еще один столбец в компоненте таблица
for i=1:1:4
{
set obj=##class(Test.Pili).%OpenId(i) // открыли хранимый объект класса таблица
do ..StringGrid1.SetCells(4,i,obj.Pili) // занесли в столбец значение свойства объекта
set obj="" // удалили объект
}
// методом SQL -доступа заполняем второй компонент таблица
set i=0
&sql(DECLARE MyCursor CURSOR FOR SELECT KumName, MyName,
Pili, Litr INTO :KumName,:MyName,:Pili,:Litr FROM Test.Pili)
&sql(OPEN MyCursor)
FOR { &sql(FETCH MyCursor)
QUIT:SQLCODE
set i=i+1 // тут собственно само заполнение
do ..StringGrid2.SetRowCells(i,$listbuild("",KumName,Litr,MyName,Pili))
}
&sql(CLOSE MyCursor)

set ..Edit1.Text=SQLCODE // вывели в компонент значение кода завершения
14 мар 06, 11:10    [2445205]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
AlexKB
Там еще один товарищ пытался таблицу на сто индексов получить, так вот у меня в одном проекте их было около 400.

не надо про проекты и 400 индексов. раскажите лучше как ОДНУ табличку на 100 полей реализовать на М - принцип ессно.
14 мар 06, 11:13    [2445238]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
// вот тут собственно и создается множество индексов, поскольку каждая переменная может принять новое значение на каждой новой итерации

set ^ARHIV(Ndvig,RegimZap,DataZap,TimeZap,vars,TimeTicKontrPC)=res

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

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

Да и нельзя сравнивать Cache и просто SQL - разные категории.
SQL в Cache это только некоторое подмножество, пусть неудобное, пусть неполное, пусть для Вас необычное, но оно МАМПСистам не мешает.

Кстати, а почему Вы не критикуете CacheBasic и VBA 6.0? Там тоже много тем для критики. И тоже есть о чем поспорить. К счастью, не нужно будет комментировать код, думаю что Basic знают почти все.
14 мар 06, 11:38    [2445455]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
AlexKB
Поймите же Вы наконц-то, существуют задачи где необходим именно этот подход, несмотря на то что говорят академики.

Да и нельзя сравнивать Cache и просто SQL - разные категории.
SQL в Cache это только некоторое подмножество, пусть неудобное, пусть неполное, пусть для Вас необычное, но оно МАМПСистам не мешает.

Кстати, а почему Вы не критикуете CacheBasic и VBA 6.0? Там тоже много тем для критики. И тоже есть о чем поспорить. К счастью, не нужно будет комментировать код, думаю что Basic знают почти все.
Вы вообще о чём?

Я лично никого не критикую. Это реляционную теорию отчего-то вдруг мампсисты начинают критиковать. Вот тогда и начинаются споры. А так.. Ну нравится вам каше - ну и пишите на ём.
14 мар 06, 11:57    [2445604]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
"Вы" - это "неМАМПСисты".
За критикантов давайте извинимся мы с Вами за всех .

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

Кстати есть даже такая: пишут код на MUMPS, потом прекомпилятором преобразуют в С-код, потом линкуют со всем остальным и получают ехе-шники. Но ведь для чего-то это сделано. Ведь буржуи ленивые, и просто так они ничего делать не будут.
14 мар 06, 12:18    [2445707]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

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


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

Но проблема в том что кроме производительности есть и др достоинства недостатки. Было время када иерархические СУБД были в производительности не досягаемы для РСУБД. Но уже лет 20 как ситуация изменилась.


AlexKB

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

Вот если Вы говорите, что необходим именно этот подход, то тут без акдэмиков не обойтись. Это ить надо еще доказать. А если говорите что прокатит и такое, то другое дело.
По Вашему коду не понятна до конца задача - что хотели? ООП там не впечатляет. Хде такого нет? Он и в PL/SQL есть. А паттернов не представлено, архитктуры, да и вопрос это к сравнению с к C#, Java и проч. Тока SQL там более или менее смотрится. Но он маленикий. Нужны сложные запросы чтобы почуствовать разницу. GUI-интерфейс тоже нуждается в демонстрации возможностей всех контролов и форм. Но это к C#, Java и проч.
В общем этого пока не достаточно или не все там ясно, чтобы почувствовать особые достоинства Кэша или Мумпса.
14 мар 06, 12:18    [2445713]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
AlexKB
// методом прямого доступа к данным только что заполненной таблицы
// выводим их в компонент таблица
for i=1:1:4
{do ..StringGrid1.SetRowCells(i,$list(^Test.PiliD(i),1,4))}

Стоп - какой StringGrid? это всё выполняется на клиенте?
14 мар 06, 12:27    [2445761]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Опять про табличную организацию данных... Всё, я умываю руки.
14 мар 06, 12:29    [2445764]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
SergSuper
AlexKB
// методом прямого доступа к данным только что заполненной таблицы
// выводим их в компонент таблица
for i=1:1:4
{do ..StringGrid1.SetRowCells(i,$list(^Test.PiliD(i),1,4))}

Стоп - какой StringGrid? это всё выполняется на клиенте?

Судя по идентификаторам и формату вызова речь идет о smwrap.
Работает на сервере. do ..StringGrid1.SetRowCells отправляет команду клиенту. Клиент отрабатывает (в данном случае изменение строки).
Непривычность состоит в том, что в традиционных клиентах к sql клиент запрашивает сервер для получения данных, а в данном случае сервер управляет клиентом, указывая что с каким контролом делать.
14 мар 06, 12:37    [2445816]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

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


Ну есть типы приложений хде табличная в смысле РМД не адекватна. Тока не не известно шо та адеватней ООСУБД или ОРСУБД (табличная с поддержкой ООП). А Мумпс не СУБД, а про Кэш нет однозначного подтверждения что ООСУБДшники считают ООСУБД.
14 мар 06, 12:40    [2445828]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
vadiminfo
Максимального в Кэше? Или среди всех возможных СУБД? Две большие разницы. Существуют тесты производительности призннаные всеми и на которых системы настраивают представители фирм производителей. Там такие утверждения про максиамльность реальны. А здесь как мы можем это проверить?


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

vadiminfo

Но проблема в том что кроме производительности есть и др достоинства недостатки. Было время када иерархические СУБД были в производительности не досягаемы для РСУБД. Но уже лет 20 как ситуация изменилась.


Полностью согласен, поэтому и приходится выбирать иногда не в пользу Cache

vadiminfo

Вот если Вы говорите, что необходим именно этот подход, то тут без акдэмиков не обойтись. Это ить надо еще доказать. А если говорите что прокатит и такое, то другое дело.

Да, некоторые всю жизнь только доказывают, а другие просто реализуют.

vadiminfo

По Вашему коду не понятна до конца задача - что хотели?

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

vadiminfo

В общем этого пока не достаточно или не все там ясно, чтобы почувствовать особые достоинства Кэша или Мумпса.


Сколько можно доказывать что пиво лучше чем вода.
С моих слов Вы все равно не поверите.
Возьмите и попробуйте.
Меня вот тоже SQL совсем не впечатляет, но я же не говорю об этом на каждом углу. Просто я знаю, что есть много задач, которые требуют иного подхода чем SQL.
14 мар 06, 12:40    [2445829]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Павел Воронцов
Опять про табличную организацию данных... Всё, я умываю руки.


Ну ладно, многотабличную организацию данных. Как это не называй - данные то все равно хранятся в таблицах. И доступ к ним двумерный (в пределах таблицы), и данные часто дублируются, и клеточки есть пустые.

Где-то это все напоминает коробки и стеллажи с перфокартами.
14 мар 06, 12:50    [2445870]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
А клеточки то - пустые! Все, Павел, попалси ты....
=)
14 мар 06, 12:58    [2445907]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
AlexKB
Где-то это все напоминает коробки и стеллажи с перфокартами.
Просто у Вас бедная фантазия.
14 мар 06, 12:58    [2445917]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
Вот интересно, он правда ни хрена не понимает ("...данные то все равно хранятся в таблицах...", "...доступ к ним двумерный...", "...клеточки есть пустые..." ) или пишет эту чушь для того что бы позлить этх "злых скульщиков которые весь рынок заняли" ?
14 мар 06, 13:02    [2445935]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Павел Воронцов
AlexKB
Где-то это все напоминает коробки и стеллажи с перфокартами.
Просто у Вас бедная фантазия.


Ну ладно, вот фантазия побогаче.
Все это напоминает устройство доступа на магнитной ленте. Индекс позволяет быстрее домотать до нужного тома. А дальше опять все записи перебираем и ищем ту что удовлетворяет.
14 мар 06, 13:10    [2445977]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
AlexKB
Павел Воронцов
AlexKB
Где-то это все напоминает коробки и стеллажи с перфокартами.
Просто у Вас бедная фантазия.


Ну ладно, вот фантазия побогаче.
Все это напоминает устройство доступа на магнитной ленте. Индекс позволяет быстрее домотать до нужного тома. А дальше опять все записи перебираем и ищем ту что удовлетворяет.
Верите, нет, но вот лично я записи не перебираю. Я формирую РСУБД команду извлечения нужных мне данных, а как она там их найдет, ее сугубо унутреннее дело. Кстати, судя по многим примерам М-программ, именно мампсисты-то и "перебирают". Циклы там нередки. Вот и выходит, что M куда как ближе к вашей ассоциации.
14 мар 06, 14:49    [2446558]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить