Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 69 70 71 72 73 [74] 75 76 77 78 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31631
iscrafm
DocAl
iscrafm

И у Вас тоже спрошу... А как же глобали? Какую БД в M-коде Вы ищите?
Какие вы видите глобали в постановке задачи?

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


Нет постановки задачи - два куцых примера. Эталонного кода тоже нет. Кортеж от множества не отличаем, какие-то строки с братьями приплели невесть зачем.
На исходную задачу - только намёки - https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=72#3611394
для решения этой задачи ИМХО вовсе не нужно строить вспомогательную базу в таком виде - достаточно глобала ^E (E,N) (и ^e(N,E) - издержки иерархической структуры)
автор
^y и y^z - это для нас одна и та же строка. Я ж говорил - порядок элементов в строке роли не играет. Если такие две строки будут на входе - они будут считаться братьями. Но генерировать две штуки не надо. Достаточно одной.
- Достаточно или необходимо? Как результаты сравнивать будем?
7 янв 07, 11:57    [3611812]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Ptn

>>Ну как бы все берут прото язык БД.
Замечательно берите его - слово "внутренний" появилось исключительно из предложенных оппонентами Pyton и PHP. Так яснее ?

>>Ну у него есть расширения в СУБД. Например, у ОРАКЛА PL/SQL.
Замечательно - вы поймите простую вещь - если у мумпсеров или кашистов спросять пример чего-либо - они его дадут на М. Потому что это так и есть на самом деле.

А в ответ нам говорять да я на С, С++, PHP, Python и т.д т.п.

Ну и что тут делать ? - приходится объяснять почему пример на М ! Ибо я точно так же могу реализовать пример для каши с использованием С, С++, PHP, Python и т.д т.п.

Давайте сравнивать c PL/SQL.

Аббревиатура UDF вызывает у вас какие-либо ассоциации? Это о том, откуда берутся C(++) и Java.
Пример на PHP был приведён просто потому, что а) показывает, что задача не имеет ни малейшего отношения к СУБД и б) потому что у PHP достаточно понятный C-подобный синтаксис, который, IMHO, конечно, будет более понятен для большинства читателей, чем конструкции типа "^ s f a" M-решения.
А на Python пример привели просто чтобы показать, что арифметика для чисел произвольной длины может быть и встроенной.
7 янв 07, 12:00    [3611814]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
decaml
Member

Откуда:
Сообщений: 228
Итак, мы подходим к лекарству от диабета.
Это просто – кусочек рыбки, натуральный контейнер «строк» для синтеза + стаканчик сухого винца + соль.

В маленькой рыбке больше «строк», чем в большом баране.
Потому что баран питается травой, а рыба – микробами, те же в свою очередь занимаются комбинаторикой с утра до вечера.

Сухое винцо – для желудочного сока, движка омоложения.
А соль – это электропроводность нервной системы, гипертранспорт команд синтеза и переваривания.

Хватает «строк» - железы синтеза работают.
Не хватает – не работают.

Поэтому надо заниматься р-ы-б-о-в-о-д-с-т-в-о-м.
Не лишне вспомнить, что зимой трава не растет, а вот синтез «строк» подо льдом наверно продолжается :-)

мораль - надо разводить радужную форель на даче на артезианской проточной воде.
И все будет ништяк.
7 янв 07, 12:12    [3611821]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31631
DocAl

у PHP достаточно понятный C-подобный синтаксис, который, IMHO, конечно, будет более понятен для большинства читателей, чем конструкции типа "^ s f a" M-решения.


Ничего особо страшного в синтаксисе M - нет.
Благодаря уcилиям V52 и iscrafm - пришлось освоить, пару часов заняло, использовал для изучения http://math-cs.cns.uni.edu/~okane/source/MUMPS-MDH/compiler.html
7 янв 07, 12:12    [3611822]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Изопропил
DocAl

у PHP достаточно понятный C-подобный синтаксис, который, IMHO, конечно, будет более понятен для большинства читателей, чем конструкции типа "^ s f a" M-решения.


Ничего особо страшного в синтаксисе M - нет.
Благодаря уcилиям V52 и iscrafm - пришлось освоить, пару часов заняло, использовал для изучения http://math-cs.cns.uni.edu/~okane/source/MUMPS-MDH/compiler.html

это же хорошо! Будете понимать о чем речь идет. А то в этом топике спорят не зная что имеет ввиду оппонент обычно :)
7 янв 07, 12:27    [3611830]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
))
Guest
iscrafm
в постановке нет конечно глобалей, есть требование хранить информацию. Как хранится информация в MUMPS и что является БД надеюсь знаете (в споре же учавствуете). Они (база данных) есть в решении автора.

1. в постановке задачи нет требования хранить информацию
2. информация уже хранится в исходном файле
3. я действительно не понимаю что написано на языке му, кажется там манипулируют миллиардами строк во вложенных циклах...
7 янв 07, 13:11    [3611873]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
decaml
Итак, мы подходим к лекарству от диабета.
Это просто – кусочек рыбки, натуральный контейнер «строк» для синтеза + стаканчик сухого винца + соль.

В маленькой рыбке больше «строк», чем в большом баране.
Потому что баран питается травой, а рыба – микробами, те же в свою очередь занимаются комбинаторикой с утра до вечера.

Сухое винцо – для желудочного сока, движка омоложения.
А соль – это электропроводность нервной системы, гипертранспорт команд синтеза и переваривания.

Хватает «строк» - железы синтеза работают.
Не хватает – не работают.

Поэтому надо заниматься р-ы-б-о-в-о-д-с-т-в-о-м.
Не лишне вспомнить, что зимой трава не растет, а вот синтез «строк» подо льдом наверно продолжается :-)

мораль - надо разводить радужную форель на даче на артезианской проточной воде.
И все будет ништяк.

Тонко подмечено. И PHP имеет перл-подобный синтаксис
7 янв 07, 13:16    [3611879]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
V52
Guest
Я должен извиниться за отсутствие ограничений которое привело к генерации слишком большого выходного файла. Нам большой файл ни к чему потому как мы его не сможем переслать через этот форум (действует ограничение в 100 кб). Потому я даю новый входной файл из 1000 строк, ввожу ограничение на главный цикл - выход после обработки 1000 записей глобала ^S, и вывод результатов в выходной файл для 500 первых строк глобала ^S. Также исключаем повторное порождение родителя который уже однажды был порожден. Привожу полный синтаксис окончательного кода (с учетом вышеперечисленных ограничений) .

MR ;
; Read input file
;
Open "IN" Use "IN" Set N=0 Kill ^S,^E
For Read S Quit:$Zeof Set N=N+1,^S(N)=S For i=1:1:$Length(S,"^") Set ^E($Piece(S,"^",i),N)=""
Close "IN"
;
; Make relations
;
Set (N,N1,counter)="" Kill ^T
For Set N=$Order(^S(N)) Quit:N="" Set S=^(N) Kill ^M Do Set counter=counter+1 Quit:counter'<1000
. For i=1:1:$Length(S,"^") Set E=$Piece(S,"^",i) Do
. . For Set N1=$Order(^E(E,N1)) Quit:N1="" If N1'=N Set ^M(N1,i)="+",^M(N1)=$Get(^M(N1))+1
. For Set N1=$Order(^M(N1)) Quit:N1="" Do
. . If ^M(N1)=$Length(S,"^") Do Quit
. . . If $Length(^S(N1),"^")=$Length(S,"^") Set ^S(N,"B",N1)="",^S(N1,"B",N)="" Quit
. . . Set ^S(N,"C",N1)="",^S(N1,"P",N)=""
. . If ^M(N1)=$Length(^S(N1)) Set ^S(N1,"C",N)="",^S(N,"P",N1)="" Quit
. . Set (SP,i)="" Kill T
. . For Set i=$Order(^M(N1,i)) Quit:i="" Set T($Piece(S,"^",i))=""
. . Set E="",i=0 For Set E=$Order(T(E)) Quit:E="" Set i=i+1,$Piece(SP,"^",i)=E
. . If '$Data(^T(SP)) Do
. . . Set NP=$Order(^S(""),-1)+1,^S(NP)=SP,^T(SP)=NP
. . . For i=1:1:$Length(SP,"^") Set ^E($Piece(SP,"^",i),NP)=""
. . Else Set NP=^T(SP)
. . Set ^S(N,"P",NP)="",^S(NP,"C",N)="",^S(N1,"P",NP)="",^S(NP,"C",N1)=""
;
; Write output file
;
Open "OUT":newversion Use "OUT" Set (N,N1,counter)=""
For Set N=$Order(^S(N)) Quit:N="" Do Set counter=counter+1 Quit:counter'<500
. Write ^(N),! For i="Parents","Children","Brothers" Do
. . Write i,! For Set N1=$Order(^S(N,$e(i),N1)) Quit:N1="" Write ^S(N1),!
. Write !
Close "OUT"
Quit

Просьба к Выбегалло: - Когда будете демонстрировать своего кадавра, то, пожалуйста, в полный рост и с приложением выходного файла (результаты для 500 первых строк).
Ко всем остальным - то же самое.
Плюс укажите время выполнения и характеристики компутера.

Также даю краткое пояснение о работе с БД в моем примере для тех, кто не имеет представления о том, как это делается в М:
При считывании строк входного файла их информация заносится в БД в два глобала
^S(N)=S где N-порядковый номер строки в файле, S - собственно строка.
^E(E,N)="" где E - элемент строки
Определенные (и сгенерированные) отношения фиксируются тоже в глобале ^S в виде
^S(N,"Relation",N1)="" где Relation может быть равна "Parents", "Children" или "Brothers".
Глобал ^T используется для исключения дублирования сгенерированных строк.

К сообщению приложен файл (IN.tar.gz - 15Kb) cкачать
7 янв 07, 15:01    [3611984]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30290
приводимая задача и ее решение показывают, что

1. в Mumps можно хорошо организовывать циклы
2. в Mumps есть функции для работы со строками
3. в Mumps можно быстро сохранить массив большого размера
4. можно обработать этот массив используя пункты 1 и 2

собственно, ничего больше я не вижу.

p.s. пожалуйста, не надо доказывать прелести Mumps по крайней мере мне. я на нем работал весьма интенсивно 3 года, около 15-16 лет назад. в это же время занимался структурами хранения данных, и хорошо себе представляю не только M, но и как данные хранятся. Впоследствии я перешел на РСУБД, о чем нисколько не жалею, и обратно к M возвращаться не хочу ни в каком виде - ни как M, ни как Cache с его SQL и объектными надстройками.

А приведенную задачу я бы точно также мог решить при помощи Pascal + любой библиотеки (возможно, слегка модифицированной), которая реализует доступ к страничным b-деревьям.
7 янв 07, 15:43    [3612028]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

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

Вопрос был другим. ;) Не нужно так передергивать.

Значит я не понял про что был вопрос. Но главное в Джаве язык, а в СУБД МД, которую(ые) она поддерживает. По крайней мере, как правило, без этого она предмет выбора редко рассматривается. Ну может быть, только отпетыми ассемблиристами, и потому готовых программировать что угодно и на чем угодно и сколь угодно долго.


Ptn

>>В книге "Базы данных" Конноли он упоминается как язык.
И что ?

Это означает обоснование сомнений в том, М - СУБД. Если бы везде про M писали (тем более люди пограмотнее нас с Вами), что это СУБД, то вопроса бы не было.

Ptn

А должна ?

Если она серьезная СУБД, претендующая на постреляционность, замеченная серьезными спецами в ИТ, то ее появление там ожидалось.
Книга обощающего характера с тучей ссылок. Даже М там, правда, среди языков упомянут, правда в связи с поддержкой SQL.

Ptn

Есть SQL - БД называется SQL-сервер. Это общеупотребимое но некорректное название. И что дальше ?

Не понял к чему это.

Ptn

Мне кажется вы опять не поняли моей фразы - Если мне потребуется реализовать ЕЩЕ один поддерживаемый язык внутри СУБД - мне не потребуется ничего кроме СУБД. Её мне будет более чем достаточно.

Если для поодержания БД понадобится ЕЩЕ один язык входящий в лидеры языков (а не какой попало), то об этом позаботятся производители СУБД. Она собсно для того и нужна, чтобы мне ничего не понадобилось кроме СУБД по управлению БД. В Оракле внутри СУБД есть JAVA, В MS SQL С# (вроде и в Оракл для Виндов его собирались). Потому я, скорее всего, и не понял Вас.


Ptn

Нет не ставить

Этот форум этого не показывает. Я уже говорил про представителя Версанта (а это признанная ООСУБД и, в частности, упоминаемая среди ООСУБД в книге Коннолли) отрицал что Каша ООСУБД.
Подобные сомнения высказывались и другими.



Ptn

Согласен - вы хотите что бы я отвечал за ISC ?

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

Ptn

Их право

Проблема не в том, что это их право, а в том, что они им воспользовались.
Если бы не воспользовались, счас было бы все намного ясней.

Ptn

Да кстати раньше европейцы считали что у негроподоидных рас нет души.

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

Ptn

А что не так с МД ? Ведь вы Модель Данных имеете в виду ? или я недопонял малех?

Она пока никак не идентифицирована. Она не РМД. Это ясно. Она не ООМД? Вы сказали - ни разу М не ООП. Остаетются иерархические, сетевые. Некотоые представители М сказали, что иерархическая, другие отрицали. Или как ЧАЛ тут толкал - Дореляционная (она же по ЧАЛу классическая) ОМД. Так какая она? Если же М просто язык - то МД получается типа плоская. Т.е. без клиентского приложения, БД - просто набор байтов или близко к тому.

Ptn

Э-э-э ну вот я например считаю что "любую" и что дальше ?

В таком случае, М не просто СУБД, но и в частности РСУБД, т.е. на "общеупторебимом" - SQL - сервер. Или там другой реляционный язык (не SQL)?
Однако, Вы признаете, что это все еще не столь распространееная точка зрения? Ведь Кодд, автор РМД возражал, чтобы СУБД просто так без дополнительных оговорок называли РСУБД.


Ptn


Эту тему предлагаю обсудить с ёё автором. Я тут причем ?

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

Ptn


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

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

Ptn

По строгому определению М действительно нельзя назвать СУБД.
Но как раньше было принято говорить:
Говорим Ленин подразумеваем Партия. Говорим Партия подразумеваем Ленин.

Ну это другое дело. Уже больше ясности.

Ptn

М - это не средство _создания_ СУБД !!! посмотрим что вы напишите про cache.exe

Я всегда это подозревал. Ваше подтверждение укрепляет меня в такой оценке.

Ptn

Хм - это надо обсуждать в ветке по Каше. К сути здешней дисскуии это не имеет ровно никакого отношения.

Здесь ветка про сравнении Каши со Скулем (MSSQL). Ее социальная оценка мумпситами, мне все еще кажется, имеет значение. Если к ней негативно относятся мумпсисты, в то время как она "М-система", это, скорей всего, не такой уж и большой плюс в этом сравнении.

Ptn

подтверждение). Каша- СУБД
Мне казалось этот вопрос можно выяснить на сайте ISC ?

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

Ptn

Подзравляю вас - М это не ООП ЯП как я и говорил. что дальше ?

Это ставит под сомнение ООМД в М. А вы говорили любая МД в М.
Т.е. с любыми МД в М не все так очевидно.

Ptn

Кашисты упирают на тройственности доступа к данным - в ряде случаем это действительно привлекает внимание.

О "тройствености" МД. И если эти МД там сильно представлены, то это не просто в ряде случаев привлекло бы внимание, а просто поставило бы ее над всеми другими СУБД. И она бы реально претендовала быть постреляционной СУБД.

Ptn

Мне кажется это немного из разряда догоним и перегоним Америку - мы например никому вызов не бросаем - мы просто работаем.
С той лишь разницей что для решения широкого круга задач - нам не нужны сторонние продукты и доп программеры.

Т.е. Вы сравниваете только в плане кол-ва инструментов в линейке разработке? А их качество считаете заведомо равным? Может лучше разные специализированные на своих подзадачах, чем одно универсальное (интегрированное). Например, для клиентов лучше Джава или Дельфи или Басик, чем М. Для драйвероа - С. Для БД - СУБД (Пратия сильнее Ленина оказалась, не смотря на то, что подразумевали).
Да и насчет разницы - могие файлсерверные СУБД тоже ни в чем не нуждаются.Акцесс, Фокспро.

Ptn

На их сайте черным по белому написано что Каша не РСУБД - и на это же напирают в вопросах о тестах.

А как же про трействееность: ОО, Р и многомерность? Включает Р. Я так понял может выступать как РСУБД.


Ptn


Замечательно - вы поймите простую вещь - если у мумпсеров или кашистов спросять пример чего-либо - они его дадут на М. Потому что это так и есть на самом деле.



Да про мумпсеров то я понял. Не понял почему это может привлечь при выборе Каши против MSSQL. Меня то как и многих именно выбор интересут.

Ptn

А в ответ нам говорять да я на С, С++, PHP, Python и т.д т.п.
Ну и что тут делать ? - приходится объяснять почему пример на М ! Ибо я точно так же могу реализовать пример для каши с использованием С, С++, PHP, Python и т.д т.п.

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



Ptn

Давайте сравнивать c PL/SQL.

А там еще есть Джава. Однако, важнейшим в успехе РСУБД является именно SQL. Его декларативность, ассоциативность и достаточная полнота как языка БД. Это позволяет легко извлекать достаточно сложную информацию во многих случаях. Он не обладает вычислительной полнотой, в частности, потому понадобились императивные расширения типа PL/SQL. Но первые три качества слишком существенны перед этим недостатком. Потому сравнеие только с PL/SQL не поможет даже если М превзойдет его.

Ptn

А М с тех времен не сильно изменился IMXO

А в развитии языков с тех произошли кое-какие изменения. Т.е. это не плюс для М без дополнительных уточнений.

Ptn

>>Язык БД, который специализируется только на управлении БД
Проблема SQL что да - проблема М в том что нет - не только.

Язык SQL - именно специализированный язык БД. Поэтому не понял про какую проблему Вы говорите.
7 янв 07, 16:06    [3612044]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
V52
Guest
Позвольте мне сказать, что я считаю в М главным и в чем я вижу его преимущество перед Р системами.

Если вы обратили внимание на работу с базой данных в моем примере, то вы увидели, что работа программы со структурами данных, расположенными в БД, ничем не отличается от работы с локальными переменными или массивами, находящимися в оперативной памяти. Вся разница – в наличии символа “^” (caret или циркумфлекс) перед именем переменной. Нет символа – переменная в ОП, есть – переменная да диске в БД. Таким образом, база данных М системы является неограниченным расширением оперативной памяти и в ней могут быть сохранены любые структуры данных простым добавлением символа “^” перед именем переменной. Из этого вытекает также, что все команды и функции языка, работающие с какими-либо переменными, массивами или строками или с какими угодно структурами данных пригодны также для непосредственной работы с БД.

Теперь о модели данных. Кто-то когда-то где-то по своей неполноте знаний сказал, что М это иерархическая БД. Это подхватили сторонники Р концепции для того, чтобы можно было называть М СУБД иерархической и устаревшей, а мы, мол, работаем с Р, а это «суперсовременно». Модель данных М СУБД НЕ ИЕРАРХИЧЕСКАЯ. М СУБД МОЖЕТ хранить иерархические структуры, также как и реляционные таблицы, также как и сетевые и любые другие структуры. Изобразите нужную структуру данных в ОЗУ, добавьте спереди “^” и вы получите структуру БД. Т.е. М не зажата в рамках никакой парадигмы и Р это частный случай М.

Отсюда вытекает эффективность использования М. Кто бы что ни говорил, но программу написать – раз плюнуть, если известно, что и как надо писать. Т.е. основная трудоемкость программирования – разработка ОПТИМАЛЬНОГО алгоритма. Абсолютное отсутствие в М ограничений на структуры данных позволяет разрабатывать наиболее оптимальные алгоритмы за наименьшее время. Именно поэтому я являюсь его сторонником.

Да, в исходном М нет SQL и его центральной части – оператора SELECT. Потому что он НЕ НУЖЕН так как М позволяет строить алгоритмы с превалирующим ПРЯМЫМ обращением к данным, а не через механизм последовательной выборки. А для организации последовательной выборки можно организовать один-два цикла с условиями отбора, что по трудоемкости написания не превышает изображение SELECTa.

В итоге можно сказать, что М – это универсальная глобальная концепция, а Р – ее частный случай который сектанты возвели в ранг самостоятельной религии, воздвигли себе идола в виде оператора SELECT и пляшут вокруг него с бубнаим цепляя бусы и цветные лоскутки в виде всяких WHERE и FROM.

Пардон, немного занесло в конце, но надеюсь, последний абзац не помешал вам понять предыдущие.
7 янв 07, 20:29    [3612260]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
V52

Да, в исходном М нет SQL и его центральной части – оператора SELECT. Потому что он НЕ НУЖЕН так как М позволяет строить алгоритмы с превалирующим ПРЯМЫМ обращением к данным, а не через механизм последовательной выборки. А для организации последовательной выборки можно организовать один-два цикла с условиями отбора, что по трудоемкости написания не превышает изображение SELECTa.

А вы уверены, что "один-два цикла с условиями отбора" являются оптимальным решением такой задачи? Большинство РСУБД позволяет реализовать такой алгоритм использованием курсоров, только вот без обоснованной необходимости их использовать моветон: работает медленнее, чем "пляски с бубном вокруг SELECT, с бусами и лоскутками", а точнее, не поддаётся оптимизации построением индексов и т.п.
7 янв 07, 20:48    [3612273]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
V52
Позвольте мне сказать, что я считаю в М главным и в чем я вижу его преимущество перед Р системами.

Если вы обратили внимание на работу с базой данных в моем примере, то вы увидели, что работа программы со структурами данных, расположенными в БД, ничем не отличается от работы с локальными переменными или массивами, находящимися в оперативной памяти. Вся разница – в наличии символа “^” (caret или циркумфлекс) перед именем переменной. Нет символа – переменная в ОП, есть – переменная да диске в БД. Таким образом, база данных М системы является неограниченным расширением оперативной памяти и в ней могут быть сохранены любые структуры данных простым добавлением символа “^” перед именем переменной. Из этого вытекает также, что все команды и функции языка, работающие с какими-либо переменными, массивами или строками или с какими угодно структурами данных пригодны также для непосредственной работы с БД.

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

V52

Теперь о модели данных. Кто-то когда-то где-то по своей неполноте знаний сказал, что М это иерархическая БД. Это подхватили сторонники Р концепции для того, чтобы можно было называть М СУБД иерархической и устаревшей, а мы, мол, работаем с Р, а это «суперсовременно». Модель данных М СУБД НЕ ИЕРАРХИЧЕСКАЯ. М СУБД МОЖЕТ хранить иерархические структуры, также как и реляционные таблицы, также как и сетевые и любые другие структуры. Изобразите нужную структуру данных в ОЗУ, добавьте спереди “^” и вы получите структуру БД. Т.е. М не зажата в рамках никакой парадигмы и Р это частный случай М.

В ОЗУ и С изобразит структуру.
Изображать структуры в ОЗУ - это слишком много усилий по подламыванию реального мира под компьютерные структуры для разработчика БД. Они должны заниматься чем-то более важным. В же общем случае он имеет право о ней ничего не знать - он не системный программист.
А вот насчет МД в МСУБД пока и непонятка. МД это не только структура. Да и структура МД должна поддерживаться СУБД явно. Например, если это таблица, то язык БД должен работать с таблицами, а не с ОЗУ.
Р частный он случай или нет чего либо, должен поддерживаться с определенными требованиями, например, 12 правилами Кодда. Т.е. именно должна быть "зажата в рамках парадигмы и Р" Без этого как РСУБД она может быть поставлена под сомнение.
Но как выяснилось благодаря Вашему коллеге есть вопросы и по ООМД у М (он не разу не ООП - Ваш клооега сказал).
Вот с иерархическими МД, возможно, пока положение пороще у М.


V52

Отсюда вытекает эффективность использования М. Кто бы что ни говорил, но программу написать – раз плюнуть, если известно, что и как надо писать. Т.е. основная трудоемкость программирования – разработка ОПТИМАЛЬНОГО алгоритма. Абсолютное отсутствие в М ограничений на структуры данных позволяет разрабатывать наиболее оптимальные алгоритмы за наименьшее время. Именно поэтому я являюсь его сторонником.

Не все так просто. Эффективность - достижение цели с наименьшими трудозатратами. А что проще, например, реляционных таблиц, декларативного, ассоциативного языка БД, архитектуры приложения, обеспечивающей максимальную независимомть данных от приложений. Для маленьких прог это может и не так существенно, хотя как посмотреть. Зачм заниматься ОПИМАЛЬНЫМ алгоритмом, если можно и вовсе без алгоритма обойтись для извлечения инфы из БД.

V52

Да, в исходном М нет SQL и его центральной части – оператора SELECT. Потому что он НЕ НУЖЕН так как М позволяет строить алгоритмы с превалирующим ПРЯМЫМ обращением к данным, а не через механизм последовательной выборки. А для организации последовательной выборки можно организовать один-два цикла с условиями отбора, что по трудоемкости написания не превышает изображение SELECTa.

Заменить деклартивный язык императивным можно. Но не совсем ясно зачем. Императивный заменить декларативным сложнее. Зато ясно зачем.

V52


В итоге можно сказать, что М – это универсальная глобальная концепция, а Р – ее частный случай который сектанты возвели в ранг самостоятельной религии, воздвигли себе идола в виде оператора SELECT и пляшут вокруг него с бубнаим цепляя бусы и цветные лоскутки в виде всяких WHERE и FROM.

Частный случай Р перевесил по успешности универсальную концепцию М из которой он якобы вышел (что не соответсвует известной истории РМД). Т.е. Р долго и вполне успешно обходился без М. Потому может вполне безболезнено отказаться от чести быть частью М.
7 янв 07, 21:51    [3612331]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
V52
Guest
DocAl
V52

Да, в исходном М нет SQL и его центральной части – оператора SELECT. Потому что он НЕ НУЖЕН так как М позволяет строить алгоритмы с превалирующим ПРЯМЫМ обращением к данным, а не через механизм последовательной выборки. А для организации последовательной выборки можно организовать один-два цикла с условиями отбора, что по трудоемкости написания не превышает изображение SELECTa.

А вы уверены, что "один-два цикла с условиями отбора" являются оптимальным решением такой задачи? Большинство РСУБД позволяет реализовать такой алгоритм использованием курсоров, только вот без обоснованной необходимости их использовать моветон: работает медленнее, чем "пляски с бубном вокруг SELECT, с бусами и лоскутками", а точнее, не поддаётся оптимизации построением индексов и т.п.


Уверен потому что все в моих руках - и структуру данных подобрать оптимальную и алгоритм выборки построить.
7 янв 07, 21:51    [3612332]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31631
V52
...
Уверен потому что все в моих руках - и структуру данных подобрать оптимальную и алгоритм выборки построить.

И в Ваших силах на 4 процессора распараллелить?
7 янв 07, 21:53    [3612335]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Изопропил
V52
...
Уверен потому что все в моих руках - и структуру данных подобрать оптимальную и алгоритм выборки построить.

И в Ваших силах на 4 процессора распараллелить?



Multi-user, multi-tasking, multi-processor
===============================
MUMPS allowed multi-user operation at a time when memory was measured in kilobytes, and processor time was both scarce and slow, but processors themselves were even more so. MUMPS implementations include full support for multi-tasking, multi-user, multi-machine programming even when the host operating system itself does not.


Есть одна замечательная СУБД - ANTS Data Server... Для нее, чем больше нагрузка - тем она лучше работает. К чему это я... К тому что иногда нужно отводить затуманенный взгляд от надписи ORACLE (или MS SQL) на стене и смотреть по сторонам. Весьма полезно.
7 янв 07, 22:04    [3612349]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
V52
Guest
vadiminfo
Частный случай Р перевесил по успешности универсальную концепцию М...


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

Однако, то-ли я плохо мысли излагаю, то-ли вы понять не хотите. В дискуссию вступать не буду. Я просто свой взгляд высказал. Может кому-то пригодится.
7 янв 07, 22:06    [3612350]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

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

И в Ваших силах на 4 процессора распараллелить?



Multi-user, multi-tasking, multi-processor
===============================
MUMPS allowed multi-user operation at a time when memory was measured in kilobytes, and processor time was both scarce and slow, but processors themselves were even more so. MUMPS implementations include full support for multi-tasking, multi-user, multi-machine programming even when the host operating system itself does not.


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


iscrafm
Есть одна замечательная СУБД - ANTS Data Server... Для нее, чем больше нагрузка - тем она лучше работает. К чему это я... К тому что иногда нужно отводить затуманенный взгляд от надписи ORACLE (или MS SQL) на стене и смотреть по сторонам. Весьма полезно.


ANTs - вполне себе реляционная СУБД.
7 янв 07, 22:21    [3612368]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Выбегалло

ANTs - вполне себе реляционная СУБД.

не отрицаю. Я использую в разработке, то что больше подходит для решения задачи и перепробовал все. Ни от чего не фанатею :) Все хорошо к месту.
7 янв 07, 22:34    [3612386]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
V52

Отсюда вытекает эффективность использования М. Кто бы что ни говорил, но программу написать – раз плюнуть, если известно, что и как надо писать. Т.е. основная трудоемкость программирования – разработка ОПТИМАЛЬНОГО алгоритма. Абсолютное отсутствие в М ограничений на структуры данных позволяет разрабатывать наиболее оптимальные алгоритмы за наименьшее время. Именно поэтому я являюсь его сторонником.

Да, в исходном М нет SQL и его центральной части – оператора SELECT. Потому что он НЕ НУЖЕН так как М позволяет строить алгоритмы с превалирующим ПРЯМЫМ обращением к данным, а не через механизм последовательной выборки. А для организации последовательной выборки можно организовать один-два цикла с условиями отбора, что по трудоемкости написания не превышает изображение SELECTa.


Кто вам сказал, что для сложных выборок прямой перебор с внутренними циклами - "наиболее оптимальный алгоритм" ? Умеете ли вы "за наименьшее время" написать алгоритм выборки с использованием хэш-таблиц ? А с индексами ? А с read-ahead ? А с фрагментированием по разным дискам для распараллеливания IO? А fragment elimination сделаете ? А сумеете самостоятельно написать оптимизатор, который будет анализировать предполагаемую стоимость выборки и принимать решение, каким из вариантов пользоваться ? А как у вас с написанием, за наименьшее время, поддержки транзакций ? Блокировки, откаты, разные степени изоляции - легко и просто ? за три дня управитесь ? А как насчет кеширования - имеете доступ под капот M, сможете его заставить часто используемые данные хранить в памяти ? Какой процент ваших read-ов лезет на диск за данными, а какой - использует уже имеющиеся в буферах ?

MUMPS - это не СУБД. Это набор "сделай сам".
7 янв 07, 22:39    [3612393]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
))
Guest
iscrafm
Есть одна замечательная СУБД - ANTS Data Server... Для нее, чем больше нагрузка - тем она лучше работает. К чему это я... К тому что иногда нужно отводить затуманенный взгляд от надписи ORACLE (или MS SQL) на стене и смотреть по сторонам. Весьма полезно.

дорогой украинский друх, комбинация некоторых физиономий со словами "весьма полезно" и названием продухта может приводить к самым парадоксальным последствиям для производителей и потребителей последнего
7 янв 07, 22:43    [3612399]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
))
дорогой украинский друх, комбинация некоторых физиономий со словами "весьма полезно" и названием продухта может приводить к самым парадоксальным последствиям для
производителей и потребителей последнего

Дорогой инопланетный друг... было сказано и написано без всяких физиономий, т.е. на земном языке это означает - серьезно.
7 янв 07, 22:45    [3612409]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

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

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

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



V52

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

Эти мысли не новы. Их многие программисты, любящие свой язык излагают в том или ином виде излагают. Ассемблирист что-то подобное приведет, скорее всего. Но, скоррее всего, времена, когда такие аргументы в БД могли иметь значение, прошли лет 20 назад.
7 янв 07, 22:51    [3612418]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Выбегалло>>Умеете ли вы "за наименьшее время" написать алгоритм выборки с использованием хэш-таблиц ?
А что проблемы ? Не нужно считать что М-специалисты ничего за своб жизнь не видели.

>>А с индексами ?
Какие проблемы ?

>>А с фрагментированием по разным дискам для распараллеливания IO?
А по ECP ?

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

В том то и дело что сможем. У меня такой есть в упрощенном виде - хранимая процедура в зависимости от параметров срабатывает по определенным схемам.

>>Блокировки, откаты, разные степени изоляции - легко и просто ?
Читайте доки они рулез

>>Какой процент ваших read-ов лезет на диск за данными, а какой - использует уже имеющиеся в буферах ?
надесь видеть подробное описание как это делать в MS-SQL.
7 янв 07, 23:07    [3612437]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
))
Guest
iscrafm
Дорогой инопланетный друг... было сказано и написано без всяких физиономий, т.е. на земном языке это означает - серьезно.

кто бы усомнился. как вы сказали?... чем больше - тем лучше? записал на жесткий диск
7 янв 07, 23:10    [3612442]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 69 70 71 72 73 [74] 75 76 77 78 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить