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

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


Андрей Леонидович, я не настолько любопытен, чтобы интересоваться тем конкретным программным продуктом, который вы по какой-то причине называете ОСУБД, и который состоит по крайней мере из двух частей, одна из которых написана на плохом языке, позволяет пользователям "без программистов и программирования" получать две стрелки, и называется "объектный навигатор", а остальные я уж не знаю как. Я не буду второй раз просить вас объяснить природу этого феномена своими словами. Дайте формальное самодостаточное определение объектного навигатора.
Обратите особое внимание: я не читаю ниже известной вам строчки.
16 янв 05, 23:23    [1248399]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

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



А Вы постарайтесь понять или хотя бы немного подумать о том, что курсоры призваны «не спасть» от второй системы, но, наоборот, избежать такового якобы "спасения". Курсоры используются, например, во встроенных в другие языки SQL. Например, в С. Потому, что С может сам работать с одной записью, но не может со множеством записей. И это не есть навигация. Это в терминах этого языка просто управления вычислениями. Курсор - указатель на набор записей.
Навигация в приложении не есть навигация в модели данных, типа иерархической. Индоевропейские языки многозначны, и не все что называется «навигацией» имеет значение, когда сравниваются модели данных. Например, летняя навигация северных морских путей не имеет к этому никакого отношения. Как впрочем, и навигация кнопок интерфейса – может быть вообще в системе без БД.
Кроме того, навигация в модели данных (иерархической или сетевой) не спасает от двух систем, если для реализации интерфейса приложения нужен С++. Или МУМПС лучше С++? Что касается SQL, то дело в его декларативности (какая бы модель данных не была, она всегда бы "хотела" иметь декларативный язык БД - язык IV поколения), когда речь идет о второй системе (язык процедурный III поколения). Другие языки IV поколения, например, генератор приложения – (тоже декларативный язык), тоже не задаются целью спастись от второй системы. SQL до появления SQL3 не содержал средств для управления ходом вычислений - циклов, переходов и т.д (хотя в СУБД были таковые языки). И потому не обладал вычислительной полнотой. Т.е. мы должны отказаться от декларативности? Ведь инструкции SQL можно интерактивно выполнять в специальных приложениях и управлять БД и извлекать информацию достаточно сложную. Это имеет большое значение для ИС во всех отношениях. И ради чего от этого отказаться? Ради якобы интегрированности? Ну, считайте С со встроенным SQL интегрированным. Бросайте свой МУМПС вместе с М- технологией, и переходите на С: по крайней мере, не будете выглядеть таким ретроградом на форумах.
Впрочем, зная Ваши манеры, допускаю, что Вы будете повторять свои мысли про курсоры, игнорируя ответы оппонентов. Этот метод доказательства – доказательство измором: Повторять любой вздор пока Оппонентам не надоест. Рано или поздно они перестанут отвечать. Вот и теорема якобы доказана. Не оппонентам, так руководству своей фирмы. Потом придумаете новые наивные мысли, чтобы спровоцировать активность новых оппонентов, и так же их "докажете".
17 янв 05, 01:13    [1248444]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович

>А с "приложениями" и "алгоритмами" Вам еще рано "общаться". И, тем более, обсуждать такие "вопросы" со мной...

Я уже предлагал Вам по отношению к себе пользоваться фразой "Зовите меня просто: Бог".

Смотрим внимательно.

Андрей Леонидович 14 янв 05, 17:51> Задача" "Расчет ЗП" сложна вовсе не из-за алгоритмов, а потому что она весьма объемная. Посмотрите любое развитое "зарплатное" приложение ..., и Вы увидите сколько там нормализованных отношений...

Определение понятия "весьма объемная" как противопоставление понятию алгоритма, получить у Андрея Леонидовича очевидно не удасться. Ну и ладно, не впервой, идем дальше.

Андрей Леонидович 9 янв 05, 20:35>А ведь не может быть никаких сомнений (у меня, во всяком случае их нет), что ASCRUS - профессионал высокого класса. (повторено 2 раза, видно очень уж хотелось обратить внимание на этот факт)

Цитирую уважаемого и нами и Вами ASCRUS-а из того топика, который Вы будто бы "ЕЩЕ РАЗ тщательно, не пропуская ни одного сообщения," (Андрей Леонидович [1232219]) перечитали.

ASCRUS>
В моем последнем проекте "Расчет заработной платы",...
Во первых у меня перед глазами была постановка старой задачи Расчет ЗП, написанной еще аж на Досовом доисторическом MS Си. Постановка для этой задачи была разработанна очень профессионально,....
Тихий кошмар - сплошные исключения из правил, ...

Это введение. Решается сложная задача, но с хорошей постановкой и устаревшим решением на С. Никаких специфических сложностей из-за выбора РСУБД в качестве средства ASCRUS не ожидает. Дальше:
ASCRUS>
Каждый обьект может иметь один или множество алгоритмов....
Теперь об расчетных ХП, на которые ссылаются алгоритмы - каждая ХП отвечает за расчет одного или нескольких расчетных обьектов,...
Задним числом могут изменяться не только входящие данные, но и даже алгоритмы расчетов.
Во вторых в технологическом плане построения сложных расчетов у меня имеется достаточный опыт построения систем с сложными или динамически изменяющимися алгоритмами обработки информации
Насчет самого движка - зарплата - продукт, действительно имеющий уникальные, сложные и динамически изменяющиеся алгоритмы расчетов.
Для движка расчетов я использовал 3 самые элементарные вещи любого порядочного SQL сервера - хранилище данных, хранимые процедуры и динамический SQL. Можно сказать, была разработана обьектная модель расчетов, где любое начисление, удержание или налог приравнивается к обьекту, имеющего один или несколько алгоритмов расчета, способных изменяться во времени, а сами скрипты алгоритмов расчетов (решения) хранятся в виде ХП.


И т.д. в том же духе.

По-прежнему нет никаких сложностей из-за специфики реляционной структуры данных. И не будет.

Рассказывая о сложности расчета зарплаты ASCRUS постоянно говорит о каких-то сложных алгоритмах и пр, но почему-то ни слова не сказал о загадочных "нормализованных отношенях", которых по предположению Андрея Леонидовича в системе должно быть невероятное количесво, и именно из-за которых (а вовсе не из-за сложных алгоритмов) задача расчета зарплаты так сложна при решении в РСУБД. Один раз мимоходом было упомянуто "хранилище данных".

Тут еще фигурируют некие хранимые процедуры (ХП), динамический SQL и модель расчетов, так вот для темных сторонников МУМПСА напоминаю, что это тоже есть алгоритмы в чистом виде, а не структура данных и уж точно не "нормализованные отношения".

Получается что
1) либо ASCRUS тоже, вместе со всеми нами, не является "профессионалом высокого класса", как было заявлено ранее, не разбирается в проблеме расчета зарплаты и полтора года пишет не расчет зарплаты а неизвестно что,
2) либо Андрей Леонидович как обычно херню спорол со своими "нормализованными отношениями" и алгоритмами.

Даже если выбрать первое, то опять же получается что Андрей Леонидович спорол херню, но уже при оценке профессионализма ASCRUS-а и повторил это 2 раза. Но по-моему второе все-таки вероятнее.




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

Не нужно ничего говорить, уже все сказано. Совершенно очевидно, что Ваша единственная цель - отработать зарплату, которую Вам по-видимому платит или платила компания Информ-икс, для чего Вы тут рекламируете никому ненужный MUMPS, который Информ-икс пытается продвигать на рынке. То что с "Пока с ней (с целью) ничего не получается", есть совершенно закономерный факт, потому что реклама в Вашем стиле является антирекламой. Ваш агрессивный стиль и абсолютная неспособность отвечать на вопросы распугивает потенциальных клиентов и Вы растеряли даже тех немногих сочувствующих, которые искренне пытались у Вас что-то выяснить. Агрессивным можно быть когда есть что ответить оппонентам по-существу, но это не Ваш случай.
17 янв 05, 03:25    [1248469]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

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

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

Итак, с навигацией "на уровне приложения" пришлось смириться - ведь она объективно есть. А "смириться" с навигацией на уровне баз данных "мешает" математика ? Уверен, что в борьбе математики со здравым смыслом победит, как всегда, здравый смысл. Ведь навигация на уровне БД радикально упрощает и неизбежную навигацию на уровне приложения.
Подождите, подождите! Так мы про приложения или базы данных? Вы нам тут пеняете, что мы от темы уклоняемся с зарплатой, а сами...
Андрей Леонидович
"Более сложные" случаи - это всего лишь комбинации перечисленных и аналогичная навигация (в терминах модели данных !) по индексам, так как индексы в ОСУБД являются полноценной частью данных, а не каким-то придатком для ошибающегося, как выяснилось, даже на элементарных запросах, оптимизатора...
Так что же оно такое, эта самая ОМД?! Покажите мне её, дайте ссылку!
17 янв 05, 06:46    [1248500]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Мне кажется, что вести спор о состоятельности/не состоятельности РСУБДvsMUMPS без толку по одной простой причине - абсолютно разные технологии. Это тоже самое, как существу из другого измерения доказывать, что физические законы нашей вселенной гораздо состоятельнее, чем их законы. В данном случае общего между MUMPS и РСУБД только одно - назначение - хранить и обрабатывать данные. Даже между файл-серверными технологиями (FoxPro, Access, DBase, etc) и клиент-серверными гораздо больше одинаковых свойств, чем между MUMPS и РСУБД. Было бы конечно интересно понаблюдать битву между теми, кто работает на Лиспе или Форт против того же C++ или Java, но думаю результат был бы такой же - нулевой. Поэтому я могу точно сказать только одно - не нам судить MUMPS. Я подозреваю (не на пустом месте), что там есть неплохие фичи, позволяющие более легко и с меньшими затратами описывать структуру хранения данных предметной области. И не Вам Андрей Леонидович судить РСУБД, потому как связка SQL+Dynamic SQL+Triggers+Stored Procedures позволяет эффективно и быстро изменять, управлять и обрабатывать огромные массивы данных, реализовывать в базах данных сложную бизнес-логику работы с множествами (что более правильно, чем работа с единичными обьектами - ведь в конце концов наши задачи сводятся не к построению мира обьектов аналогичных предметной области, а всего лишь хранение информации о них) и главное - свести всю работу с информацией в одну централизованную точку, гарантируя такие важные параметры, как целостность и непротиворечивость данных, защита доступа к ним, надежность хранения и отказоустойчивость системы. Как известно - увеличивая функциональность в чем то одном мы всегда проигрываем в чем то другом. Поэтому каждая технология, каждый продукт имеет свои плюсы и вытекающие с них свои минусы. С учетом того, что опять же наша задача при создании информационных автоматизирующих систем - минимальными затратами решить на существующем на текущий момент ПО поставленную задачу, а не стремиться к идеальному продукту и выбору идеальной технологии, то все решается не технологиями, а грамотностью и знаниями специалиста, перед которым была поставленна эта задача.

P.S. Для Андрея Леонидовича - можно прочитать сколько угодно книжек про РСУБД и я могу прочитать сколько угодно книжек про MUMPS. Ни Вам, ни мне это не будет давать повода рассуждать о несостоятельности той или иной технологии, максимум что мы сможем с Вами выразить - это удивление тем, как же различаются в корне даже сами парадигмы разработки информационных приложений. Для того же, чтобы судить конкретно о продуктах нам придеться пару годиков поработать с технологией, создать и запустить на ней проекты, и только потом ее можно будет более менее обоснованно начать критиковать. Кстати исходя из личного опыта могу сказать, что критиковать то, что не понимаешь, нахваливая то, что знаешь - это самый дурной маркетинговый ход, который можно только придумать. В данном случае было бы граммотнее сравнивать по общим вопросам построения автоматизированных систем, а не физическую реализацию той или иной системы, фактически проводя ликбез для себя и своих оппонентов.
17 янв 05, 10:49    [1248896]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
curious.
Guest
ASCRUS
Мне кажется, что вести спор о состоятельности/не состоятельности РСУБДvsMUMPS без толку по одной простой причине - абсолютно разные технологии.


Нет, ну почему же, есть ведь бесспорно неэффективные, ужасные технологии разработки информационных систем. Ассемблер, GW-BASIC, MUMPS, ОСУБД...
Андрей Леонидович вовсе не спорит с этим.
Андрей Леонидович хочет случиться невинно зобаненым
Андрей Леонидович 5 (пять) раз проделывает на доске следующее упражнение.
1. Предлагается некая недопустимая операция типа манипуляций с нулевыми указателями.
2. Приводится список проблем, к которым привела недопустимая операция.
3. Список группируется по признаку "потеряли/приобрели"
4. Предлагается понять список.

Вот оно:

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


Исходные данные:

namespace RSUBD
{
  class IdRow {}
}

namespace OSUBD
{
  class IdObject {}
}


Реализация:

OSUBD.IdObject idObject1 = new OSUBD.IdObject();

// RSUBD.IdRow idRow1 = idObject1;
//  RESULT: compiler error CS0029: Cannot implicitly convert type 'OSUBD.IdObject' to 'RSUBD.IdRow'
//  REASON: windows must die!
    
// RSUBD.IdRow idRow1 = (RSUBD.IdRow)idObject1;
//  RESULT: compiler error CS0030: Cannot convert type 'OSUBD.IdObject' to 'RSUBD.IdRow'
//  REASON: RSUBD sucks!

RSUBD.IdRow idRow1 = null;

try
{
  idRow1 = (RSUBD.IdRow)(object)idObject1; // yeah! OMD kicks ass!
}
catch(Exception) {}

for(int i=0; i++<6;)
{
  string PROBLEM = Masturbate(idRow1, idObject1, new Random());
  Console.WriteLine(PROBLEM);
}


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

[url=https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=9021&pg=38#1236440]здравствуй дерево[/url]

Получилось? Ну и ладушки. Давайте теперь мне формальное самодостаточное определение объектного навигатора.
17 янв 05, 15:25    [1250198]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Увадаемый curious !

Ни о каком "программном продукте" речи не идет. И конкретную "Р"СУБД, например, нет никакого смысла обсуждать в данной теме.
Нет никаких "двух частей".
Нет никакого "плохого языка" (а есть один стандартный интегрированный язык баз данных).
Нет никаких "двух стрелок".
Придется Вам читать ниже известной мне строчки...
17 янв 05, 15:55    [1250357]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый vadiminfo !

1. Навигацию на уровне приложения называют в С - управлением вычислениями. Спасибо за информацию. Но какое она имеет отношение к сути вопроса ?

2. "Навигация кнопок интерфейса" может быть вообще в системе без БД. Спасибо за информацию. Но какое она имеет отношение к сути вопроса ?

3. "Навигация в модели данных" не спасает от двух систем, если нужен С++ (можно было перечислить еще с десяток языков). Спасибо за информацию. Но какое она имеет отношение к сути вопроса (ведь у "меня" все написано на одном языке) ?

4. Когда я "призывал отказываться от декларативности" ? Объектные системы не препятствуют декларативности, а в "реляционных" принципиально нет навигации. И т.д. Не устану повторять, раз это каждый раз оказывается необходимо...

5. Считать С со встроенным SQL "интегрированным" ? Это уже более-менее ясная гипотеза (типа "больших" отчетов или "отчетов сложной формы"). Но зачем мне "считать" ? Вы утверждаете, что С со встроенным SQL - это один интегрированный язык баз данных ?

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

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

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

Это же замечательно, что "нет никаких сложностей". Я же сказал, что рад за Вас ! Просто сообщил Вам, что в ДОреляционных СУБД тем более нет ни каких сложностей. И спросил у Вас: зачем же тогда нужны "реляционные" СУБД ?
Поскольку по-существу темы Вам сказать нечего, остается только по-чаще обзывать меня (теперь вот "темным сторонником МУМПСА").
Пожалуйста, ASCRUS не "трогайте". Отвечайте за себя. "Построили таки систему расчета ЗП" - молодец !
17 янв 05, 16:15    [1250464]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
curious.
Guest
Андрей Леонидович
Увадаемый curious !

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


Да вы не суетитесь так, Андрей Леонидович :) Про ниже строчки сюда смотри. И давайте уже определение объектного навигатора.
17 янв 05, 16:31    [1250582]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый ASCRUS !

Я и не собираюсь судить чего-то. Я только сравнивать стараюсь. То есть я с Вами, как раз, согласен. Вы, правда, тоже говорите, что я не понимаю реляционную технологию, и занимаюсь маркетингом (?).
От "физической реализации той или иной системы" я упорно стараюсь уйти.
И, именно, сравнивать по "общим вопросам".
17 янв 05, 16:35    [1250613]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый Павел Воронцов !

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

Да нет ничего особенного в ОМД. У Чена (специально ссылаюсь именно на хорошо известные Вам работы) не получилось ее нормально описать, так как, находясь под влиянием "реляционных идей", он не доработал с идентификацией. И туманно получилось со "слабыми" и "сильными" сущностями.
Но ведь как раз про идентификацию Вы, вроде бы, все поняли !? Я, со своей стороны, концептуально и весьма подробно все изложил про идентификаторы. Что именно Вам не понятно-то ?
17 янв 05, 16:59    [1250750]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Не волнуйтесь, уважаемый curious !

Мне совсем не сложно Вам помочь:

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

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

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

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

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

Но какое она имеет отношение к сути вопроса ?


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

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

С "ключами" мы уже насмотрелись чьи именно мысли "неожиданно" оказались наивными.


Вы бы уж лучше не вспоминали. Что Вы здесь понаговорили, понаобещали доказать? Прямо революция в инфотехнологиях (только в обратном направлении - возврат лет так на 30 назад). Поначалу было интересно посмотреть на эти доказательства, того что недоказуемо. Но все ваши простые доводы не выдерживали никакой элементарной критики. Тогда Вы стали брать измором - повторами тезисов, которые давно были опрвергнуты. Но разве это не скучно?
Стоит ли Вам тратить на это время? Ничего это не изменит. Не повернете Вы прогркесс назад, тем более какими-то жалкими повторами неубедительных тезисов на форуме. Вот задайтесь целью повернуть реки в спять повторами одних и тех же фрах. А ведь это проще, чем то, что Вы пытаетесь делать.
17 янв 05, 20:18    [1251420]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
сuriоus.
Guest
Андрей Леонидович

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

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


Да нет проблем, Андрей Леонидович, выводы выше, вопросы закрыты, садитесь, два.

Кто-нибудь еще есть с мумпсом?..
17 янв 05, 22:04    [1251535]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
с127
Guest
2 Андрей Леонидович

>остается только по-чаще обзывать меня (теперь вот "темным сторонником МУМПСА").

Должен же я как-то разнообразить свои посты, ниша тупого копирования текста из поста в пост уже занята Вами.

Вы еще работаете в Информ-икс или уже нет? Не вижу ответа.

>Просто сообщил Вам, что в ДОреляционных СУБД тем более нет ни каких сложностей. И спросил у Вас: зачем же тогда нужны "реляционные" СУБД ?

В асемблере тоже нет никаких трудностей, зачем же тогда нужен MUMPS? Та же логика: если где-то что-то можно сделать, то зачем это делать по-другому.

Если человек за 20+ лет изучения компьютерных наук не понял, почему все приложения не пишутся исключительно на асемблере (на бейсике, в машинных кодах, на С - на выбор), то объяснять ему это уже бесполезно.

>Пожалуйста, ASCRUS не "трогайте".

Так Вы уже согласны, что 14 янв 05 в 17:51 сморозили очередную чущь: "Задача" "Расчет ЗП" сложна вовсе не из-за алгоритмов, а потому что она весьма объемная"?

>Отвечайте за себя. "Построили таки систему расчета ЗП" - молодец !

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

Как это делается в РСУБД рассказал ASCRUS. А вы со своей стороны ИМХО ничего в ответ предложить не можете, кроме упрямого повторения спасительной (с Вашей точки зрения) фразы, что к теме это не имеет отношения.
18 янв 05, 01:07    [1251630]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Уважаемый Андрей Леонидович!
Андрей Леонидович
Да нет ничего особенного в ОМД. У Чена (специально ссылаюсь именно на хорошо известные Вам работы) не получилось ее нормально описать, так как, находясь под влиянием "реляционных идей", он не доработал с идентификацией. И туманно получилось со "слабыми" и "сильными" сущностями.
Но ведь как раз про идентификацию Вы, вроде бы, все поняли !? Я, со своей стороны, концептуально и весьма подробно все изложил про идентификаторы. Что именно Вам не понятно-то ?
Вы мне тогда ничего кроме своей необразованности и скудоумия не доказали. Спасибо, что напомнили об этои. Сакральная сущность ваших идентификаторов таки осталась для меня скрыта, увы. Я так и не понял чем они отличаются от суррогатных ключей кроме того, что не видны и чем это так замечательно. Только Бога ради не надо сейчас копировать свои вопросы о том "насколько часто" и "насколько totally"! Я на них уже отвечал, но Вы по своей привычке ответов не услышали. Ответы, которые Вам нужны, от меня Вы не услышите.

Так где можно посмотреть сжатое и хорошо формализованное изложение ОМД?
18 янв 05, 07:47    [1251754]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый vadiminfo !

У меня были надежды, что Вы стремитесь к самообразованию. То есть к исправлению того "фундамента" в области теории баз данных вообще, и реляционных баз данных, в частности, который заложили Ваши некомпетентные преподаватели. Но не получилось. Как только поняли, что аргументов по-существу вопросов (идентификация, интегрированный язык баз данных, навигация и т.п.) нет, сразу стали "дразниться". Вот этому Вас хорошо научили. Видимо в этой "области" Вам диплом и выдали...
18 янв 05, 17:24    [1254525]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый curious !

Да вопросы-то для таких SQLящих, как Вы (но не для профессионалов в области баз данных), уже давно закрыты...
Желаю творческих успехов в освоении "отчетов сложной формы" и "нерегламентированных запросов"...
18 янв 05, 17:28    [1254542]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый Павел Воронцов !

За "необразованность" и "скудоумие" отдельное спасибо. Неплохой аргумент...
Идентификаторы, кстати, видны, и этим, как раз, не отличаются от суррогатных ключей. Но ничего страшного. Обязательно поймете...
Копировать для Вас я не буду. Я же вижу, что Вы перечитываете мои сообщения, и стремитесь к пониманию. Это меня радует. Теперь вот Чена (1976) наверняка перечитаете...
18 янв 05, 17:32    [1254569]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемый с127 !

Что же мне остается, если не "тупо копировать", то есть напоминать о чем идет речь ?
Вы же не хотите сравнивать технологии по ясно сформулированным направлениям. Я что-то не учел ? Поправьте. Можете, заодно, еще раз идиотом назвать. Но хоть что-то конструктивное скажите. Пока только vybegallo высказал идею в пользу "Р"СУБД, но и он, думаю, уже отказался от нее...
18 янв 05, 17:40    [1254612]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

У меня были надежды, что Вы стремитесь к самообразованию.

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

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

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

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

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

Но не получилось.

И слава Богу. Вы что хотите, чтобы меня с работы выгнали за такие познания как у Вас?

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

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

Как только понял, что Вы делаете сенсационные тезисы (типа провала ключей или краха РМД) просто так (от скуки), обещаете их доказать, но доказательств у Вас нет, а вместо них Вы подбрасываете всякую наивную ерунду для начинающих, то и потерял интерес. И пожалел, что потратил время на диспуты с Вами.

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

Видимо в этой "области" Вам диплом и выдали...


Опять Вы ошиблись. Диплом у меня по информационным системам. Видно ошибки - Ваше кредо.
18 янв 05, 19:44    [1255012]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vybegallo
Guest
Андрей Леонидович
Уважаемый с127 !

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


Отказался. От идеи спорить с вами. Вы как попка затвердили "навигация хорошо, язык MUMPS мечта всякого программиста, неструктурированные запросы - буржуазная выдумка, а реляционная модель - продажная девка империализма". Любые попытки вам что-то объяснить за полтора года окончились неудачей. Для таких ситуаций у американцев есть хорошая поговорка : "Never argue with an idiot. They drag you down to their level then beat you with experience".
Была у меня идея протестировать запрос на MUMPS и на SQL, ткнуть, как говорится, носом - но потом решил - а зачем ? Вы ж все равно скажете, что производительность не главное, а главное, что программисту ничего кроме того уродства, которое вы называете языком, учить не надо... ну и конечно, что ученые мужи давно отвергли идентификаторы как лжеучение, так что не тычте мне в нос ваши гадкие результаты тестирования. Верно я предвижу ваши дальнейшие ходы ? Или вы готовы прилюдно признать (если тесты докажут), что на неструктурированных запросах SQL рвет MUMPS как тузик грелку и вы, Андрей Леонидович, публично обещаете перестать нести чушь на данном форуме ? На таких условиях я могу потратить некоторое время на изучение вашего MUMPSa.
18 янв 05, 21:59    [1255176]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович

>За "необразованность" и "скудоумие" отдельное спасибо. Неплохой аргумент...

Другое дело "Ваши некомпетентные преподаватели" в исполнении Андрея Леонидовича, вот это аргумент.

>Что же мне остается, если не "тупо копировать", то есть напоминать о чем идет речь ?

Можно еще, например, отвечать на вопросы, которые Вам задаются.

>Вы же не хотите сравнивать технологии по ясно сформулированным направлениям.

Хочу. Как только Вы приведете ссылку на формальное изложение ОМД (или сами изложите) мы сразу начнем сравнивать его с РМД.

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

Если эта задача слишком сложна и Вы не в состоянии ее решить - не беда, к счатью выход есть. В соседнем топике (https://www.sql.ru/forum/actualthread.aspx?tid=138641&pg=2) в посте [1206843] сторонниками ОМД совершенно добровольно выбрана и сформулирована очень простая задача, совсем детский сад, как они говорят. Сами они ее решение до сих пор почему-то не продемонстрировали, но это сейчас не важно. ПОЛНОЕ реляционное решение есть в следующем посте (автор - SergSuper), с ним может ознакомиться всякий желающий. Приведите полное MUMPS решение и сразу станут очевидны все преимущества ОМД вообще и MUMPS-а в частности.

Это и будет сравнение технологий.
19 янв 05, 01:21    [1255387]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
curious.
Guest
Андрей Леонидович
... для таких SQLящих...

Я сказал "SQL" ? Где я сказал "SQL" ?? Нет никакого "SQL" !
Нет никакой модели данных !! Есть УСУБД(r). Данные есть, стрелки есть, модели нет.
Как только мы с коллегами избавились от модели данных, тормоза исчезли, стрелки появились.
800.03% на любой задаче. Глобальная Система Сбора и Обработки. Тысячи суперкомпьютеров. Секретно. Не продается.

c127
ПОЛНОЕ реляционное решение есть в следующем посте (автор - SergSuper), с ним может ознакомиться всякий желающий.

Стыдитесь, юноша, разве это ПОЛНОЕ решение? Автор решения прозрачно намекнул, что либо база денормализована, либо другая задача.
Вот решение на языке У: #am **=** (1[hk](2)) 1: <s{,oo}> 2: <rt{g}>
800.03%. Не продается.

vadiminfo

Не нервничайте. Смотрите как надо:

Так гдееее формализованная материализация чувственных идей???


vybegallo
Never argue with an idiot. They drag you down to their level then beat you with experience

Если Вы будете хорошо учиться, Мы Вас возьмем на работу.


Хорошие новости. Второй день на мумпсе никто не пишет. А был ли мальчик?..
19 янв 05, 04:15    [1255484]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 36 37 38 39 40 [41] 42 43 44 45 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить