Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 24   вперед  Ctrl
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Андрей Леонидович
Павел Воронцов !

Не хотите - не разбирайтесь. Неужели я виноват в Вашем нежелании разбираться ??? Причем в данном контексте определение "ключа" ???


Как раз при том, что Вы не показали отчего это "в Р СУБД с ключами просто беда" и что такое "провал ключей".

Андрей Леонидович
Павел Воронцов !

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


Вот вот. Ну да. Ага. А что такое "модель данных" в Вашем понимании? Определение пожалуйста.

И вообще давайте не мешать компот с борщом. Есть технология (восхитительно-обворожительно-передовая) MUMPS, а есть теория (как угодно плохо формализованная, но теория) РМД. Всё же теорию надо сравнивать с теорией, а технологию с технологией.
17 ноя 04, 06:45    [1111273]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Андрей Леонидович

Вы придумали именно собственную технологию, которую можно реализовать в Cache. Молодец ! Но будьте внимательны. Ладно я "запутался" и "до сих пор не могу понять". Главное, чтобы Вы поняли и не запутались.

Ничего не придумал, просто предположил. Гипотеза которую я описал. Основана на теории, теория описана здесь >>>

Методы представления сложных объектов во внешней памяти

я описал всё то же самое, в наглядной, ... очень упрощенной, ... прикладной форме. :)
17 ноя 04, 08:21    [1111341]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Андрей Леонидович
Павел Воронцов !

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

Ух ты! Певый раз я подумал, что вы случайно глупость сказали. (заговорились подумал... а сейчас вижу, что всё очень даже запущено...)

Андрей Леонидович, при всём уважении, не могу не отправить вас СЮДА
17 ноя 04, 08:35    [1111354]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
И студентам тоже не нужно... (вы ведь днём преподаёте ... предполагаю)

Because, there is no patch for human stupidity.
17 ноя 04, 08:43    [1111369]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
Andrey K
Андрей Леонидович
Павел Воронцов !

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

Ух ты! Певый раз я подумал, что вы случайно глупость сказали. (заговорились подумал... а сейчас вижу, что всё очень даже запущено...)

Андрей Леонидович, при всём уважении, не могу не отправить вас СЮДА


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

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

если есть конкретные вопросы про Каше или MUMPS - пишите мне напрямик -я вам постараюсь все объяснить, поскольку знаю там все достаточно глубоко.
dimon_n2000@mail.ru
17 ноя 04, 12:40    [1112662]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
dimon_n2000

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

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

dimon_n2000

и нечего матом ругаться на человека, имеющего свое мнение. вот я ж на вас не ругаюсь, хотя вы - редиска :)

Есть мнение, что земля имеет форму чемодана.... Согласен давайте не будем ругаться... но и глупости тоже не будем говорить...
17 ноя 04, 13:13    [1112820]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
To dimon_n2000

Да не хочу я в этом всём разбираться капитально, не до того мне. Общее представление я получил, ставил Каше, игрался. Пока жизнь за жопу не схватит, я от этих технологий буду держаться подальше.

Мне за державу обидно. Когда отвергают формальную теорию, обосновывая это успехом или неуспехом разных технологий, меня начинает бить нервенная дрожь. Это уже диагноз, причём не Андрея Леонидовича, а целой индустрии. Так называемое "market-based education", заменяющее фундаментальное образование. В головах у людей свалка из рекламных слоганов вместо твёрдых знаний. С появлением новой "серебряной пули" (на поверку оказывающиеся хорошо забытыми старыми технологиями) все начинают кричать новые лозунги, забывая о прежних поражениях и проблемах. А когда пытаешься это объяснить, тебя этими самыми лозунгами закидать и прав оказывается тот, кто громче и неразборчивей кричит. "Провал ключей!" "РМД плохо формализована!" "Объект есть реальность, противостоящая субъекту!"

Скучно жить на этом свете, господа.
17 ноя 04, 13:35    [1112937]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Павел Воронцов
To dimon_n2000
Мне за державу обидно. Когда отвергают формальную теорию, обосновывая это успехом или неуспехом разных технологий, меня начинает бить нервенная дрожь. Это уже диагноз, причём не Андрея Леонидовича, а целой индустрии. Так называемое "market-based education", заменяющее фундаментальное образование. В головах у людей свалка из рекламных слоганов вместо твёрдых знаний. С появлением новой "серебряной пули" (на поверку оказывающиеся хорошо забытыми старыми технологиями) все начинают кричать новые лозунги, забывая о прежних поражениях и проблемах. А когда пытаешься это объяснить, тебя этими самыми лозунгами закидать и прав оказывается тот, кто громче и неразборчивей кричит. "Провал ключей!" "РМД плохо формализована!" "Объект есть реальность, противостоящая субъекту!"

Скучно жить на этом свете, господа.

Поддерживаю, очень точно сказано :)
17 ноя 04, 13:45    [1112990]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
jvvjvv
Member

Откуда:
Сообщений: 56
dimon_n2000

если есть конкретные вопросы про Каше или MUMPS - пишите мне напрямик -я вам постараюсь все объяснить, поскольку знаю там все достаточно глубоко.
dimon_n2000@mail.ru


Может быть все таки здесь обсуждать?
Тема ведь интересная.

Выскажите пожалуйста свою точку зрения на следующее мое замечание.
Я обнаружил (в результате изучения Cache) что:

1. Используя только Cache-Mumps можно создать работающую систему. Для этого есть средства разработки бизнес-логики (язык COS) и возможность манипулировать данными в глобалях (создать, редактировать,индексировать, искать...)

2. Используя Cache-SQL и COS так же можно создать работающую систему.

Но

Используя только "Cache-Object" и COS нельзя создать работающую систему. Здесь можно только создавать, редактировать и удалять конкретный экземпляр объекта использую его идентификатор.
Для любой работы с группой экземпляров требуется использовать или прямой доступ или SQL, что вроде как к объектной парадигме не имеет отношения.

Если я не ошибся в оценке (в силу малого опыта работы с Cache), то вопрос :
Является ли показанная особенность собственным недостатком Cache, или же это свойство объектной парадигмы вообще.
17 ноя 04, 13:55    [1113060]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

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

Если я не ошибся в оценке (в силу малого опыта работы с Cache), то вопрос :
Является ли показанная особенность собственным недостатком Cache, или же это свойство объектной парадигмы вообще.


Собственно объектной парадигме групповые операции не противоречат. В принципе вполне возможно представить себе класс-контейнер, содержащий экземпляры объектов одного типа, выполняющий Revoke некоторого метода этого типа. Что-то вроде (псевдо-java)
Method custMeth = Reflaction.getClassByName("Customer").getMethod("setRating", new Array()={int.getClass()});
Collection col = DB.GetCustomers(/* some query conditions */);
col.RevokeForEach( custMeth, new Array()={1});
В smaltalkе такая штука ещё красивше выглядит.

Другое дело, что программист обязан сам сперва описать такое поведение (спроектировав должным образом класс Collection), а РСУБД даёт возможность производить такие операции без дополнительных затрат.
17 ноя 04, 14:24    [1113234]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
jvvjvv
Member

Откуда:
Сообщений: 56
>>Другое дело, что программист обязан сам сперва описать такое поведение >>(спроектировав должным образом класс Collection), а РСУБД даёт >>возможность производить такие операции без дополнительных затрат.

Вот то то и оно...
17 ноя 04, 14:57    [1113473]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=GSQL_intro#GSQL_C9265

Integration with Caché Objects—Caché SQL is tightly integrated with Caché Objects. You can mix relational and object access to data without sacrificing the performance of either approach

The SQL Processor and Optimizer—a set of programs that parse and analyze SQL queries, determine the best search strategy for a given query (using a sophisticated cost-based optimizer), and generate code that executes the query.


"Другое дело, что программист обязан сам сперва описать такое поведение (спроектировав должным образом класс Collection), а РСУБД даёт возможность производить такие операции без дополнительных затрат."

Получается, что с одной стороны можно обойтись только объектным языком. :)

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

(Стратегия поиска по такому запросу в любом случае должна основываться на анализе эффективности горизонтального и вертикалоного сканирования описанного здесь http://meta.math.spbu.ru/publication/SPB-K.pdf применительно, к объектной модели - то есть не зависит по идее от конструкции самого запроса (в традиционных РСУБД один запрос можно написать поразному => планы запроса могут быть различными.... то есть "правильность" написания запроса зависит только от разработчика)... вероятно имеет место, какое то промежуточное преобразование ... которое скорее всего основано на "жестком" (определённом) алгоритме оптимизации ...) IMHO



ClassMethod FindBySKU(sku As %String)
{
&sql(SELECT %ID INTO :id FROM Product WHERE SKU = :sku)

If (SQLCODE = 0) {
// ask the product to display details about itself
Set product = ##class(Product).%OpenId(id)
Do product.DisplayDetails()
}
}

17 ноя 04, 16:58    [1114172]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Andrey K

(Стратегия поиска по такому запросу в любом случае должна основываться на анализе эффективности горизонтального и вертикалоного сканирования описанного здесь http://meta.math.spbu.ru/publication/SPB-K.pdf

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

Andrey K

к объектной модели - то есть не зависит по идее от конструкции самого запроса (в традиционных РСУБД один запрос можно написать поразному => планы запроса могут быть различными.... то есть "правильность" написания запроса зависит только от разработчика)...
"По идее" от конструкции самого запроса (если применяется декларативный язык запросов) "стратегия поиска" не зависит для ЛЮБОЙ модели. Зависимость плана исполнения запроса от формулировки запроса, это недостаток конкретного оптимизатора в конкретном случае.
17 ноя 04, 18:19    [1114485]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Alex.Czech !

Напрминаю Вам первую реакцию ASCRUS на мои высказывания (речь шла об интегрированном языке баз данных).

Сначала ASCRUS сказал что лучше написать

IF NOT EXISTS (SELECT ??? FROM ??? WHERE ???)
THEN
CALL PRG() ;
RETURN;
END IF;

(и еще оптимизатор будет оптимизировать),
чем

i $$g(io,ie,ih)="" d ^PRG q

И сразу, без всяких объяснений, перешел к "своим" вопросам. Это именно предвзятость и корпоративная солидарность.

Далее ASCRUS странно прореагировал на то, что при использовании ОСУБД сводится к минимуму программирование нерегламентированных отчетов. И я понимаю откуда "растут ноги" у такой реакции. Вот, например, цитата из учебника-руководства по внедрению Oracle Applications 11i (приложение класса ERP):

"Если программист имеет опыт работы с инструментами Developer 2000 и Developer 6i и хорошо знаком со схемой данных Oracle Applications и языком SQL, то создание пользовательских отчетов для приложений Oracle Applications будет относительно простой задачей. Однако, следует помнить, что конечный пользователь не должен заниматься созданием пользовательских отчетов."

Вот как ! Наверное и Выши приложения так "организованы" ?
ПОЛЬЗОВАТЕЛЬСКИЕ отчеты должны создавать ПОЛЬЗОВАТЕЛИ. Так и есть, когда приложение работает в ОСУБД. И в тех, очень редких, случаях, когда невозможно получить нужный отчет с помощью объектного генератора отчетов, я стараюсь сделать все возможное, чтобы программисты ничего не программировали. В результате:

1) программисты решают более важные и интересные задачи;
2) пользователи могут создать МНОЖЕСТВО отчетов в данной "области", а не ОДИН, который им был нужен.

А Ваша технология ничем не отличается от технологии многих мампсистов, которые строят приложения на произвольных глобалах (это, как я уже говорил, можно делать, если не ожидаются нерегламентированные запросы). Совершенно искренне желаю творческих успехов. Надеюсь и Вы мне желаете того же ?

И, главное: все, что я сейчас опять повторил, не выходит за границы элементарной теории баз данных. И это нужно повторять 100 раз ?
Я понимаю, если бы сообщил какую-то НОВУЮ идею. Ее не поняли. Пришлось повторить. Какую это, интересно, НОВУЮ идею (хотя бы одну) Вы нашли в моих высказываниях ? Значит Вам ВСЕ ПОНЯТНО ?
17 ноя 04, 18:40    [1114556]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Павел Воронцов !

Почему же не показал ? То, что

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

вовсе не значит, что не показал. Именно показал, и весьма убедительно.
17 ноя 04, 18:44    [1114566]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Andrey K !

Я же говорю, молодец ! Творческий человек. Немного подтянуться в теории, и все будет хорошо. Начинать, конечно, нужно с работ Кодда и MUMPS. Создавались одновременно в 1969 году, но на берегах разных океанов.
17 ноя 04, 18:46    [1114578]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Павел Воронцов !

Вот в этом согласен полностью. Действительно, в головах моих оппонентов "свалка рекламных слоганов". Но, надеюсь, это можно поправить, если есть желание учиться...
17 ноя 04, 18:49    [1114587]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

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

А что значит "те или иные"? Это получается один видит "те" элементы, а другой утверждает, что это совсем не те элементы, а в качестве определяющих нужно брать совсем иные. И тот и другой прав. Вот, например, оракл является полностью ООМД системой.

Вообще ООП не означет, набор фиксированных принципов. Т.е. могут быть и более объектно "ориентированные" принципы в дальнейшем. Что касается ООМД то так и есть: существует как минимум два набора принципов. Один из которых не включает иерархию классов. Мы не знаем какой лучше. Но мы можем оба отнести к ООМД, а их сравнивать уже внутри ООМД.
Оракл ОРМД, а ООМД - отказ от реляционности. Допустим, есть недостатки при внесении поддержки ОО в РМД. Два подхода - один поиск преодоления этих недостатков, в рамках РМД, другой радикальный - отказ от РМД вообще.
Это я и пытался сказать.

c127

Но этот недосток отменяет единое понятие ООМД со всеми вытекающими. Всего-навсего.

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





c127

Довольно сложно найти на шару книгу выпущенную пол-года назад, а покупать за $120 неохота.

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



c127

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

Вот если снять это "скорее всего" можно было бы открывать толстую книгу и смотреть какие известны подходы среди ООСУБД и понять к чему она относится. А так как там присутствует MUMPS, то не ясно. Там есть COS, тоже не ясно. На нем все можно сделать или нет? Какие он принципы ООП поддерживает? Можно ли сделать на нем модель из объектов, с методами со всем, а потом работать с этой БД работать только с MUMPS, но уже без всяких объектов? Что это будет тогда за модель? Куда делись объекты? Так что не все так просто. Это "скорее всего" в данном случае существенно.
17 ноя 04, 21:33    [1114859]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Alex.Czech
Guest
2Андрей Леонидович

Лично я тоже считаю что первый вариант лучше - хотя бы потому что его я могу понять, а второй - это выше моих сил... вы, я верю, можете понять смысл написанного в обоих. И есть много людей, которые могут понять смысл написанного в обоих. Но я не могу, извините, поверить, что найдется такой человек, который понимает что написано в "вашем" варианте кода, но абсолютно не поймет (не в деталях и не в терминах реляционной теории, а просто на уровне логики происходящего) что написано в "нашем". Какой из этого я делаю вывод ? Чтобы студент, пришедший к нам трудиться после институтской скамьи, чтобы работать с "вашим" языком, должен сначала год ему учиться... причем не как в случае SQL - учиться в процессе решения несложных задач постепенно переходя к сложным, а банально сидеть и смотреть чо да где да как понаписано. Если же этот эмпирический студент придет писать на SQL - несомненно, такой же период будет иметь место, но возьму на себя смелость утверждать что этот период будет на порядок короче.

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

Вот поэтому и хотелось бы узнать сколько строк будет в программе которая будет выполнять уже упомянутый мной запрос (могу его поискать в старом топике если вам лень). Точнее, даже банально любопытно поглядеть на этот поток мысли из символов #$%^&* и имен переменных. Однако ваше упорное нежелание этот код предъявить наводит на мысль что с вами в принципе нет резона обсуждать сравнительные достоинства и недостатки MUMPS и SQL, потому что вы знаете оба почти исключительно с точки зрения теории. А я плохо знаю теорию и в общем-то не считаю что это мне сильно мешает :)
18 ноя 04, 00:31    [1115090]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

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

а второй - это выше моих сил...

А что же Вы хотели? Было время когда весь код вообще писали с использованием только двух символов 0 и 1. В конце концов, это всего лишь детали. Это проблемы кодеров. А главное все-таки это БД.
18 ноя 04, 01:11    [1115145]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Ekuku
Member

Откуда: оттуда
Сообщений: 451
vadiminfo
А что же Вы хотели? Было время когда весь код вообще писали с использованием только двух символов 0 и 1. В конце концов, это всего лишь детали. Это проблемы кодеров. А главное все-таки это БД.
главное все-таки - это не БиДе, а тот бизнес, который в ней отмывается..
Если этот бизнес описывать иероглифами, в которые другой человек быстро не сможет вьехать, то бизнес подохнет.. Поэтому побеждают инструменты тупые и бездарные, но простые.. Посмотрите на PL/SQL или ABAP к примеру..
Все это давно известно.. А мне например безумно нравится Prolog, но в нашем бизнесе его нет, потому как инфраструктуры нет.. или вот SmallTalk где-то в углу притаился..
18 ноя 04, 03:13    [1115223]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
c127
Guest
Андрей Леонидович> вовсе не значит, что не показал. Именно показал, и весьма убедительно.

А вот и образец "убедительного показа"
Андрей Леонидович>"Замкнутое изложение" разбросано по разным страницам.

Андрей Леонидович, раз уж Вы утверждаете, что отвечаете на ВСЕ вопросы, то ответьте и на такой: где Вы учились и какой ВУЗ (ВУЗы) закончили и по какой специальности (специальностям)?

2 Павел Воронцов

Про "market-based education" и пр. это ты хорошо сказал. Поддерживаю.

2 Andrey K

>Ничего не придумал, просто предположил. Гипотеза которую я описал. Основана на теории, теория описана здесь >>>
"Методы представления сложных объектов во внешней памяти"


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

2 vadiminfo

>У меня теперь две таких за 2000 год и за 2003 год.

Попробую найти издание 2000 года. А то я искал 2004, в соответсвии с названием. Не оставляю надежды разобраться.
18 ноя 04, 03:50    [1115229]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Андрей Леонидович
Alex.Czech !

Напрминаю Вам первую реакцию ASCRUS на мои высказывания (речь шла об интегрированном языке баз данных).

Сначала ASCRUS сказал что лучше написать

IF NOT EXISTS (SELECT ??? FROM ??? WHERE ???)
THEN
CALL PRG() ;
RETURN;
END IF;

(и еще оптимизатор будет оптимизировать),
чем

i $$g(io,ie,ih)="" d ^PRG q

И сразу, без всяких объяснений, перешел к "своим" вопросам. Это именно предвзятость и корпоративная солидарность.

Далее ASCRUS странно прореагировал на то, что при использовании ОСУБД сводится к минимуму программирование нерегламентированных отчетов. И я понимаю откуда "растут ноги" у такой реакции. Вот, например, цитата из учебника-руководства по внедрению Oracle Applications 11i (приложение класса ERP):

"Если программист имеет опыт работы с инструментами Developer 2000 и Developer 6i и хорошо знаком со схемой данных Oracle Applications и языком SQL, то создание пользовательских отчетов для приложений Oracle Applications будет относительно простой задачей. Однако, следует помнить, что конечный пользователь не должен заниматься созданием пользовательских отчетов."

Вот как ! Наверное и Выши приложения так "организованы" ?
ПОЛЬЗОВАТЕЛЬСКИЕ отчеты должны создавать ПОЛЬЗОВАТЕЛИ. Так и есть, когда приложение работает в ОСУБД. И в тех, очень редких, случаях, когда невозможно получить нужный отчет с помощью объектного генератора отчетов, я стараюсь сделать все возможное, чтобы программисты ничего не программировали. В результате:

1) программисты решают более важные и интересные задачи;
2) пользователи могут создать МНОЖЕСТВО отчетов в данной "области", а не ОДИН, который им был нужен.

А Ваша технология ничем не отличается от технологии многих мампсистов, которые строят приложения на произвольных глобалах (это, как я уже говорил, можно делать, если не ожидаются нерегламентированные запросы). Совершенно искренне желаю творческих успехов. Надеюсь и Вы мне желаете того же ?

И, главное: все, что я сейчас опять повторил, не выходит за границы элементарной теории баз данных. И это нужно повторять 100 раз ?
Я понимаю, если бы сообщил какую-то НОВУЮ идею. Ее не поняли. Пришлось повторить. Какую это, интересно, НОВУЮ идею (хотя бы одну) Вы нашли в моих высказываниях ? Значит Вам ВСЕ ПОНЯТНО ?

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

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

MUMPS у меня как-то не вызвал восторга. То, что Вы написали, мне сильно напомнило синтаксис макросов на QUATTRO-PRO для DOS, которые я имел несчастье писать году этак в 95ом. Программировать на нём можно и даже иногда красиво получается, но выразительности маловато.

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

Что-то я растёкся мысью по древу... Вы бы лучше, Андрей Леонидович, хоть одно определение дали. Напомню - публика с нетерпением ждёт от Вас откровения на тему
1) Что такое ключ? Определение.
2) Что таоке модель данных. Определение.

Всё ещё надеюсь на просветление.
18 ноя 04, 07:08    [1115280]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Андрей Леонидович
Andrey K !

Я же говорю, молодец ! Творческий человек. Немного подтянуться в теории, и все будет хорошо. Начинать, конечно, нужно с работ Кодда и MUMPS. Создавались одновременно в 1969 году, но на берегах разных океанов.

Тем более странно слышать от вас такие слова :) -
"Никакой реляционной модели данных не существует. То, что называется "реляционная модель данных", настолько плохо формализовано, что говорить о "модели данных" нельзя." (почитайте ещё здесь http://www.citforum.ru/database/dbguide/3-1.shtml )

Я и Ёжик

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

А от методов хранения разве не зависит стратегия поиска? Я считаю, что зависит напрямую.

Я и Ёжик

"По идее" от конструкции самого запроса (если применяется декларативный язык запросов) "стратегия поиска" не зависит для ЛЮБОЙ модели.

Вот тут вопрос... я второй раз слышу в этом топике понятие "декларативный" (и "навигационный"). Хотелось бы понять.... получается, что для обычных РСУБД применение SQL конструкций носит "навигационный" характер а для Cache "декларативный". (Хочу извиниться... , утверждал, что SQL в Cache не нужен.. я говорил с точки зрения.... Однако работа с коллекциями для групп экземпляров действительно очень не удобна... Хотя можно всё же любой запрос написать на чисто ОО языке.)
Если не трудно дайте чёткие определения "декларативный" - "навигационный".

Я и Ёжик

Зависимость плана исполнения запроса от формулировки запроса, это недостаток конкретного оптимизатора в конкретном случае.

Конкретно этим страдает любая стандартная РСУБД. Вы это хотите сказать?

Быстродействие Cache связанно именно с техноголией хранения данных. Засчёт приведения "плоской таблицы" ... к виду иерархических списков. (при этом неизбежно появляется избыточность... дополнительные ключи ("перекрёстные ссылки") для каждой ячейки данных... Но эта избыточность оправдана! ... для самих данных индексы не нужно строить! ... они итак хранятся в виде аналогичном по структуре "кластерному индексу"... индексы вероятно строятся для самих "перекрёстных ссылок" (для повышения эффективности "горизонтального сканирования") при этом вероятно очень эффективно используются bitmap индексы... кроме того создание и поддержку таких индексов можно целиком возложить на само ядро БД...
Такая модель хранения данных, в отличии от традиционных РСУБД позволяет наложить более гибко объектную модель работы с данными и использовать соответственно объектно ориентированный язык для работы с ними!)

С быстодействием Cache и его преимуществами всё понятно. Но есть и недостатки. До сих пор не реализованна полнофункционально репликация! (насколько я осведомлён) ... это огромный косяк... Т.к. для серьёзных проектов имеющих в своей основе распределённую БД.... Её нельзя применить.
Виды и технологии репликации используемые в обычных РСУБД очевидны (просты и понятны для разработчика). Всё уже давно отлажено... А как дело обстоит в Cache?
18 ноя 04, 09:10    [1115395]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Andrey K

Получается, что с одной стороны можно обойтись только объектным языком. :)


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

Кстати тут ещё ни разу не назывался такой продукт - Alphoria Dataphor - который Фабиан Паскаль всем рекомендует как удачную реализацию реляционной системы. Поинтересуйтесь - забавная штука. Написано на .NET, реляционный язык отражается на методах некоторых классов (то есть "A UNION B" трансформируется при разборе во что-то типа "Engin.Union(A,B)") однако эти особенности реализации не мешают системе быть реляционной.
18 ноя 04, 09:20    [1115416]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить