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

ну не знаю - это все давно придумано
вот именно то, что вы перечислили, поддерживается специально созданным для этой цели супер-пупер протоколом - ECP - Enterprise Cache Protocol

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

Если сеть захлебнулась - надо переконфигурировать м-клиенты.
Мне интересно, а что вам удасться переконфигурировать, когда винты "кластера" встанут от сиков, да ничего (причем за любые деньги).


Все эти "проблемы" высосаны из пальца, потому что уже давно есть Fiber Channel, iSCSI и RAID...
8 янв 07, 23:46    [3613976]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
frutalino
Выбегалло
frutalino

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


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



мне ничего не остается предположить, что там именно она и работает - идентификация, навигация и семантика

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


Ну давайте прикинем. 256 клиентов содержат каждый по копии данных. Один из них данные изменил. Остальные 255 а) должны быть оповещены, б) должны загрузить эти данные к себе в ОЗУ. Все это - по одной и той же медленной сети. После этого первый компьютер может завершить транзакцию.
Вопрос : будут ли эти 256 компьютеров, с 256X памяти и процессоров, работать быстрее одного единственного компьютера ?
Ответ : фруталино, перестаньте позориться.
8 янв 07, 23:52    [3613984]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
>>все это замечательно и все такое, но как они поддерживают согласованность копий данных ?

>мне ничего не остается предположить, что там именно она и работает - идентификация, навигация и семантика

Прямо почти по классику(ам) :) -

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

:-)

- Как синхронизировать данные по медленной сети на большом кол-ве узлов ?

- "...именно она и работает..."

.....

- Как вы хэш собрались делать ?

- А вот сцылка !

- Так это же косяк какого-то очередного "механика-баптиста", а не хэш !!!

- Ну так не для практических же целей .....

:-)

Вроде неглупые люди, а так позорятся :(


Всё.

"Дальнейшее молчание" (с)
9 янв 07, 00:07    [3614003]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Выбегалло
Остальные 255 а) должны быть оповещены, б) должны загрузить эти данные к себе в ОЗУ

И еще в) сказать, что у них все ОК после этого. И кстати, как выясняется, вроде не обязательно в ОЗУ.
9 янв 07, 00:11    [3614006]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

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

Ничего не имею против. есть.

Ну видимо и Каше тоже

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


Ptn

Да можно

Имелось в виду, что так многие языки могут быть клиентами РСУБД. Вот РСУБД от этого они не становятся.

Ptn

Да поддерживает за процент поддержки не скажу - ибо слова слишком общи.

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


Ptn

Можно - именно так и сделано вся SQL это надстройка на М.
Тогда он должен поддерживать реляционные таблицы.


Т.е. именно у М РБД? Давайте строго отделять М от Каши? Я же не так их хорошо знаю, меня их взаимное подразумевание путает.

Ptn


Не уверен. Мне почему то порой кажется что вы просто хотите услышать что М это не СУБД.

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

Ptn

Потому что нет никакого смысла сравнивать SQL c SQL IMXO

Имелось ввиду зачем что-то делать на М, раз там есть SQL?


Ptn

НЕТ - это значить что я не вижу смысла обсуждать тут данный вопрос.
Ну или давайте подумаем как относяться SysBase-вцы вроде да ? к MS-SQL - и кому это вообще интересно.

Я думал, что это другая ситуация. Когда SysBase-вцы относятся к более продвинутым версиям SysBase же?
Судите сами. Каша - СУБД. А М, как Вы сказали не совсем попадает под определение СУБД.

Ptn

Не совсем ясно как язык может быть моделью данных. Он либо позволяет её использовать либо нет.

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




Ptn


Мое мнение что да. CDL - с полной атрибутикой (указание классов, наследования, полиморфизма и т.д.) и реализующая ООМД - и класс хранения обеспечивающий МД написан именно на М.

Ну Оракл написан на С. Причем тут на чем написан?
Кроме того я думал, что это в Каше, а не СУБД М.
Уточните в какой БД эти классы?


Ptn

Я пояснил выше. Дело в том что вы как то уперлись именно в М. В Каше есть Class Defitininon Language через него SQL далее Cache Script Rules, Cache Script Pages и даже BASIC и всё это построено на М. А SQL получается сразу построен при помощи классов.


Я не уперся, а запутался когда Вы говорите про М, а когда про КАШУ. Особенно если они теперь оба СУБД. Я думал мы говорим про СУБД М пока. А про Кашу пока нет.


Ptn

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

Ну знаете, пока еще не установлено, что реляционная эпоха прошла, и ей на смену пришла постреляционная.

Ptn


Мне неизвестны критерии Версанта - но вполне допускаю что какому либо критерию Каше не соотвествует. Значить ли что эти критерии единственно возможные ? - сомневаюсь ;)

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




Ptn

Добавление триггера

Это добавление в КАША БД или М БД?
9 янв 07, 01:08    [3614043]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30290
автор
Это добавление в КАША БД или М БД?

это Cache.

в общем, ситуация следующая. Есть M. Над ним в Cache есть две надстройки - одна SQL, другая ОО. Обе внутри проецируются на M. При этом, под "пост-реляционной" имеется в виду ОО-надстройка.
ОО- и SQL- надстройки вроде бы работают, но когда поклонники M (или Cache) начинают пинать РСУБД, оказывается, что сами поклонники M предпочитают работать именно с ним (c М), т.е. "в самом низу", а не с SQL-надстройкой, как минимум.

В итоге споры по поводу "модели данных" теряют всякий смысл. Это то же самое как если сравнивать BTrieve с РСУБД.

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

Конечно, нельзя не признать попытки InterSystems реинкарнировать все это дело (MUMPS), но они примерно аналогичны попыткам сделать популярной СУБД Pick (если кто помнит такую, здесь на форуме были ссылки), и т.п., и в общем если не обречены на провал, то успеха не возымеют.
9 янв 07, 01:28    [3614053]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
NetApp
Guest
Локшин Марк
Выбегалло
Остальные 255 а) должны быть оповещены, б) должны загрузить эти данные к себе в ОЗУ

И еще в) сказать, что у них все ОК после этого. И кстати, как выясняется, вроде не обязательно в ОЗУ.


А вот вопрос для frutalino. Если почитать про этот ECP:

http://www.intersystems.com/cache/technology/components/ecp/index.html

то станет видно, что это не кластер а много Application Servers + один Data Server + возмоность кэшировать данные на Applcaition Servers. Data Server при это все равно один, то есть все это "заточено" на чтение данных. Если эти 255 клиентов начнут много писать то вся нагрузка пойдет на единственный Data Server. Поправьте меня если это не так:

Here’s how ECP works. When a client makes a request for information, the application server will attempt to satisfy the request from its local cache. If it cannot, the application will request the necessary data from the Caché data server. The reply data package includes not only the desired piece of data – it also includes the entire database block where that data was stored. The natural data relationships inherent to objects and Caché’s multidimensional data model make it likely that this “extra” data will be needed by the application logic in subsequent processing steps.
The “extra” data is cached (in the normal database cache) on the application server, where it is available to all applications running on that server. That means that these data are available to satisfy subsequent requests from the client, or in fact from any client connected to the application server. ECP automatically takes care of managing cache consistency across the network and propagating changes back to the data server.
9 янв 07, 01:28    [3614054]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
iscrafm
c127
Я Вас разочарую, если Вы действительно считаете это преимуществом. В СКЛ серверах вообще не требуется ничего подобного символу '^' перед именами, разницы в том, где находятся данные нет никакой. С точки зрения программиста работа с ними одинаковая, независимо лежат ли они на диске или прокешироаны и лежат в памяти, сервер сам решает куда положить данные.

и меня тоже...
я не знал об этом, когда делал declare @a для объявления переменных в памяти, и зачем то insert into ... или update для записи.

Ничего удивительного, Вы и сейчас не знаете, что в СКЛ-е переменных нет.


Ptn
c127 Будьте любезны, изобразите таблицу из трех полей типа целое, с ключом по одному из них и индексом по двум другим. Разумеется индекс должени автоматически поддерживаться при изменеии данных.
Class T.T Extends %Persistent 
{

Property a1 As %Integer [ Required ];

Property a2 As %Integer [ Required ];

Property a3 As %Integer [ Required ];

Index a1Index On a1 [ IdKey, Unique ];

Index a2Index On (a2, a3);

}

Вопрос был обращен к V52, речь шла об М:
"V52> Теперь о модели данных. Кто-то когда-то где-то по своей неполноте знаний сказал, что М это иерархическая БД. Это подхватили сторонники Р концепции для того, чтобы можно было называть М СУБД иерархической и устаревшей, а мы, мол, работаем с Р, а это «суперсовременно». Модель данных М СУБД НЕ ИЕРАРХИЧЕСКАЯ. М СУБД МОЖЕТ хранить иерархические структуры, также как и реляционные таблицы, также как и сетевые и любые другие структуры. Изобразите нужную структуру данных в ОЗУ, добавьте спереди “^” и вы получите структуру БД. Т.е. М не зажата в рамках никакой парадигмы и Р это частный случай М."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=75#3612620
Поэтому если хотите что-то изобразить по этому пункту, то изображайте на М.
9 янв 07, 02:33    [3614077]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Изопропил
CREATE TABLE S(I INTEGER,J INTEGER,V INTEGER, PRIMARY KEY (I,J))
SELECT I,SUM(V) FROM T GROUP BY I ORDER BY 1

На М примерно так будет?
s (I,J)="" k ^R
f s I=$o(^S(I)) q:(I="") d
. f s J=$o(^S(I,J)) q:(J="") s ^R(I)=^R(I)+^S(I,J)
f s I=$o(^R(I)) q:I="" w I," ",^R(I),!

А как записать на M
SELECT I,SUM(V) FROM T GROUP BY I ORDER BY 2
?

Зависит он нескольких факторов, например, являются ли значения I уникальными. Если да, то
...
 . s J="" f  s J=$o(^S(I,J))  q:J=""  s ^R(I)=^R(I)+^S(I,J),^W(J,I)=""
 s J="" f  s J=$o(^W(J))  q:J=""  s I="" f  s I=$o(^W(J,I)) q:I=""  w I," ",^R(I),!
Если нет, то предварительный вопрос: в каком виде Вы хотели бы их получить?
9 янв 07, 03:14    [3614088]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)
Вообчето я говорил о возможности задействования из Cache МНОГОБЛОЧНОГО чтения на уровне ОС, хождение по правым и левым ссылкам на одном уровне это и есть RangeScan в случае B+дерева.

Что Вы подразумеваете под МНОГОБЛОЧНЫМ чтением? Read ahead? Ну да, такого конечно нет.

Gluk (Kazan)

А я говорю о том, что данные содержат ТОЛЬКО листовые блоки B+ дерева и только они будут читаться на RangeScan, никакая дефрагментация (жизненность такого подхода оставим за кадром) Вам не поможет

Ну ничем логически эти блоки не отличаются от блоков Вашей таблицы. Там данные и тут данные.
Те читаются и эти читаются. Те не подряд и эти не подряд. Я чего-то может не понял?

Gluk (Kazan)

Либо денормализует БД как в случае хранение max-ов и count-ов в отдельных счетчиках
Со всеми вытекающими тормозами на конкурирующем обновлении этих счетчиков и необходимостями всех этих обновлений ручками

Не все так страшно. При постоянном обновлении счетчиков можно гарантировать наличие блоков с ними в кэше. А насчет ручек не стоит, ну надоело уже.
9 янв 07, 03:26    [3614090]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
))
ну, у него там ноут 2кг, 12 дюймов, а под картинкой написана цена вашего домашнего. 2.5tps в одном потоке, 8.3tps в восьми. что такое "запрос" кстати? тексты приведены, графики нарисованы... откуда Итог?

Что значит "откуда"? 2.5k tps в одном процессе это не Итог? Тогда что же это такое?
9 янв 07, 03:33    [3614093]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
DocAl
Так tps или qps?

Сравнивались tps, предлагаются qps, так вроде серьезнее будет.
9 янв 07, 03:41    [3614096]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Sergei Obrastsov
DocAl
Так tps или qps?

Сравнивались tps, предлагаются qps, так вроде серьезнее будет.
В смысле, "а в попугаях-то я гоораздо длиннее!"? Или просто в Каше с транзакциями не очень? Тут вот выяснили, что в Каше на разных слоях транзакции разные, и друг с другом несовместимые.
9 янв 07, 04:46    [3614107]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
DocAl
Sergei Obrastsov
DocAl
Так tps или qps?

Сравнивались tps, предлагаются qps, так вроде серьезнее будет.
В смысле, "а в попугаях-то я гоораздо длиннее!"? Или просто в Каше с транзакциями не очень? Тут вот выяснили, что в Каше на разных слоях транзакции разные, и друг с другом несовместимые.

Вообще-то изначально речь зашла именно о qps, это товарищ )) вдруг заменил их на tps, что я считаю несколько некорректным. С транзакциями в Каше все в порядке, что и выяснилось в сравнении. Вполне может быть, я не лазил внутрь эмуляции SQL, как-то неинтересно. Но в итоге все все-равно сводится к записи в журнал, так что какая собственно говоря разница?
9 янв 07, 06:13    [3614136]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Выбегалло
слив защитан.


Уважаемый профессор - а разве могло быть иначе ? . Где ваша прозорливость ?

PS: Нужно будет с Циника долю за сливы стрясти
9 янв 07, 08:00    [3614199]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Ptn
Выбегалло
слив защитан.


Уважаемый профессор - а разве могло быть иначе ? . Где ваша прозорливость ?

PS: Нужно будет с Циника долю за сливы стрясти


Вполне, уважаемый, вполне могло. Вы бы нам показали , как средний программист на мумпсе может легко и просто налабать и пользоваться различными индексами для поиска; как этот же программист одной левой рисует транзакции в прямом доступе, заодно находя и разрешая дедлоки; как он мастерски сочетает три типа доступа к данным, не чеша при этом правое ухо левой рукой и не руша сервер - и мы бы дружно, всей толпой ринулись на этот вас хваленый мумпс. Вместо этого, вместо разговора по существу, вы предпочли стать в третью позицию и использовать весь набор самых примитивных отмазок ( а) "у меня нет времени вам разъяснять", б) "читайте доки, там все написано", в) "я консультирую только за деньги" и г) "гы-гы-гы" ). Ну, звиняйте, есть аргументы - есть разговор, нет аргументов - слив таки защитан, слушаем следущего оратора.
9 янв 07, 08:29    [3614225]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
>>Замечтательно коли так, но какова будет стоимость разработки этого велосипеда ?
Блогодоря ООП небольшая. Тем более я хотел бы обратить внимания что всего этого якобы нет в принципе - то есть невозможно.


БуГаГа нинада мне втирать про ООП, я его кушаю на завтрак обед и ужин.
Если Вы считаете, что он Вам СИЛЬНО поможет при разработке озвученных велосипедов (ACID например), Вам ЯВНО не приходилось заниматься такими задачами

Про многоблочное чтение понятно. Но это НЕ ИЗБАВЛЯЕТ Вас от необходимости разработки дорогостоящих велосипедов, в то время как пользователи ДРУГИХ продуктов могут сосредоточится на самой задаче

(Кстати, если ентим пользователям ПРИСПИЧИТ, оне тоже могут пуститься во все тяжкие)
9 янв 07, 08:33    [3614230]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
frutalino
ну не знаю - это все давно придумано
вот именно то, что вы перечислили, поддерживается специально созданным для этой цели супер-пупер протоколом - ECP - Enterprise Cache Protocol


Черная коробочка с красивой ленточкой - это конечно здорово, но иногда и голову включать невредно. Хотя-бы чтобы снять лишнюю маркетинговую лапшу с ушей
9 янв 07, 08:36    [3614234]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
frutalino
дисковая система имеет ярко выраженный порог возможностей механических устройств.
А сеть - это же транзисторы, там ничего не крутится и не вертится.


Эта 5
фцитатник адназначна
9 янв 07, 08:37    [3614235]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Выбегалло
Ptn
>>Название доки, номер страницы ?
Вы не поверите - дока на сайте ISC


Так дока-то ваша - по SQL , однако ! Прямой доступ, выходит, это хорошо - но как до дела доходит, когда транзакции потребовались - то начинаете SQL использовать ? Ну и нахрена мало-мальски трезвому программисту учить два языка (M и SQL), вникать в детали физического хранения индексов, ловить баги блокировок - когда можно взять нормальную РСУБД и не париться ?


Тем более, что SQL-нашлепкой НЕ РЕКОМЕНДУЮТ пользоваться даже сами ярые апологеты Cache Этой наколенке даже до RBO оччччень далЁко
9 янв 07, 08:41    [3614239]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
vadiminfo >>Роль самодельных скриптов тогда не так высока, раз есть более продвинутые средства от ведущих фирм для тех же целей.
Согласен - как то доводилось работать с Кристал Репортс - но всегда могуть быть нюансы разработки.

>>Имелось в виду, что так многие языки могут быть клиентами РСУБД. Вот РСУБД от этого они не становятся.

То что они как М не существуют внутри СУБД IMXO сказывается куда сильнее в данном вопросе - и опять же вы всё таки просто хотите услышать что М не СУБД.

>>Ну хотя бы на 90% тянет?
Я не знаком с критериями версанта - но IMXO легко.

>>Опять - можно ли в 90% обойтись без М работая с этой БД?
>>Просто с текстовым редактором писать SQL инструкции и посылать их СУБД?

Можно - вопрос целесообразности оставим.

>>А М считать просто неким расширением SQL?

Ну ... на самом деле с точностью до наоборот - Хотя со стороны юзера вполне может быть такое виденье. М для него язык для огранизации циклов и доп логики. Аналог PL/SQL вроде.

>>Мне иногда кажется, что в ответах про М подразумевается Каша и наоборот. Ну как там про Ленина и Партию у вас говорили.

Ну дык потому и говорили (деятельность ISC приводить к тому что на рынке остается Каша. Но ест слово богу GT.M и еще пара вещей)


>>Давайте строго отделять М от Каши?
Хорошо .. давайте - всё сказанное мной относится к Каше.
Но не забывайте про пример компиляции SQL c последующим переносом рутины на другие М системы.

>>Важно, чтобы это была правильная информация о том, кто же он в конце концов этот М?
М это как Java.
- язык
- технология
- платформа

В контексте обсуждения Вы скорее всего рассматривается ТОЛЬКО язык.
SQL и надстройки живут в технологии. А МД в платформе.

>>Имелось ввиду зачем что-то делать на М, раз там есть SQL?

С практической точки зрения да - никто без необходимости не пишеть сразу на М.
И наличие SQL на мой конкретный выбор СУБД повлиял достаточно сильно.

С точки зрения сравнения (а именно это я имел в виду) - вот приведут какую нибудь задачу.
Вы приведете решение на SQL и я приведу решение на SQL и что сравнивать ?

>>Судите сами. Каша - СУБД. А М, как Вы сказали не совсем попадает под определение СУБД.
Можно зайти с другой стороны
MSM, DTM, GT.M - там нет SQL - можно ли их считать СУБД ? IMXO можно.

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

Язык не может быть СУБД - СУБД это я М-язык, М-технология + М-платформа. IMXO.

>>Ну Оракл написан на С. Причем тут на чем написан?
Я не знаю причем здесь оракл. Просто модель данных реализована через UDF на М.

>>Уточните в какой БД эти классы?
К Каше - имено она заявлена как ООП продукт.

>>Я не уперся, а запутался когда Вы говорите про М, а когда про КАШУ. Особенно если они теперь оба СУБД. Я думал мы говорим про СУБД М пока. А про Кашу пока нет.

Хм ... нет я в основном Говорю про Кашу - той лишь разницей ничего не мешает прикрутить теже объекты и SQL к GT.M например. Им просто это не нужно.

>>Ну знаете, пока еще не установлено, что реляционная эпоха прошла, и ей на смену пришла постреляционная.

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

>>Версант то сто пудов признан как ООСУБД. В той книге про БД упоминался среди таковых. А в отношении КАши чувствуется некая сдержанность в этом плане. Я и хочу это уточнить.

Понятно - можно тынц ?

>>Это добавление в КАША БД или М БД?
Каша - в других М БД - ООП-а нету.
9 янв 07, 08:50    [3614255]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
Выбегалло Почитал. Проникся. Оказывается, для того, чтобы эффективно программировать на MUMPS, надо быть напроловину разработчиком движков баз данных. Все, за что в РСУБД уже заплачено - индексирование, к примеру - в M надо писать самому.
Ну значить так читал - чтение и толкование вслух извини платное.


Да нет, сказано там все это довольно внятно. Да и не тайна это ни для кого.

Ptn
Кроме того, оптимизатор ценен тем, что позволяет менять план динамически - в зависимости от статистики индексов, таблиц, и много чего. А что можете вы ? В лучшем случает - написать его жалкое подобие, "если в таблице А меньше ста трок, использовать индекс 1, иначе - индекс 2". В 99.9% случаев и этого никто из М-программистов не делает, потому что не тот уровень.

Опа - нада же я тот самый 0.01% Оценил-оценил ) Читать раздел Dynamic SQL до просветления.
Вслух извини платное.


Динамическое изменение ПЛАНА и ЗАПРОСА это две больших разницы мон шер. Если я начну решать проблемы оптимизатора динамическим SQL-ем меня уволють

Ptn

>>Так дока-то ваша - по SQL , однако !
ДА ВЫ ЧТО ? Бес попутал однозначно. А ссылку на Language Bindings вообще давать страшно - вдруг еще какие открытия совершите


Тема сисек, тьфу транзакций не раскрыта, так можно их использовать из ридного M или тильки из слабоумной SQL-нашлепки ??? Не блокировка ручками всего и вся, а вменяемый Begin Transaction, Commit Transaction, ну и Rollback для кучи ?
9 янв 07, 09:00    [3614267]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
Недавно у нас в разделе подобный вопрос поднимался - если интересно зайдите.


В таких случаях полезно давать сцылки.
Меня эта тема тоже интересует
9 янв 07, 09:01    [3614272]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
c127 >>Поэтому если хотите что-то изобразить по этому пункту, то изображайте на М.

^T.TD=3
^T.TD(1)=$LB(1,3)
^T.TD(2)=$LB(1,2)
^T.TD(3)=$LB(2,3)

^T.TDI("a2Index",1,2,1)=""
^T.TDI("a2Index",1,3,2)=""
^T.TDI("a2Index",2,3,3)=""

Приводить весь сгенерированный М код не вижу смысла. Но вы правы - вопрос не мой.
9 янв 07, 09:05    [3614280]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
frutalino
мне ничего не остается предположить, что там именно она и работает - идентификация, навигация и семантика


Чур меня, никак ЧАЛ начал РЕГИСТРИРОВАТЬ клонов

frutalino

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


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

frutalino

> Уважаемый, вы не сталкивались с настоящими оптимизаторами. И настоящими запросами. Там количество вариантов плана идет на миллиарды.


Покажите мне DSS на Каше и я подумаю над тем чтобы съесть вашу шляпу
9 янв 07, 09:07    [3614285]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 74 75 76 77 78 [79] 80 81 82 83 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить