Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 19 20 21 22 23 [24] 25 26 27 28 29   вперед  Ctrl
 Re: Каше vs. Фокс....  [new]
Слон бъет Ц4
Guest
Что упало то пропало ?
18 мар 06, 12:21    [2462946]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

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

Автоматизация автоматизации рознь. Но если считать установки 1С (SQL системы) автоматизацие предприятия, то может и сотни. Почему нет?
Тут упоминались ERP системы. SAP например (SQL система в смысле что там используются РСУБД) способна автоматизировать реальные предприятия. Да все мне известные ERP - SQL системы.


Очевидно AndreiNz имел ввиду опыт с127 в разработке и внедрении промышленных решений
18 мар 06, 16:48    [2463287]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

Вы, vadiminfo, даже читать не умеете. Уже сравнили mumps с pl (без sql) или с pascal (без sql) ?

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

токарь

А sql - приложение, без которого нельзя обойтись в pl или pascal, но для mumps это просто один из прибамбасов.

Без комментариев.

токарь

А пока тока болтаете незнамо о чем.

Боюсь, что на этом форуме для Вас все "незнамо".
Знания Ваши вызывают, по меньшей мере, недоумение
18 мар 06, 16:50    [2463292]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

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

Где ответы на 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


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

c127

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


Еще раз попытаюсь донести. В М-системах существует для долговременного хранения даныы лишь одна структура называемая global. Другими словами это многомерный persistent массив, который может быть визально представлен как дерево.
Для реализации РМД посредством таблиц используется построение деревьев имеющих 1 уровень глубины, например
^TABLE(PRIMARYKEY)=DATA
причем PRIMARYKEY может быть составным для отображения составного ключа, например
^TABLE(ATTR1^ATTR2^ATTR3)=ATTR4^ATTR5^...^ATTRn

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

Индекс по атрибуту ATTR4 ссылающийся на кортеж содержащий остальные данные посредством FK=ATTR1^ATTR2^ATTR3
^TABLEINDEX1(ATTR4)=ATTR1^ATTR2^ATTR3 

Индекс по совокупности атрибутов ATTR4+ATTR6
^TABLEINDEX2(ATTR4^ATTR6)=ATTR1^ATTR2^ATTR3 

если не стараться моделировать в терминах РМД, то аналогичные данные могут быть размещены в иерархической структуре, например

^TABLE(ATTR1,ATTR2,ATTR3)=ATTR4^ATTR5^...^ATTRn

а соответствующие инверсные индексы могут быть
^TABLEINDEX2(ATTR4,ATTR6)=ATTR1^ATTR2^ATTR3 
^TABLEINDEX3(ATTR3,ATTR2,ATTR1)=""
^TABLEINDEX3(ATTR6,ATTR2,ATTR1)=ATTR3


Возвращясь к примеру с билетами:
^БИЛЕТЫ(дата,рейс,место)
^БИЛЕТЫ(рейс,дата,место)
^БИЛЕТЫ(место,дата,рейс)
суть равноправные структуры, с точностью до размещения в одной из них прочих данных, например, имени пассажира. Какой именно индкс использовать зависит от запроса - если на входе известна дата, то выбирается первый, если на входе рейс, то второй, если дата+рейс - первый или второй, если на входе номер места, то третий.

c127

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


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

c127

Rus000

c127

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


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

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


в таком случае некорректно сравнивать M и SQL. Кто-то тут правильно сказал - давайте сравнивать М с диалектами для ХП, это гораздо корректнее.

с127

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


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

c127

Rus000

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

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


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

c127

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


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

c127

Rus000

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

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


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

с127

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


Моя мысль была в том, что современные СУБД как Р- так и О- уже настолько переплелись по фичам, что утратили академическую чистоту. Поэтому hollywar на эту тему имеет мало смысла.
18 мар 06, 16:52    [2463295]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
Если б, vadiminfo, не болтали чушь всякую, а написали бы приложение БД на pl (или на с) без sql, тада может чего и поняли бы. Ни pl, ни c, ни mumps не знаете. То есть полный ноль. Ни одного реального приложения БД не напишите, если знаете тока sql. А на mumps приложения БД пишутся легко безо всяких других языков. Неужто на "этом форуме" все такие специфические. Технологии БД без СУБД. Кашмар.
18 мар 06, 17:11    [2463318]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

Если б, vadiminfo, не болтали чушь всякую, а написали бы приложение БД на pl (или на с) без sql, тада может чего и поняли бы.

Мысль достойная ЧАЛа. Тут пытылись сравнивать Скуль с МУМПСом - а ЧАЛ предлагает сравнивать с Мумпсом другие языки без Скуля, да еще писать это другим. С причинно следственной связью проблемы не говоря уже о знании языков и их проблемных областей.

токарь

Ни pl, ни c, ни mumps не знаете.

О незнании МУМПСа сокрушаться не буду. Мож еще Наири-2 какой-нибудь прикажете изучать?

токарь

То есть полный ноль.

Ну где уж нам од Вас?

токарь

Ни одного реального приложения БД не напишите, если знаете тока sql.

Ну тока у Вас и буду консультироваться что мне лично надо для написания приложений.

токарь

А на mumps приложения БД пишутся легко безо всяких других языков.

Уже умираю от зависти МУМПСистам. Жаль тока 24 страницы ниче не прояснили стоящего.

токарь

Неужто на "этом форуме" все такие специфические.

Как Вы с ЧАЛом? Встречаются.

токарь

Технологии БД без СУБД. Кашмар.

Вы про МУМПС? Пока похоже что так обстоит. Ну ниче лет 40 тому назад тока так и работали. некоторые остались верны тем принципам юности.
18 мар 06, 18:00    [2463402]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
Ага, значит не смог написать приложение БД на pl. И на с тоже не смог. И заскулил про любимого чала и про наири. Пошел от нуля в минус бесконечность.
19 мар 06, 00:12    [2463849]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

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

Ага, значит не смог написать приложение БД на pl. И на с тоже не смог. И заскулил про любимого чала и про наири. Пошел от нуля в минус бесконечность.

Файловые системы писать не собираюсь, для этого есть ЧАЛы.
Про бесконечнось (если вы рюхаете в теории пределов) вам ЧАЛам виднее из далеких семидесятых. Балабановской спичечной фабрике пламенный привет. Кстати такие спецы тока у МУМПСа вроде встречаются - еще один недостаток МУМПСа.

Rus000

Очевидно AndreiNz имел ввиду опыт с127 в разработке и внедрении промышленных решений

Насколько, я помню там речь шла о недрении вдвоем четь ли не сотни приложений. А AndreiNz назвал это чем то важным, типа это довод в пользу МУМПСа.
19 мар 06, 01:23    [2463975]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AndreiNz
Member

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

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

1. Стоимостью подготовки специалистов. Научить работать с MUMPS нормального программиста занимает в среднем около недели. А что у Oracle?

2. Стоимостью поддержки системы. Вы в курсе, сколько платят Oracle DBA? Ни когда не возникал вопрос: "А за что?". Ведь, как кто-то здесь пытался убеждать в SQL все просто и легко. Если все именно так, то мне не понятно зачем люди выбрасывают такие деньги (платят) за такую простую работу. Что-то тут у вас госпада не вяжется.

3. Стоимостью самого продукта (хотя пнризнаюсь, что не сравнивал цены на Oracle и Сache)

4. Стоимостью разработки. Это ведь только из одной таблицы выбоку с помощью select * from mytable легко сделать. В реальной жизни приходится делать всякие там inner и outer jointы, приплетать к ним финкции и пт. А приложения, как правило пишут люди работающие на процедурных языках (Java, C#, Delphi и тд.) для них простой запрос написать не проблема, а вот запросы по серьезней уже отнимают достаточно времени.

Все это вместе взято и определяет понятие Total Cost Of Ownership. простите, не знаю как это по-русски называется.
19 мар 06, 02:17    [2463993]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
CesaTheGuest
Guest
AndreiNz
Так тут люди хотели узнать в чем MUMPS лучше того же oracle. Вот я и пытался подвести вас к мысли. Ну раз уж вы сами к ней не идете, то придется сказать прямо.
Ага, а я как SQL разработчик сделаю коменты.

1. Стоимостью подготовки специалистов. Научить работать с MUMPS нормального программиста занимает в среднем около недели. А что у Oracle?

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

2. Стоимостью поддержки системы. Вы в курсе, сколько платят Oracle DBA? Ни когда не возникал вопрос: "А за что?". Ведь, как кто-то здесь пытался убеждать в SQL все просто и легко. Если все именно так, то мне не понятно зачем люди выбрасывают такие деньги (платят) за такую простую работу. Что-то тут у вас госпада не вяжется.

Вы смешиваете понятия. Oracle DBA не пишет запросы, у него другие функции и стоит он дорого от того что в Oracle вагон с тележкой всяких параметров, и специально покрашенный бубен для подбора их правильного соотношения. И чем бубен цветастее тем больше понтов и как следствие зарплата. В качестве БД можно чего и попроще выбрать, у некоторых вон и затраты на администрирование нулевые. Что до денег, то если бизенс требует Оракла -то деньги на админа как правило найдутся. Это опять же к размеру систем. Так что все вяжется. Кроме того, часто разработчики под Оракл получают меньше чем админы. Есть также админы - разработчики и т.п. включения, мир разнообразен.

3. Стоимостью самого продукта (хотя пнризнаюсь, что не сравнивал цены на Oracle и Сache)

Что Вы доскреблись до цены оракла и до самого оракла. Он и бесплатный есть. Плюс бесплатный VB Express = все бесплатно. Так что тоже не аргумент.

4. Стоимостью разработки. Это ведь только из одной таблицы выбоку с помощью select * from mytable легко сделать. В реальной жизни приходится делать всякие там inner и outer jointы, приплетать к ним финкции и пт. А приложения, как правило пишут люди работающие на процедурных языках (Java, C#, Delphi и тд.) для них простой запрос написать не проблема, а вот запросы по серьезней уже отнимают достаточно времени.

Но это уже и вовсе абзац. Не видел я разработчиков, которые пишут ГУИ к БД, а запросы писать не умеют. Это либо криворукие, либо лисоводы. Может стоить тогда разделить ГУИ и SQL проще сравнивать будет, и насколько я видел проще (короче) это все же SQL. Я так и не смог увидеть задач, где у М чудовищная эффективность хотя бы в плане разработки. Кивание на деревья и графы как-то не выглядит впечатляюще. Хотя с точки зрения Андрея Леонидовича есть такие системы где все решается объектным навигатором и программировать вообще не надо.
19 мар 06, 11:03    [2464116]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AndreiNz
Member

Откуда:
Сообщений: 471
1.

Примеры, ну пожалуйста.

Для того чтобы присвоить переменной A значение 10 в любом процедурном языке достаточно написать что-то типа :
A=10.

В MUMPS это будет:
S A=10

Дак вот, чтоь значение 10 было сохранено на диске под именем A достаточно написать:

S ^A=10

И все...

Если же вам надо присвоить переменной B сохранненое значение, то вы пишите:

S B=^A

Как видете синтаксис для работы с данными на диске НИ ЧЕМ НЕ ОТЛИЧАЕТСЯ от синтаксиса для работы с данными в оперативной памяти.

А теперь, хотелось бы увидеть тоже самое на SQL.

2. Я говорил о стоимости поддержки системы. И мне совсем не видно, чтобы вы мое утверждение опровергли. Навалили в кучу высказывания про другие системы, когда я говорил о том чем MUMPS лучше oracle. Но зато признали, что администрирование Oracle это танец с бубнами. А разве от этого покупателю легче? Кстати, мне слабо верится, что разработчик Oracle - это низкооплачиваемая должность. А вам?

3. Бесплатный Oracle? Что уже дают? А то тут у меня куча клиентов готова очередь занимать на такую халяву. Нет, вы уж пожалуйста уточните, скажем если Министерство какое захочет Oracle бесплатный получить, то куда им обращаться. Да и что такое VB Express? А то у меня Google все Visual Basic Express да Visual Basic Express выдает. Как это к Oracle то относится?

4. Не знаю на чем вы работаете, а я последнее время работаю с Delphi. А терерь представте запрос на два экрана в мониторе в разрешением 1600х1200 с парой дюжин параметров. Так вот пишешь его сначала в Delphi, так как не всегда знаешь какие пераметры в него придут. Ловишь в точке, где они уже подставленны и копируешь все это удовольствие в Toad и там уже начинается нормальная отладка. Только сначала надо убрать все форматирование нужное Delphi и ненужное Toadу. Ну а как отладил - процесс повторяется в обратном порядке. Может вы предложите что-нибудь по-эффективнее?
19 мар 06, 13:38    [2464226]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
У MUMPS не чудовищная эффективность, CesaTheGuest. Это Ваша выдумка. Но очень трудно найти задачу, которая решалась бы в РСУБД эффективнее, чем в СУБД на MUMPS. Никто ни на что не кивает. Вам даже детали объясняют. Я уже говорил об изяществе s a=x и s ^a=x. Теперь это объясняет и AndreiNz. В MUMPS много разных изяществ. Это оригинальная система, которую просто не с чем сравнить. Вам нравится программировать на процедурных (не нужно загибать про SQL !) языках под РСУБД - программируйте на здоровье. Вы же не говорите чем Вас MUMPS разочаровал. Что у Вас не получилось сделать в этой среде - оптимальной для решения информационно-логических задач ? Может Вы не инфологические задачи, а дифуры решаете ? Не знаю, не пробовал - может SQL и эффективнее MUMPS при решении дифуров. Может как-нибудь на досуге сравню.
19 мар 06, 20:59    [2464931]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
Кажись Балабаново хде-то под Москвой - далековато будет за пару тыщ км приветы передавать. И терзает смутное подозрение, а не выгнали случаем vadiminfo с этой спичечной фабрики за профнепригодность, раз он ее все время поминает ? Даже sql не помог.
19 мар 06, 21:38    [2464971]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
токарь и vadiminfo. Может вы свои производственные проблемы где-нибудь в другом месте порешаете ?
19 мар 06, 21:44    [2464974]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Ц4
Guest
Кто на ком лежал, я вас спрашиваю ?
19 мар 06, 21:46    [2464977]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Слон бъет Ц4
Guest
А что упало то пропало ?
19 мар 06, 21:50    [2464981]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Непонимающий...
Guest
Че-то никак не воткнусь... А чо енто мумпсисты замахнулись свое поделие с SQL сравнивать??? Вы для начала COBOL переплюньте, а уж потом пальцы растопыривайте...
(Пы. Сы. А за базар я отвечаю - опыт, однако...)
20 мар 06, 00:17    [2465255]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
токарь
Ни одного реального приложения БД не напишите, если знаете тока sql.

Чушь, у нас в приложении процентов 80 чистого СКЛ-я, вся логика на абосолютно чистом СКЛ-е. Оставшиеся проценты это интерфейс со средним звеном, без них можно было бы обойтись, но решили немного облегчить жизнь разработчикам среднего звена, а то они там на пошарпаном си совсем запарились.


ораклоидальный мампсист
У MUMPS не чудовищная эффективность, CesaTheGuest. Это Ваша выдумка. Но очень трудно найти задачу, которая решалась бы в РСУБД эффективнее, чем в СУБД на MUMPS.

Пока как раз выходит наоборот, противники СКЛ серверов не смогли придумать задачу, которая решалась бы более эффективно размеру кода чем на СКЛ-е. А компактность кода это эффективность работы программиста.

ораклоидальный мампсист
В MUMPS много разных изяществ.

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

ораклоидальный мампсист
Это оригинальная система, которую просто не с чем сравнить.

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

ораклоидальный мампсист
Вам нравится программировать на процедурных (не нужно загибать про SQL !) языках под РСУБД - программируйте на здоровье.

Похоже что как раз МУМПС-истам нравится программировать на процедурных языках. Или Вы хотите сказать что это не процедурный язык:
БРОНИРОВАТЬ(дата,рейс,место,пассажир)
 {
	tstart
	set ^БИЛЕТЫ(дата,рейс,место)=пассажир
	set ^(место,"статус")=1   ;признак "бонирован"
	tcommit
 }
 
 /// На входе дата  номер рейса, и массив данных на нескольких пассажиров со структурой
 /// данные(место)=пассажир
БРОНИРОВАТЬНЕСКОЛЬКО(дата,рейс,данные)
 {
	 for {
		 set место=$ORDER(данные(место))
		 quit:место=""
		 do БРОНИРОВАТЬ(дата,рейс,место,данные(место))
		}
 }
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=10#2389080

Независимо от Вашего мнения, СКЛ не является процедурным языком. Вопреки распространенному среди дилетантов мнению, СКЛ-я почти на все случаи жизни хватает (на определенном классе задач разумеется, но мы ведь говорим только об этом классе), нужно только результаты СКЛ запроса не тянуть в курсор, а использовать в другом СКЛ запросе и все будет очень хорошо. Если кто-то умеет программировать только в процедурном стиле, то это его личные проблемы, но процедурным СКЛ от этого не становистя.
20 мар 06, 00:41    [2465319]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Rus000
Для реализации РМД посредством таблиц...
Единственное замечание: "реализовать" таблицы -- не значит "реализовать" РМД, поскольку в модели данных кроме структурного есть еще как минимум аспект манипуляции и аспект целостности. Кроме того, в MUMPS невозможно реализовать даже и структурный аспект РМД, а именно отношения (которые вы не вполне верно называете таблицами, да бог с ним). Почему? Хотя бы потому, что в РМД отношения строятся на строгих типах (доменах), а в MUMPS вроде типизации не наблюдается в принципе.
20 мар 06, 08:44    [2465591]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
Rus000
Еще раз попытаюсь донести. В М-системах существует для долговременного хранения даныы лишь одна структура называемая global.
^TABLE(PRIMARYKEY)=DATA
причем PRIMARYKEY может быть составным для отображения составного ключа, например
^TABLE(ATTR1^ATTR2^ATTR3)=ATTR4^ATTR5^...^ATTRn
Индекс по атрибуту ATTR4 ссылающийся на кортеж содержащий остальные данные посредством FK=ATTR1^ATTR2^ATTR3
^TABLEINDEX1(ATTR4)=ATTR1^ATTR2^ATTR3 

спасибо, наконец-то реальный пример БД на М !
осталось только добавить что ATTR4^ATTR5^...^ATTRn - это строка знаков через разделитель а ^TABLEINDEX1(ATTR4)=ATTR1^ATTR2^ATTR3 и другие инверсные индексы должны поддерживаться вручную -вот и будет полная картина - есть что сравнивать с РБД - хотя бы с xBase (не говоря уж об оракле)
должен
20 мар 06, 09:39    [2465727]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
c127

........Пока как раз выходит наоборот, противники СКЛ серверов не смогли придумать задачу, которая решалась бы более эффективно размеру кода чем на СКЛ-е. А компактность кода это эффективность работы программиста.

[quot ораклоидальный мампсист]В MUMPS много разных изяществ.

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

ораклоидальный мампсист
Это оригинальная система, которую просто не с чем сравнить.

Это скорее всего потому что ничего решающего аналогичные задачи, кроме МУМПСА, Вы не знаете. Если два инструмента могут решить одну задачу, то их можно сравнить. Например компилятор асемблера с СКЛ сервером сравнить можно. Непонятно почему МУМПС нельзя.
ораклоидальный мампсист


реально работающие М-системы на многих обьектах:
вся бизнес-логика и запросы к базе сидят в ячейках EXCEL-листов
(примерно как его родные формулы)
работает согласованно с родными формулами EXCEL
как единое целое
Хотелось бы сделать нечто подобное без MUMPS
Посоветуйте - что можно применить ?
Притом это действительно важно - без шуток.
есть заангажированные клиенты которым надо именно без MUMPS
Нам по фене на чем - согласны и без MUMPS
Лишь бы продать.
Но на чем еще можно сделать аналогичную систему ?
Может есть примеры ?
(** В ячейку excel больше чем 255 знаков не лезет)
20 мар 06, 09:56    [2465790]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
MX -- ALEX
реально работающие М-системы на многих обьектах:
вся бизнес-логика и запросы к базе сидят в ячейках EXCEL-листов
(примерно как его родные формулы)
работает согласованно с родными формулами EXCEL
как единое целое
Хотелось бы сделать нечто подобное без MUMPS
Посоветуйте - что можно применить ?
Притом это действительно важно - без шуток.
есть заангажированные клиенты которым надо именно без MUMPS
Нам по фене на чем - согласны и без MUMPS
Лишь бы продать.
Но на чем еще можно сделать аналогичную систему ?
Может есть примеры ?
(** В ячейку excel больше чем 255 знаков не лезет)
Вероятно - больше такую систему сделать не на чем. Ну и что? Как говорил один мой знакомый (программист от Бога): Программирование есть поиск языка для решения задачи. Вы себе нашли такой язык для решения всех и всяческих задач, ну так и счастья вам! Что поделились - спасибо. Только чтобы мы могли осознать всю прелесть - будьте так добры, ответьте на конкретные вопросы. Ну ладно, мы, быть может, на разных языках говорим - ну так поясняйте что вы понимете под тем или иным термином, мы же разумные люди - поймём. Вот с127 про индексы всё спрашивает - ну так растолкуйте ему (и мне, и всем) - эти индексы надо руками поддерживать или нет? Если не руками - то как системе сообщить что вот такой-то индекс надо актуализировать при таких-то и таких-то действиях? Чтоб оно потом автоматически поддерживалось?

ЗЫ: специально проверил, мой ёксель жрёт формулы до 1024 символов.
20 мар 06, 10:41    [2465995]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
AndreiNz
Примеры, ну пожалуйста.

Для того чтобы присвоить переменной A значение 10 в любом процедурном языке достаточно написать что-то типа :
A=10.

В MUMPS это будет:
S A=10
А теперь, хотелось бы увидеть тоже самое на SQL.

С данными нужно работать, работа с одной записью никого не интересует.

AndreiNz
4. Не знаю на чем вы работаете, а я последнее время работаю с Delphi. А терерь представте запрос на два экрана в мониторе в разрешением 1600х1200 с парой дюжин параметров. Так вот пишешь его сначала в Delphi, так как не всегда знаешь какие пераметры в него придут. Ловишь в точке, где они уже подставленны и копируешь все это удовольствие в Toad и там уже начинается нормальная отладка. Только сначала надо убрать все форматирование нужное Delphi и ненужное Toadу. Ну а как отладил - процесс повторяется в обратном порядке. Может вы предложите что-нибудь по-эффективнее?

Неправильно значит работаете. Я работаю с Delphi с разрешением 1024х768. Что такое Toad - не знаю. Запросы больше чем в 10 строчек редко пишу. Для SQL отладчик не использую.
Опишите структуры, покажите запросы, напишите что такое Toad и как Вы его используете - тогда можно будет чем-то помочь

MX -- ALEX
** В ячейку excel больше чем 255 знаков не лезет)

Якобы негр из африки приехал на заработки в Россию, через полгода возвращается. Его друзья спрашивают почему так рано. Он отвечает: "Когда я приехал была зима, жутко холодно. Но когда она была зелёной я еще терпел, а вот когда она стала белой - пришлось уезжать".
Надеюсь намёк понятен. Т.е. до этой фразы я еще относился к МУПСу и разработчикам на нём с пониманием.

Ну причем здесь ексель с его ограничениями? Зачем вообще писать запросы в ячейках? А если запрос поменялся - у всех клиентов менять файл? А если люди туда уже кучу полезного позаносили?

Ну и маленький Вам ликбез по екселю:
Найдите раздел "Технические характеристики и ограничения Microsoft Excel". Там в табличке найдите строчку:
Длина записи для содержимого ячеек (текст): 32767 знаков. В ячейке отображаются только 1024 знака; все 32767 знаков отображаются в строке формул.

Пишите на экселе и ни в чем себе не отказывайте!
20 мар 06, 11:12    [2466186]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Павел Воронцов
(** В ячейку excel больше чем 255 знаков не лезет)Вероятно - больше такую систему сделать не на чем. Ну и что? Как говорил один мой знакомый (программист от Бога): Программирование есть поиск языка для решения задачи. Вы себе нашли такой язык для решения всех и всяческих задач, ну так и счастья вам! Что поделились - спасибо. Только чтобы мы могли осознать всю прелесть - будьте так добры, ответьте на конкретные вопросы. Ну ладно, мы, быть может, на разных языках говорим - ну так поясняйте что вы понимете под тем или иным термином, мы же разумные люди - поймём. Вот с127 про индексы всё спрашивает - ну так растолкуйте ему (и мне, и всем) - эти индексы надо руками поддерживать или нет? Если не руками - то как системе сообщить что вот такой-то индекс надо актуализировать при таких-то и таких-то действиях? Чтоб оно потом автоматически поддерживалось?

ЗЫ: специально проверил, мой ёксель жрёт формулы до 1024 символов.


если 1024 - то не даст потом скопировать книгу - сначала обрежет до 255
с предупреждением.

индексы руками поддерживать не надо
мы работаем с системами - надстройками над MUMPS
которые сами разбираются с индексами и со всем прочим
пример - система qWORD производства СП-АРМ (Санкт-Петербург)
или наш MX (который сидит в клетках excel)
там везде встроенные генераторы отчетов, ввода, интерфейса, запросов.

Но если сам создаешь специализированую СУБД - то надо лезть в индексы.

Рядовому M-программисту - только изредка .
Как правило, разработчики сидят на готовом инструменте-надстройке над М.
За счет этого быстро делают прикладные задачи.
20 мар 06, 11:29    [2466289]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
SergSuper
AndreiNz
Примеры, ну пожалуйста.

Для того чтобы присвоить переменной A значение 10 в любом процедурном языке достаточно написать что-то типа :
A=10.

В MUMPS это будет:
S A=10
А теперь, хотелось бы увидеть тоже самое на SQL.

С данными нужно работать, работа с одной записью никого не интересует.

AndreiNz
4. Не знаю на чем вы работаете, а я последнее время работаю с Delphi. А терерь представте запрос на два экрана в мониторе в разрешением 1600х1200 с парой дюжин параметров. Так вот пишешь его сначала в Delphi, так как не всегда знаешь какие пераметры в него придут. Ловишь в точке, где они уже подставленны и копируешь все это удовольствие в Toad и там уже начинается нормальная отладка. Только сначала надо убрать все форматирование нужное Delphi и ненужное Toadу. Ну а как отладил - процесс повторяется в обратном порядке. Может вы предложите что-нибудь по-эффективнее?

Неправильно значит работаете. Я работаю с Delphi с разрешением 1024х768. Что такое Toad - не знаю. Запросы больше чем в 10 строчек редко пишу. Для SQL отладчик не использую.
Опишите структуры, покажите запросы, напишите что такое Toad и как Вы его используете - тогда можно будет чем-то помочь

MX -- ALEX
** В ячейку excel больше чем 255 знаков не лезет)

Якобы негр из африки приехал на заработки в Россию, через полгода возвращается. Его друзья спрашивают почему так рано. Он отвечает: "Когда я приехал была зима, жутко холодно. Но когда она была зелёной я еще терпел, а вот когда она стала белой - пришлось уезжать".
Надеюсь намёк понятен. Т.е. до этой фразы я еще относился к МУПСу и разработчикам на нём с пониманием.

Ну причем здесь ексель с его ограничениями? Зачем вообще писать запросы в ячейках? А если запрос поменялся - у всех клиентов менять файл? А если люди туда уже кучу полезного позаносили?

Ну и маленький Вам ликбез по екселю:
Найдите раздел "Технические характеристики и ограничения Microsoft Excel". Там в табличке найдите строчку:
Длина записи для содержимого ячеек (текст): 32767 знаков. В ячейке отображаются только 1024 знака; все 32767 знаков отображаются в строке формул.

Пишите на экселе и ни в чем себе не отказывайте!


попробовать бы не мешало - прежде чем поучать ..

и вообще - "если я этого не понимаю - это не правильно .."

танкисты..
20 мар 06, 11:45    [2466377]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 19 20 21 22 23 [24] 25 26 27 28 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить