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

Откуда:
Сообщений: 349
mir
Ув. хе-хе. Вы, видимо, не совсем в курсе истории БД-технологий. Сначала пару десятков лет как раз все программеры писали работу с БД на низком уровне. То есть "операции на индексах, доступные программисту" были как раз очень долгое время. Этакий ассемблер баз данных.
...
В общем, помедитировав над вопросом, почему ЯВУ в мейнстриме категорически вытеснили ассемблер (в свою очень узкую нишу), можно понять, почему РСУБД живут и побеждают, а про MUMPS-подобные системы можно сказать "пациент скорее мертв, чем жив".
Смешно то, что основоположник MUMPS, а затем Cache, говорит почти тоже самое, но по отношению к SQL и даже РСУБД в От М-технологий к постреляционной СУБД Cache
Терри Рэгон
Да, SQL был определенно хорош для своего времени, но его время уходит. Сейчас можно с уверенностью констатировать, что эта волна прошла свой максимум но многие промышленные гиганты, поднявшиеся на этой волне, по сути, остановились в развитии ядра своих технологий. Смогут ли они отреагировать так, как следует? Поверьте, еще три года назад подобный разговор был совершенно невозможен, все были в полном восторге от реляционных СУБД, но волна, порожденная Internet, меняет технологический ландшафт, и впереди, как полагают многие, нас ожидают большие перемены.
Сейчас Cache претендует не много не мало, а на роль постреляционной СУБД, включающей в себя возможности РСУБД. Дак о чем спор? Речь не идет о полном отказе от РСУБД и даже SQL. Если у MUMPS есть что-то положительное (работа с индексами, blah-blah-blah), почему от этого нужно отказываться?

А Интернет действительно сейчас предъявляет новые требования. Это не только поддержка иерархических структур как в Cache и Sav Zigzag. Даже с типизацией данных все не так просто…. Можно ли в SQL тип данных (по сути домен или класс) определять перечислением множества возможных значений как в языке Zigzag? Есть ли такие возможности у Cache? Например, почему бы не использовать такое описание схемы таблицы:
CREATE TABLE friends
(name VARCHAR(25) [a-z],
country [select name from country],
age NUMBER [1-150]
)
23 фев 06, 14:15    [2385222]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Уважаемые МАМПСисты, приводите пожалуйста примеры в развернутом виде.
Сейчас не те времена, когда в разделе 32К крутится одновременно несколько пользователей и нужно на всем экономить. Я понимаю, что мы привыкли к виду программного кода 80х24 без лишних пробелов, но мы же общаемся с теми кому это не доставляет радости. Будьте взаимно вежливы.

s A="S" k SS
f s A=$q(@A) q:A="" f N=1:1:$ql(A) s i=$qs(A,N),SS(i)=$g(SS(i))+@A
zw SS

//////// Может так лучше
Set A="S"
Kill SS
For {
Set A=$Query(@A)
Quit:A=""
For N=1:1:$QLength(A) {
Set i=$QSubscript(A,N)
Set SS(i)=$Get(SS(i))+@A
}
}
ZWrite SS
//////
23 фев 06, 15:01    [2385317]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
SergSuper


AlexKB

Технический пример. Двумерная таблица по которой необходимо выполнять интерполяцию входной величины. Таблица с уступами справа и слева, вверху и внизу. Расстояние между колонками и рядами переменно. Что поделать, такова таблица. Это не прикол - это реальные экспериментальные данные.

ничё не понял.Как тут древовидное мышление может помочь?


Вот структура дерева
^Table("имя объекта", "дата актуальности", "значение аргумента__1", "значение аргумента__2")="экспериментальное значение функции"


Имея на вооружении такое дерево выполнять интерполяцию можно в реальном времени, затрачивая на это пару десятков микросекунд. Благо во многих М языках время исполнения каждой команды можно оценивать с точностью до микросекунд. Причем, если аргументы меня направляют в существующую точку - то результат практически мгновенный.
23 фев 06, 15:29    [2385373]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
AlexKB
Уважаемые МАМПСисты, приводите пожалуйста примеры в развернутом виде.
Сейчас не те времена, когда в разделе 32К крутится одновременно несколько пользователей и нужно на всем экономить. Я понимаю, что мы привыкли к виду программного кода 80х24 без лишних пробелов, но мы же общаемся с теми кому это не доставляет радости. Будьте взаимно вежливы.

s A="S" k SS
f s A=$q(@A) q:A="" f N=1:1:$ql(A) s i=$qs(A,N),SS(i)=$g(SS(i))+@A
zw SS

//////// Может так лучше
Set A="S"
Kill SS
For {
Set A=$Query(@A)
Quit:A=""
For N=1:1:$QLength(A) {
Set i=$QSubscript(A,N)
Set SS(i)=$Get(SS(i))+@A
}
}
ZWrite SS
//////

..не стреляйте в программиста он играет как умеет..

в приложениии - если Вы видели -
код сидит в ячейках excel, откуда идет запрос на м-сервер

демонстрировалась принципиальная возможность решить поставленую
задачу минимальными средствами - 3 строчки кода = 3 ячейки excel

комментарии:
Set A="S" ;; установим "S" - имя дерева для просмотра
Kill SS ;; зачистка результирующего дерева "SS"
For { ;; начинаем цикл просмотра по ветвям дерева S
Set A=$Query(@A) ;; возьмем следующую ветвь ...
Quit:A="" ;; выход из цикла если ветвей больше нет
For N=1:1:$QLength(A) { ;; пройдемся по ветви - по именам начальников
Set i=$QSubscript(A,N) ;; начальник номер N и зовут его i
Set SS(i)=$Get(SS(i))+@A ;; @A - это его деньги или деньги его вассала
}
}

ZWrite SS ;; распечатаем готовую таблицу SS

мне конечно роднее первый - компактный - код
думаю - и Вам тоже :)

а интересно чисто спортивно как это на SQL будет ?
23 фев 06, 15:42    [2385396]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
Представленный код выводит всех работающих, без разбору количества вложенности и ветвистости, и сколько там "вассальства" - 1, 3 или тыщя_тыщ - код остался один.

пришел погулять пока в праздничек делать нечего
23 фев 06, 15:50    [2385410]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Не вводите людей в заблуждение.
Реальные ограничения конечно же существуют по количеству уровней индексации.
Хотя более 30-40 уровней вложенности никакому начальнику уже не охватить разумом, значит и отчет такой ему не нужен.
23 фев 06, 16:02    [2385430]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
Где-то я писал про микроскоп. В том понимании, что нет такого понятия "задача выполняема ТОЛЬКО на М" или "задача выполняема ТОЛЬКО на не_М" .... здесь важен анализ.

Я (мы) к примеру выбрали М из таких соображений:

1) - работает на любом железе, толстый клиент требует примитивной ОС для загрузки и наличие сетевого протокола, сервер на 486DX-200 под DOS-6.22 успешно держит до сотни таких юзеров

2) - поддерживает ANSI-терминалы и устройства, подключённые к ним

3) - недостаточная распространённость равно как одна из степеней защищённости ПО

4) - нет необходимости ограничиваться в структуре хранимых данных, дальнейшее развитие (ветвление) не мешает работе устаревшего ПО одновременно с работающими новыми версиями

5) - использование т.н. "удалённого монтирования" - комплексы программ находятся централизованно, замена отдельных программ не требует веерных действий по юзерам

6) - максимальный размер базы на одном (возможна размазанность базы по разным серверам) компьютере намного превышает размер винчестера

7) - средства разработки CHUI или GUI - в зависимости от степени презентабельности интерфейса

8) - возможность адаптировать под М процедуры из других языков (CALL) или станд. ActiveX-ы

9) - трёхуровневая защита баз от сбоев - защита целостности (журнал "до записи"), защита выполняемых команд (журнал "после записи"), межмашинное журналировани (зеркальные базы)

10) - обращение к базе из не_М или обращение из М наружу (Activate)

и только потом ....

11) - наличие разработчиков, умеющих и знающих М

12) - MSM-SQL, MSM-WEB, telnet и прочее

З.Ы. Я лично разрабатываю ПО с 1996-го года, эпизодически появляются помощники. С тех пор MSM из конкурентных соображений вытеснен "паровозом" Cache', но это не значит, что "всё плохо" или "всё хорошо".
З.Ы.-2 Ни в коей мере не хочу нападать на других, использующих отличные от меня СУБД, просто убеждён, что в М есть своя прелесть.
23 фев 06, 16:11    [2385447]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
чисто спортивно
Guest
MX -- ALEX


а интересно чисто спортивно как это на SQL будет ?


Oracle SQL

create table test_sal(
       name varchar2(20),
       name_boss varchar2(20),
       sal number
)

insert into test_sal values('a',null,100);
insert into test_sal values('b','a',60);
insert into test_sal values('c','a',50);
insert into test_sal values('d','a',40);
insert into test_sal values('e','b',30);
insert into test_sal values('f','b',20);

select s.name,
(select sum(t.sal) 
 from test_sal t
 connect by prior t.name = t.name_boss
 start with t.name = s.name) sum_sal
from test_sal s 
23 фев 06, 16:12    [2385448]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
AlexKB
Не вводите людей в заблуждение.
Реальные ограничения конечно же существуют по количеству уровней индексации.
Хотя более 30-40 уровней вложенности никакому начальнику уже не охватить разумом, значит и отчет такой ему не нужен.


Какое заблуждение - я говорю не о конкретной задаче "начальник-подначальник-подчинённый", я говорю о структуре данных в виде дерева, где кол-во ветвей не лимитируется.
23 фев 06, 16:15    [2385453]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
чисто спортивно
MX -- ALEX


а интересно чисто спортивно как это на SQL будет ?


Oracle SQL

create table test_sal(
       name varchar2(20),
       name_boss varchar2(20),
       sal number
)

insert into test_sal values('a',null,100);
insert into test_sal values('b','a',60);
insert into test_sal values('c','a',50);
insert into test_sal values('d','a',40);
insert into test_sal values('e','b',30);
insert into test_sal values('f','b',20);

select s.name,
(select sum(t.sal) 
 from test_sal t
 connect by prior t.name = t.name_boss
 start with t.name = s.name) sum_sal
from test_sal s 

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

короче пацаны кончай травить - 23 февраля никто не отменял
даже здесь в Латвии

ВСЕХ С ПРАЗДНИКОМ !
ИДЕМ ВОДКУ ПЬЯНСТВОВАТЬ И ДИСЦИПЛИНУ ХУЛИГАНИТЬ !
23 фев 06, 16:46    [2385517]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Кстати, яслужил на ВЦ дивизии в г Черновцы.
Там были машины СМ-1634.
На них не было реализации МАМПС.
Но валялась литература по стандарту МАМПС. Вот там то я и понял и полюбил эти системы навсегда.
Хотя по жизни мне чем только не доводилось заниматьс.

Вот этим я занимался лет 12

8134 8150 0А78 4053 9550 FF78 и т.д. это текст программы

как Вы понимаете комбинаций 65535, но достаточно было взглянуть в любую точку программы, и все становилось ясно. Так что сложность языка это вопрос желания его понять.
23 фев 06, 17:02    [2385560]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

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

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

okdoky

Речь не идет о полном отказе от РСУБД и даже SQL. Если у MUMPS есть что-то положительное (работа с индексами, blah-blah-blah), почему от этого нужно отказываться?

А Вы уверены, что не взяли? И не из MUMPS, а у кого-то покруче в плане индексов. Литры про исследования индексов полно. Она открыта. Как правило не является изобретением производимтелей. Последнии в основном доробатывают.

okdoky

А Интернет действительно сейчас предъявляет новые требования. Это не только поддержка иерархических структур как в Cache и Sav Zigzag.

А может как в иерархических и сетевых дореляционных СУБД? Или Вы думаете, что это что-то новое? У IBM есть IMS - иерархическая СУБД, но она производит и реляционную DB2, да жизнь реляционным собственно IBM и дала.
А на самом деле причем тут интернет пока не ясно. И при чем тут Sav Zigzag?
Вроде выяснилось в начале топика что он в плане БД уступает SQL в базовых вещах, так и что забыть про него можно. Не может же быть так, что ничего стоящего в нем мы здесь не обнаружели, но тада будем просто так считать что он отвечает современным требованиям. А каким не важно. Он позже появился - значит отвечает.


okdoky

Даже с типизацией данных все не так просто…. Можно ли в SQL тип данных (по сути домен или класс) определять перечислением множества возможных значений как в языке Zigzag? Есть ли такие возможности у Cache? Например, почему бы не использовать такое описание схемы таблицы:

Вы даете. Это что современные требования интернета? Это какая-то мелкая деталь, а нужно то-что концептуальное для превосходства. А таблы SQL может создавать на основне запросов.
CREATE TABLE ffff AS SELECT ....
Да и поддержка ООП уже допускает и объектные типы для колонок, а у Оракла есть и вложенные таблы - коллекции и объектные таблицы.
Не ужели Вы считаете что все до Sav Zigzag темные, не пользуются компьютерными учеными, чтобы их можно было на какой-то ерунде так просто подловить? Даже не изучая.
Надо чтобы чего-то не было, оно было необходимо, и этого нельзя было бы добавить. Вы просто прикинте какие ресурсы в том числе и научные, инженерные стоят стоят за РСУБД и какие за Sav Zigzag.
23 фев 06, 17:23    [2385611]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

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

Даже с типизацией данных все не так просто…. Можно ли в SQL тип данных (по сути домен или класс) определять перечислением множества возможных значений как в языке Zigzag? Есть ли такие возможности у Cache? Например, почему бы не использовать такое описание схемы таблицы:

Вы даете. Это что современные требования интернета? Это какая-то мелкая деталь, а нужно то-что концептуальное для превосходства. А таблы SQL может создавать на основне запросов.
CREATE TABLE ffff AS SELECT ....
Да и поддержка ООП уже допускает и объектные типы для колонок, а у Оракла есть и вложенные таблы - коллекции и объектные таблицы.
Между прочим очень интересная идея реализованная в Zigzag. И Вы так легко от нее отмахиваетесь? Только потому что SQL не поддерживает такую возможность? А ведь
CREATE TABLE friends
(name VARCHAR(25) [a-z],
country [SELECT name FROM country],
age NUMBER [1-150]
)
выглядит достаточно просто и понятно :). Типизация в Интернет действительно имеет свои особенности. Начнем с того, что отсутствие типов переменных в JavaScript существенно упрощает жизнь разработчиков. Браузеру предлагается самому догадаться какой используется тип. Даже коряво написанный HTML он худо-бедно, но воспроизводит. Разве это плохо? Типизация в Интернет должна быть гибкой и даже подстраиваться под требования конкретного пользователя. Имеет право на жизнь и такое описание схемы:
CREATE TABLE friends
(name [IF ENGLESH [a-z] | IF RUSSIAN [а-я]],
)
Все это можно сделать в рамках SQL.
23 фев 06, 18:42    [2385765]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
MX -- ALEX
c127

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 знака?


Уважаемые с127 и mir ,
мы
кашисты-мумпсисты
не стали комментировать это вульгарное сравнение из соображений
политкорректности
но Вы нарываетесь :
ведь понятно что условие q:d>20060227.9
выбирает по дням рождения с точностью до дня
а Ваше - до года
Напишите условие не "16 лет"
а "дети родившиеся в период 20060202-20060227 включительно"
и тогда считайте

Вы что издеваетесь? Вам постоянно говорят, что совершенно ничего непонятно, а Вы каждый раз упрямо повторяете что-то вроде: "ведь понятно что условие q:d>20060227.9 ...". Еще раз, постарайтесь исходить из предположения что ВООБЩЕ НИЧЕГО НЕПОНЯТНО. Это близко к истине по крайней мере для меня.

CesaTheGuest уже ответил(а). Но чтобы уж совсем по-честному, то лучше так:
select c from t where p='Иванов' and b>='20020202' and b<='20060227'
или даже так
select c from t where p='Иванов' and b>'20020201' and b<'20060228'
68 (66) символов против 65 нечитаемой абракадабры. Ну и в чем состоит обещанный ГРОМАДНЫЙ выигрыш в компактности программ, в трех символах? Так это меньше 5 процентов.

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

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

MX -- ALEX
чисто спортивно
MX -- ALEX


а интересно чисто спортивно как это на SQL будет ?


Oracle SQL
create table test_sal(
       name varchar2(20),
       name_boss varchar2(20),
       sal number
)

insert into test_sal values('a',null,100);
insert into test_sal values('b','a',60);
insert into test_sal values('c','a',50);
insert into test_sal values('d','a',40);
insert into test_sal values('e','b',30);
insert into test_sal values('f','b',20);

select s.name,
(select sum(t.sal) 
 from test_sal t
 connect by prior t.name = t.name_boss
 start with t.name = s.name) sum_sal
from test_sal s 

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

Вот мужик в пиджаке, а вот дерево:
    a 
   / \  \
  b   c   d
 / \
e   f
Причем дерево может быть любым, хоть пальма, хоть баобаб, даже дубовая роща, в смысле лес, зпрос не изменится.
24 фев 06, 02:24    [2386366]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
CesaTheGuest
Guest
с127
Я согласен с CesaTheGuest, сравнивать длину кода на подобных коротких примерах смысла нет, но ведь не мы это начали. Нам пообещали невероятную компактность программ, привели пример, согласен, не очень удачный, но который был выбран абсолютно свободно, без давления. Но обещанной компактности что-то не видно. Причем ситуация повторяется уже в третий раз, если не ошибаюсь.

Думаю стоит пояснить до конца... Мое мнение - нет смысла сравнивать компактность кода на ЛЮБЫХ проектах. Кодирование при запуске проекта составляет 10%. Т.е. даже есть запись на М будет короче в два раза, то выигрышь будет 5%. Вот отладка будет возможно затруднительной. Кроме того sql запрос 2 программера напишут примерно одинаково, а вот в М я такого не наблюдаю, а как же работа в команде?
Может доказывать нужность М можно подругому?... Типа меньше время на проектирование, внедрение, сопровождение, на разработку интерфейса. Но тут важно другое... В соседней ветке Андрей Леонидович доказывал, что при разработке на пост-реляционных СУБД программировать вообще не надо, только как мы не пытались, доказательств не выбили... Отбивался как матерый партизан... Так что меренье пиписками на уровне скриптов в БД, как-то не выглядит серьезным. Как пример: обработка деревьев в одних РСУБД лучше чем в других, но никто особо не ломится переделывать проекты... Мне какая разница как коротко обсчитываются деревья если в моей ИС их всего два. Нужны более распространенные примеры.
24 фев 06, 06:25    [2386397]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky

Даже с типизацией данных все не так просто…. Можно ли в SQL тип данных (по сути домен или класс) определять перечислением множества возможных значений как в языке Zigzag?
Конечно можно. В стандарте SQL2 формально определение домена включает не только базовый тип, но и ограничения целостности как в виде выражений, так и в виде списков допустимых значений.
CREATE DOMAIN VALID_EMPL_IDS INTEGER CHECK (VALUE BETWEEN 101 AND 199)
CREATE DOMAIN RGBCOLOR VARCHAR(5) CHECK (VALUE IN ('Red', 'Green', 'Blue') )
Конечно, в разных SQL-СУБД свои диалекты, то это уже другой вопрос.
Короче, вам бы изучить хоть азы SQL, прежде чем его критиковать.
24 фев 06, 07:26    [2386412]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
CesaTheGuest
с127
Я согласен с CesaTheGuest, сравнивать длину кода на подобных коротких примерах смысла нет, но ведь не мы это начали. Нам пообещали невероятную компактность программ, привели пример, согласен, не очень удачный, но который был выбран абсолютно свободно, без давления. Но обещанной компактности что-то не видно. Причем ситуация повторяется уже в третий раз, если не ошибаюсь.

Думаю стоит пояснить до конца... Мое мнение - нет смысла сравнивать компактность кода на ЛЮБЫХ проектах. Кодирование при запуске проекта составляет 10%. Т.е. даже есть запись на М будет короче в два раза, то выигрышь будет 5%. Вот отладка будет возможно затруднительной. Кроме того sql запрос 2 программера напишут примерно одинаково, а вот в М я такого не наблюдаю, а как же работа в команде?
Может доказывать нужность М можно подругому?... Типа меньше время на проектирование, внедрение, сопровождение, на разработку интерфейса. Но тут важно другое... В соседней ветке Андрей Леонидович доказывал, что при разработке на пост-реляционных СУБД программировать вообще не надо, только как мы не пытались, доказательств не выбили... Отбивался как матерый партизан... Так что меренье пиписками на уровне скриптов в БД, как-то не выглядит серьезным. Как пример: обработка деревьев в одних РСУБД лучше чем в других, но никто особо не ломится переделывать проекты... Мне какая разница как коротко обсчитываются деревья если в моей ИС их всего два. Нужны более распространенные примеры.


Вам и 127-му лучше пойти в НКВД работать
Или в ГЕСТАПО
Выбивать доказательства из партизан..

а мы
мампсисты-кашисты
вам ничего не скажем и Большую Тайну не выдадим

и нам по х..
скока буквов в SQL и скока в муму

главное работаеть и бапки капають - 3 %

вот с этих 3-x процентов мы и живем..
24 фев 06, 10:24    [2386585]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
AlexKB
Кстати, яслужил на ВЦ дивизии в г Черновцы.
Там были машины СМ-1634.
На них не было реализации МАМПС.
Но валялась литература по стандарту МАМПС. Вот там то я и понял и полюбил эти системы навсегда.
Хотя по жизни мне чем только не доводилось заниматьс.

Вот этим я занимался лет 12

8134 8150 0А78 4053 9550 FF78 и т.д. это текст программы

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

я увидел ДИАМС на СМ-1420
и тоже прикипел
до этого работал на PL/1
а иногда прямо в кодах на советских Электроника -125
Мы тогда на ДИАМС сразу АДАБАС переплюнули раз в 5 по
скорости и колич рабочих мест
Минчермет за опытом приезжал на наш заводик
Глаза большие
============
24 фев 06, 10:34    [2386595]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
А давайте переименуем топик ? Мне например совсем не нравится процесс сравнения, потому как всегда скатывается на взаимные обиды.
24 фев 06, 10:58    [2386656]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
По поводу сравнений.

Помнится как-то централизованно внедрили небольшой проект на FoxBase кажется. Нужно было заниматься вопросами паспортизации оборудования.
Под это дело выделили отдельный ПК и пользователи приходили друг за дружкой, по расписанию, что-то вбивали, печатали отчеты. Но они много ругались и постоянно пытались включить меня в их разборки.
Мне это надоело и я поступил следующим образом.
Я тогда эксплуатировал NTSM (диалект М советская разработка) и у меня случайно оказался пакет NtBase (кнвертор d-Base в MUMPS). С помощью этих средств за пяток дней я перенес все программы, включая интерфейсную часть, в NTSM-NtBase. Затем перенес данные, посадил людей за терминалы и они продолжили работу. Единственное различие между двумя решениями для пользователей - это монохромный терминал. Кстати за это я не получил ни одного замечания от пользователей.

А люди, работая теперь сообща в "многозадачном многопользовательском Foxе", даже помирились.

Выод: Fox людей поссорил, а MUMPS - примирил.
24 фев 06, 11:38    [2386747]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
2 AlexKB

Может, всем нам не стоит приводить уж такие "детсадовские" примеры и аргументы? С такими вот "детсадовскими" выводами (без обид). Это только приводит к деградации уровня обсуждения.
24 фев 06, 11:48    [2386770]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Sergo Gromov
Member

Откуда: Lviv Ukraine
Сообщений: 56
mir
2 AlexKB

Может, всем нам не стоит приводить уж такие "детсадовские" примеры и аргументы? С такими вот "детсадовскими" выводами (без обид). Это только приводит к деградации уровня обсуждения.


Возможно. Тогда что же приводить в пример ? Если у человека действительно произошло так, и его это удивило - почему бы не послушать ?? Может между строк что-то написано ? :-)
24 фев 06, 11:52    [2386784]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс.... - развенчание мифов.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
mir
Ув. хе-хе. Вы, видимо, не совсем в курсе истории БД-технологий. Сначала пару десятков лет как раз все программеры писали работу с БД на низком уровне. То есть "операции на индексах, доступные программисту" были как раз очень долгое время. Этакий ассемблер баз данных.
...
В общем, помедитировав над вопросом, почему ЯВУ в мейнстриме категорически вытеснили ассемблер (в свою очень узкую нишу), можно понять, почему РСУБД живут и побеждают, а про MUMPS-подобные системы можно сказать "пациент скорее мертв, чем жив".
Смешно то, что основоположник MUMPS, а затем Cache, говорит почти тоже самое, но по отношению к SQL и даже РСУБД в От М-технологий к постреляционной СУБД Cache
Прочитал статью. Обычный набор сугубо маркетинговых заявлений главы компании о преимуществах своего товара и недостатках товаров конкурентов. Заявлений, сделанных, что характерно, во время публичной презентации своего товара. Естественно, всё в одни ворота и без малейших аргументов, если не считать такими слова вроде "поверьте" и "как полагают многие".
Полагаю, что обращать на подобные заявления внимание, значит просто тратить время.
24 фев 06, 12:09    [2386821]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
mir
2 AlexKB

Может, всем нам не стоит приводить уж такие "детсадовские" примеры и аргументы? С такими вот "детсадовскими" выводами (без обид). Это только приводит к деградации уровня обсуждения.


Никаких обид.

Я начинал с Логика-Т и ко всему нынешнему пришел эволюционно, поэтому мне есть что и с чем сравнивать.
Выод у меня один - мало какие задачи MUMPSу не по плечу (в разумном сравнении).

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

Ведь если Наши (сторонники MUMPS) начнут Вашим (сторонникам SQL)приводить аргументы из расширений стандарта, тогда Вы вообще ничего не сможете понять.

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

Я и сейчас использую SQL, но очень мало. Скажем нужно в ComboBox положить список для выбора, так я от лени просто прикрепляю предопределенный запрос.

МНЕ SQL НЕ МЕШАЕТ, поэтому я к нему абсолютно лоялен, нет никакой агрессии.
Но вот почему Вы к Нам настолько агрессивны?
Может от безсилия? Тут же извиняюсь.
24 фев 06, 12:53    [2386920]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

c127 wrote:
> Вы что издеваетесь? Вам постоянно говорят, что совершенно ничего
> непонятно, а Вы каждый раз упрямо повторяете что-то вроде: "ведь понятно
> что условие q:d>20060227.9 ...". Еще раз, постарайтесь исходить из
> предположения что ВООБЩЕ НИЧЕГО НЕПОНЯТНО. Это близко к истине по
> крайней мере для меня.
>
> CesaTheGuest уже ответил(а). Но чтобы уж совсем по-честному, то лучше так:
> select c from t where p='Иванов' and b>='20020202' and b<='20060227'
> или даже так
> select c from t where p='Иванов' and b>'20020201' and b<'20060228'
> 68 (66) символов против 65 нечитаемой абракадабры. Ну и в чем состоит
> обещанный ГРОМАДНЫЙ выигрыш в компактности программ, в трех символах?
Для неграмотного что q:d, что select c from t - всё одно, закорючки...
с какого такого Вы решили, что усе НЕ понимають М и усе ПОНИМАЮТЬ скл?
или так, специфика сайта навеяла?


--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

24 фев 06, 13:18    [2387007]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить