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

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
ораклоидальный мампсист
Выбегалло познал истину. Или угадал - не суть важно. Только не действующую модель, а собственно СУБД с автоматическими индексами, будь они неладны, транзакциями, автоматическими блокировками, и, естественно, с наилучшей, с точки зрения "сборщика", моделью данных.


Только давайте договоримся о значении слова "автоматический". Если поддержание индекса берет на себя субд - то он да, автоматический. А если программист - то что именно в нем автоматического ?
То же касается блокировок.
Между прочим, в бытность мою в саппорте Информикса, именно блокировки служили постоянным источником трудноуловимых багов. Скажем, существует структура а, в которой есть указатель на структуру б. Структуру б программист залочил - а про структуру а позабыл. Уж больно далеко она в коде, а то и вообще через пару других списков связана. А тут другая нить бац - и изменила структуру а - и фсе, неверный пойнтер. И, самое неприятное, воспроизвести баг практически невозможно.
С тех пор я сильно предпочитаю автоматические блокировки ручным. Автоматические - их когда-то уже оттестировали, кто-то по этим граблям потоптался до меня.
21 мар 06, 23:00    [2474021]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Rus000
c127

Rus000

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

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


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


Ок.

Rus000

у Вас есть строгое определение индекса? А то как то странная аргументация типа приведенной выше "весь мир", "который в основном".
Если есть, то давайте отталкиваться от него как от точки отсчета, в противном случае этот термин никто не запрещает использовать в ином также общепринятом смысле, даже если он означает "вспомогательные деревья"

Сколько раз нужно отвечать на вопрос, чтобы его перестали задавать? Вам же отвечал:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=14#2416524
Не нравится то что у Дейта - определите по-другому, но Вы ведь этого не сделали. Я не знаю кто Вы, но почему-то думаю, что авторитет Дейта немного выше Вашего и моего вместу взятых, поэтому я ориентируюсь на то, как понимает индексы Дейт, а не на то, как их понимаете Вы.

Вы не согласны что рынок СУБД это в основном РСУБД? Тоже будем спорить?


Rus000

c127

Предлагаю закончить дискуссию об индексах в М на том, что их там нет.

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

Блин, в который раз повторяю, дело даже не в том, как оно внутри, дело в том, что в РСУБД индекс определил и забыл. А в М этот так называетмый индекс нужно поддерживать руками. Каждую операцию изменения данных нужно дублировать. А если "индексов" два, то повторять уже не 2, а 3 раза. Ну и так далее.

Следующее, уже спрашивал там же.
"Например вот еще одна проблема: если структура
^БИЛЕТЫ(дата,рейс,место)=пассажир
занимает один терабайт, то сколько займет ^БИЛЕТЫИНДЕКСЫ(1,рейс,место,дата) и
^БИЛЕТЫИНДЕКСЫ(2,рейс,дата,место),
которые заменяют индексы и существуют исключительно для упрощения и ускорения поиска?

Индекс в РСУБД тоже занимает место, но все-таки данные тупо не дублирует.
"

Это же с Вами был разговор, не помню чтобы Вы как-то прокомментировали этот момент.


Rus000

c127

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

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

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


Rus000

c127

c127

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

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

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

риторика, однако.
Я просто ратую за чистоту и аргументированность формулировок. Как в математике - либо прямое доказательство, либо от противного :)
Пока мы манипулируем субъективными мнениями и косвенными данными.
Думаю что эффективность той или иной системы трудно доказать, т.к. синтетические тесты всего лишь модель реальной ситуации, а реальные решения вводят дополнительный размывающий коэффициент под названием "профессионализм команды разработчиков". Лично я склонен все же критерием эффективности считать эффективность готового решения на реальных данных, однако в этом случае для корректного сравнения требуется сделать аналог решения на другой платформе, что вряд ли кто себе может позволить


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

Rus000

попробую, но чуть позже - цейтнот сейчас ... а алгоритмический вариант кто-нибудь предлагал? Что-то мне кажется использование sql для этой задачи каким-то извратом, если честно.

А бегать 10км под секундомер не изврат, на машине никто не пробовал? Всякий тест есть изврат, на то он и тест.

Rus000

да не говорили, но как Вы можете быть уверены, что выбрав из n решений с приемлемым для заказчика временем отклика, самое легкое для Вас, Вы сможете обеспечить стабильность времени отклика в случае линейного или нелинейного роста объемов данных у заказчика? Мне кажется что дальновидный проектировщик или программист закладывает дополнительную прочность своего алгоритма, не всегда выбирая самый легкий, а компромис между трудностью и эффективностью.
c127

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

см.выше

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

Rus000

М-системы:
1)специфика задачи, в которой данные имеют неоднородную сильно разреженную структуру
2) учетные системы с характерно выраженной объектной семантикой, например, БД для народонаселения
3)плохие каналы связи (14400 Kb/s), соответственно необходимость использования тонких клиентов в виде аппаратных терминалов (при этом работает всякий хлам типа УКНЦ,x286/386,СМ7238, КРОН, и т.п.)

РСУБД:
1) семантическая природа моделируемых сущностей более-менее однородна
2) отчет-ориентированные системы, с множеством нерегламентируемых запросов
3) простое подключение или использование встроенного графического интерфейса для клиента
4) необходимость использование olap и data mining, т.к. продукты такого типа ориентированы на РСУБД

Ага, это уже не ЧАЛ-овский бред, это похоже на критерии. В принципе пониятно, спасибо. Пара замечаний.
По М.
1) разреженная структура это как раз для РСУБД, если мы термин одинаково. Определение.
2) Сложно что-то возразить, не знаю что такое объектная семантика. Насколько я понимаю всякая семантика может стать объектной, было бы желание. Определение.
3) не верно, сайбейз АСА умеет реплицировать через почту. Клиент это вообще проблема клиента, мы говорим о сервере, хотя у вас там все перепутано.

По РСУБД.
2) не представляю систему с заранее регламентитрованными запросами, развче что традиционная бухгалтерия. ИМХО всегда в середине разработки пояляется куча новых запросов. Но главное то, что любая система, включающая СУБД, кроме АСУ какого-нибудь стингера, направлена на отчеты. Поэтому этот пункт ничего не дает, если речь идет не об АСУ.
3) Что такое встроенный графический интерфейс для клиента? Такого в РСУБД нет вообще, это же сервер в архитектуре клиент-сервер. Клиентом занимается клиент.

Rus000

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

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


Rus000

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

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

Забыли про войны. Разбираемся в сути.
22 мар 06, 01:02    [2474212]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
ggv
странно, но за весь топик никто еще не вякнул, что данные в объеме хранить удобнее, чем на плоскости.

По-моему что-то мелькало об ограниченности плоских таблиц.

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

Читатели, блин
dvm 21 фев 06, 12:17> Дык пример без нормализации, а делать по букварю так и длиннее получится(хотя можно через view)
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=7#2377469

токарь
с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 сделал. Тада посмотрим хто из нас чушь гаварит.

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

МУМПС-исты конечно же все задачи решают исключительно МУМПС-ом. И все бы поверили в эту идилию, но вот некстати был приведен пример екслелем и 255 символами. Читаем:
MX -- ALEX>
--MUMPS нашел
--отдал excel-у
--excel все посчитал-разложил красиво

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=26#2471429
А зачем же ексель, если МУМПС это и сервер и клиент, причем универсальный, удобный и работающий на всём чем можно?



AndreiNz

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

Абсолютно уверен. Ни одного цикла, ни одной переменной.

c127

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

AndreiNz

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

Извините, не у нас, а у Вас (С). Я к этим Вашим рассуждениям отношения не имею. Это даже не фантазии "по мотивам", это вообще куда-то в сторону.

AndreiNz

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

Где, в какй это системе чем больше - тем лучше? Я такое говорил? Где?

Чем меньше тем лучше.

AndreiNz

Что-то я краткости SQL в данном случае не вижу

В данном случае действительно не видно. А вот в почти жизненном примере с билетами - сколько угодно, любуйтесь краткостью СКЛ-я на здоровье:
select s.race 
  from Sold s, Shadule h, Fly f 
  where s.race=h.race // связываются таблицы
    and h.fly=f.fly       // связываются таблицы
    and f.caption<>'TU 154'
    and datediff(month,'2003.01.01',h.date)=0 // можно заменить на h.date between  '2003.01.01' and '2003.01.31' 
    and s.flag=1
  group by s.race
  having (((select sum(cnt) from place p where p.fly=f.fly) - count(*)) between 10 and 20)
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406559
Сравните это с компактным и удобным М:
//Функция-счетчик дочерних подузлов дерева path
COUNT(path)
 {
	 set idx=""
	 for count=0:1 set idx=$ORDER(@path@(idx)) quit:idx=""
	 quit count
 } 

 set месяц="2003-01"
 set кромесамолета="TU-154"
 set кол1=10,кол2=20           ;от [кол1,кол2] билетов
 
 set дата=$ZDATEH(месяц_"-01",3)  // начинаем с 1-го числа месяца
 for {
	 set дата=$ORDER(^РАСПИСАНИЕ(дата))
	 quit:дата=""
	 quit:$EXTRACT($ZDATE(дата,3),1,7)'=месяц  //прекращаем поиск если достигли конца месяца
	 
	 set рейс=""
	 for {
		 set рейс=$ORDER(^РАСПИСАНИЕ(дата,рейс)) 
		 quit:рейс=""
		 set типсамолета=^РАСПИСАНИЕ(дата,рейс)
		 if (типсамолета'=кромесамолета) { //отбрасываем лишние типы
			set проданомест=$$COUNT($NAME(^БИЛЕТЫ(дата,рейс)))
			set мествналичии=$$COUNT($NAME(^САМОЛЕТ(типсамолета)))
			set непродано=мествналичии-проданомест
			if (непродано'<кол1) && (непродано'>кол2) set рейсы(рейс)=""
		 }
	 }
	 
 }
 zw рейсы
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406070
22 мар 06, 01:24    [2474235]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
c127
ggv
странно, но за весь топик никто еще не вякнул, что данные в объеме хранить удобнее, чем на плоскости.

По-моему что-то мелькало об ограниченности плоских таблиц.

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

Читатели, блин
dvm 21 фев 06, 12:17> Дык пример без нормализации, а делать по букварю так и длиннее получится(хотя можно через view)
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=7#2377469

токарь
с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 сделал. Тада посмотрим хто из нас чушь гаварит.

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

МУМПС-исты конечно же все задачи решают исключительно МУМПС-ом. И все бы поверили в эту идилию, но вот некстати был приведен пример екслелем и 255 символами. Читаем:
MX -- ALEX>
--MUMPS нашел
--отдал excel-у
--excel все посчитал-разложил красиво

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=26#2471429
А зачем же ексель, если МУМПС это и сервер и клиент, причем универсальный, удобный и работающий на всём чем можно?



AndreiNz

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

Абсолютно уверен. Ни одного цикла, ни одной переменной.

c127

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

AndreiNz

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

Извините, не у нас, а у Вас (С). Я к этим Вашим рассуждениям отношения не имею. Это даже не фантазии "по мотивам", это вообще куда-то в сторону.

AndreiNz

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

Где, в какй это системе чем больше - тем лучше? Я такое говорил? Где?

Чем меньше тем лучше.

AndreiNz

Что-то я краткости SQL в данном случае не вижу

В данном случае действительно не видно. А вот в почти жизненном примере с билетами - сколько угодно, любуйтесь краткостью СКЛ-я на здоровье:
select s.race 
  from Sold s, Shadule h, Fly f 
  where s.race=h.race // связываются таблицы
    and h.fly=f.fly       // связываются таблицы
    and f.caption<>'TU 154'
    and datediff(month,'2003.01.01',h.date)=0 // можно заменить на h.date between  '2003.01.01' and '2003.01.31' 
    and s.flag=1
  group by s.race
  having (((select sum(cnt) from place p where p.fly=f.fly) - count(*)) between 10 and 20)
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406559
Сравните это с компактным и удобным М:
//Функция-счетчик дочерних подузлов дерева path
COUNT(path)
 {
	 set idx=""
	 for count=0:1 set idx=$ORDER(@path@(idx)) quit:idx=""
	 quit count
 } 

 set месяц="2003-01"
 set кромесамолета="TU-154"
 set кол1=10,кол2=20           ;от [кол1,кол2] билетов
 
 set дата=$ZDATEH(месяц_"-01",3)  // начинаем с 1-го числа месяца
 for {
	 set дата=$ORDER(^РАСПИСАНИЕ(дата))
	 quit:дата=""
	 quit:$EXTRACT($ZDATE(дата,3),1,7)'=месяц  //прекращаем поиск если достигли конца месяца
	 
	 set рейс=""
	 for {
		 set рейс=$ORDER(^РАСПИСАНИЕ(дата,рейс)) 
		 quit:рейс=""
		 set типсамолета=^РАСПИСАНИЕ(дата,рейс)
		 if (типсамолета'=кромесамолета) { //отбрасываем лишние типы
			set проданомест=$$COUNT($NAME(^БИЛЕТЫ(дата,рейс)))
			set мествналичии=$$COUNT($NAME(^САМОЛЕТ(типсамолета)))
			set непродано=мествналичии-проданомест
			if (непродано'<кол1) && (непродано'>кол2) set рейсы(рейс)=""
		 }
	 }
	 
 }
 zw рейсы
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406070


Кроме краткости "M" тут еще есть сомнения насчет производительности
2 вложенных цикла я думаю при большом объеме данных просто умрут. Одной из причин отказа нашей компании от использования М системы была крайне низкая производительность и сложность поддержки. То что на М ситеме (биллинг телефонной компании) считалось 5-6 часов (таких отчетов в конце месяца надо было около 10) на оракле считалось менее часа. Это при том что железо было одинаковое. С М на оракл систему переводили люди с ораклом до этого не знакомые (разработчики М системы). В настоящее время они же поддерживают систему на Оракле и в принципе довольны им. В настоящий момент с ситемой работае порядка 350 пользователей одновременно. Объем базы 180 Gb. Объем данных в таблице с первичной информацией по которой строятся некоторые отчеты порядка 700 млн. записей. На этих объемах расчет дебеторской задолженности абонентов происходит чуть больше часа. При это с бозой работаю пользователи в обычном режиме и кроме этого расчета выполняется еще куча аналитических отчетов и вставка новых данных.
Если бы доступ к данным осуществлялся подобным образом производительность былабы еще та :)
22 мар 06, 03:57    [2474291]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
токарь
От SergSuper сквозь mir и Павла Воронцова и опять до mir код рос как на дрожжах, но так и не был написан ! Сначала vadiminfo не смог написать код ни на pl ни на с. Таперича сразу три спеца не смогли написать код даже на sql. Даже не ожидал что Sergo так велик (см. что делает его код, бедолаги).
А чо set переменная=значение это чистый sql ? Ну прям чистый mumps. И begin, if, end это чистый sql. Надо же как развился. И функции строковые включили в "декларативный язык запросов". Неплохо. Но код написать все равно не получилось. И забормотал тада ggv, шо его и не надо писать ваще. Молодца !
А чем вас не устроил код от Воронцова:
SELECT REPLACE(REPLACE(REPLACE(RTRIM(LTRIM(@fld)), ' ', ' '+char(1)), char(1)+' ',''),char(1),'')
Он работает правильно (запусти и убедись), он короче решения на MUMPS и он существенно нагляднее, даже без форматирования. Кстати, где написано, что декларативность языка запросов влечет запрет на наличие в языке строковых функций? Или это просто вам так захотелось?
22 мар 06, 05:25    [2474301]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
кстати, функции работы со строками в SQL имеют более смысла, будучи использованными в WHERE предикате, по типу - выбрать записи, у которых если поле преобразовать таким-то образом, то было бы нечто.
Но форматировать вывод SQL-ем не совсем верно. Хотя и можно.
Вот например, синтаксис DB2 SQL поддерживает кучу всего, включая CASE.
как вот например - https://www.sql.ru/forum/actualthread.aspx?tid=273235#2465791
И прошу заметить - это "чистый" SQL.
22 мар 06, 07:55    [2474371]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
to ну я

Спасибо, я так и предполагал.
22 мар 06, 07:57    [2474374]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
To "c127"
на будущее

если я тут чего еще спрошу у ребят на форуме
Вы можете не беспокоится.

Ваши бредовые ответы-пустышки меня абсолютно не интересуют
Ноль информации.
22 мар 06, 08:56    [2474487]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
mir
токарь
От SergSuper сквозь mir и Павла Воронцова и опять до mir код рос как на дрожжах, но так и не был написан ! Сначала vadiminfo не смог написать код ни на pl ни на с. Таперича сразу три спеца не смогли написать код даже на sql. Даже не ожидал что Sergo так велик (см. что делает его код, бедолаги).
А чо set переменная=значение это чистый sql ? Ну прям чистый mumps. И begin, if, end это чистый sql. Надо же как развился. И функции строковые включили в "декларативный язык запросов". Неплохо. Но код написать все равно не получилось. И забормотал тада ggv, шо его и не надо писать ваще. Молодца !
А чем вас не устроил код от Воронцова:
SELECT REPLACE(REPLACE(REPLACE(RTRIM(LTRIM(@fld)), ' ', ' '+char(1)), char(1)+' ',''),char(1),'')
Он работает правильно (запусти и убедись), он короче решения на MUMPS и он существенно нагляднее, даже без форматирования. Кстати, где написано, что декларативность языка запросов влечет запрет на наличие в языке строковых функций? Или это просто вам так захотелось?

код Воронцова конечно красивый
но для мумпсиста - м-код Серго тоже имеет свои изюминки

во многом язык - дело привычки

для россиян - русский самое то
для америки - тарабарщина

а человеку со стороны все программные языки - бред
22 мар 06, 09:20    [2474589]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

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

во многом язык - дело привычки

для россиян - русский самое то
для америки - тарабарщина

а человеку со стороны все программные языки - бред
Дело не в красоте кода и не в привычке. Вообще вот это сравнение кусков кода - бред. Сравнивать надо концепции, подходы, а вы (мампсисты) всё время сваливаетесь в постулирование красоты мампсового кода. Ответы "ну я" по принципиальным вопросам меня удовлетворили, я услышал именно то, что и ожидал услышать.
22 мар 06, 09:43    [2474674]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
MX -- ALEX
To "c127"
на будущее

если я тут чего еще спрошу у ребят на форуме
Вы можете не беспокоится.

Нет проблем, не буду.

Успехов в сексе стоя в гамаке. Только не забудьте потом поделиться впечатлениями, думаю всем будет интересен Ваш уникальный опыт.
22 мар 06, 09:52    [2474728]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Павел Воронцов
MX -- ALEX
код Воронцова конечно красивый
но для мумпсиста - м-код Серго тоже имеет свои изюминки

во многом язык - дело привычки

для россиян - русский самое то
для америки - тарабарщина

а человеку со стороны все программные языки - бред
Дело не в красоте кода и не в привычке. Вообще вот это сравнение кусков кода - бред. Сравнивать надо концепции, подходы, а вы (мампсисты) всё время сваливаетесь в постулирование красоты мампсового кода. Ответы "ну я" по принципиальным вопросам меня удовлетворили, я услышал именно то, что и ожидал услышать.

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

можно не сравнивать языки между собой

но внутри одного языка (любого) красивый код - лучше некрасивого
хотя во многом это конечно понятие интуитивное

думаю согласятся не только мумпсисты
22 мар 06, 10:06    [2474802]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
c127
MX -- ALEX
To "c127"
на будущее

если я тут чего еще спрошу у ребят на форуме
Вы можете не беспокоится.

Нет проблем, не буду.

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


не учи отца
и баста
22 мар 06, 10:08    [2474818]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Joker_Ya

Кроме краткости "M" тут еще есть сомнения насчет производительности
2 вложенных цикла я думаю при большом объеме данных просто умрут. Одной из причин отказа нашей компании от использования М системы была крайне низкая производительность и сложность поддержки. То что на М ситеме (биллинг телефонной компании) считалось 5-6 часов (таких отчетов в конце месяца надо было около 10) на оракле считалось менее часа. Это при том что железо было одинаковое. С М на оракл систему переводили люди с ораклом до этого не знакомые (разработчики М системы). В настоящее время они же поддерживают систему на Оракле и в принципе довольны им. В настоящий момент с ситемой работае порядка 350 пользователей одновременно. Объем базы 180 Gb. Объем данных в таблице с первичной информацией по которой строятся некоторые отчеты порядка 700 млн. записей. На этих объемах расчет дебеторской задолженности абонентов происходит чуть больше часа. При это с бозой работаю пользователи в обычном режиме и кроме этого расчета выполняется еще куча аналитических отчетов и вставка новых данных.
Если бы доступ к данным осуществлялся подобным образом производительность былабы еще та :)


Я не сомневался что при программировании на СКЛ-е МУМПС проиграет, но была надежда что на родном М все не так плохо. Приложение в М системе было не на СКЛ-е?
22 мар 06, 10:16    [2474871]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Joker_Ya

..............................
Кроме краткости "M" тут еще есть сомнения насчет производительности
2 вложенных цикла я думаю при большом объеме данных просто умрут. Одной из причин отказа нашей компании от использования М системы была крайне низкая производительность и сложность поддержки. То что на М ситеме (биллинг телефонной компании) считалось 5-6 часов (таких отчетов в конце месяца надо было около 10) на оракле считалось менее часа. Это при том что железо было одинаковое. С М на оракл систему переводили люди с ораклом до этого не знакомые (разработчики М системы). В настоящее время они же поддерживают систему на Оракле и в принципе довольны им. В настоящий момент с ситемой работае порядка 350 пользователей одновременно. Объем базы 180 Gb. Объем данных в таблице с первичной информацией по которой строятся некоторые отчеты порядка 700 млн. записей. На этих объемах расчет дебеторской задолженности абонентов происходит чуть больше часа. При это с бозой работаю пользователи в обычном режиме и кроме этого расчета выполняется еще куча аналитических отчетов и вставка новых данных.
Если бы доступ к данным осуществлялся подобным образом производительность былабы еще та :)


странно
обьемы вроде бы не очень большие..
полчаса с запасом должно хватить

не могли бы уточнить - какая именно версия M
- DIAMS
- GTM
- DTM
- MSM
- CACHE
и номер версии

(скорость например CACHE-5.1 в разы больше чем устаревших )

нельзя ли связаться с Вашими программистами,
работавшими на М а затем перешедшим на ORACLE ?

спасибо

kosinec@metalurgs.LV
-----------------------------
22 мар 06, 10:39    [2475040]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Joker_Ya
Member

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

..............................
Кроме краткости "M" тут еще есть сомнения насчет производительности
2 вложенных цикла я думаю при большом объеме данных просто умрут. Одной из причин отказа нашей компании от использования М системы была крайне низкая производительность и сложность поддержки. То что на М ситеме (биллинг телефонной компании) считалось 5-6 часов (таких отчетов в конце месяца надо было около 10) на оракле считалось менее часа. Это при том что железо было одинаковое. С М на оракл систему переводили люди с ораклом до этого не знакомые (разработчики М системы). В настоящее время они же поддерживают систему на Оракле и в принципе довольны им. В настоящий момент с ситемой работае порядка 350 пользователей одновременно. Объем базы 180 Gb. Объем данных в таблице с первичной информацией по которой строятся некоторые отчеты порядка 700 млн. записей. На этих объемах расчет дебеторской задолженности абонентов происходит чуть больше часа. При это с бозой работаю пользователи в обычном режиме и кроме этого расчета выполняется еще куча аналитических отчетов и вставка новых данных.
Если бы доступ к данным осуществлялся подобным образом производительность былабы еще та :)


странно
обьемы вроде бы не очень большие..
полчаса с запасом должно хватить

не могли бы уточнить - какая именно версия M
- DIAMS
- GTM
- DTM
- MSM
- CACHE
и номер версии

(скорость например CACHE-5.1 в разы больше чем устаревших )

нельзя ли связаться с Вашими программистами,
работавшими на М а затем перешедшим на ORACLE ?

спасибо

kosinec@metalurgs.LV
-----------------------------


Был MSM и было это в 2000 г.
Насчет скорости при однопользовательском доступе может быть. А вот при условии обеспечения непротиворечивости данных и многопользовательской работе сомневаюсь. Насчет в разы больше такое ощущение что вы в отделе маркетинга работают. Реплики типа "Наш парошок стирает чище в 3 раза " выглядят как реклама. Система переводилась на Оракл 8. С тех пор вышли 9 и 10 и скорость их работы тоже на месте не стоит. Я не против М систем но если честно они на ассемблер похожи. Инексы сам делай. Все остальное тоже сам. Язык просто ужастный. Я видел листинги модулей на М старой системы. Если честно хуже чем ассемблер. Поддерживать сие чудо оказалось слишком хлопотным делом. Кучи циклов вложенных циклов никогда быстро работать не будут. Поверте мне. Задача прикладного программиста не придумывать алгаритмы доступа к данным ипостроения индексов а решать проблеммы учета в бизнесе. Если было бы не так все писалибы на С и ассемблере, где надо аждый раз заново велосипед изобретать.
22 мар 06, 11:14    [2475269]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Joker_Ya
MX -- ALEX
Joker_Ya

..............................
Кроме краткости "M" тут еще есть сомнения насчет производительности
2 вложенных цикла я думаю при большом объеме данных просто умрут. Одной из причин отказа нашей компании от использования М системы была крайне низкая производительность и сложность поддержки. То что на М ситеме (биллинг телефонной компании) считалось 5-6 часов (таких отчетов в конце месяца надо было около 10) на оракле считалось менее часа. Это при том что железо было одинаковое. С М на оракл систему переводили люди с ораклом до этого не знакомые (разработчики М системы). В настоящее время они же поддерживают систему на Оракле и в принципе довольны им. В настоящий момент с ситемой работае порядка 350 пользователей одновременно. Объем базы 180 Gb. Объем данных в таблице с первичной информацией по которой строятся некоторые отчеты порядка 700 млн. записей. На этих объемах расчет дебеторской задолженности абонентов происходит чуть больше часа. При это с бозой работаю пользователи в обычном режиме и кроме этого расчета выполняется еще куча аналитических отчетов и вставка новых данных.
Если бы доступ к данным осуществлялся подобным образом производительность былабы еще та :)



"я видел листинги модулей на М старой системы"

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

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

нельзя ?



странно
обьемы вроде бы не очень большие..
полчаса с запасом должно хватить

не могли бы уточнить - какая именно версия M
- DIAMS
- GTM
- DTM
- MSM
- CACHE
и номер версии

(скорость например CACHE-5.1 в разы больше чем устаревших )

нельзя ли связаться с Вашими программистами,
работавшими на М а затем перешедшим на ORACLE ?

спасибо

kosinec@metalurgs.LV
-----------------------------


Был MSM и было это в 2000 г.
Насчет скорости при однопользовательском доступе может быть. А вот при условии обеспечения непротиворечивости данных и многопользовательской работе сомневаюсь. Насчет в разы больше такое ощущение что вы в отделе маркетинга работают. Реплики типа "Наш парошок стирает чище в 3 раза " выглядят как реклама. Система переводилась на Оракл 8. С тех пор вышли 9 и 10 и скорость их работы тоже на месте не стоит. Я не против М систем но если честно они на ассемблер похожи. Инексы сам делай. Все остальное тоже сам. Язык просто ужастный. Я видел листинги модулей на М старой системы. Если честно хуже чем ассемблер. Поддерживать сие чудо оказалось слишком хлопотным делом. Кучи циклов вложенных циклов никогда быстро работать не будут. Поверте мне. Задача прикладного программиста не придумывать алгаритмы доступа к данным ипостроения индексов а решать проблеммы учета в бизнесе. Если было бы не так все писалибы на С и ассемблере, где надо аждый раз заново велосипед изобретать.
22 мар 06, 11:40    [2475438]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
"я видел листинги модулей на М старой системы"

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

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

нельзя ?
22 мар 06, 11:43    [2475460]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
AndreiNz
Member

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

Уважаемый знаток MS SQL Server, прочитайте-ка про SET IMPLICIT_TRANSACTIONS.


Прочитал, вот здесь. В краце говорится, что у MS SQL есть проблема с соответствием ANSI SQL и чтобы хоть как-то притянуть его за уши поближе (именно так и сказанно closer) к стандарту придумали эту команду. А разве я не это пытался сказать?
22 мар 06, 13:38    [2476295]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
О, с127 признался шо чушь сказал как он приложения БД на sql пишет. Оказалося - использует более подходящие средства даже для того шоб убрать лишние пробелы. Дальше страшно копать. А продолжает врать: "Ни одного цикла, ни одной переменной". Непробиваемый демагог.
Шо sql - процедурный язык, уступающий mumps, енто итак ясно было. Вспомнилось однако как эти же спецы возмущались команде set, типа устарело. А сами сэтят как миленькие.
Угомонися, mir. Код не дописан и не работает (господа sql-щики даже не знают шо делает LTRIM). Када будет написано то шо делает $$S от Sergo Gromov, тада посмотрим. Давайте, соберитесь с силами, може еще получится.
22 мар 06, 21:46    [2478483]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
М программист
Guest
Страшную историю рассказал джокер. Расчет дебеторской задолженности на таких объемах и с таким числом пользователей проходит в Cache примерно за 15 минут (а не за полчаса, как предположил MX--ALEX). Надо еще железо сравнить. Может слабая тачка у оракула. А связаться с М программистами у MX--ALEX не получится. Нет их в природе.
22 мар 06, 22:06    [2478532]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
О чем договариваться, Выбегалло ? Я же не ребенок. Зачем я буду называть ручные блокировки автоматическими ? Ручные блокировки иногда нужны, но автоматические обязаны быть. Так же как и индексы. Конечно автоматические, но одно удовольствие, когда ты можешь прочитать из индекса так же естественно, как из данных.
22 мар 06, 22:37    [2478647]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
MX -- ALEX

странно
обьемы вроде бы не очень большие..
полчаса с запасом должно хватить

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

токарь
О, с127 признался шо чушь сказал как он приложения БД на sql пишет. Оказалося - использует более подходящие средства даже для того шоб убрать лишние пробелы.

Не использую я вообще никаких средств для убирания лишних пробелов в середине строки, поскольку такая задача не встречалась ни разу. Но если бы встретилась, то возможно решал бы ее примерно так, как тут предложилили:
SELECT REPLACE(REPLACE(REPLACE(RTRIM(LTRIM(@fld)), ' ', ' '+char(1)), char(1)+' ',''),char(1),'')
Но похожие задачи встречались, решались на клиенте, но не потому что РСУБД это сделать не в состоянии, а потому что так было удобнее по другим условиям задачи.

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

токарь

Дальше страшно копать. А продолжает врать: "Ни одного цикла, ни одной переменной". Непробиваемый демагог.

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

токарь

Шо sql - процедурный язык, уступающий mumps, енто итак ясно было.

Какой процедурный, что Вы плетете. Если в языке используются вызовы процедур, то это еще не значит, что он процедурный, грамотей. А бинарная операция '+' Вас не смущает? Это ведь тоже процедура.
22 мар 06, 23:26    [2478754]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Дельфийская убогость
Guest
От бяда, так бяда.....растраение ЧАЛовеческой личнасти, острае висенние абастрение... а кто же такую пургу про "читать из индесков"...экое чудило...чё там читать та?... смещение ат начала файла? давай, читай чудик, раз тебе это "одно удовольствие"....видал я разных мазахистов, но такое извращение...ФУУУУ....
22 мар 06, 23:29    [2478764]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
MX -- ALEX
"я видел листинги модулей на М старой системы"

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

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

нельзя ?


1. Начнем с того что я не начальник.
2. То что вы с ними хотите поговорить не означает что они хотят общаться с вами.
Про жуткий и идиотский синтаксис М я говорю потому что в свое время пришлось писать на ассемблере достаточно большой проект. Удовольствие я вам скажу еще то. Так вот листинги на М примерно то-же самое. Если писал другой человек то разобраться крайне сложно. Вы кичитесь тем что можно 1 буквой целый оператор записать. С моей точки зрения это зло. Читабельность программ просто нулевая.
М, по моему мнению, похож на курсовую работу студента по построению интерпритатара. Им даже лень было нормально сделать разбор порядка математических операций. Если в математике принято что 3+2*3 = 9 то в М 3+2*3=15 (круто не прав да ли ) Причем М, видимо писали люди без математического образования.

Про то какими методами пытаются ускорить работу циклов даже на ассемблере могу рассказать. М в Каше на сколько я знаю это тоже самое что pl/sql в оракле. Т е есть интерпритатор который выполняет скрипты. Одной из серьезных проблем в производительности интерпритирующих языков является низкая скорость выполнения циклов. Возмите любые тесты например VB6. В тех тестах где интенсивно используюся циклы он на порядки проигрывает компиляторам. В M скриптах циклы используюся постояно для работы с данными. От этого всегда стремились уйти так как неэффективно гонять цикл по миллиону строк внутри которого выполняется например цикл обрабатывающий 1000 строк. Надеюсь не надо объяснять почему. К тому же нет типизации т.е.все храниться в строках переменной длинны. Работа со строками одна из самых медленных операций (необходимо постояно выделять освобождать память, следить за длинной и т.д. на все это нужно время и ресурсы). Все это негативно сказывается на производительности. И не надо людям пудрить мозги насчет того что InterSystem все эти проблеммы решили каким-то чудесным непостижимым образом.
Далее. Стоит Каше больше чем Оракл. За эти деньги в Каше я получаю конструктор где все надо делать самому (индексы например и поддерживать их, следить за целостностью т.к. автоматических транзакции нет и т.д.) Возникает вопрос за что я плачу такие нехилые деньги? Нормальных книг по Каше на русском например нет или их очень мало. По ораклу или SQL Server их на несколько порядков больше причем можно скачать обсолютно бесплатно. Все основные инструменты разработчика поддерживают Oracle (VS, Delphi, VB, PowerBuilder и т.д.). Каше этим похвастаться не может. Я уже не говорю что есть куча как платных так и бесплатных инструментов для администрирования Оракла. В Каше кроме их убогого и глючного Enterprise manager практически ничего нет. Только не надо говорить что все можно разработать самому. Если я плачу достаточно большие деньги то я хочу в замен получить готовую систему которая позволит мне решать конкретные задачи (например учет чего-либо) а не сидеть и ломать голову как бы сделать индекс и поддерживать его актуальность. Если вам нравиться такой подход вперед дерзайте. Купите кубаметр железа, резину, набор инструментов и. т. д. за цену Феррари и сделайте её сами. Сомневаюсь что у вас что-либо стоющее получиться. А если и получиться то на это столько времени и сил уйдет что на заводе за это время и с затратой таких же усилий 10 машин выпустят. У М систем есть своя ниша для применения. Но она небольшая о чем свидетельствует её распространенность в мире и то что большие компании не стремяться поддерживать данную технологию (Если бы они была действительно так хороша как выставляют её сторонники то компании типа Microsoft, IBM или Oracle авно уже скупили бы их на корню как всегда делали с сильными конкурентами).
23 мар 06, 04:17    [2478966]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 20 21 22 23 24 25 26 [27] 28 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить