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

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

Вы, судя по изобилию COMMITов, вы работаете сoracle. Дак почему бы вам не сказать, что даже в этой области RDBMS разных производителей существенно отличаются. Так oracle постоянно находится в состоянии транзакции и если вы забудете вызвать COMMIT, то все ваши изменения потеряются. А MS SQL наоборот требунт явного задания начала и конца транзакции.

А что до ошибок, так я все это в обеденный перерыв набивал, на клавиатуре без русских букв - тоесть вслепую. А когда обнаружил, что обед уже закончился, тут у меня ошибки и посыпались. Зато вы все поставили на место.
21 мар 06, 10:15    [2470231]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Дело не в изобилии COMMIT-ов. Я хочу увидеть на MUMPS транзакции с уровнями изоляции, без которых многопользовательская работа любого сервера не возможно. Соотеетствующе я привел пример на SQL, чтобы посмотреть примерную реализацию на MUMPS.

P.S. Работаю я вообще то с ASA, у которой любой DML автоматически приводит к старту транзакции. Можете поставить перед каждым DML оператор BEGIN TRAN, чтобы не смущаться :)
21 мар 06, 10:25    [2470289]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Ц4
Guest
иначе вопрос ASCRUS формулирую:

какова модель транзакций в MUMPS?
21 мар 06, 10:32    [2470327]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
токарь
с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 сделал. Тада посмотрим хто из нас чушь гаварит.

А чё так мелко? В начале, в конце...
Универсалка от меня убирает символ @sim везде!
update tbl set fld=replace(fld, @sim,'')
21 мар 06, 11:56    [2470895]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
AndreiNz
ASCRUS,

Вы, судя по изобилию COMMITов, вы работаете сoracle. Дак почему бы вам не сказать, что даже в этой области RDBMS разных производителей существенно отличаются. Так oracle постоянно находится в состоянии транзакции и если вы забудете вызвать COMMIT, то все ваши изменения потеряются. А MS SQL наоборот требунт явного задания начала и конца транзакции.

Уважаемый знаток MS SQL Server, прочитайте-ка про SET IMPLICIT_TRANSACTIONS.
21 мар 06, 12:06    [2470965]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
SergSuper
токарь
с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 сделал. Тада посмотрим хто из нас чушь гаварит.

А чё так мелко? В начале, в конце...
Универсалка от меня убирает символ @sim везде!
update tbl set fld=replace(fld, @sim,'')

Или с пробелами вот так вот:
DECLARE @fld VARCHAR(1000)
SET @fld = '   sdfbsdbvds d dfgb dfgdfb  fdgdfgn  fgdfgndfn   '
SET @fld = REPLACE( RTRIM(LTRIM(@fld)), '  ', ' ')
SELECT @fld
И все это без страшных программок, похожих на ключ для криптоалгоритма
21 мар 06, 12:13    [2471018]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
SergSuper
токарь
с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 сделал. Тада посмотрим хто из нас чушь гаварит.

А чё так мелко? В начале, в конце...
Универсалка от меня убирает символ @sim везде!
update tbl set fld=replace(fld, @sim,'')


тогда в М :
s str=$tr(str," ")
--------------------------------
но здесь то речь про другое -
M-вариант убирает "дубликаты" - то есть один символ вместо нескольких
подряд идущих в тексте - оставляет .

Ваша универсалка вычистит ВСЕ @sim
21 мар 06, 12:16    [2471036]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
mir
..........
Или с пробелами вот так вот:
DECLARE @fld VARCHAR(1000)
SET @fld = '   sdfbsdbvds d dfgb dfgdfb  fdgdfgn  fgdfgndfn   '
SET @fld = REPLACE( RTRIM(LTRIM(@fld)), '  ', ' ')
SELECT @fld
И все это без страшных программок, похожих на ключ для криптоалгоритма


ещё вопрос - что страшнее :)

и опять неправильно ..
21 мар 06, 12:30    [2471144]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
странно, но за весь топик никто еще не вякнул, что данные в объеме хранить удобнее, чем на плоскости.
А так поржать хотелось....
Да, а на asm код никому не выложить, с просьбой повторить на зиге-заге, мампсе, и прочем? Или таки кесарю - кесарево, а слесарю - слесарево?
И для обработки согласно бизнес логике найденных в базе данных - один язык, а для нахождения тех данных - другой. С разделением ролей и разделением инструментов.
Вот для бизнес логики все больше моделирование используется в индустрии, с такими вещами, как BPEL, и не кесарево это дело - искать/сохранять данные.
База данных - сервис персистентности или перманентности (как, кстати, правильно), всего лишь сервис, обслуживающий бизнес потребности, но никак не средство от перхоти, и от всего прочего.
И теннденция заставлять базу делать все - не совсем правильно. Хоть это, видимо, и не всем очевидно, блин.
21 мар 06, 12:38    [2471182]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
ggv
странно, но за весь топик никто еще не вякнул, что данные в объеме хранить удобнее, чем на плоскости.
А так поржать хотелось....
Да, а на asm код никому не выложить, с просьбой повторить на зиге-заге, мампсе, и прочем? Или таки кесарю - кесарево, а слесарю - слесарево?
И для обработки согласно бизнес логике найденных в базе данных - один язык, а для нахождения тех данных - другой. С разделением ролей и разделением инструментов.
Вот для бизнес логики все больше моделирование используется в индустрии, с такими вещами, как BPEL, и не кесарево это дело - искать/сохранять данные.
База данных - сервис персистентности или перманентности (как, кстати, правильно), всего лишь сервис, обслуживающий бизнес потребности, но никак не средство от перхоти, и от всего прочего.
И теннденция заставлять базу делать все - не совсем правильно. Хоть это, видимо, и не всем очевидно, блин.

ну дык так и работаем

--MUMPS нашел
--отдал excel-у
--excel все посчитал-разложил красиво

-- блин
21 мар 06, 13:20    [2471429]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
MX -- ALEX
mir
..........
Или с пробелами вот так вот:
DECLARE @fld VARCHAR(1000)
SET @fld = '   sdfbsdbvds d dfgb dfgdfb  fdgdfgn  fgdfgndfn   '
SET @fld = REPLACE( RTRIM(LTRIM(@fld)), '  ', ' ')
SELECT @fld
И все это без страшных программок, похожих на ключ для криптоалгоритма


ещё вопрос - что страшнее :)

и опять неправильно ..
DECLARE @fld VARCHAR(1000)
SET @fld = '   sdfbsdbvds d dfgb             dfgdfb     fdgdfgn  fgdfgndfn   '
SELECT REPLACE(REPLACE(REPLACE(RTRIM(LTRIM(@fld)), ' ', ' '+char(1)), char(1)+' ',''),char(1),'')
21 мар 06, 13:24    [2471459]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
MX -- ALEX
mir
..........
Или с пробелами вот так вот:
DECLARE @fld VARCHAR(1000)
SET @fld = '   sdfbsdbvds d dfgb dfgdfb  fdgdfgn  fgdfgndfn   '
SET @fld = REPLACE( RTRIM(LTRIM(@fld)), '  ', ' ')
SELECT @fld
И все это без страшных программок, похожих на ключ для криптоалгоритма
ещё вопрос - что страшнее :)
и опять неправильно ..
Ну, по поводу "страшноты" вопросов-то как раз быть не может, хе-хе. А по поводу неправильности, я сначала понял, что просто надо удалить двойные пробелы в середине и все пробелы по бокам. Решение такое и привел, абсолютно правильное. Ежели надо создать пользовательскую функцию, удаляющую все подстроки пробелов, длиннее 1, то вот вам вариант кода:
CREATE FUNCTION aaa( @fld VARCHAR(1000) ) RETURNS VARCHAR(1000)
AS
BEGIN
  DECLARE @t VARCHAR(1000)
  WHILE (1=1)
  BEGIN
    SET @t = REPLACE(@fld, '  ', ' ')
    IF @t = @fld
      BREAK
    SET @fld = @t
  END
  RETURN LTRIM( RTRIM(@fld) )
END
Вызов:
SELECT dbo.aaa ( '   sdfbsdbvds d dfgb dfgdfb            fdgdfgn  fgdfgndfn   ' )
21 мар 06, 13:56    [2471651]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Павел Воронцов
MX -- ALEX
mir
..........
Или с пробелами вот так вот:
DECLARE @fld VARCHAR(1000)
SET @fld = '   sdfbsdbvds d dfgb dfgdfb  fdgdfgn  fgdfgndfn   '
SET @fld = REPLACE( RTRIM(LTRIM(@fld)), '  ', ' ')
SELECT @fld
И все это без страшных программок, похожих на ключ для криптоалгоритма


ещё вопрос - что страшнее :)

и опять неправильно ..
DECLARE @fld VARCHAR(1000)
SET @fld = '   sdfbsdbvds d dfgb             dfgdfb     fdgdfgn  fgdfgndfn   '
SELECT REPLACE(REPLACE(REPLACE(RTRIM(LTRIM(@fld)), ' ', ' '+char(1)), char(1)+' ',''),char(1),'')

во !
теперь правильно ..
и красиво ..
super !
не то что mumps ублюдучны криптал... скриптул .. тьфу .. блин
21 мар 06, 14:03    [2471693]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
это работа по парсингу/изменению строки - называется работа для языка работы с данными???
Нафик-нафик.... К терапевту...
21 мар 06, 14:07    [2471721]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
MX -- ALEX
во !
теперь правильно ..
и красиво ..
super !
не то что mumps ублюдучны криптал... скриптул .. тьфу .. блин
Вы лучше про транзакции ответьте. Или про то как в разных М-системах сделано автоматическое обновление индексов.

Понимаете какая штука. Мне вот например по барабану на чём делать информационные системы. И принципы при выборе той или иной технологии именно те, что декларируете Вы - простота разработки, изменений и сопровождения. Эти требования выливаются в требования к надёжности и предсказуемости используемой технологии. И вот наличие поддержки транзакционности - это жизненно необходимое качество. Я должен точно знать как это делается. А Вы отчего-то не рассказываете подробностей. И так со всем, чего ни коснись. Вы же сами впечатление о М портите своим нежеланием отвечать на конкретные вопросы. Мне вот к примеру действительно интересно. Теоретически интересно. Хотя наверняка там ничего сильно нового нет...
21 мар 06, 14:13    [2471760]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Павел Воронцов
MX -- ALEX
во !
теперь правильно ..
и красиво ..
super !
не то что mumps ублюдучны криптал... скриптул .. тьфу .. блин
Вы лучше про транзакции ответьте. Или про то как в разных М-системах сделано автоматическое обновление индексов.

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



http://www.intersystems.com/cache/downloads/index.html

нам все равно не поверят
21 мар 06, 15:36    [2472296]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Павел Воронцов
Или про то как в разных М-системах сделано автоматическое обновление индексов.
Мне вот к примеру действительно интересно. Теоретически интересно. Хотя наверняка там ничего сильно нового нет...

Автоматического нет. Чтобы было, пишут функции типа СохранитьЗапись, УдалитьЗапись, в которой перестраиваются индексы.
Есть материалы скорее учебного характера.
тынц, что-ли справа оглавление.
Но поскольку стандарт ничего такого не требует, никак не способствует и никак не препятствует, то обычно пишут кому какой надо струмент под его понимание модели данных. У кого-то пишется ручками, у кого-то автоматический генератор, у кого-то разные комбинации, тут никто никого не ограниивает. По ссылке в учебных материалах организация данных аналогична таблицам как массивам однородных объектов с простым структурированием. Чтобы предупредить очередные выходки скулистов (ну устали они меня уже), теперь уже специально напишу - материалы по ссылке не про организацию данных, а про принципы организации индексов и принципы операций с ними.
21 мар 06, 16:26    [2472571]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Павел Воронцов
И вот наличие поддержки транзакционности - это жизненно необходимое качество. Я должен точно знать как это делается. А Вы отчего-то не рассказываете подробностей.

Ну, наверно, документацию пересказывать мало кто возьмется, разве что те кто постоянно рвется других поучать. Есть тут на форуме такие. Тут обычно пишут RTFM, но мне не влом.
В двух словах - в стандарте транзакции есть. В реализациях транзакции в действительности работают и доделаны не во всех системах. В каше есть. Другой вопрос что понимать под транзакциями. Если интересует изолированность транзакций - то в каше это грязное чтение и разруливать нужно своими блокировками. Своими - значит что есть такая команда, lock называется. Пишем что именно и как лочить. Никакие реализации, в том числе каше, не будут ничего лочить и тем более автоматически, ибо стандарт. Но автоматически сгенерированные коды, например по выражениям &sql() или по коду классов могут содержать полагающиеся в соответствии с их моделью данных блокировки.
По умолчанию у процесса нет транзакции, вызов роллбека ничего не даст, вызов коммита даст ошибку. Почему такая разная реакция - к разработчикам каше. Транзакция начинается явно командой tstart, повышает на 1 уровень транзакции. Для процесса уровень 0, если не было ts. Каждый tcommit подтверждает уровень транзакции на единицу. trollback откатывает по журналу все до уровня транзакции 0. Максимальный уровень вложения транзакций 255.
Процессу можно выставить состояние что пока оно не убрано в журнал не идут записи о действиях с хранимыми переменными. Их изменение при откате не откатится. Можно выставить именам переменных что их не журналировать, их изменение тоже не откатится.
Если лок был поставлен в транзакции, то его снятие по умолчанию не приводит к его снятию до конца транзакции. Можно снять лок до окончания транзакции специальным указанием типа "снять непостредственно сейчас".
В принципе, это все. Остальное - детали генераторов кода по выражениям &sql() и по объектному синтаксису, или у кого еще какие автоматические генераторы кода.
21 мар 06, 16:51    [2472702]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Со стороны сильно напоминает конструктор лего, набор "собери сам действующую модель многопользовательской субд".

В таком вот аксепте
21 мар 06, 19:45    [2473530]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Глубокое впечатление произвела на меня фраза с127:
"Доступ к индексу это доступ к тому чего нет. Разумеется он прямой. Или есть индексы ? Или нет ? Сами разберитесь сначала."
Видимо это что-то очень тонкое. У меня не получилось разобраться.
Еще большее впечатление от вопроса: "МУМПС==М ?".
И опять очень интересно про критерии. Я не скажу (и других очень прошу), что с127 брякнул от фонаря, когда он расскажет про свои критерии выбора. Заранее считаю, что они хорошо научно обоснованы.
Так и не понял что все-таки не получилось при инсталляции ?
21 мар 06, 20:05    [2473581]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

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

Rus000

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

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


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

1.
SELECT Р.Дата,М.Самолет->ТипСамолета
FROM РАСПИСАНИЕ Р,САМОЛЕТ_МЕСТА М 
WHERE Р.САМОЛЕТ=М.САМОЛЕТ 
AND М.Места_Пассажир='Scott Tiger'
AND Р.Дата in ('2003-01-01','2003-01-09','2003-01-12','2003-01-13','2003-01-18','2003-01-22','2003-01-28','1924-07-04')

2.
SELECT *
FROM РАСПИСАНИЕ Р,САМОЛЕТ_МЕСТА М 
WHERE Р.САМОЛЕТ=М.САМОЛЕТ 
AND М.Места_Статус<2
AND Дата between '2003-01-01' and '2003-01-31' 
AND М.Самолет->ТипСамолета<>'ТУ-154'
GROUP BY Р.Дата,Р.НомерРейса
HAVING (((SELECT COUNT(*) FROM САМОЛЕТ_МЕСТА ММ WHERE ММ.САМОЛЕТ=Р.САМОЛЕТ) - COUNT(*)) BETWEEN 10 AND 20)

c127

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


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

c127

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


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

c127

Не хотите - идите против всех, на здоровье, но не советую.


а то что?

c127

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


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

Ладно, закрыли тему индексов - уже не интересно.


c127

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


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

c127

c127

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

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

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


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

c127

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

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

с127

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

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

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


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


c127

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


см.выше

с127

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


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

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

c127

c127

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

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

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


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

c127

Но возможно мне просто не повезло и рынок полон М системами, я эту возможность допускаю и поэтому пытаюсь задавать тут вопросы.
Приведите хоть какую-нибудь статистику, только желательно независимую.


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

с127

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

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


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

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

c127

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


вес не главное даже в боксе, а уж в мире СУБД и подавно :)
21 мар 06, 20:40    [2473646]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
От SergSuper сквозь mir и Павла Воронцова и опять до mir код рос как на дрожжах, но так и не был написан ! Сначала vadiminfo не смог написать код ни на pl ни на с. Таперича сразу три спеца не смогли написать код даже на sql. Даже не ожидал что Sergo так велик (см. что делает его код, бедолаги).
А чо set переменная=значение это чистый sql ? Ну прям чистый mumps. И begin, if, end это чистый sql. Надо же как развился. И функции строковые включили в "декларативный язык запросов". Неплохо. Но код написать все равно не получилось. И забормотал тада ggv, шо его и не надо писать ваще. Молодца !
21 мар 06, 21:08    [2473711]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Выбегалло познал истину. Или угадал - не суть важно. Только не действующую модель, а собственно СУБД с автоматическими индексами, будь они неладны, транзакциями, автоматическими блокировками, и, естественно, с наилучшей, с точки зрения "сборщика", моделью данных.
21 мар 06, 21:28    [2473758]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
дык и не надо изврат писать на SQL.
Для этого надо С использовать. А вот С можно обернуть и в функцию SQL. Если надо.
И вообще. Если уж так сравнивать, то BerkeleyDB - гораздо круче Каш и Мумпсов.
Не привязывает программиста к "птичьему" языку, можно использовать множество.
Оперирует только парами "ключ - значение", что позволяет построить любую модель данных, хоть иерархическую, хоть сетевую, вообще любую.
Транзакции в наличии, опять же.
Отсутсвует необходимость в обучении - языка то нету.
Отсутсвует необходимость в администрировании.
В наличии множество прикладных иснтрументов, построенных над BerkeleyDB, и позволяющих быструю разработку в целевой предметной области.
И при всем при том уважаемый, честный продукт - правильно себя позиционирует, не обещая решения всех проблем и избавления от перхоти.
При чем может похвастатся огромным кол-вом внедрений, от OpenSource как OpenLDAP, так и коммерческих, типа SUN-овского iPlanet LDAP, ну и у них на сайте можно глянуть еще.
Как-то после всех топиков, затрагивающих мумпсы с кашами, интерес к ним все меньше и меньше. IMHO.
21 мар 06, 22:24    [2473928]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
MX -- ALEX
c127
MX -- ALEX

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

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

MX -- ALEX

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

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

MX -- ALEX

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

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


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


Я сказал что я НАДЕЮСЬ что его у меня никогда не будет. Это был ответ на замечание что, что всякий легко может проверить, копирует ли ексель 97 больше 255 символов в ячейку. Проверить легко, если ексель 97 установлен.

MX -- ALEX

А вообще Вы где-нибудь его видели ?


Каюсь, ексель 97 давно не видел. А Вы все боретесь с его ограничениями.

Зачем Вы лезете на рожон? Вы написали:
"Посоветуйте - что можно применить ?
Притом это действительно важно - без шуток."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=24#2465790

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