Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 35 36 37 38 39 [40] 41 42 43 44 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 vybegallo

>>У ваших клиентов мумс работает быстро, потому что они больших выборок не делают.

Откуда вы знаете, может и делают ? Тут речь не совсем о СКОРОСТИ РАБОТЫ СУБД, скорее о скорости разработки таких запросов и лёгкости дизайна и performance tuning-a. При изрядной сноровке можно делать достаточно производительные "запросы" для быстрых выборок больших объёмов, проверено на своём опыте :), вопрос в другом : насколько быстро потом в этих запросах можно будет разобраться и\или использовать их для других отчётов\модулей ? Вопрос в том насколько легко потом будет структуру БД модифицировать для слегка(или не очень) изменившихся требований ? Если у вас какой-нибудь "замечательный" МУМПС (?) кто будет разбираться в многостраничных текстах состоящих из $$#%"Object"P->G ? Насколько легко в них ошибиться? И сможет ли кто-нибудь кроме автора в них разобраться ? Коллега ЧАЛ, например, простенький пример от ASCRUS с нарастающим итогом проигнорировал ответив что-то вроде "Ха ха у меня это любой бухгалтер делает", что говорит о том, что это пример весьма трудозатратный, даже для него иначе бы мы получили очередной : PM=g(f$c).

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

В РМД есть только множество и отношение, в этом то и есть их сила и конечно слабость, идеальные СУБД, идеальные ОС и идеальные оптимизаторы бывают только в мечтах и в глазах некоторых фанатов одного финского студента :). Рел. Модель замкнута и у РСУБД есть декларативный SQL который не знает КАК ВЫТАСКИВАТЬ ДАННЫЕ С НОСИТЕЛЯ, НО ЗНАЕТ КАКИЕ и в этом его сила, можете добавлять удалять индексы, менять структуру хранения, переписывать ничего не придётся, можете добавлять новые запросы ничего не изменя в структуре данных, а только заботится об индексах и т.п., оптимизатор , насколько это возможно, сам разберётся КАК.

Ничего похожего на Алгебру отношений из РМД в иерархическом подходе (про который из формальной части известно только то, что данные хранятся в виде дерева) или в сетевом (для которого кроме практической части - CODASYL похороненой ещё в 79 году во время "великого спора") ничаго нету, потому они успешно сдохли и возраждаться не спешат, несмотря на "некроманта" коллегу ЧАЛ-а.

З.Ы. Коллега ЧАЛ, если вы решите ответить, опережая ваш ответ, спешу напомнить, что вы обещали дать ссылки или привести в форуме формальную часть ОМД. По-прежнему жду с нетерпением :|)
14 янв 05, 21:15    [1246801]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
сuriоus.
Guest
Андрей Леонидович
Обращайтесь, пожалуйста, например, к Alexey Rovdo с проблемами ООП и ООСУБД...


Забудьте об этом. Меня не хватит на двух ботов одновременно.


Андрей Леонидович
Про мою "чушь собачью", и что я, конечно, опять "ничего не понял" - это радует. Стабильность - важная "вещь" в споре...


Абсолютно. А уж как меня радует!..


Андрей Леонидович
Извините, конечно, но приходится (раз даже объяснение С.Д.Кузнецова не убедило Вас в том, что про "указатели" и "диски" что-то не то, мягко говоря, сообщали мои оппоненты)...


"Извините" - это не ко мне.
Чужие посты читал по диагонали. Покажите пальцем. Где видел диски - по делу, указатели - не знаю. Не понятно - спрашивайте.

Андрей Леонидович

---------------------

Что же было утрачено, а что приобретено в результате помещения идентификаторов в записи (и называния их ключами), и предложения математического аппарата операций над множествами ?


Ниже вы можете хоть Капитал цитировать.


Что такое объектный навигатор? Объясните своими словами, не как вы по яндексу найдете, а как у вас в голове. На каком языке написан объектный навигатор? Это очень простые вопросы. Вы знаете что такое объектный навигатор?
14 янв 05, 21:35    [1246823]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vybegallo
Guest
Andreww
2 vybegallo

>>У ваших клиентов мумс работает быстро, потому что они больших выборок не делают.

Откуда вы знаете, может и делают ? Тут речь не совсем о СКОРОСТИ РАБОТЫ СУБД, скорее о скорости разработки таких запросов и лёгкости дизайна и performance tuning-a. При изрядной сноровке можно делать достаточно производительные "запросы" для быстрых выборок больших объёмов, проверено на своём опыте :),


И все-таки. Вы - человек "от сохи" - оцените мою задачу в IO.
Я правильно посчитал, что потребуется 2000 чтений ? 1000 чтений первой таблицы + 1000 чтений второй таблицы, верно ?
14 янв 05, 22:48    [1246957]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 vybegallo

Насколько я смог понять по потоку сознания коллеги ЧАЛ-а, и насколько сам видел в некоторой другой "постреляционной" СУБД :), перемещаться не всегда можно только по записям (кортежам,объектам как угодно), но и по индексам ( Btree)построенным по аттрибутам этих записей. Это меняет дело, согласитесь.

Т.е. имея в языке способ обхода индексов, способ обхода записей (навигацию) оператор ветвления (IF) и способ выделения\освобождения памяти, не существует препятствий построить план выборки, например такой же какой выстроит оптимизатор Oracle или MSSQL, а возможно даже и оптимальнее.

Только в одном случае это делает оптимизатор без вашего участия, возможно учитывая такие параметры о которых вы и не подозреваете (например кол-во памяти свободной для использования в данный момент), а в другом случае это делаете вы или ваш коллега :). Кроме того лучше иметь систему где 200 запросов работают не на 100% оптимально,а на 90% зато работают и читаемы, чем систему где 1 запрос работает на 100%, 2-ой запрос дописывается и тестируется, а 198 мы обязательно допишем, скоро :). Кроме того для критических по времени\объему запросов всегда есть хинты, трассировка и прочее, прочее.
14 янв 05, 23:52    [1247089]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый vybegallo !

Я настолько глуп, что глупее не может быть ! Это очень удачная добавка ко всем предыдущим определениям моего умственного развития. Вы на правильном пути !

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

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

Конечно, не нужно мне, глупому человеку, несущему всякий бред, верить на слово, которого я, к тому же, не говорил...
15 янв 05, 00:20    [1247130]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый Andreww !

Я не использую тексты, состоящие из $$#%"Object"P->G, поэтому ни чем не могу Вам помочь в изучении подобных текстов...
На пример ASCRUS я ответил не "ха-ха", а конкретно...
Я не использую иерархические структуры, поэтому ни чем не могу Вам помочь в анализе таких структур...
Про использование индексов в объектных и "реляционных" системах все конкретно объяснял на конкретных примерах...
Про иерархический и сетевой подходы все конкретно объяснил. Поэтому стал еще и "некромантом". Вот это по Вашему !
У меня не было случая, чтобы один "запрос" работал на 100%, 2-ой "запрос" дописывался и тестировался, а 198 я "обязательно допишу, скоро". Наверное Вы опять рассуждаете про какие-то иерархические системы ? Но при чем здесь ОМД и ОСУБД ?

Так Вы тоже, как и с127, "ничего не поняли" в ОМД ?
15 янв 05, 00:29    [1247136]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый curious !

Если Вас "не хватит", то не нужно, по крайней мере, обращаться ко мне с ООП и ООСУБД. Это же не по адресу...
Пожалуйста, не ленитесь, и читайте все сообщения. Ведь, например, мои сообщения тоже чужие для Вас...

Если Вы не знаете что такое объектный навигатор, и на каких языках такие навигаторы пишут, то Вам нужно просто подучиться. Как совершенно справедливо заметил Andreww: форум - не место для ликбеза.
15 янв 05, 00:33    [1247141]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vybegallo
Guest
Андрей Леонидович
Уважаемый vybegallo !

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


Отряд не заметил потери бойца ? Информ Икс уже давно перешел на Cache, а Андрей Леонидович, старый большевик, все рубится за народное счастье в виде MUMPS !
:-)))))))))))
15 янв 05, 00:55    [1247154]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
curious.
Guest
Андрей Леонидович, я могу писать "объектные навигаторы" на разных языках. Меня интересует конкретно Ваш объектный навигатор. Это, видите ли, очень забавный артефакт, если он намертво прилагается к вашей БД. Как у вас происходит навигация без объектного навигатора? На каком языке написан объектный навигатор?
15 янв 05, 00:56    [1247155]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

То есть в приложении (почти в любом !) навигация есть.
Реляционная теория не в состоянии решить эту "проблему". Что делать ?
Либо использовать две "подсистемы" (два языка программирования).
Либо отходить от реляционных принципов.
Инструкции DECLARE CURSOR, OPEN, FETCH, CLOSE - это, конечно, отход от реляционных принципов, не спасающий, к тому же, от другого языка программирования.

Вопрос о навигации и операций над множествами в рел алгебре перепутан с вопросом о взаимодействии универсальных и специализированных языков. Кроме языка БД существуют специализированные языки генерации отчетов, форм и даже приложений. Они тоже как-то взаимодействуют с универсальными языками. Более того, если SQL непроцедурный язык (язык IV поколения), то существуют и процедурные языки БД. Они используются в иерархических и сетевых моделях данных. И тоже встраиваются в универсальные языки. А навигация у них только и есть. Т.е. наличие навигации не исключает двух подсистем. Это вообще вопрос реализации СУБД. Там, как правило, есть специализированный язык БД и базовый (host).
Бывают языки БД и в ООСУБД.
И курсор не отход от реляционных принципов (и не второй по отношению к двум пjдсистемам подход), а механизм обеспечивающий взаимодействие процедурных языков, у которых нет конструкций - "множество записей" и языка БД SQL, у которого таковые конструкции имеются. Хотя, например, у Вижуал Бэйсика есть RecordSET вместо курсора.
Другое дело, что МУМПС не СУБД, а универсальный язык. Там, как это реализует автор, архитектура ИС другая вообще - без СУБД. Прога и данные. Тут тогда автор фактически само СУБД должен отвергнуть в технолгиях БД, если будет последовательным в своей борьбе с РМД. Т.е. он борясь с рел моделью готов, скорее всего, снести все достижения, которые были достигнуты после МУМПС в технологих БД. Тогда следует отменить и понятие БД, а оставить толко данные проги, написанной на МУМПС.
У языка SQL есть множество достоинств, которые и оправдывают его существование. Есть достоинства и универсальных языков. Почему им не сосуществовать на данном этапе инфотехнолгий, если это существование достаточно оправдано в приложениях БД? По крайней мере, не менее оправдано, чем МУМПС в качестве единственного языка для приложений БД. А по мнению многих и более оправдано. В толстых книгах реализация приложение и данные (БД) - это все-таки не есть лучшее из лучшего во всех отношениях. С периодом когда такой подход был единственным связывают дипрессию програмного обеспечения - разочарование в ожиданиях от внедрения ИС тех времен.
15 янв 05, 02:43    [1247224]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
с127
Guest
2 Андрей Леонидович

c127> Я, конечно, отвечаю на все вопросы...

Ну да, только их нужно повторить не 17 раз, а раз 60, наверное.

>Да ! Я, конечно, не стал бы реализовывать РСУБД на MUMPS, хотя многие это сделали. Потому что:

1) "реляционные" СУБД уже были на рынке, и очень плохо себя зарекомендовали (и, эта "рекомендация" не изменилась до сих пор);
2) РМД слабее ОМД.


Так вроде никто и не просил ничего реализовывать. Вы как обычно пытаетесь решать несуществующие проблемы. Был вопрос:
"Андрей Леонидович> Какую модель данных нельзя реализовать на MUMPS с минимальными затратами ?"

Я ответил:
"c127> Например реляционную, в РСУБД затрат будет наверняка меньше, их там 0."

Как обычно вопрос: по существу моего ответа возражения есть? Читайте внимательно.


>Никакой рекламой я, конечно, никогда не занимался - это не мое...

Конечно заниметесь. Вы рекламируете продукт компании, в которой получаете зарплату.

Отвечаю за свои слова. Я - сволочь. Нужно было сказать "Я выбрал MUMPS"...

Пока что Вас в очередной раз поймали только на том, что Вы говорите неправду. Из этого не следует, что Вы сволочь. Поймают на сволочизме - будете сволочью.

Алгоритмы и параметры меняются не только в "задаче" "Расчет ЗП". Имеется давно известный "тупой", элементарный "алгоритм":

а) делается правильный расчет по датам;
б) создаются по датам экземпляры на РАЗНИЦЫ между правильным расчетом и существующим;
в) если экземпляр попадает в "закрытый" период, то сдвигается в "открытый"...


Да уж, алгоритм дейтсвительно тупой, хотя другого ожидать и не стоило. Лучше было бы написать так:

Алгоритм пересчета зарплаты в духе Андрея Леонидовича:
a) правильно пересчитывается зарплата.

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


"Задача" "Расчет ЗП" сложна вовсе не из-за алгоритмов, а потому что она весьма объемная. Посмотрите любое развитое "зарплатное" приложение (в котором есть, разумеется, полноценная кадровая "часть", нормирование труда для выполняемых технологических операций, учет выработки по этим операциям для расчета сдельной оплаты труда и т.п.), и Вы увидите сколько там нормализованных отношений (в Вашей терминологии)...

Вот блин, достает иногда необразованность собеседника. Так все эти КЗОТЫ, ГОСТЫ, или что-то еще, чем оно там все регулируется и ЕСТЬ АЛГОРИТМЫ. Их объемность это и есть сложность алгоритмов расчета. Вы по-видимому, по простоте душевной, перепутали сложность алгоритмов с алгоритмической сложностью, так это Ваши проблемы.

В отличие от Вас, мы таки построили работающую систему расчета зарплаты на госпредприятии. Она не пошла в производство, но большинство тестов прошла успешно. Поэтому я знаю совершенно четко сколько там "нормализованных отношений", и что в данном случае основная проблема не куда положить данные и как их прочитать, а как записать всю эту "весьма объемную" задачу на алгоритмическом языке, иначе говоря как ПОСЧИТАТЬ зарплату. Язык может быть любой, мы выбрали C/C++, ASCRUS выбрал WatcomSQL, разницы мало. Все это к технологиям баз данных отношения не имеет, данные там можно и в екселе хранить, длина программ практически не изменится. Поэтому не нужно изрекать глупости, что "дело ИМЕННО В ТЕХНОЛОГИЯХ." (Андрей Леонидович) и что "Если бы такая задача решалась более одного человекогода, для меня это был бы настоящий скандал" (Андрей Леонидович). Сначале подтвердите хоть как нибудь свои слова о человекогоде, а то Вас тут неоднократно ловили на вранье, как бы опять чего не вышло.

c127> Советую Вам не "лезть" в "приложения" и "алгоритмы" - там от Вас мокрого места не останется.

Ну с этим только что разобрались.


И это выходит за рамки темы...

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


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

Вот это и будет разговор по-существу.
15 янв 05, 03:08    [1247234]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович

>Когда пользователь нажимает клавишу <стрелка вниз> или <стрелка вверх>, и "перемещается" на следующую (предыдущую) запись товарной накладной - это навигация. То есть в приложении (почти в любом !) навигация есть.
Реляционная теория не в состоянии решить эту "проблему". Что делать ?

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


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

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

>Ведь навигация на уровне БД радикально упрощает и неизбежную навигацию на уровне приложения.

Точно упрощает? А по-моему как раз будет проще если отделить навигацию в приложении от навигации в БД, которая тогда станет вообще не нужна. Как это и делается, например, в PowerBuilder-е.

>Так что мой посыл - "Р"СУБД шаг назад к временам до СУБД, а SQL бесполезен для получения данных - остается в силе, хотя и "заставляет" выдерживать "тяжелое противостояние"...

Посыл-то есть, да истины в нем, как мы только что видели, нет. А из ложных посылов, как нам известно, следует все что угодно.
15 янв 05, 04:22    [1247246]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 ..... ну всё поняли :)

>>Я не использую тексты, состоящие из $$#%"Object"P->G, поэтому ни чем не могу Вам помочь в изучении подобных текстов...

А я и не просил вас помогать, я просил вормализованное описание ОМД.
А тексты которые ВЫ используете ещё страшнее :

s ie2="" f s ie2=$$oc(io1,io2,ns,ie1,ie2) q:ie2="" d

или

s query(1)="h2.o1,h7.o2",query(2)="o1,o2",query(3)="h2=h7"
s result=$$^%oz("query","result")

и ничуть не лучше чем

$$#%"Object"P->G

>>На пример ASCRUS я ответил не "ха-ха", а конкретно...

Неужели я пропустил ссылку или пост где был КОНКРЕТНЫЙ текст запроса (программа) которая на МАМПС, решает ASCRUS-овскую задачку.
Г-н ASCRUS ответье, пожалуйста,неужели пропустил ? ))))))))))

>>Я не использую иерархические структуры, поэтому ни чем не могу Вам помочь в анализе таких структур...

Но и про объектный подход нам пока ничего не известно. Ждём-с формального описания, чёткого и внятного :)
Там будет видно что же вы используете :)

>>Про использование индексов в объектных и "реляционных" системах все конкретно объяснял на конкретных примерах...

Вас никто не просил объяснять про устройство индексов, вас просили только привести формальное описание ОМД :)
Да вообщем-то, большинству присутствующих и без обяснений всем известно как устроены Btree и Bitmap индексы.

>>Про иерархический и сетевой подходы все конкретно объяснил. Поэтому стал еще и "некромантом". Вот это по Вашему !

Вас никто не просил рассказывать про устаревание сетевого и иерархического подхода, вас просили только привести формальное описание ОМД :)
Совсем не сожно в поисковике набрать : "Кодд" "Великий спор" "Вклад" уверен ссылки будут :)
Почему вы тогда так удивились когда я сказал что концепция иерарических подходов отжила своё и успешно сдохла ?
Напомнить ссылочкой когда это было ;)
Есс-но я стал подозревать вас в некромантии

>>У меня не было случая, чтобы один "запрос" работал на 100%, 2-ой "запрос" дописывался и тестировался, а 198 я "обязательно допишу, скоро". Наверное Вы опять рассуждаете про какие-то иерархические системы ? Но при чем здесь ОМД и ОСУБД ?

Вас никто не спрашивал, какие у вас случаи были, вас просили только привести формальное описание ОМД :)
Пока его нету считаем,что я рассказываю г-ну Vybegallo почему и как сдохли иерархические СУБД и никакие Каше с иерархическими подходам их не спасут не смотря на маркетинговый слоган про "объектность".
15 янв 05, 13:13    [1247436]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый vybegallo !

Когда же Вы, наконец, поймете (ТРЕТИЙ ГОД ИДЕТ !) что такое MUMPS, что такое Cache, и что такое COS в Cache ???
15 янв 05, 20:46    [1247805]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый curious !

Как Вы понимаете у "меня" все написано на одном языке, и Вы прекрасно знаете на каком...
15 янв 05, 20:48    [1247807]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый vadiminfo !

Вы не правы, утверждая что MUMPS не СУБД. Не случайно, в свое время решили ввести понятие М-технология, чтобы, в том числе, подчеркнуть, что MUMPS - это не просто интегрированный язык баз данных.
Вы, все-таки, не хотите понять (не могу сказать про Вас "не понимаете", хотя раньше один раз сказал) существо технологии...
Еще раз подчеркну, что ОСУБД не препятствует ни декларативному программированию, ни SQL, в частности. Просто я совершенно конкретно объясняю почему в SQL нет необходимости...
15 янв 05, 20:53    [1247812]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый с127 !

Примите мои глубочайшие соболезнования, если основная проблема для Вас "как ПОСЧИТАТЬ зарплату". И я искренне рад, что "вы" "таки построили работающую систему расчета зарплаты на госпредприятии". Вы "строили, строили, и, наконец, построили" !

А то, что дело именно в технологиях, Вы обязательно поймете. И Вам станет стыдно...

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

А лучше, не упрямьтесь, и переходите к разговору по-существу обсуждаемых вопросов.
15 янв 05, 20:58    [1247819]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый Andreww !

Раз участвуете в дискуссии в такой форме, то, пожалуйста, все внимательно читайте, анализируйте, и не торопитесь. Некуда нам торопиться...
Какое еще устройство индексов ???
Тем более B-tree ???

Вы просто не хотите понять что я объяснял про индексы в "реляционных" системах и индексы в объектных системах...
Видимо скоро придется опять повторять старые сообщения...

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

Я иерархические СУБД не использую, но то что они "сдохли" - это, конечно, маркетинговый слоган. "В бессильной злобе красные наймиты..." И т.д.

Так Вы тоже, как и с127, "ничего не поняли" в ОМД и ОСУБД ?
И из-за этого решили "отомстить" каким-то иерархическим СУБД ?
15 янв 05, 21:10    [1247823]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
curious.
Guest
Андрей Леонидович
Уважаемый curious !

Как Вы понимаете у "меня" все написано на одном языке, и Вы прекрасно знаете на каком...


Большое спасибо, Андрей Леонидович. Теперь я понял зачем вам эта штука, благодаря которой "пользователи приложений на ОСУБД получают сами, без программистов и программирования". Вы скорее всего обломаетесь сами написать на мумпсе полноценный пользовательский интерфейс, поэтому вам и выдают 1С-подобные оболочки, из принципа написанные на том же языке. Я бы постеснялся вот так честно про объектный навигатор. Вы очень отважный человек
Не поленился прочитать фак по мумсу (по диагонали, извините) и не пожалел потраченного времени. Я как будто потягивал пивко у камина, наблюдая как за окном Андрей Леонидович и Ко по колено в дерьме спасают Землю от пришельцев. Очень, очень способствует. Вопрос №29 "Do comments really affect efficiency?", поверг меня в истерический хохот. О, да тут еще и ответ... Простите, я щаз не могу про нерегламентированные запросы
16 янв 05, 00:23    [1247926]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович

>Примите мои глубочайшие соболезнования, если основная проблема для Вас "как ПОСЧИТАТЬ зарплату".

Правильно, Андрей Леонидович, не нужно считать. И думать не нужно, есть MUMPS, который думает за Вас: "И, еще раз напоминаю, что многое из того, что приходится программировать в приложениях на "Р"СУБД, пользователи приложений на ОСУБД получают сами, без программистов и программирования." (Андрей Леонидович). Это ведет к атрофии мозга, но Вам не привыкать, как и к скандалам.

Скажите, лучше, где учат таким алгоритмам:
"а) делается правильный расчет по датам;" (Андрей Леонидович, 14 янв 05, 17:51)?

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

Я верю, что в Ваших приложениях вообще никаких проблем нет.

Андрей Леонидович> И я искренне рад, что "вы" "таки построили работающую систему расчета зарплаты на госпредприятии".

Не льстите себе, Вам, этого, не понять. Для того чтоб понять нужно построить хоть одну работающую систему. Но Вам это совершенно не грозит, расслабьтесь. Если бы Вы написали в жизни хоть одно настоящее приложение, то не изрекали бы с умным видом откровения вроде: ""Более сложные" случаи - это всего лишь комбинации перечисленных" (Андрей Леонидович [1246602]).



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

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


Так, налицо очевидный прогресс. Наш герой освоил cut-paste рехнику и интенсивно копирует наиболее удачные с его точки зрения результаты своих мозговых усилий из поста в пост. Поразительный успех, ведь только "ТРЕТИЙ ГОД ИДЕТ!" (Андрей Леонидович), страшно подумать, что будет дальше.

Андрей Леонидович, Вы почему-то ушли от ответа на на вопрос, до сих пор ли Вы работате в Информ-икс или Вас уже выгнали?

Еще вопрос, на который по-прежнему нет ответа.
На какой странице учебника по теории множеств Вы забросили попытки изучения, если утверждаете, что нельзя перебрать конечное множество элемент за элементом и "Реляционная теория не в состоянии решить эту "проблему""? (Андрей Леонидович, [1246602])

А риторическое "Что делать ?" ((С) Н.Г.Чернышевский 1863 год, В.И.Ленин 1901 год, Андрей Леонидович 14 янв 2005 года, 18:43) выбивает из-под ног оппонентов остатки шаткого фундамента реляционной теории.
16 янв 05, 01:15    [1247944]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 :))

Уважаемый Andreww !

>>Раз участвуете в дискуссии в такой форме, то, пожалуйста, все внимательно читайте, анализируйте, и не торопитесь. Некуда нам торопиться...

Господь с вами уважаемый :)), какая ещё дискуссия :))
Я жду от вас ссылки (или текста) с формализацией ОМД, как получу будем дискутировать.

>>Какое еще устройство индексов ???
>>Тем более B-tree ???

Для вас это новость ? Что в большинстве СУБД существуют индексы на основе Btree или B*tree ?

>>Вы просто не хотите понять что я объяснял про индексы в "реляционных" системах и индексы в объектных системах...

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

>>Видимо скоро придется опять повторять старые сообщения...

Ой-ей ей. Не надо, пожалуйста.

>>"Вклад в великий спор" (как совокупность докладов и статей) для своего времени может быть и выглядел строго и формально. Ну не знали люди на берегу Тихого океана что делается на берегу Атлантического.

Да Кодд про вас и про меня не слышал, это точно :))

>>Но сейчас просто смешно об этом говорить.

С вами вообще очень смешно говорить.

>>Я в этой дискуссии очень тщательно и подробно цитировал и основоположника, и самого последовательного сторонника РМД в части "ключей".

Хммммм. А ответs на свою ШТАТЬЮ читали в этом топике ? А зря. Надо бы :))

>>Если будет желание можем проанализировать и "вклад в великий спор"...

Конечно "проанализируем" :)) ПОСЛЕ ФОРМАЛИЗАЦИИ РМД. Давайте всё же по-порядку :)

>>Я иерархические СУБД не использую, но то что они "сдохли" - это, конечно, маркетинговый слоган. "В бессильной злобе красные наймиты..." И т.д

Да ну ??? В бессильное говорите злобе :)) А вы попробуйте зайти на dice.com :)) MUMPS - 26, Cache - 213, IMS - 388, Oracle - 9209 И никаких наймитов :)) Ни красных ни чёрных.

>>Так Вы тоже, как и с127, "ничего не поняли" в ОМД и ОСУБД ?

Нет я как раз абсолютно всё понял. Ни ОМД ни ОСУБД не имеют чёткой формализации, у каждого производителя своя ОМД и ничего не опеределено хотя бы примерно. Или нет ? Или есть всё же работы с попытками формализовать ОМД ? Жду, жду с нетерпением ! И с127 наверное тоже ещё ждёт :))

>>И из-за этого решили "отомстить" каким-то иерархическим СУБД ?

Не, я жду ФОРМАЛИЗАЦИИ, а пока жду решил обяснить г-ну vybegallo почему исчезли (~9000 позиций против ~400 это не просто исчезли, это растворились) иерархические и сетевые СУБД. Зачем мне "мстить" давно исчезнувшим динозаврам ?

На "некроманта" не обижайтесь пожалуйста, извините если что не так, но посудите сами :

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

- Вы хранитель "утерянного знания о навигации", которое все, кроме вас не то что не стремятся обрести, а скорее наоборот, стараются избежать.

- Определения (которые вам очень нравятся), напоминают труды средневековых алхимиков : "Объект это всё что противостоит субъекту ..."

- Ваш любимый язык с трудом воспринимается всеми, кроме небольшого кол-ва личностей и похож на древние скандинавские руны: s query(1)="h2.o1,h7.o2",query(2)="o1,o2",query(3)="h2=h7"

- Вам очень нравятся давно устаревшие и мёртвые вещи типа иерархических СУБД

НУ КАК ТУТ БЫЛО НЕ ОШИБИТЬСЯ ????
Просто я очень ЖДУ обещанного формального описания ОМД, оттого и рассудок помутился чес. слово.
16 янв 05, 19:58    [1248272]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый curious !

Не хотите понимать о чем идет речь ?

Что Вы "поняли" ???
Какая "штука" ???
Какие "1С-подобные оболочки" ???
Кто мне их "выдает" ???
Что я должен "постесняться" ???

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

----------------------- постарайтесь понять это ---

Что же было утрачено, а что приобретено в результате помещения идентификаторов в записи (и называния их ключами), и предложения математического аппарата операций над множествами ?

1. Утратили.

1.1. Идентификацию. Частично. Она стала настолько "кривой", что (парадокс) привела еще к трем утратам.

1.2. Навигацию. Полностью.

1.3. Интегрированный язык. Полностью.

1.4. Семантику данных. Почти полностью.

2. Остались "при своих". Возможность применения декларативного языка запросов.

3. Приобрели. Более "естественное" "связывание не по ключам". Часто эту возможность ошибочно выдают за "возможность нерегламентированных запросов". Это не так. Нерегламентированные запросы - это запросы, которые не написаны прикладным программистом в рамках приложения, и их создают сами пользователи. И, как мы уже убедились, в приложениях на "Р"СУБД - это (в отличие от ОСУБД) определенная проблема.
Но есть разница. Если рассмотреть некий язык (типа SQL), в который "транслируются" пользовательские "запросы" (хотя в объектных системах - это далеко не всегда так !), то в инструкции FROM:

а) в реляционных системах - произвольные таблицы;
б) в объектных системах - связанные объекты.

Но ! В объектных системах есть возможность использовать и "традиционный SQL" ради "связывания не по ключам".

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

Так вот и нужно, чтобы объяснить применение "Р"СУБД, искать задачи с актуальностью "связывания не по ключам", да еще и доказывать силу оптимизаторов "Р"СУБД (а, обратили внимание, чуть-чуть затронули этот вопрос, и оказалось: и ошибается оптимизатор в тривиальных случаях, и сбор статистики не производит впечатления хорошей проработанности; а ведь оптимизатор - "сердце" "Р"СУБД).

А здесь все были увлечены поиском задач для ПОСТреляционных ООСУБД, с которыми они справлялись бы лучше, чем "Р"СУБД. И пока еще не обнаружено ни одной задачи, с которой "Р"СУБД справлялись бы лучше, чем ДОреляционные ОСУБД.

Может быть через месяц, когда придется по просьбе очередного невнимательного зрителя опять все это повторять, появится какая-то благоприятная для "Р"СУБД информация ?

----------------------

Пока появилась гипотеза vybegallo: ЛЮБАЯ ЗАДАЧА с "большими [???] объемами данных" и "большими [???] отчетами" может быть решена ТОЛЬКО С ПОМОЩЬЮ "Р"СУБД (то есть с помощью СУБД, которые хотя бы в какой-то степени (???) поддерживают РЕЛЯЦИОННУЮ МОДЕЛЬ ДАННЫХ).

То есть совет тем, кто эксплуатирует некие "нереляционные системы" звучит примерно так: в ожидании того момента, когда объемы данных станут "большими", не теряйте время и готовьтесь к переходу на "Р"СУБД.
А никто не поможет как-то оценить прилагательное "большие" ? Вдруг критический момент настанет уже завтра ? Или, наоборот, через 1000 лет ?

----------------------- постарайтесь понять это ---

Когда пользователь нажимает клавишу <стрелка вниз> или <стрелка вверх>, и "перемещается" на следующую (предыдущую) запись товарной накладной - это навигация. То есть в приложении (почти в любом !) навигация есть.
Реляционная теория не в состоянии решить эту "проблему". Что делать ?
Либо использовать две "подсистемы" (два языка программирования).
Либо отходить от реляционных принципов.
Инструкции DECLARE CURSOR, OPEN, FETCH, CLOSE - это, конечно, отход от реляционных принципов, не спасающий, к тому же, от другого языка программирования.

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

Извините, конечно, что приходится цитировать такие банальные вещи на столь серьезном форуме:

Дж.Грофф, П.Вайнберг. Энциклопедия SQL. 3-е изд. 2004, стр. 477:

"
- Инструкция OPEN устанавливает курсор в положение, предшествующее первой строке таблицы результатов запроса. В этом положении у курсора нет текущей строки.
- Инструкция FETCH продвигает курсор на следующую доступную строку таблицы результатов запроса, если таковая имеется. Данная строка становится текущей строкой курсора.
- Если инструкция FETCH продвигает курсор в положение, следующее за последней строкой таблицы результатов запроса, то эта инструкция возвращает предупреждение NOT FOUND. В данной ситуации у курсора опять нет текущей строки.
- Инструкция CLOSE прекращает доступ к таблице результатов запроса и закрывает курсор.
"

Далее повторю еще раз примеры объектных функций. Обратите внимание на пример 2, и сравните с соответствующей "курсорной" реализацией перебора строк в РЕЗУЛЬТАТЕ (то есть до этого еще одна навигация - по БД - должна быть выполнена) запроса.

1. Получить значения нескольких характеристик экземпляра ie объекта io:

d $$gs(io,ie,"gs")

где в gs(ih) - список идентификаторов нужных характеристик и полученные значения.

2. Получить список всех идентификаторов экземпляров ie2 объекта io2, связанных с экземпляром ie1 объекта io1 по связи ns - это типичная "задача" "получить все записи (в широком смысле слова) данного документа (в широком смысле слова)":

s ie2="" f s ie2=$$oc(io1,io2,ns,ie1,ie2) q:ie2="" d
.; здесь что-то делаем с экземплярами ie2
.q

3. Получить "документ" по "записи":

s ie1=$$oc(io2,io1,ns,ie2,"")

4. Получить значение характеристики ih экземпляра ie объекта io:

$$g(io,ie,ih)

например, получить дату "документа" от "записи":

s data=$$g(io1,$$oc(io2,io1,ns,ie2,""),ih)

где ih - идентификатор характеристики "Дата".

------------------

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

И, еще раз напоминаю, что многое из того, что приходится программировать в приложениях на "Р"СУБД, пользователи приложений на ОСУБД получают сами, без программистов и программирования. Эта "тонкость" все время ускользает от внимания многих участников дискуссии. Но, надеюсь, Вы понимаете что такое объектный навигатор...

Так что мой посыл - "Р"СУБД шаг назад к временам до СУБД, а SQL бесполезен для получения данных - остается в силе, хотя и "заставляет" выдерживать "тяжелое противостояние"...

----------------------- постарайтесь так же понять ---

- Чем объектные навигаторы отличаются от "1С-подобных оболочек".
- Что прикладные задачи в ОСУБД, конечно, написаны на том же самом языке, и запускаются, конечно, из объектного навигатора.
- О чем мы здесь говорим уже год.

И тогда Вы, наконец, доберетесь до многострадальных "нерегламентированных запросов"...
16 янв 05, 20:54    [1248302]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый Andreww !

Я, в отличие (видимо) от Вас, не живу на берегу Атлантического океана. То есть опять "ничего не поняли" ?
И что же я должен делать в такой ситуации ?
Пожалуйста, почитайте мое последнее сообщение для curious...

Хотите вернуться к подтеме "ключи и идентификаторы". С удовольствием !
Конечно, ПОСЛЕ ФОРМАЛИЗАЦИИ РМД. Именно, давайте по порядку. В историческом, так сказать аспекте.

Хотите про "вклад в великий спор" поговорить ? С удовольствием !

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

А статистика, которую Вы привели, уж точно не в пользу "Р"СУБД, я это уже объяснял...
16 янв 05, 21:06    [1248306]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый с127 !

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

А с "приложениями" и "алгоритмами" Вам еще рано "общаться". И, тем более, обсуждать такие "вопросы" со мной...
16 янв 05, 21:16    [1248314]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Как только терпения хватает отвечать...
Эту бы энергию да в мирных целях...
16 янв 05, 21:30    [1248320]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 35 36 37 38 39 [40] 41 42 43 44 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить