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

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


он что - гавно не в ту сторону качал ?
или немецкий газ на Украину отправлял ?

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

Вам бы поработать не мешало.
С насосами.

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

на MUMPS.
============================

Перечитайте, Я говорил о драйвере, а Вы о подшипнике. Драйвер работает плохо именно потому что написан на перле. Перл для написания таких драйверов не подходит. Хотя драйвер кое-как работает и тоже с горем попалам прошел аттестации. Т.е. формально Все как в Вашей системе. Это я привел контрпример к Вашему утверждению что Ваши системы работают. Поэтому то что они работают почти ничего не значит, еще нужно знать КАК они работают, сколько труда было затрачено на создание и сколько тратится на поддержку. Но Вы же понимаете, что проверить эту информацию нет реальной возможности, получается что Вы требуете верить Вам на слово, что несерьезно. Мне тоже верить не нужно. Чтобы этого избежать мы пытаемся разобраться на простых примерах, тут верить никому не нужно, все перед глазами.

Может Вы все-таки ответите на давным-давно заданный вопрос по индексам? (https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=19#2437781 )
Не понимаю в чем проблема, с этим элементарным вопросом. Вопрос простой, но важный для любой СУБД независимо от архитектуры:
"Покажите пример использования индекса если это несложно. Например по полю "рейс" в ^БИЛЕТЫ(дата,рейс,место)."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=10#2392797

Мне было сказано что индексов в М нет:
Rus000

с127

Когда в ^БИЛЕТЫ(дата,рейс,место) добавляется нечто, то это должно быть отражено в индексе. Как система может не знать, что индекс должен быть модифицирован? Это же индекс.

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

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2404653
Потом было сказано что это неверно и индексы там вроде бы есть и что глобалы и есть индексы.
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=19#2434036
Проясните ситуацию и приведите все-таки пример индекса по полю "рейс", если не сложно.





MX -- ALEX

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

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=14#2416586
Вы уже посмотрели решение на СКЛ-е? Если еще нет, то ссылки тут: https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=14#2420046
Удалось сравнить по удобству и выразительности программирования? Есть что сказать на этот счет?
15 мар 06, 23:12    [2453376]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
[quot c127Удалось сравнить по удобству и выразительности программирования? Есть что сказать на этот счет?[/quot]

похоже что мы действительно сравниваем разные по
назначению вещи

MUMPS скорее все-же инструмент для создания СУБД
и это правильно подмечено с статье А. Долженкова

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

Наша группа разработчиков использует не чистый MUMPS ,
а инструмент сделаный на его основе ("MX" = mumps+excel)
который сочетает разные подходы - и табличный и иерархический
и имеет хорошо отлаженные встроенные средства
(отчетники,генераторы ввода,средства организации интерфейса и т п)
И поэтому, в частности, наши разработки находят покупателя.

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

а статью все таки почитайте
кое что проясняет
-------------------------
С уважением
Алексей
16 мар 06, 09:02    [2453915]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
ораклоидальный мампсист
Например:
^индексы сущности(ид.свойства,значение свойства,ид.сущности)=""

давайте не уходить от ответа
сначала вы написали так
ораклоидальный мампсист

^сущность(ид. сущности, ид. свойства)=значение свойства
или
^сущность(ид. сущности)=свойства сущности

и вопросы касались этих примеров. теперь вдруг что-то новое про что вас пока не спрашивали
16 мар 06, 09:32    [2454024]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Дельфийская убогость...
Guest
типа ораклоидный мампсист
А мне, ggv, неохота не только ввязываться в дискуссии
Превед апять!.....что жа Вы таварищ "тот каво здесь усе знають" в десятый раз в её ввязываитись та? Апатом апять начнети гаварить что де. Уж с вашей та менрай вести биседу, афармлят пастЫ, я уж ни гаварю пра мысли ГЫ-ГЫ-ГЫ как вы сибя ни называйте, а канкретный ЧАЛовек так и вылизаит.... Ой што та у миня с кнопкой SHIFT приключилась....
16 мар 06, 12:26    [2455156]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
vadiminfo
Слабость Зигзага в том, что он ваще пока никак не продемонстрировал каких-то достоинств, чтобы хотя быть достаточно известным. Например, он не может потеснить иерархические языки БД (если он вообще позиционирует себя как язык БД). А РБД выиграла уже не тока у иерахичеких БД, но и у сетевых. А Вы кого-то хотите удивить каким-то простым маршрутом из семантической сети.
Вы сначала поисчите в литре причины, почему РБД лидирует - может узаете, что не все так просто в мире БД как Вам кажется, када Вы рисуете ветки про собак.
Дело конечно не в собаках. Я привел Вам наглядный пример, как можно использовать механизм наследования атрибутов. В примерах по SQL Вы этого не найдете. Может когда-нибудь пригодится. Тем более, пример связан не с программным объектом, а с представлением и запросом в ОРБД. А на счет РБД я очень рад. На сколько мне известно Cache и Sav Zigzag - ОРСУБД, то есть их представление включает и реляционное.
vadiminfo
А универсальными являются С++, Джава и, в частности, Мумпс.
Специализированное, как правило, лучше универсально на том, на чем оно специализируется.
Ваше пустословие заключается в том, что Вы говорите вещи которые все знают. То есть Вы не говорите ничего нового. Фактически, Вы не критикуете меня (мои ответы ggv на счет преимуществ универсального), а просто незаметно уводите диалог в сторону. Я Вам привел достаточно наглядный пример на Zigzag о том как можно эффективно использовать механизм наследования атрибутов в БД. Что Вы можете показать похожего на SQL? Чем можете удивить?
vadiminfo
Но Джаве Зигзаг сто лет не нужен, а то что Скуль хорошее дополнение к Джаве даже Вы сказали.
Т.е. пока Zigzag = 0
Просто я стараюсь, в отличии от Вас, не переводить все в 0 или в пустые слова.
16 мар 06, 18:46    [2457434]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
c127

Rus000

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

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


ну что ж, немного с опозданием, но предлагаю иную реализацию
/// ------------------------------------------------------
/// Дано: дата ,рейс
/// Выдать таблицу (билеты в наличии): рейс - класс - кол-во мест
/// ------------------------------------------------------
/// SELECT Дата,НомерРейса,COUNT(*) 
/// FROM РАСПИСАНИЕ Р,САМОЛЕТ_МЕСТА М 
/// WHERE Дата=30010 AND 
///       НомерРейса='D3857' AND 
///       Р.САМОЛЕТ=М.САМОЛЕТ AND 
///       Места_Статус<1 
/// GROUP BY 1,2
/// 
/// ------------------------------------------------------
/// Дано: дата, рейс
/// Выдать таблицу (свободные места): номер места m - класс - цена
/// ------------------------------------------------------
/// SELECT Места_Класс,Места_Место,Места_Цена 
/// FROM РАСПИСАНИЕ Р,САМОЛЕТ_МЕСТА М 
/// WHERE Дата=31004 AND 
///       НомерРейса='U9358' AND 
///       Р.САМОЛЕТ=М.САМОЛЕТ AND 
///       NOT Места_Статус IN (1,2) 
/// ORDER BY 1,2 DESC
/// 
/// ------------------------------------------------------
/// Дано: дата, рейс
/// Выдать таблицу (список пассажиров): место - Name - выкуплено/забронировано
/// ------------------------------------------------------
/// SELECT Места_Место,Места_Пассажир,Места_Статус 
/// FROM РАСПИСАНИЕ Р,САМОЛЕТ_МЕСТА М 
/// WHERE Дата=31004 AND 
///       НомерРейса='U9358' AND 
///       Р.САМОЛЕТ=М.САМОЛЕТ AND 
///       Места_Статус IN (1,2)
///  ORDER BY 1
///  
/// Расписание рейсов
Class User.РАСПИСАНИЕ Extends (%Persistent, %Library.Populate)
{

/// Дата+Рейс однозначно определяют самолет в расписании
Index Primary On (Дата, НомерРейса) [ IdKey ];

/// Дата вылета
Property Дата As %Date;

/// Номер рейса
Property НомерРейса As %String;

/// Тип самолета
Property Самолет As САМОЛЕТ;

}

/// Описывает типы самолетов, и классы мест в нем
Class User.САМОЛЕТ Extends (%Persistent)
{

Property ТипСамолета As %String(VALUELIST = ",ИЛ-86,ИЛ-96,ТУ-154,АН-24,БОИНГ-737");

Property Места As array Of МЕСТО;

}

Class User.МЕСТО Extends %SerialObject
{

/// Номер места
Property Место As %Integer(MAXVAL = 400, MINVAL = 1);

/// Класс места
Property Класс As %SmallInt(VALUELIST = ",1,2,3");

/// Цена билета
Property Цена As %Numeric(MINVAL = 0);

/// ФИО Пассажира
Property Пассажир As %Name;

/// Статус брони 
Property Статус As %SmallInt(DISPLAYLIST = ",Свободно,Бронировано,Выкуплено", VALUELIST = ",0,1,2");

}



c127

c127

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

Я даже не знаю систем, где этот код доступен для обозрения. План запроса можно посмотреть, но это другое.


из того, очевидно, не следует что его нет :)

c127

Мы же хотим сделать жизнь человека легче. Есть средство, котрое что-то делает за человека, причем в данном случае вполне эффективно. Вот пусть оно и работает. А Вы предлагаете смотреть как оно работает. Если Вы пишите базы данных, а не оптимизаторы запросов, то это трата времени. У БД программиста есть более полезные, а главное высокооплачиваемые занятия, чем копаться в низкоуровневом коде.


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

Например мне, как Вы выражаетесь, низкоуровневое M-программирование не мешает быстро создавать вполне эффективные и легко сопровождаемые (дистанционно) проекты ... даже не могу оценить смог бы сделать аналогичные решения с такими же ТТХ в РМД-парадигме.

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

с127

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


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

1:1?

:)
16 мар 06, 19:18    [2457525]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

В примерах по SQL Вы этого не найдете.

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

okdoky

Может когда-нибудь пригодится.

Вот именно что может быть когда-нибудь кому-нибудь. Смешно чесслово.

okdoky

Ваше пустословие заключается в том, что Вы говорите вещи которые все знают.

А Вы наверное верите, что Вы говорите новое слово в компьютерных науках?
Возможно, Вы говорите не только, что все давно знают, но и знают, что это наивно. Наример, Ваши критерия выбора языков. Рассуждения про универсальность и выразительность. Кто знает? Разве тока я отсылал Вас изучить критикуемый Вами предмет. Посмотрите что Вам писали. Это же не реально - не знать элементарных вещей про SQL и открывать Америку в "языкознании".

okdoky

Тем более, пример связан не с программным объектом, а с представлением и запросом в ОРБД.

Вы ожидали, наверное, что этот пример компенсирует от сутствие в Зигзаге группировки или еще чего там не хватает?
Как все знающий вы должны знать, что ОРМД - расширение РМД. А все лидирующие РСУБД, на самом деле уже ОРСУБД. Так что SQL Вы буквой О не удивите.

okdoky

На сколько мне известно Cache и Sav Zigzag - ОРСУБД, то есть их представление включает и реляционное.

Про Cache пока нет таких однозначных подтверждений, что они ОРСУБД. И ОРСУБД, если Вы все знаете, не реляционное включает, а ООП оно включает. А реляционная там основа.
Про Sav Zigzag ниче не известно пока из достоверных источников. Вы его позиционировали то как реляционное када тока появились, потом про деревья пытались толкать - иерархические. Вы сами не знаете чего Вы хоЧИте. Но если он ОРСУБД, то тем хуже для него - шансов совсем никаких слишком серьезные технологии у его тада конкуретов. Там Оракл, DB2, МС Скуль.

okdoky

Фактически, Вы не критикуете меня (мои ответы ggv на счет преимуществ универсального), а просто незаметно уводите диалог в сторону.

Насчет универсального я Вам сказал - Ассемблер форева. Я считаю Ваши доводы слишком наивными, чтобы к ним в серьез относиться и критиковать. Достаточно легких комминтариев, а иногда и отсутствия таковых.

okdoky

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

Но сетевые СУБД это луче делают, чем Зигзгзаг. Да и ООСУБД это луче делают. Причем тут зигзаг, когда конкурируют реально продвинутые в этих вопросах СУБД? Зачем что-то узнавать из Зигзага? Вы этим не можете удивить - это знают ВСЕ. Нужно что-то принципиально новое и значимое, а не заимствование каких-то мелких решений из продвинутых систем, чтобы потеснить SQL. Я давно Вам это говрил и тепрь намекнул, а Вы просто не увидели того моего ответа.

okdoky

Что Вы можете показать похожего на SQL? Чем можете удивить?

Да мне то показывать и не надо. Разве задача для SQL стоит потеснить Зигзага, а не наоборот? Я Вам советовал узнать побольше про SQL и причины его успеха. Вы хотите верить, что какая-то там мелочь может все решить. Думаю, Вы заблуждаетесь. Вы на велосипеде можете проехать там где не проедете на мерседесе. Что теперь велосипед луче? А если учесть, что Ваш велосипед скорее всего не лучше, других, то его все равно могут не выбрать.

okdoky

Просто я стараюсь, в отличии от Вас, не переводить все в 0 или в пустые слова.

Вы просто и наивно пытатесь толкануть Зигзагом Скуль, веря что все зигзаге все есть последний писк и стоит тока предъявить все перед ним расступятся. Даже не удосужились ниче узнать о реальном положении дел в БД и что за технологии есть в других СУБД.
Сначала Вы пытались Зигзаг на рел стезе сравнивать с SQL. Там совсем смешно получилось - у Зигзага нет базовых вещей.
Тада Вы начали проталкивать его нереляционные свойства. Но не учли, что в лагере нереляционных СУБД есть более продвинутые, в которых Ваше ноухау вчерашний день. И если бы эти якобы Ноухау были бы достаточными чтобы потеснить то, не Зигзаг а они бы давно потеснили SQL. Поэтому Ваши старания скорее всего тщетны. Вам пытались тут многие советовать изучить предмет. Но Вам времени на это жалко, Вы спешите толкануть Зигзаг хоть как-то. Ну толкнуть самокат вместо Вольво много проще, чем Зигзагом Скуль, а бабок больше. Подумайте об этом.
16 мар 06, 22:09    [2457924]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Вот теперь понятно, мод. Вы не издеваетесь, как я предполагал сначала. Вы спросили про табличку и поля - я Вам ответил:
^сущность(ид.сущности,ид.свойства)=значение свойства
Потом Вы спросили (здесь я уже заподозрил неладное) "как искать по значению ? только full scan ?" - я Вам ответил как для сущности выглядят индексы:
^индексы сущности(ид.свойства,значение свойства,ид.сущности)=""
где в качестве "значения свойства" в зависимости от типа индекса ... и т.д.
Ну можно было предположить еще вопрос про оптимизацию запросов, и для Вас, как для начинающего изучать БД, можно было бы пояснить про статистики:
^индексы сущности(ид.своиства)=количество значений
^индексы сущности(ид.свойства,значение свойства)=количество экземпляров/количество значений слева
и т.д.
Но вот теперь видно, что Вы не издевались, а совершенно искренне не понимаете элементарных вещей. Вам даже помощь предлагали. Но, "гордо" отказавшись, Вы написали уже какую-то откровенную чушь.
16 мар 06, 22:14    [2457936]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Интересно какими представлениями о базах данных нужно обладать, чтобы всерьез строить приложения класса ERP на РБД ? Стыдно, ggv, не знать, что РСУБД не пригодны для ERP.
16 мар 06, 22:19    [2457950]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
###
Guest
ораклоидальный мампсист
Интересно какими представлениями о базах данных нужно обладать, чтобы всерьез строить приложения класса ERP на РБД ? Стыдно, ggv, не знать, что РСУБД не пригодны для ERP.

Точно - ЧАЛ!!! А я все сомневался до этого...
16 мар 06, 22:23    [2457955]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Еще один.
У мумпса сплошные проблемы. Убедился на своем горьком опыте:
1) транзакции нормально не сделаны
2) боле-менее большие отчеты напрочь вешают систему
3) да и без больших отчетов больше 10 пользователей и уже еле ворочается
4) горячего бэкапа нет
5) язык плохо приспособлен для работы с базой
6) короче даже непонятно для чего мумпс вообще можно применить, вроде не для чего.
Свалил на оракул и забот не знаю.
16 мар 06, 22:29    [2457964]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Вот это уже конкретно. Интересно было бы узнать что за мумпс такой, который к таким тяжким последствиям привел.
16 мар 06, 22:35    [2457974]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
обычный мумпс MG от MGSystems. Наскока я знаю он в России-матушке преобладает.
16 мар 06, 22:39    [2457980]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
MX -- ALEX
В этой связи я считаю целесообразным прекратить спор
- ввиду неудачной постановки самого вопроса

Ок. Напоминаю, однако, что неудачная постановка вопроса и инициатива начать спор принадлежала не РСУБД-шникам.

MX -- ALEX

Если хотите считайте что Вы выйграли.

Не хочу, мне это безразлично, выигрыш не был целью.
16 мар 06, 22:40    [2457981]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
###
Guest
Точно ! У нас в соседнем отделе тоже намучились с MG. Но я даже не знал что это мумпс.
16 мар 06, 22:41    [2457986]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
вот теперь знай, и держися подальше от любых мумпсов.
16 мар 06, 22:43    [2457990]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Дельфийская убогость...
Guest
Абалдеть ! Вона как плохи дила у мумсов...
16 мар 06, 22:47    [2457998]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Ничего не слышал об MGSystems, поэтому не могу и возразить. Мне не известны MUMPS с такими проблемами.
16 мар 06, 22:52    [2458011]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
с127
Guest
Господа, давайте уже заканчивать. Мы не знаем мампс, и никогда не узнаем. Они не знают РСУБД, и никогда не узнают. И к чему эти разговоры слепых с глухими ?
16 мар 06, 22:56    [2458016]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Чернышев Андрей Леонидович
Guest
Почему же заканчивать, с127. На самом интересном ! Про MGSystems.
Теперь самое время возобновить наш старый спор про шары в мешках. И я уверен что Вы признаете в конце концов очевидную убогость "Р"СУБД.
16 мар 06, 23:02    [2458029]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
уймись ЧАЛ ! только тебя здесь не хватало
16 мар 06, 23:03    [2458034]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
с127
Guest
Сам собой получился капец теме.
16 мар 06, 23:04    [2458036]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Rus000

ну что ж, немного с опозданием, но предлагаю иную реализацию
...

МУМПС-овый СКЛ обсуждалися на 11 странице:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=11#2394023
Вроде все выяснили, возражений не было. Зачем ходить по кругу.

Где ответы на 3 вопроса?
Показать
1) типы самолетов, которыми летал Scott Tiger, 1,9,12,13,18,22,28 января 2003 года
2) номера рейсов которые были в январе 2003 года и на которые оставалось от 10 до 20 непроданных билетов включительно, но самолет не "TU 154"
3) пары рейсов, где 10 или более пассажиров общие (летели одни и те же люди)
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=11#2397065

Как проиндексировать поле?
"Покажите пример использования индекса если это несложно. Например по полю "рейс" в ^БИЛЕТЫ(дата,рейс,место)."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=10#2392797

Производительность решений на СКЛ-е в МУМПС-е будем обсуждать или замнем ввиду очевидности резульатата?

Rus000

c127

Я даже не знаю систем, где этот код доступен для обозрения. План запроса можно посмотреть, но это другое.


из того, очевидно, не следует что его нет :)

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

Rus000

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

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

Rus000

Например мне, как Вы выражаетесь, низкоуровневое M-программирование не мешает быстро создавать вполне эффективные и легко сопровождаемые (дистанционно) проекты ...

По-меому это иллюзия, Вы себя обманываете. Посмотрите на решение нашей задачи на СКЛ-е и на М. Сами же говорили: "Безусловно все быглядит куда более понятнее и лаконичнее, ..." https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406684
А компактность в большой степени синоним быстроты разработки и простоты сопровождения. Вы же только что привели решение на МУМПС СКЛ-е, как я понимаю специально чтобы показать что на МУМПС-е тоже можно компактно решить задачу. А теперь заявляете что на М не хуже. Противоречие.

Rus000

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

Вы не смогли бы, кто-то бы смог. Поверьте мне, в РМД решаются очень сложные задачи. Не хотите верить мне - посмотрите сами на соотношение СУБД разных архитектур на рынке.


Rus000

с127

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

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

1:1?

:)

Я что, где-то использовал объектные расширения РСУБД? Или хотя бы упоминал их в положительном смысле? Они ИМХО никому не нужны, ведут к проблемам, реляционные решения удобнее. Вы же постоянно вспоминаете МУМПС СКЛ и даже наваяли на нем решение задачи. Так о каком 1:1 идет речь?

Тем более что объектов в М похоже что нет, т.е. Вы хитрите, пытаясь сравнивать то, чего нет с тем, что есть. А если сравнивать надстройки над М типа кеша, то еще неизвестно что будет быстрее работать, объекты в кеше или объекты в оракле. Хотя еще раз повторяю, в оракле они и даром не нужны.
16 мар 06, 23:34    [2458083]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AndreiNz
Member

Откуда:
Сообщений: 471
c127
Драйвер работает плохо именно потому что написан на перле

А вы абсолютно уверенны, что драйвер был написан на перле? Я что-то не припомню, чтобы в перле были средства для работы с регистрами внешних устройств. С такими средствами даже в более серьезных средах напряженка а тут перл. Конечно, наличие ассемблерных вставок могло бы помочь, да только я и их как-то тоже не припомню, хотя проработал с перлом ровно 2 года немного отвлекаясь на С++. Кроме того, структура драйвера, обычно, достаточно специфична и линкуется по особому, а тут интерпретатор перла..

Кроме того, двигателями в промышленных системах нормальные люди управляют через системы SCADA ну там MOSAIC, iFix, Wonderware и тд. Там все делается через PLC, а в нем перл, обычно не живет.

Нет, я конечно допускаю возможность того, что, какой-нибудь ошалелый студент написал курсовую на тему "Драйвер двигателя под QNX(там перл теоретически должен жить, а сама стимтема является системой реального времени те может управлять двигателем) для процессора М68000(на сколько я помню, этот процессор повторяет архитектуру PDP-11, а там регистры внешених устройств пасположенны в адресном пространстве ОЗУ и у перла есть больше шансов до них добраться). Допускаю, также, что такое мог сделать какой-нибудь ошалелый преподаватель. Но даже при таком расскладе, вероятность подобного события ничтожно мала. А что кто-то делает подобное в коммерческих системах - это уже из области фантастики.

Для меня ваше утверждение звучит также убедительно, как утверждение что драйвер был написан на SQL. И привели вы его чтобы отвлечь внимание и принизить важность высказывания вашего оппонента о том, что они вдвоем автоматизировали порядка сотни проедприятий всего за 2 года.

А что вы сами можете сказать о количестве внедрений на одного человека в год при использовании любой SQL системы?
17 мар 06, 01:28    [2458178]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

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

Автоматизация автоматизации рознь. Но если считать установки 1С (SQL системы) автоматизацие предприятия, то может и сотни. Почему нет? Или может предприятие из одного чела - Вордов таким поставил и типа автоматихзировал таких море. А можно в какм-то отделе установить телефонный справочник и сказать автоматизировал предприятие. Потому о важности высказывания про автоматизацию вдвоем сотни предприятий не реально говорить ни в какой системе.

AndreiNz

А что вы сами можете сказать о количестве внедрений на одного человека в год при использовании любой SQL системы?

Тут упоминались ERP системы. SAP например (SQL система в смысле что там используются РСУБД) способна автоматизировать реальные предприятия. Да все мне известные ERP - SQL системы. А это автоматизация крупных предприятий. Но по любому не менее 90% всех автоматизаций в мире SQL системы. Т.е. ни по качеству ни по количеству сеня говорить не приходится - реляционная эпоха пока еще на дворе.
17 мар 06, 02:08    [2458200]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 17 18 19 20 21 [22] 23 24 25 26 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить