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

Откуда:
Сообщений: 3652
MX -- ALEX
если 1024 - то не даст потом скопировать книгу - сначала обрежет до 255
с предупреждением.

ЧАВО???
Кто обрежет?
Кому обрежет?
При каком копировании???
Почему не даст?
Бред сивой кобылы какой-то

Нормально в эксель вставляются формулы длиной больше 255.
[переходы на личность удалены модератором]
20 мар 06, 11:59    [2466462]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Rus000
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

Чего Вы хотите добиться этим вопросом?

Я хочу увидеть удобнее ли МУМПС чем СКЛ сервер. Если я увижу, что он действительно настолько удобнее, как об этом говорят, то я постараюсь переключиться на него.

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

Rus000
Решение на чистом М я Вам показывал ранее.

Там не было ответа на третий вопрос, но это не важно.


Rus000

В решении с классами решение тоже несложное - на кашовом скл. Честно сказать лениво писать, но если настаиваете - сделаю.

Я не настаиваю, дело Ваше. Но если Вы сказали, что СКЛ в МУМПС-е не хуже, то продемонстрируйте это хоть как-то. Или не говорите.

Rus000

Еще раз попытаюсь донести. В М-системах существует для долговременного хранения даныы лишь одна структура называемая global.

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

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

Rus000

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

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

Предлагаю закончить дискуссию об индексах в М на том, что их там нет. Исключение, как я понял, это индексирование множества (или списка) детей данной вершины:
^TABLE(PRIMARYKEY)=DATA
А детей разных вершин одного уровня в один общий индекс, который поддерживается системой, положить невозможно.

Rus000

c127

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

а очевидность результата кому очевиден? кто-то уже что-то доказал?

МУМПС-истам же и очевидна:
MX -- ALEX> хотя согласен - ORAKLE в целом покруче смотрится
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=15#2420195
Не доказательство, конечно, но все-таки. Причем речь даже не об СКЛ, а о более "родном" для М систем решении. СКЛ будет смотреться еще более жалко, он же еще дальше от М, к тому же с глобалями ему работать неудобно.

Rus000

ну давайте пообсуждаем - для этого же этот форум :)

Никаких проблем, есть задача Эйнштейна, есть решение на СКЛ-е, предложенное SergSuper-ом.
https://www.sql.ru/forum/actualthread.aspx?bid=1&tid=5836#26828
Вы утверждаете, что СКЛ в МУМПСЕ не сильно хуже, поэтому адаптировать данный СКЛ код для МУМПС-а не представляет труда. Прогоните ИМЕННО ЭТОТ тест на МУМПС-е и поделитесь результатами.

Rus000

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

Сравнивать можно все что угодно со всем чем угодно, если оно решает аналогичные задачи.

Но если хотите, то назовите предложенный СКЛ код диалектами ХП, он там тоже сработает примерно с тем же результатом. Теперь можно сравнивать?

Rus000

с127

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

Вы не правы, говоря что выберете решение приемлемое для Вас.

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

Rus000

c127

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

Компактно написанная не означает более эффективная - вопрос какой критерий выбрать.

Да какое мне дело до эффективности, если решение удовлетворяет требованиям заказчика по эффективности. Ну предположим заказчик хочет время отклика не более чем в 1 секунду, а у меня есть одно решение с 0.001 сек, а другое с 0.1 сек. Если это позволит мне сэкономить месяц работы из полугода, то я выберу второе.




Rus000

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

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

Иначе это демагогия и Вы всегда выбираете что-то одно, я подозреваю М-систему.





Rus000

c127

Rus000

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

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

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

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

Rus000

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

Да нету там никакой "О". Типы расширили, так это не противоречит первоначальной концепции. C# и джава объекты можно хранить в базе, так я и раньше их мог хранить в блобах в случае надобности. Сильно подозреваю что там они и хранятся, только интерфейс появился. Поделка с объектами ни на что не повлияла, болтается сбоку, никому не мешает. А СКЛ стал больше похож на теоретический идеал, но к объектам это никакого отношения не имеет.

Rus000
Поэтому hollywar на эту тему имеет мало смысла.

Ну причем тут войны. Приходят люди, утверждают что работают со страшно удобной системой, предлагают срочно всем переходить на нее. На совершенно естественную просьбу привести примеры удобства начинают почему-то говорить о каких-то hollywar. Да не может быть никаких hollywar хотя бы потому что воевать особенно не с кем, весовая категория слишком разная. Есть попытки разобраться.
20 мар 06, 12:05    [2466506]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Павел Воронцов
Если не руками - то как системе сообщить что вот такой-то индекс надо актуализировать при таких-то и таких-то действиях? Чтоб оно потом автоматически поддерживалось?

С этим как раз понятно, они просто пишут запрос, то бишь код, с использованием того дерева, которое им больше подходит.
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406070
Они же (деревья) равноправные, а код все равно оптимизируется руками.

Павел Воронцов

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

По-видимому это требование заказчика, 255 символов. ТЗ такое. Можно еще потребовать чтобы СУБД марш Мендельсона играла на каждое третье нажатие клавиши, мало ли что прийдет заказчику в голову. А в клиент-сервере третье нажатие клавиши отловить - ну никак.

Тут тоже один анекдот вспомнился о технических требованиях и трудностях.
Идет красавица Мери по ранчо, жара, солнце, видит ковбой Билл в противогазе и костюме химзащиты рубит дрова.
Красавица Мери: Билл, что ты делаешь?
Билл (приглушенно из противогаза): рублю дрова, не видно разве.
Красавица Мери: а почему в костюме химзащиты и противогазе?
Билл: я преодолеваю трудности.
Красавица Мери: а нахрена трудности, Билл, давай лучше займемся сексом.
Билл: Ок. Только стоя и в гамаке.
20 мар 06, 12:36    [2466661]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX - ALEX
Guest
c127
Павел Воронцов
Если не руками - то как системе сообщить что вот такой-то индекс надо актуализировать при таких-то и таких-то действиях? Чтоб оно потом автоматически поддерживалось?

С этим как раз понятно, они просто пишут запрос, то бишь код, с использованием того дерева, которое им больше подходит.
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406070
Они же (деревья) равноправные, а код все равно оптимизируется руками.

Павел Воронцов

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

По-видимому это требование заказчика, 255 символов. ТЗ такое. Можно еще потребовать чтобы СУБД марш Мендельсона играла на каждое третье нажатие клавиши, мало ли что прийдет заказчику в голову. А в клиент-сервере третье нажатие клавиши отловить - ну никак.

Тут тоже один анекдот вспомнился о технических требованиях и трудностях.
Идет красавица Мери по ранчо, жара, солнце, видит ковбой Билл в противогазе и костюме химзащиты рубит дрова.
Красавица Мери: Билл, что ты делаешь?
Билл (приглушенно из противогаза): рублю дрова, не видно разве.
Красавица Мери: а почему в костюме химзащиты и противогазе?
Билл: я преодолеваю трудности.
Красавица Мери: а нахрена трудности, Билл, давай лучше займемся сексом.
Билл: Ок. Только стоя и в гамаке.

за это время что писали про негров и мери
можно было 9 раз убедится что ячейки excel длиннее 255 символов
не переносятся целиком в другую книгу при копировании листа
например excel-97

негру легче втолковать
20 мар 06, 13:06    [2466839]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

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

за это время что писали про негров и мери
можно было 9 раз убедится что ячейки excel длиннее 255 символов
не переносятся целиком в другую книгу при копировании листа
например excel-97

Ну вообще-то Вами было написано:
вся бизнес-логика и запросы к базе сидят в ячейках EXCEL-листов
(примерно как его родные формулы)
...
(** В ячейку excel больше чем 255 знаков не лезет)

Про перенос книги ни слова. Ну с последним пунктом разобрались. Но всё это вызывает вопросы:
- зачем их копи-пастингом переносить?
- почему нельзя хранить в ячейках вызовы хранимых процедур?
- почему бы (если предыдущий пункт не реализовать) не хранить запрос в базе, а в ячейке хранить идентификатор запроса?
- как быть если запрос поменялся и надо всем изменить EXCEL-листы?
20 мар 06, 14:10    [2467247]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
MX - ALEX
за это время что писали про негров и мери
можно было 9 раз убедится что ячейки excel длиннее 255 символов
не переносятся целиком в другую книгу при копировании листа
например excel-97

А может на календарь посмотреть, да от 97-го экселя избавиться?
В старших версиях все великолепно переносится.
В чем тоже можно было 9 раз убедиться.
20 мар 06, 14:17    [2467298]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Пьяный Лох
MX - ALEX
за это время что писали про негров и мери
можно было 9 раз убедится что ячейки excel длиннее 255 символов
не переносятся целиком в другую книгу при копировании листа
например excel-97

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

совместимость приходится поддерживать
много пользователей - в т ч с лицензионным excel-97
не все великолепно и в старших версиях
иногда теряет хвосты сверх 255 - видимо глюки есть в 2000-ом excel
20 мар 06, 14:26    [2467363]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
MX - ALEX
за это время что писали про негров и мери
можно было 9 раз убедится что ячейки excel длиннее 255 символов
не переносятся целиком в другую книгу при копировании листа
например excel-97

негру легче втолковать
Мда. Даже копи-паст виндовый использовать по уму не умеете. Печальная картина...
20 мар 06, 14:42    [2467471]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
SergSuper
MX - ALEX

за это время что писали про негров и мери
можно было 9 раз убедится что ячейки excel длиннее 255 символов
не переносятся целиком в другую книгу при копировании листа
например excel-97

Ну вообще-то Вами было написано:
вся бизнес-логика и запросы к базе сидят в ячейках EXCEL-листов
(примерно как его родные формулы)
...
(** В ячейку excel больше чем 255 знаков не лезет)

Про перенос книги ни слова. Ну с последним пунктом разобрались. Но всё это вызывает вопросы:
- зачем их копи-пастингом переносить?
- почему нельзя хранить в ячейках вызовы хранимых процедур?
- почему бы (если предыдущий пункт не реализовать) не хранить запрос в базе, а в ячейке хранить идентификатор запроса?
- как быть если запрос поменялся и надо всем изменить EXCEL-листы?


- копи-пастингом
потому что из за ошибки в excel-2000 копирование целого
листа проходит только N раз за сессию -затем excel ломается
N зависит от памяти

- почему нельзя хранить в ячейках вызовы хранимых процедур?
а кто будет писать-сохранять ?
система работает аналогично excel и запросы пишет не всегда программист
а часто простой инженер или бухгалтер
(также как и в "чистом" excel)
и он должен видеть все дела сам лично в ячейках
плюс ко всему море хранимок потребует администрирования-учета
но система не рассчинана на полноценное админовское обслуживание.
(хотя процедуры тоже применяются иногда - например включить генератор отчетов и создать отчеты по заданным параметрам.)

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

Откуда:
Сообщений: 3652
MX -- ALEX
- копи-пастингом
потому что из за ошибки в excel-2000 копирование целого
листа проходит только N раз за сессию -затем excel ломается
N зависит от памяти

Ниче не понимаю... Если уж у вас от копи-паста ломается эксель, то зачем вы копи-пастом переносите? Чтоб сломалось?
Кстати сказать, у меня вроде как ничего не ломается.
Полмиллиона копипастов эксель нормально съел, и продолжает кушать дальше. Так что это...
20 мар 06, 15:14    [2467676]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Пьяный Лох
MX -- ALEX
- копи-пастингом
потому что из за ошибки в excel-2000 копирование целого
листа проходит только N раз за сессию -затем excel ломается
N зависит от памяти

Ниче не понимаю... Если уж у вас от копи-паста ломается эксель, то зачем вы копи-пастом переносите? Чтоб сломалось?
Кстати сказать, у меня вроде как ничего не ломается.
Полмиллиона копипастов эксель нормально съел, и продолжает кушать дальше. Так что это...

копипаст всех ячеек листа копирует-пастирует нормально
при этом настройки печати не переносятся

ломает когда копируем целым листом (с настройками печати)

обычно работаем копипастом ячеек и без проблем

но иногда приходится листом чтоб сохранить настройки печати
(например альбомная-портретная)
после 200-300 документов надо перезагружать excel
20 мар 06, 15:25    [2467765]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 MX -- ALEX
Я правильно понимаю, что:
- в 97-м экселе посредством "формул" забита какая-то логика работы с БД (MUMPS)
- зачем-то надо копировать листы
- копировать целыми листами вы не можете, потому что ломается 97-й эксель
- перейти на другую версию экселя вы не хотите
- копировать по-ячейкам вы не тоже хотите, потому что при этом не копируются настройки печати
- копировать отдельно настройки печати вы опять не хотите
- однако копировать вам надо
- и еще при копировании у вас обрезаются те самые формулы в ячейках (длиннее 255 символов), в которые зашита логика. этого обрезания не происходит в старших версиях экселя, но на старшие версии вы опять таки не хотите переходить
???

И теперь вы задаете вопрос "на чем еще можно сделать аналогичную систему"???
упалпацтул...

а оно нужно, делать аналогичную систему???

З.Ы. И собственно при чем здесь мумпс? Из экселя что, к другим БД нельзя обращаться?
20 мар 06, 16:00    [2467975]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Пьяный Лох
2 MX -- ALEX
Я правильно понимаю, что:
- в 97-м экселе посредством "формул" забита какая-то логика работы с БД (MUMPS)
- зачем-то надо копировать листы
- копировать целыми листами вы не можете, потому что ломается 97-й эксель
- перейти на другую версию экселя вы не хотите
- копировать по-ячейкам вы не тоже хотите, потому что при этом не копируются настройки печати
- копировать отдельно настройки печати вы опять не хотите
- однако копировать вам надо
- и еще при копировании у вас обрезаются те самые формулы в ячейках (длиннее 255 символов), в которые зашита логика. этого обрезания не происходит в старших версиях экселя, но на старшие версии вы опять таки не хотите переходить
???

И теперь вы задаете вопрос "на чем еще можно сделать аналогичную систему"???
упалпацтул...

а оно нужно, делать аналогичную систему???

З.Ы. И собственно при чем здесь мумпс? Из экселя что, к другим БД нельзя обращаться?

обращайтесь :)
20 мар 06, 16:28    [2468192]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
MX -- ALEX
Из экселя что, к другим БД нельзя обращаться
обращайтесь :)

обратились уже ...
и результат лучше и проблем меньше
20 мар 06, 17:55    [2468709]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Красиво излагает SergSuper: "с данными нужно работать, работа с одной записью никого не интересует". И это не правда, но особенно впечатляет широко распространенная у чистых (приходится так говорить, чтоб не нести ответственность - я ведь тоже РСУБД-шник) РСУБД-шников ложь

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

Выкинул аж 6 предложений. Ну хорошо, не понял о чем речь, но врать-то зачем ? Помню как один знакомый физик сказал про другого физика, совершившего нехороший поступок: "Надо же, а ведь он песни у костра под гитару пел." Вот и тут приходится говорить: "Надо же, а ведь он задачу Эйнштейна решал."
20 мар 06, 19:59    [2469213]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Хитрый (оптимистическая оценка - просто хитрый) с127 говорит, что хочет разобраться, а сам игнорирует и перевирает любые объяснения. Сказали про несколько изяществ (прозрачная работа с локальными и глобальными переменными, прямой доступ к данным и индексам наряду с автоматическим, разнообразие типов индексов), а он за свое: "продемонстрируйте изящества".
В любой СУБД на MUMPS "индексы" поддерживаются автоматически (причем их типы разнообразнее, чем в РСУБД), но к ним, в отличие от РСУБД, имеется естественный прямой доступ, как и к "данным". А с127 твердит о "факте отсутствия индексов в М." Демонстрирует невежество даже в отношении РСУБД, утверждая, что в РСУБД "называют индексами не то, что называют МУМПС-исты." В Oracle индексами называют ровно то, что и в любой СУБД на MUMPS. Это я знаю точно. Может быть Oracle стоит особняком от других РСУБД, и в этих других индексами называют что-то другое ?
Зачем то упомянул "задачу Эйнштейна". Если с127 хочет перейти на MUMPS только если это будет SQL, тогда можно прекратить дискуссию и об индексах, и обо всем остальном. SQL - не существенное приложение к MUMPS. Если больше нравятся оптимизированные (!) 7 секунд против "не оптимизированных" 0.07, то красиво жить не запретишь.
Про критерии хорошо сказано. Логично. У меня они такие: скорость разработки, производительность решения, наглядность решения и простота доступа к данным, простота сопровождения и развития системы. И если бы решение принимал я сам, а не руководство, то пока, как я уже говорил, не приходилось сталкиваться с задачами, для которых РСУБД по указанным критериям превосходили бы СУБД на MUMPS. Но жизнь есть жизнь - сижу и программирую на PL/SQL.
Ранок не "полон М системами." Но многие разработчики "М систем" известны - обычно это партнеры Intersystems. Вы можете обратиться к ним не просто за статистикой, а за самой конкретикой. Не думаю, что пошлют. Хотя не уверен.
Люди не приходят и не утверждают, что "работают со страшно удобной системой" и не предлагают "срочно всем переходить на нее." Зачем же передергивать ? Если "есть попытки разобраться", то сказали бы что конкретно не получилось при инсталляции MUMPS. Какое было сообщение ? Чего тут стесняться-то ?
20 мар 06, 20:29    [2469276]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Постепенно перешли от БД к Excel. Оказывается без Excel ничего не получается ни у мампсистов, ни у скулистов. А мод даже успел сделать сравнительный анализ, и определил где Excel лучше !
20 мар 06, 20:32    [2469282]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
MX -- ALEX

реально работающие М-системы на многих обьектах:
вся бизнес-логика и запросы к базе сидят в ячейках EXCEL-листов
(примерно как его родные формулы)
работает согласованно с родными формулами EXCEL
как единое целое
Хотелось бы сделать нечто подобное без MUMPS

Объясните сначала, что они там делают, кроме того, что "сидят". Зачем они там вообще нужны?

MX -- ALEX

Посоветуйте - что можно применить ?
Притом это действительно важно - без шуток.

Первое что приходит в голову это посадить туда же СКЛ запросы или вызовы сохраненок, но об этом Вам уже сказали. Принципиальной разницы никакой, тот СКЛ запрос который мы тут обсуждали длиннее аналогичного М запроса аж на 2 символа, это не принципиально.

MX -- ALEX

есть заангажированные клиенты которым надо именно без MUMPS
Нам по фене на чем - согласны и без MUMPS
Лишь бы продать.
Но на чем еще можно сделать аналогичную систему ?

Объясните что делает система такого, что формулы нужно непременно складывать в ячейки ексела, почему было принято это решение, может были какие-то дополнительные условия, требовавшие именно такой архитектуры? Не проще ли было написать несложный редактор запросов, запросы хранить в базе, а в екселе показывать только данные?
20 мар 06, 23:20    [2469592]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
MX - ALEX

за это время что писали про негров и мери
можно было 9 раз убедится что ячейки excel длиннее 255 символов
не переносятся целиком в другую книгу при копировании листа

Нельзя, нет у меня екселя и надеюсь никогда не будет.






ораклоидальный мампсист
Хитрый (оптимистическая оценка - просто хитрый) с127 говорит, что хочет разобраться, а сам игнорирует и перевирает любые объяснения. Сказали про несколько изяществ (прозрачная работа с локальными и глобальными переменными,

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

ораклоидальный мампсист

прямой доступ к данным и индексам наряду с автоматическим,

Доступ к индексу это доступ к тому, чего нет. Разумеется он прямой. Или есть индексы? Или нет? Сами разберитесь сначала.

ораклоидальный мампсист

разнообразие типов индексов),

Ну так перечислите хоть парочку из разнообразия.


ораклоидальный мампсист

В любой СУБД на MUMPS "индексы" поддерживаются автоматически (причем их типы разнообразнее, чем в РСУБД), но к ним, в отличие от РСУБД, имеется естественный прямой доступ, как и к "данным". А с127 твердит о "факте отсутствия индексов в М."

Читаем этот кусок внимательно. Сначала: "В любой СУБД на MUMPS ..." Потом: "отсутствия индексов в М". МУМПС == М? Читать научитесь сначала, хотя бы себя, потом будете поучать других.

ораклоидальный мампсист

Демонстрирует невежество даже в отношении РСУБД, утверждая, что в РСУБД "называют индексами не то, что называют МУМПС-исты." В Oracle индексами называют ровно то, что и в любой СУБД на MUMPS.

И опять читаем внимательно:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=25#2466506
c127>Но Ваши коллеги по М почему-то не могут принять факт отсутсвия индексов в М, хотя сами об этом постоянно говорят. Данные это не индексы, а индексы это с точки знения программиста не данные. В идеале программист о них помнит только тогда, когда определяет, во время работы БД он о них помнить не должен, как они заполняются и поддерживаются - не его проблема.

Где Вы тут увидели МУМПС, ткните пальцем.

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


ораклоидальный мампсист

Это я знаю точно.

Не льстите себе, ничего Вы не знаете, щеки раздуваете и все.

ораклоидальный мампсист

Зачем то упомянул "задачу Эйнштейна". Если с127 хочет перейти на MUMPS только если это будет SQL, тогда можно прекратить дискуссию и об индексах, и обо всем остальном. SQL - не существенное приложение к MUMPS.

И опять читаем внимательно.

c127> Производительность решений на СКЛ-е в МУМПС-е будем обсуждать или замнем ввиду очевидности резульатата?
Rus000> ну давайте пообсуждаем - для этого же этот форум :)


Речь с подачи Rus000 ( https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=22#2457525 ) идет именно об СКЛ-е в МУМПС-е и ни о чем другом.

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

ораклоидальный мампсист

Про критерии хорошо сказано. Логично. У меня они такие: скорость разработки, производительность решения, наглядность решения и простота доступа к данным, простота сопровождения и развития системы.

Да, вот это критерии, сразу виден специалист. Ни секунды не сомневаюсь что именно по этим критериям Вы принимаете решения. По этим "критериям" фокспро от оракла ничем не отличается, и оба вместе не отличаются от екселя.

Вы вообще знаете что такое критерий? Чтоб получить критерий недостаточно просто брякнуть что-то наукообразное от фонаря.

ораклоидальный мампсист

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

Кто на ком стоял? "Если бы решение Я сам, а не начальство, то РСУБД не встречал, а если бы начальство, а не Я, то встречал, но не РСУБД." Хотя конечно критерии... Тут и не такое может случиться.
21 мар 06, 00:13    [2469688]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AndreiNz
Member

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

Чушь, у нас в приложении процентов 80 чистого СКЛ-я, вся логика на абосолютно чистом СКЛ-е.


А вы обсолютно уверенны, что там чистый SQL а не TSQL, PL/SQL etc. Как говорят в Одессе это две большие разницы.

c127

Оставшиеся проценты это интерфейс со средним звеном, без них можно было бы обойтись, но решили немного облегчить жизнь разработчикам среднего звена, а то они там на пошарпаном си совсем запарились.


Очень интересная мысль... Тоесть среднее звено вам совсем не нужно если без интерфейса с ним можно было обойтись. Ну а так вы с широкого плеча им (шарпщикам) работки подкинули, чтобы они не голодали. Хотя нет, они ведь уже запарились, а вы им еще работки, но это, почему-то называется облегчить жизнь. Странная, однако у вас логика.

c127

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


Еще одна выдающаяся мысль. Кто-то, где-то давно пытался оценивать производительность программиста, исходя из размера кода, который он пишет. НО в той системе считалось чем больше, тем лучше. Вы же предлагаете использовать ту-же систему с точнастью до наоборот. Вам, что зарплату платят за ненаписанный код? Открою вам великую тайну - эффективность это экономическая категория, которая определяется отношением прибыли к затратам. Дак вот затраты - это ваша зарплата, за то время, которое вы потратили на создание того или иного продукта (если говорить о вашей эффективности) а отнюдь не строчки, которые вы написали и даже не время, которое потратили.

Но если вас так умиляет краткость, то пожалуйста:

S ^A=10
в MUMPS

будет выглядеть примерно так

CTRATE TABLE T1(A int)
INSERT INTO T1(10) VALUES(10)

Что-то я краткости SQL в данном случае не вижу
21 мар 06, 04:11    [2469750]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Ай яй яй - опять эффективность продукта по кол-ву буковок считаем.

автор
S ^A=10
в MUMPS

будет выглядеть примерно так

CTRATE TABLE T1(A int)
INSERT INTO T1(10) VALUES(10)

а вот интересно, как на MUMPS будет выглядеть:
CREATE TABLE T1(A int)
COMMIT

INSERT INTO T1(A) VALUES(10)
COMMIT

UPDATE T1 SET A = A + 1 WHERE A = 10
ROLLBACK

DELETE FROM T1 WHERE A = 10
COMMIT
P.S. Ваши ошибки в приведенном Вами SQL скрипте спишем на досадные опечатки.
21 мар 06, 06:32    [2469796]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
с127 лабает приложения на чистом sql. Угу. Допустим нада лишние пробелы из строки убрать. Универсалка от Sergo Gromov на mumps убирает символ sim в начале, в конце и дубликаты в середине строки p

S(p,sim)
n p1,l,n s p1=p,p="",l=0
f n=1:1:$l(p1,sim) i $p(p1,sim,n)'="" s l=l+1,$p(p,sim,l)=$p(p1,sim,n)
q p

Таперича шоб убрать лишние пробелы из str пишем s str=$$S(str," ").
Давай дружище-врунище делай аналог на чистом sql. Случай чего SergSuper поможет, он теорию относительности на sql сделал. Тада посмотрим хто из нас чушь гаварит.
21 мар 06, 08:48    [2469975]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
Эффективность продукта по кол-ву буковок считает с127. Вот Вы с ним на пару и удаляйте лишние пробелы из строки. Тока не забудьте вовремя сделать commit и rollback.
21 мар 06, 08:56    [2469989]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
c127
MX -- ALEX

реально работающие М-системы на многих обьектах:
вся бизнес-логика и запросы к базе сидят в ячейках EXCEL-листов
(примерно как его родные формулы)
работает согласованно с родными формулами EXCEL
как единое целое
Хотелось бы сделать нечто подобное без MUMPS

Объясните сначала, что они там делают, кроме того, что "сидят". Зачем они там вообще нужны?

MX -- ALEX

Посоветуйте - что можно применить ?
Притом это действительно важно - без шуток.

Первое что приходит в голову это посадить туда же СКЛ запросы или вызовы сохраненок, но об этом Вам уже сказали. Принципиальной разницы никакой, тот СКЛ запрос который мы тут обсуждали длиннее аналогичного М запроса аж на 2 символа, это не принципиально.

MX -- ALEX

есть заангажированные клиенты которым надо именно без MUMPS
Нам по фене на чем - согласны и без MUMPS
Лишь бы продать.
Но на чем еще можно сделать аналогичную систему ?

Объясните что делает система такого, что формулы нужно непременно складывать в ячейки ексела, почему было принято это решение, может были какие-то дополнительные условия, требовавшие именно такой архитектуры? Не проще ли было написать несложный редактор запросов, запросы хранить в базе, а в екселе показывать только данные?


Вы сказали что у Вас нет EXCEL и никогда не будет

А вообще Вы где-нибудь его видели ?
21 мар 06, 09:37    [2470077]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
токарь
Эффективность продукта по кол-ву буковок считает с127. Вот Вы с ним на пару и удаляйте лишние пробелы из строки. Тока не забудьте вовремя сделать commit и rollback.

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