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

конечно Вам, как начальнику, виднее

но все же хотелось поговорить бы с бывшим м-программистом
- Вашим непосредсвенным исполнителем

нельзя ?


1. Начнем с того что я не начальник.
2. То что вы с ними хотите поговорить не означает что они хотят общаться с вами.
.................


а че обиделись что ли ?
я ж тока спросил ?

кстати в чем-то я с Вами согласен
например мало доки, арифметика непривычная.
но - много ли у нас арифметики ?

а по скорости не согласен
- например тест на запись 1000 000 узлов
в cache идет за 2 секунды
уж не знаю как - но что то там оптимизировано

лицензии мы купили 40 штук cache 5.1 по 120 USD штука
(правда - со скидкой)
может дорого может нет
но уж очень M нам нравится - простой понятный и быстрый
для заводов - самое то.
наши программисты работают на многих языках
но М-хвалят все и на нем 90 % всего сделано на заводе

Я - не начальник тоже
========================
23 мар 06, 09:01    [2479287]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
ораклоидальный мампсист
О чем договариваться, Выбегалло ? Я же не ребенок. Зачем я буду называть ручные блокировки автоматическими ? Ручные блокировки иногда нужны, но автоматические обязаны быть. Так же как и индексы. Конечно автоматические, но одно удовольствие, когда ты можешь прочитать из индекса так же естественно, как из данных.


Я только не понимаю, зачем читать из индекса. В РСУБД внутре думатель, он сам решает, использовать ли сырые данные или в индексе уже все есть что запрашивали - программисту не нужно совершать этих нелепых телодвижений. Кстати, как насчет hash- joinов - их есть в кэше, или кроме циклов в цикле других методов соединения таблиц не предусмотрено ?
23 мар 06, 21:42    [2483801]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Похоже "убогость" это с127 или vadiminfo - оба на "чалах" помешались. Очень похоже на "растраение". И уже не впервый раз в топике знакомые слова о файлах !
Я могу прочитать данные из "индекса"
^индексы(ид.свойства,значение свойства,ид.сущности)=""
так же естественно как и из "данных"
^сущность(ид.сущности,ид.свойства)=значение свойства
В Oracle, к сожалению, это невозможно. Но убогость на то и убогость, чтобы в очередной раз все свести к началу файла.
23 мар 06, 22:11    [2483863]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Ничего удивительного, Выбегалло, что не понимаете - я тоже не понимал, пока не попробовал. Нужно попробовать, иначе трудно понять. Я уже говорил, что не встречал вживую программистов, которые писали бы напрямую на глобалях. И не встречал таких, кто предпочитал бы SQL в MUMPS. Все, кого я знаю, используют какие-либо инструменты. И там всегда есть какой-либо генератор, либо графический, либо в документированную структуру пишешь свои условия. А оптимизаторы, которые я видел, весьма впечатляют.
Но всегда есть возможность в "простых" случаях, которые, как ни верти, преобладают над "сложными", написать простой код, когда очевидно, что это навсегда оптимальный способ и запускать оптимизатор бессмысленно. Сейчас мне уже сложно понять как можно не понимать таких простых вещей. А лет пять назад, зная только Oracle, сам не понимал.
23 мар 06, 22:38    [2483940]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
М программист
Guest
То джокер.
1. Когда "их" просто нет в природе, "они" никак не могут "хотеть общаться". Ваша провокация с мифическими М программистами, перешедшими с MSM под DOS на Oracle 8, весьма глупая.
2. Если человек не знает, что 3+2*3=15, то как он вообще может рассуждать о программировании ?
3. M - это не PL/SQL, чтоб Вы знали.
4. У M нет никаких проблем с производительностью, которых просто море при практическом использовании РСУБД. M не просто интерпретатор, а великий интерпретатор. Сравнивать нужно интегрированный результат, а не циклы неизвестно с чем. Не Intersystems, а изобретатели MUMPS изначально решили все проблемы.
5. Отсутствие типов одно из преимуществ M. Это даже критики M понимают. Профессиональные критики.
6. Вот это уже взрослая речь - программируем на T-SQL и PL/SQL потому что книг больше. Хороши программисты.
7. В Intersystems людям пока еще интересно создавать что-то стоящее. Фиг их купишь, пока им это интересно.
8. Ваше непревзойденное невежество связано с незнанием М, поэтому вполне простительно. Но лучше бы помолчать в ситуации полного незнания предмета.
23 мар 06, 22:57    [2483973]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
О как ! DOOM и анализ снимков в ответ на типичную функцию обработки в т.ч. реляционных данных. Ввел пользователь строку и ея нада обработать. Детский сад ! Хошь не хошь а вывод напрашивается: связка СКЛ-РСУБД - худшее шо есть для БД. Даже простейшую функцию несколько спецов не шмогли сбацать. Хде результат ? Напишите функцию $$S от Sergo хоть на чем-нибудь ! Ну не получилося на СКЛ-е, хоть на чем напишите.
"Оракломампсист" нехай сам отвечает за немеряно. Я использую всего шесть и мне хватает.
Опа ! Как же шо я плету ? А set, а if, а begin и т.д. и т.п. Енто Вы уже совсем заплелись.
23 мар 06, 23:15    [2484005]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
"Тут ворвались санитары,
Зафиксировали нас"(С)
24 мар 06, 00:04    [2484070]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
токарь
Даже простейшую функцию несколько спецов не шмогли сбацать. Хде результат ?


Совсем плох товарищ. Решение задачи на предыдущей странице, оно там встречается раз 10. Это ж как нужно хотеть ничего не видеть, чтобы не заметить.
24 мар 06, 00:21    [2484091]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Выбегалло
ораклоидальный мампсист
О чем договариваться, Выбегалло ? Я же не ребенок. Зачем я буду называть ручные блокировки автоматическими ? Ручные блокировки иногда нужны, но автоматические обязаны быть. Так же как и индексы. Конечно автоматические, но одно удовольствие, когда ты можешь прочитать из индекса так же естественно, как из данных.


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

Ну как же, там ведь русским языком сказано: "одно удовольствие, когда ты можешь прочитать из индекса". Рразве мало - получить удовольствие? А представьте если ему дать возможность читать из регистров процессора, это ж вообще. Тут и до нервного срыва может дойти, забудет человек о еде и питье, будет сутками по регистрам лазить, кайф получать. И не важно, что другие получают удовольствие загорая на пляже, "ораклоидальный мампсист" в это время перед монитором тащится от того, что читает из индекса как из данных.

Нам, увы, этого не понять. Грубые мы люди, бесперспективные в плане освоения утонченных удовольствий.
24 мар 06, 01:01    [2484148]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
c127
токарь
Даже простейшую функцию несколько спецов не шмогли сбацать. Хде результат ?


Совсем плох товарищ. Решение задачи на предыдущей странице, оно там встречается раз 10. Это ж как нужно хотеть ничего не видеть, чтобы не заметить.

Виноват, ошибся, на предыдущей странице решение встречается всего только 3 раза, раз 10 это на 26-й.
24 мар 06, 01:15    [2484163]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
М программист
То джокер.
1. Когда "их" просто нет в природе, "они" никак не могут "хотеть общаться". Ваша провокация с мифическими М программистами, перешедшими с MSM под DOS на Oracle 8, весьма глупая.
2. Если человек не знает, что 3+2*3=15, то как он вообще может рассуждать о программировании ?
3. M - это не PL/SQL, чтоб Вы знали.
4. У M нет никаких проблем с производительностью, которых просто море при практическом использовании РСУБД. M не просто интерпретатор, а великий интерпретатор. Сравнивать нужно интегрированный результат, а не циклы неизвестно с чем. Не Intersystems, а изобретатели MUMPS изначально решили все проблемы.
5. Отсутствие типов одно из преимуществ M. Это даже критики M понимают. Профессиональные критики.
6. Вот это уже взрослая речь - программируем на T-SQL и PL/SQL потому что книг больше. Хороши программисты.
7. В Intersystems людям пока еще интересно создавать что-то стоящее. Фиг их купишь, пока им это интересно.
8. Ваше непревзойденное невежество связано с незнанием М, поэтому вполне простительно. Но лучше бы помолчать в ситуации полного незнания предмета.


1 Ну во первых это не провокация а реальность хотя М сообществу очень неприятно сознавать что народ отказывается от их любимых Каше и прочей MUPS-ятины в пользу нормальных систем :)
2. Извиняюсь на вашем изврате слава богу не пишу. Хотя я думаю давайте спросим ученика 3 класса сколько будет 3+2*3 в 99% мы получим ответ 9. Видимо програмиисты и разработчики М систем до 3 класса не дотянули. Печально, что эти люди с умными лицами учат нас как надо программы писать. Вы в начальных классах доучитесь потом школу окончите тогда с вами серьезно разговаривать можно будет. Пока к сожалению нашь разговор напоминает лекцию о структуре ДНК перед стадом первобытных людей.
3 Заметьте я имел ввиду что в сервере Каше скриптовые языки интерпритирующего типа. Так же как pl/sql в оракле. Или это не так и скрипты компилируются в исполняемые файлы ? Что я не так сказал.
4. Может изобретатели MUMPS Решили и остальные проблемы человечества ? Вы надеюсь спорить не будите что сервер Каше или MUMPS работает на железе (процессор, HDD и т д.) Следовательно каким бы гениальным небыл интерпритатор скорость его все равно ограниченна возможностью процессора, не так ли? или вы в своей фанатичной преданости М системам будете утверждать что это не так и чихать вы хотели на процессоры и они вам нафиг не нужны? Так вот дорогой мой товарищь для увеличения производительности кода в тех местах где это возможно стараются избавиться от циклов. Например компилятор Intel C при включенной оптимизации там где это возможно заменяет цикл простой последовательностью команд. Я думаю, что Вы не будите спорить что ребята в Intel знают архитектуру процессоров Intel уж как нибудь получше всех создателей М систем вместе взятых. Такая оптимизация рекомендуется даже при программировании на Ассемблере для повышения производительности. Я вам еще раз повторяю что циклы это медлено даже для компиляторов. Интерпритаторы по умолчанию медленнее так как тратиться время на разбор кода, создание переменных поддержку стека да и сам и само выполнение кода. Заметьте всегда медленнее. Обратнее утверждение неверно. Создатели процессоров не смогли решить проблем связанных с неиффективностью циклов, в компиляторах идут на всякие ухищирения связанные с этим и только создатели М систем все решили и плевать хотели на компиляторы (хотя сами скорее всего на С писаны) и процессоры. Прикольно, хотя от людей с образование менее 3-х классов ничего другого я и не ожидал.
Насчет проблем с производительностью. Вот вам задача : Есть таблица протарифицированных телефонных разговоров. Объем примерно 1 000 000 000 строк. Размер порядка 120Gb небходимо вывести отчет по каждому абоненту с группировкой по дням, по тарифным планам, направлениям, филиалам с подведением промежуточных итогов па месяцам, кварталам. Подобную задачу мы задали представителю InterSystems на семенаре. Нам предложили создать спец. структуру данных удобную для выполнения этого отчета. Но вся проблемма в том что кроменего по этим данным делается еще куча отчетов для которых данная структура не подходит. Но это еще пол беды для каждого отчета надо писать свой уникальный скрипт даже если просто отличаетсяя порядок группировки. На оракле это решилось элементарно. 1 таблицей и 1 запросом с использованием аналитических функций. Если надо сменить порядок группировки достаточно изменить этот порядок в запросе во форазе group by. Делается менее 1 минуты. Кол-во затраченных усилий на М системе просто неизмеримо :) Хотя я думаю сделать можно, так же как впрочем и на ассемблере все написать. Вопрос во времени и в том а нафига изобретать велосипед второй раз.
5. Отсутствие типов никогда приемуществом не является. Вы почитайте литературу, пропробуйте сами написать что-то типа интерпритатора басика. И вы поймете почему. Все ведущие производители инструментальных средств отказываются от безтиповых переменных. Посмотрите на VB.NEt там есть типы. Присутствие типов во первых позволяет избежать ошибок, 2 увеличивает производительность так как хранить число 128 в виде строки расточительно (1 байт тип char или минимум 4 как строку к томуже для арифметических операций потребуется постояно преобразовывать строку в число так как не умеет процессор строки складывать, делить и умножать или Вы со мной опять не согласны)
6. Наличие большого кол-ва документации всегда являлось плюсом любой хорошей сстемы. У М систем нет таковой потому что они нафиг никому не нужны по большому счету. Кустарная подделка любителей которые выдают технологии 70 годов за революционный прорыв. Признайте это ибо признание ошибок первый шаг на пути к истине.
7. InterSystem не куплена до сих пор лишь потому что нафиг не кому не нужна. Если бы был реальный спрос на их систему уж поверте такие компании как Microsoft способны предложить такую сумму от которой там не отказались бы. Просто не предлагают. Не нужно им это. А если не купить то разорили бы точно. Написать систему наподобие Каше я думаю Microsoft в состоянии пусть хуже но благодаря своим деньгам и маркетингу они задавили бы Каше так же как задавили Borland. Подумайте на досуге над этим.
8. Ну естествнено нет аргументов начинае затыкать рот. Вы в школе доучитесь немного с экономикой познакомтесь, с математикой. Изучите что нибудь кроме МUMPS. Изучите архитектуру процессора поймите как оно там внутри работает. Попробуйте сами написать интерпритатор. Тогда наверно с Вами можно будет разговаривать как с адекватным человеком. Пока сторонники М систем как религиоозные фанатики или агенты по продаже кричат что М это круто. На вопрос в чем круто отвечают во всем и круче всего. Когда дело доходит до реальных примеров сразу начинают вспоминать что 2 автоматизировали Балобановскую спичечную фабрику и все там довольны. Хотелось бы мне пообщаться с людьми оттуда узнать довольны ли они всем. Или довольны лишь те кто внедрял. Единственный кто что либо сам сделал MX-ALEX. Но его пример про замену 1C на M ситему смешон. Задача которая решается даже DBF файлами. Объемы смешные говорить о необычайной производительности системы в сравнении с 1С смешно. Кстати Не обгоняет её по производительности только ленивый. Так что прочитав весь пост не одного убедительного примера Вы привести не смогли.
24 мар 06, 03:52    [2484272]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
Извиняюсь за ошибки много работы постояно отвлекают.
24 мар 06, 04:43    [2484282]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Joker_Ya
Единственный кто что либо сам сделал MX-ALEX. Но его пример про замену 1C на M ситему смешон. Задача которая решается даже DBF файлами. Объемы смешные говорить о необычайной производительности системы в сравнении с 1С смешно. Кстати Не обгоняет её по производительности только ленивый. .


смейтесь смейтесь ..
скоро до Вас дойдем :)

если серьезно - как раз пример с 1с не показатель для
сравнения скорости и не это главное в задачах такого типа
хотя со скорость у нас все очень даже прилично -
несмотря на "интерпрИтатор".
А вот изощренность алгоритмов бухгалтерского
и финансового учета, расчета зарплаты и множество тонкостей -
это довольно неплохой тест выявить практическую пригодность
той или иной системы в реальных условиях непрерывного
изменения законодательства и его неопределенности
и быстро меняющихся требований заказчиков.

Наша МX-система справилась с задачей, попутно создан
EXCEL++MUMPS интегрированый инструмент который решает
множество задач не только бухгалтерского направления.

М в этой ситуации показал свою хорошую профпригодность

Так что очень интересует Ваша "1с - но без М - альтернатива"
которая видимо у Вас припрятана
Покажете ?
Вместе посмеёмся ..
24 мар 06, 09:12    [2484564]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Joker_Ya
Извиняюсь за ошибки много работы постояно отвлекают.


а откуда работа ?
на ORACLE все отдыхают !
одну строчку написал - и на пляж.

вон 127-й всю жизнь на Канарах загорает.

только мумпсисты круглые сутки по регистрам-ассемблерам роются.
с интерпритаторами воюют.
24 мар 06, 09:30    [2484621]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
MX -- ALEX
Joker_Ya
Извиняюсь за ошибки много работы постояно отвлекают.


а откуда работа ?
на ORACLE все отдыхают !
одну строчку написал - и на пляж.

вон 127-й всю жизнь на Канарах загорает.

только мумпсисты круглые сутки по регистрам-ассемблерам роются.
с интерпритаторами воюют.


Не хтел Вас обидеть. Извините. Просто имелось ввиду что объемы не те чтоб серьезно говорить о каких то приемуществах в скорости СУБД. Может ваша система и является неплохой альтернативой 1С. С 1С работал сам. В принципе для соего сектора рынка (малый и средний бизнес) вполне нормальная система. Excel тоже уважаю когда его правильно используют. А насчет работы так не только Ораклом занимаемся. Оттуда и работа
24 мар 06, 09:50    [2484709]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
MX -- ALEX
Joker_Ya
Единственный кто что либо сам сделал MX-ALEX. Но его пример про замену 1C на M ситему смешон. Задача которая решается даже DBF файлами. Объемы смешные говорить о необычайной производительности системы в сравнении с 1С смешно. Кстати Не обгоняет её по производительности только ленивый. .


смейтесь смейтесь ..
скоро до Вас дойдем :)

если серьезно - как раз пример с 1с не показатель для
сравнения скорости и не это главное в задачах такого типа
хотя со скорость у нас все очень даже прилично -
несмотря на "интерпрИтатор".
А вот изощренность алгоритмов бухгалтерского
и финансового учета, расчета зарплаты и множество тонкостей -
это довольно неплохой тест выявить практическую пригодность
той или иной системы в реальных условиях непрерывного
изменения законодательства и его неопределенности
и быстро меняющихся требований заказчиков.

Наша МX-система справилась с задачей, попутно создан
EXCEL++MUMPS интегрированый инструмент который решает
множество задач не только бухгалтерского направления.

М в этой ситуации показал свою хорошую профпригодность

Так что очень интересует Ваша "1с - но без М - альтернатива"
которая видимо у Вас припрятана
Покажете ?
Вместе посмеёмся ..


Насчет альтернативы 1С без М так был опыт работы когда часть системы была реализована на 1С а самые ресурсремкие операции были вынесены на SQL Server. Связка получилась очень удачная. Та часть которая постояно изменяется была на 1С а та которой приходилось работать с большими объемами данных был вынесен на SQL Server в виде хранимых процедур. 1С в этом случае использовался как интерфейс. Скорось работы системы возрасла на прядки (не умеет 1С 7.7 нормально использовать вохможности SQL Server постояно курсоры в циклах гоняет) да и вообще работа данной системы стала возможна только благодаря такому разделению.
24 мар 06, 09:56    [2484742]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Joker_Ya
2. Извиняюсь на вашем изврате слава богу не пишу. Хотя я думаю давайте спросим ученика 3 класса сколько будет 3+2*3 в 99% мы получим ответ 9. Видимо програмиисты и разработчики М систем до 3 класса не дотянули. .


а давайте взглянем на это с другой стороны .

как ученик третьего класса будет решать эту задачу
на своем калькуляторе ?

наберет
3 + 2 * 3 =
и получит ....?
15 ....?
удивительно ..
в 99% случаев получаем ответ : 15
а должно бы по науке 9.
ни хрена себе ...
а как же приоритет операций ?

видимо создатели калькулятора тоже докурили только до второго класса :)

и миллиарды людей теперь мучаются
24 мар 06, 10:00    [2484755]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Joker_Ya
MX -- ALEX
Joker_Ya
Извиняюсь за ошибки много работы постояно отвлекают.


а откуда работа ?
на ORACLE все отдыхают !
одну строчку написал - и на пляж.

вон 127-й всю жизнь на Канарах загорает.

только мумпсисты круглые сутки по регистрам-ассемблерам роются.
с интерпритаторами воюют.


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


В Вашей критике М есть много справедливого.

Но мы надеемся что у М-систем есть перспективы развития.

InterSystems - главный разработчик -
потерял 9 лет - скупил на корню MSM и уснул.
24 мар 06, 10:15    [2484829]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
В M 3+2*3 = 15? Интересно, с какой это другой стороны на это можно посмотреть?

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

3 + 2 * 3

Потому что после того, как мы набрали 2 + 3 и нажали "*" нормальный калькулятор показывает 5 (как промежуточный результат). На еще более нормальных калькуляторах есть кнопки со скобочками.
24 мар 06, 10:30    [2484918]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
MX -- ALEX
Joker_Ya
2. Извиняюсь на вашем изврате слава богу не пишу. Хотя я думаю давайте спросим ученика 3 класса сколько будет 3+2*3 в 99% мы получим ответ 9. Видимо програмиисты и разработчики М систем до 3 класса не дотянули. .


а давайте взглянем на это с другой стороны .

как ученик третьего класса будет решать эту задачу
на своем калькуляторе ?

наберет
3 + 2 * 3 =
и получит ....?
15 ....?
удивительно ..
в 99% случаев получаем ответ : 15
а должно бы по науке 9.
ни хрена себе ...
а как же приоритет операций ?

видимо создатели калькулятора тоже докурили только до второго класса :)

и миллиарды людей теперь мучаются


Дело в том что калькулятор, в отлиции от компилятора или интерпритатора, не знает строчки целиком и работает не со строчкой, а двумя последними цифрами.
А вот загоните эту строчку(= 3 + 2 * 3 ) в Ваш любимый Ексель?

Такой порядок вычислений как в М - это архаизм, нигде такого больше нет(или приведёте пример?), и то что Вы это не признаёте не делает Вам авторитет.
24 мар 06, 10:35    [2484945]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Just a note
Guest
To Joker Ja:

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

Фразы типа: "Ну во первых это не провокация а реальность хотя М сообществу очень неприятно сознавать что народ отказывается от их любимых Каше и прочей MUPS-ятины в пользу нормальных систем :)"
"Единственный кто что либо сам сделал MX-ALEX."
"Может ваша система и является неплохой альтернативой 1С"
голословные утверждения человека, котрый не любит и не знает ничего кроме sql, стремиться любым образом очернить неплохую систему в глазах других. не понятно зачем только.

Понять, что слова Джокера не имеют никакого значения можно, зайдя на сайт intersystems.
MS-ALEX и его система это только один из примеров использования cache.
клиенты есть и появляются в крупных гос. и коммерческих структурах.
Очень крупные внедрения в МВД, ГИБДД, Пенсионном фонде,РЖД.
чтобы избежать лишних вопросов пример: в ржд стоит система ведения нормативно-справоной информации. номенклатура-70 000 позиций. в систему имеют доступ сотрудники ж/д от Калининграда до Владивостока. пользователей около 6 000, одновременно работает около 250-300. все это поддерживает один 2х процессорный Intel сервер, уставновленый в москве.все работает прекрасно и быстро.

Все эти противопоставления SQL - M - война брендов за вытеснения всех продуктов кроме sql с рынка. и всем очень хорошо промыли мозги. за это очень уважаю сотрудников маркетинговый отделов oracle , microsoft. но иногда стоит посмотреть дальше своего носа и дальше того, чему учили в институте.
Cache безусловно менее раскрученный бренд, но это не означает, что система плохая, ненадежная и нигде используется. прошу учесть, чтобы не вводить в заблуждение других людей.
24 мар 06, 10:42    [2484993]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Just a note

Не являетесь ли вы продовцом решений на базе МУ-МУ-МУПС ?

Очень характерные высказывания, неудобные вещи игнорируются, и листовки какие-то преподносятся :
"...от Калининграда до Владивостока. пользователей около 6 000, одновременно работает около 250-300"

250-300 РАБОТАЮЩИХ пользователей НЕ ЯВЛЯЕТСЯ ЧЕМ-ТО выдающимся, для современных СУБД, а сколько всего лицензий куплено 600, 6000, 60000 это к делу отношения не имеет, возможно в этих портах стоимость миграции пока сравнима или превышает прибыль.В мире много банков работает на IMS, не потому что всё устраивает, а потому что миграция очень дорогая и рискованная штука.

А вот конкретные технические вопросы остались без ответа :

3+2*3 = 15 )))

Это не баг это фича ? Так что ли ? Надо привыкнуть к тому что у МУ-МУ-СТОВ когда-то не получилось написать грамотный лексический анализ и теперь в ЭНТЕРПРАЙЗ РЕШЕНИЯХ на МУ-МУ мы таскаем за собой косяк 30-летней давности, но зато "...от Калининграда до Владивостока..."


"Есть таблица протарифицированных телефонных разговоров. Объем примерно 1 000 000 000 строк. Размер порядка 120Gb небходимо вывести отчет по каждому абоненту с группировкой по дням, по тарифным планам, направлениям, филиалам с подведением промежуточных итогов па месяцам, кварталам. Подобную задачу мы задали представителю InterSystems на семенаре. Нам предложили создать спец. структуру данных удобную для выполнения этого отчета. Но вся проблемма в том что кроменего по этим данным делается еще куча отчетов для которых данная структура не подходит. Но это еще пол беды для каждого отчета надо писать свой уникальный скрипт даже если просто отличаетсяя порядок группировки. На оракле это решилось элементарно. 1 таблицей и 1 запросом с использованием аналитических функций. Если надо сменить порядок группировки достаточно изменить этот порядок в запросе во форазе group by. Делается менее 1 минуты. Кол-во затраченных усилий на М системе просто неизмеримо :)"

У меня похожая таблица, только не по телефонам и записей в ней
49 000 000 в каждой годовой партиции, если для каждого отчёта (отчётов примерно около 100+отчёты в DW и каждый месяц 5-7 из них меняются, 1-2 устаревают и 1-2 добавляются) + аналитический отдел, которому бывает нужно в течении нескольких часов получить отчёт по "живым данным" или по истории, если я проникнусь МУ-МУ-САМИ для каждого отчёта мне придётся " создать спец. структуру данных удобную для выполнения этого отчета", вырисовывать на МУ-МУ-ЯЗЕ пару экранов закорючек типа : $@#%#$^%####--"Цена" или пытаться разобрать чужие закорючки продираясь через горы вложенных циклов (которые на моих 49е6 будут просто УМИРАТЬ), самому думать о блокировках и индексах и т.п. самым мягким словом которое я услышу от коллег и от начальства будет "ДУРАК".

"Отсутствие типов никогда приемуществом не является."
И не ответа не привета на вполне справедливый упрёк, что говорит о том что вам НРАВИТЬСЯ ловить ошибки типа Invalid Number или Illegal Date Specification, когда кто-то по дурости или по невнимательности забудет про проверку типа, особенно весело становиться начальству когда такая ошибка вылезает во время автоматического построения каких нибудь консолидированных данных для хранилищ Пришли все с утра, а у нас МУ-МУ...


Вместо этого рассказы про неземную МОЩЬ и про то, злых Ораклов и Майкрософтов , которые маркетят и маркетят, правда 3+2*3 у них равно 9, и оптимизаторы 49е6 записей раскладывают на запросы которые выполняются считанные минуты, и язык для работы с данными без циклов и процедурные расширения наглядны и понятны и 200 пользователей не проблема, и блокировки поддерживает система и данные типизированы, и индексты не надо поддерживать самому, но вот честные МУ-МУ-сты никогда ничего не маркетят НЕТ, НЕТ и НЕТ ! Это не они продают устаревшую иерархическую систему 70-х не поменяв в ней ничего, только обвешав рюшами и маркетинговыми слоганами про ОО. Это не они приходят на форум на сайте SQL.RU и рассказывают про "...от Калининграда до Владивостока..." Как вы могли такое подумать)))))

Пы.Сы.
На самом деле это MS,Oracle и IBM надо у Intersystems учиться, особенно IBM-y. Втюхивать иерархическую систему 70-х (принципиально ничего не изменив в ней за 30 лет) навешивая тонны лапши менеджерам и получая истеричных пользователей, которые будут всем рассказывать, что 2+3*2=15.
24 мар 06, 11:34    [2485401]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
SergSuper

Дело в том что калькулятор, в отлиции от компилятора или интерпритатора, не знает строчки целиком и работает не со строчкой, а двумя последними цифрами.
А вот загоните эту строчку(= 3 + 2 * 3 ) в Ваш любимый Ексель?

Такой порядок вычислений как в М - это архаизм, нигде такого больше нет(или приведёте пример?), и то что Вы это не признаёте не делает Вам авторитет.


ну-у ... например ...

калькулятор !
24 мар 06, 11:40    [2485446]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Ц4
Guest
а что действительно 3 + 2 * 3 =15?
Авторы языка пиво пили вместо посещения лекций?
24 мар 06, 11:45    [2485494]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Ц4
а что действительно 3 + 2 * 3 =15?
Авторы языка пиво пили вместо посещения лекций?


действительно
в мумпс нет приоритета в операциях
надо ставить скобки

set rezult=3+(2*3)
write result
15

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

а Вам не приходилось забывать ЧТО именно приоритетнее ?

if not abcd like "*########* then ....

сразу очевидно где приоритет ?

if not (abcd like "*########*) then ....
так как то надежнее - не правда ли ?

не мешают приоритеты в мумпсе работать
говорю как практик

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