Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 31 32 33 34 35 [36] 37 38 39 40 .. 51   вперед  Ctrl
 Re: Закат RDBMS?  [new]
о связях
Guest
ggv
JOIN не обязательно использовать в RDBMS.
Пример -
делаем запрос из таблицы А на поиск строки с ключём а, из записи берём значение поля b и делаем запрос к табличе B на поиск строки по ключу b.
И так далее.
Ну, может и можно, только это уже будет не РМ, поскольку мы хотим работать с множествами элементов данных, части которых расбросаны по разным таблицам. Таким образом, есть два критерия: вернуть надо множество, а во-вторых, каждый элемент этого множества является составным (включает ячейки из разных таблиц). Вышеприведенная процедура тогда должна быть адаптирована. Выбираем из А значения поля b для нужных запписей (скажем, с ключем a). Далее выбираем из таблицы B те записи, который содержат в каком-то поле ранее выбранные элементы из A. Получаем таблицу записей из B. Но ведь нам не это надо, а надо множество составных элементов с полями как из A, так и из B.

ggv
Ничего не напоминает?
А ведь таким образом можно "обойти" иерархию...
Ну в целом этот способ вполне будет работать во многих случаях. Но ведь мы опять имеет ту же проблему с указанием связей между таблицами. Мы налагаем ограничения на одну таблицу и получаем какие-то элементы. Но ведь далее надо как-то указать как эти исходные элементы связаны со следующей таблицей. В запросе в явном виде написать соответствие полей из двух таблиц. Вот это явное соответствие полей, которое в БД никак не хранится и в РМ никак не поддерживается и можно считать связью. А операция join как раз тем и удобна, что позволяет эффективно связывать множества записей из разных таблиц, но только динамически во время выполнеия запроса.
14 дек 07, 14:43    [5049897]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
как же так, дорогая редакция?

Более того, все запросы содержат на 90% одну и ту же инфу, поскольку таблицы связываются одинаково, поскольку это одна предметная область.
Верно, просто тьма кода содержит
where ... Y.x_id = X.id 
при объявленной связи
FK "xyFK1" Y.x_id ref X.id
Но даже в этом, казалось бы однозначно выигрышном для критики JOIN примере, есть нюансы.
ИМХО довольно практично то, что JOIN симметричен. Как следствие, например FULL OUTER JOIN кроме "FULL OUTER " ничем ситаксически не отличается от JOIN.
Используя же несимметричную запись навигационного типа
X.xyFK1.<Ydata>
Y.xyFK1.<Xdata>
придется FULLить ручками.
14 дек 07, 14:45    [5049919]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ggv
Member

Откуда:
Сообщений: 1810
сразу видно, что автор не писал SQL запросов.
Так как в алгоритме последовательного обхода таблиц, который я изложил, в каждом отдельно взятом запросе не придётся писать явное соответствие полй из двух таблиц.

А вот то, что РМ требует возвращать каждый элемент множества обязательно составным (из ячеек разных таблиц) - я лично первый раз слышу.
РМ не ограничивает никак право на извлечение множества (возможно из одного элемента) всего лишь из одной таблицы.
14 дек 07, 14:58    [5050039]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ответ...
Guest
ModelR
как же так, дорогая редакция?

Более того, все запросы содержат на 90% одну и ту же инфу, поскольку таблицы связываются одинаково, поскольку это одна предметная область.
Верно, просто тьма кода содержит
where ... Y.x_id = X.id 
при объявленной связи
FK "xyFK1" Y.x_id ref X.id
Но даже в этом, казалось бы однозначно выигрышном для критики JOIN примере, есть нюансы.
В этом примере как раз критиковать нечего. Более того, пока применение РМ сводилось к таким простейшим случаям, все было хорошо. А вот когда простой запрос на пару страниц растягивается, то народ стал задумываться.

ModelR
ИМХО довольно практично то, что JOIN симметричен. Как следствие, например FULL OUTER JOIN кроме "FULL OUTER " ничем ситаксически не отличается от JOIN.
Синтаксически они как раз отличаются (одно слово и два слова). Ну а симметричность, это следствие как раз того, что join определяется не как связь, а как подмножества декартова произведения, что скрывает ее реальное использование для связывания, но позволяет применить математику.

С join та же "беда", что и с ключами. Формальное определение не соответствует их реальному применению. Ключи формально определяются как ОЦ, а на правктике это просто всем хорошо известное объявление типа (но сказать, что это ОЦ гораздо круче будет). На самом деле, почему бы просто вместо типа колонки написать имя целевой таблицы? Это было бы и проще и эффективнее и понятее. Ответ ясен: это уже не будет РМ.

С join то же самое. Формальное определение одно, а реальное использование в 90% состоит в самой что ни на есть примитивной навигации.

ModelR
Используя же несимметричную запись навигационного типа
X.xyFK1.<Ydata>
Y.xyFK1.<Xdata>
придется FULLить ручками.
Не вижу, чего тут надо фулить вообще и ручками в частности.

А вообще, речь не идет о том, что хорошо, а что плохо. А всего лишь как констатация факта, что в РМ связывание данных происходит в явном (или неявном) виде в самом запросе. Ключи как ОЦ ситуацию особо не меняют, хотя бы потому что в запросах никак не испльзуются. Всякие внешние навороты и приспособы к модели не относятся, а самые навороченные из них собственно меняют модель данных.
14 дек 07, 15:25    [5050253]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
гы-гы-ва
Guest
ggv
сразу видно, что автор не писал SQL запросов.
Так как в алгоритме последовательного обхода таблиц, который я изложил, в каждом отдельно взятом запросе не придётся писать явное соответствие полй из двух таблиц.
Очевидно, придется. Откуда СУБД узнает, как ей соединять таблицы, если не из запроса? То, что эту инфу можно представить в запросе разными способами никак суть дела не меняет. Я так понял, что Вы имеете в виду вложенные select, но не уверен, да и не хотел разбираться, посколкьу, как уже говорил, конкретные синтаксические ухищрения (типа natural join) не меняют суть дела.

ggv
А вот то, что РМ требует возвращать каждый элемент множества обязательно составным (из ячеек разных таблиц) - я лично первый раз слышу.
РМ не ограничивает никак право на извлечение множества (возможно из одного элемента) всего лишь из одной таблицы.
Это вообще откуда-то из другого форума. Никто вроде бы такого не утверждал. А говорилось, что цель состоит не в том, чтобы из начальной таблицы перейти к целевой, а в том, что собрать новой множество кортежей из фрагметнов, хранящихся в разных татблицах.
14 дек 07, 17:00    [5051121]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ModelR
Member

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

Только, ИМХО, воюя с этими 90% джойнов, что суть реализуют фиксированные связи, мы тратим силы на замену простого решения простой проблемы еще более простым. Зачем?
Ведь 90% проблем - как раз в оставшихся 10% сложных запросов - туда и нужно копать.
А здесь непаханного еще.... Например, лишь в 2005 версии MS SQL обрел рекурсивные запросы,
Из ограничений целостности масштаба базы невозможно по-простому реализовать даже "у начальника не более 7 подчиненных", и проч. и проч.
14 дек 07, 17:06    [5051166]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ggv
Member

Откуда:
Сообщений: 1810
чал, вы не читатель, вы писатель.
читать вы не умеете.
ещё раз, медленно - не придётся.
первым запросов получаем множество из одной строки, берём нужное нам значение и подставляем его в условие выбора (предложение where) второго запроса.
Выполняем второй запрос безо всяких JOIN, но с условием выбора.
Из полученного множества (опять же, возможно одноэлементного) берём нужное значение и подставляем в условие выбора уже третьего запроса.
Выполняем третьий запрос. Это мы уже на третьем уровне иерархии.
Если какой-то запрос (например, второй) возвращает более чем одну строку - пишем цикл, в котором выполняем третьий запрос каждый раз с новым значением, значения берём из ресультатов второго запроса.
Так мы можем без единого JOIN выполнить обход иерархии любого уровня вложенности.
Это то, что есть в иерархических базах.
Но RDBMS предлагает JOIN (его перепишет оптимизатор и на выходе будет иерархический план доступа)
Ирерахические базы не предлагают JOIN, а предлагают программисту писать иерархический план доступа.
14 дек 07, 17:44    [5051442]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
хитрый чал
Guest
ggv
чал, вы не читатель, вы писатель.
читать вы не умеете.
Но я старался.

ggv
ещё раз, медленно - не придётся.
Да, пожалуй, надо еще раз. Не сочтите за труд.

ggv
первым запросов получаем множество из одной строки, берём нужное нам значение и подставляем его в условие выбора (предложение where) второго запроса.
Выполняем второй запрос безо всяких JOIN, но с условием выбора.
Из полученного множества (опять же, возможно одноэлементного) берём нужное значение и подставляем в условие выбора уже третьего запроса.
Выполняем третьий запрос. Это мы уже на третьем уровне иерархии.
Если какой-то запрос (например, второй) возвращает более чем одну строку - пишем цикл, в котором выполняем третьий запрос каждый раз с новым значением, значения берём из ресультатов второго запроса.
Ну что-то вроде этого я себе и представлял. Ну вернее, если совсем честно, то я лучше думал, но это уже мелочи.

ggv
Так мы можем без единого JOIN выполнить обход иерархии любого уровня вложенности.
Ну можем, причем слово "иерархии" можно убрать и заменить на граф. А что, где-то утверждалось, что нельзя?

ggv
Это то, что есть в иерархических базах.
Ух, а при чем тут иерархические БД? Разве их кто-то упоминал?

ggv
Но RDBMS предлагает JOIN
Для навигации по иерарической базе данных? Или я опять чего-то не понял?

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

Ну даже если так, Вам (случайно или нет) удалось затронуть один инетерсный момент. Ручная навигация по иерархии это значит плохо, а ручная с помощью join навигация по графу таблиц это значит хорошо. Неувязочка, однако. Какая разница, если надо найти записи на 10-ом уровне в иерархии или связать 10 таблиц с помощью join? По длине кода пожалуй второй случай длиннее будет, а по логической сложности (по семантике, да простят меня за это слово) иерархический запрос намного проще. Но это я вовсе не в защиту иерархической модели, а как раз в плане того, что запросы для РМ могут посложнее быть как по форме так и по содержанию.
14 дек 07, 18:16    [5051645]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
гы-гы-ва
ggv
сразу видно, что автор не писал SQL запросов.
Так как в алгоритме последовательного обхода таблиц, который я изложил, в каждом отдельно взятом запросе не придётся писать явное соответствие полй из двух таблиц.
Очевидно, придется. Откуда СУБД узнает, как ей соединять таблицы, если не из запроса?


А почему этим должна заниматься именно с СУБД? В Microstrategy например я в репозитории объявляю что Employees.department_id -> Departments.department_id; В принципе Microstrategy может и сам догадаться если есть foreign keys или имена одинаковыею. А я могу с его догадкой просто согласиться.

Дальше Microstrategy генерит мне код для отчетов, join делает сам исходя из того что заложено в репозитории. Моя боевая задача - кликать мышом на Excel-образный интерфейс.

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

Аналогия простая:
Можно
1. воспользоваться чем-то типа Дельфей или Билдера для ваяния "морды". Сгенерированный код компилить и не заморачиваться.
2. А можно написать все напрямую через Win32 API да еще на 40-60% на ассемблере.

Система (1) будет гораздо более жизнеспособна чем (2) ввиду того что ее гораздо дешевле и проще разрабатывать и поддерживать.

Каша - это такой аналог макроассемблера в мире баз данных. Предлагаемый коллегой ЧАЛом подход - написание монолитного кода на ассемблере (как в начале 70х на мэйнфреймах). Реляционный подход - генерить код на языке высокого уровня, который потом компилировать. Какой подход перспективнее - решайте сами.
14 дек 07, 20:59    [5052070]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ggv
Member

Откуда:
Сообщений: 1810
Предлагаю перевести диспут на другой уровень.
Господа, предлагаю -
1) С меня:
а) аудитория
b) железо на выбор - intel, system p, system z
c) проектор
d) разработчики IMS (не только теоретики, но и практики) - ну чтобы разбавить реляционную братву
Всё это в Москве
2) с вас:
PoC - Proof of Concept. У вас есть концепт - Proof его.
Опубликуйте здесь документ с основными положениями и сценарием показа (постановка задачи, критерии успеха, и вариант решения задачи удовлетворяющий критерием).
3) Желающим сторонникам РДБМС
Изучите концепт ЧАЛа.
Приготовтесь оппонировать Уясните поставленную задачу. Оцените критерии (подозреваю здесь подводные камни) и предложите альтернативное решение поставленной ЧАЛом задачи
4) Все вместе -
Милости просим на послушать/посмотреть вариант решение ЧАЛа, и на альтернативные варианты

Ну что, господин ЧАЛ, всё по взрослому. Вам - трибуна. Показывайте и рассказывайте.
У вас же есть концепция, есть объектный навигатор, что там было ещё?

Господа реляционщики - берётесь сформировать команду оппонентов?
Господин ЧАЛ, можете привлекать кого угодно. Хотите - сведу с разработчиками IMS, они вполне могут встать на вашу сторону, им тоже "за державу обидно", теоретически подкованы, практически тоже по самое немогу.
Я думаю, что при должном уровне организации всем будет познавательно и полезно.
14 дек 07, 21:30    [5052123]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
ggv

Господа реляционщики - берётесь сформировать команду оппонентов?


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

Предлагаю вот что:

В реляционном углу ринга - IBM P-series (AIX) с 10м ораклом и Microstrategy или Business Objects (в зависимости от того чем владеют участники из Москвы).
В другом углу ринга - Cache с Объектным навигатором от коллеги ЧАЛа.

Схему не мудрствуя лукаво предлагаю украсть из TPC-H и слегка модифицировать. Требуется:

1. Наваять отчеты
2. Слегка поменять постановку задачи, соответственно модифицировать БД и отчеты.

Одним из критериев успеха предлагаю считать трудоемкость (1) и особенно (2) в человеко-часах.

С IMS, Cobol и CICS вам я думаю ответ итак очевиден?
14 дек 07, 22:03    [5052162]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Невозможно читать этот бред про указатели. В этом топике я уже пытался затеять конструктивную беседу с ЧАЛом, что не увенчалось успехом (как обычно).

иван лачугин
ggv
Указатель никак не помогает в идентификации объекта.
Зачем ему помогать, если он и есть самый что ни на есть идентификатор?

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


Этот механизм не имеет к идентификатору и идентификации никакого отношения. Это другой механизм, необходимый для обеспечения доступа к объекту. И это уже не идентификация.

ggv
Более того, у одного объекта может быть больше чем один указатель.
А это уже совсем бардак какой-то!
Как же их различать тогда, эти объекты? Ну ведь не по указателям ведь?
Для тех, кто в танке: объект представляется своим идентификатором. Если они равны, то это один объект. У объекта может быть много разных идентификаторов. Если может быть только один, то такой механизм идентификации неполноценен.


Нет, и ещё раз нет. Не может у объекта быть много идентификаторов! Идентификатор - уникальное имя. Идентификатор должен идентифицировать, всегда и только всегда, только один объект и объект должен идентифицироваться только одним идентификатором. В противном случае ничего Вы им идентифицировать не сможете.

ggv
Ясно, что по аттрибутам лучше всего, полный набор уникальных аттрибутов однозначно определяет объект. Но ведь аттрибуты не есть внешние сущности по отношению к объекту.
Глупость. Идентифицировать объект по атрибутам попросту невозможно.


Можно. Но сложно. Для этого нужно каким-то образом получить доступ к объекту (перебрать их все, например). При наличии же идентификатора доступа к объекту не требуется. Мы можем идентифицировать объект просто сравнив идентификаторы.

Идентификатор по определению внешняя вещь по отношению к объекту. (Уже сколько раз здесь твердили, даже Глюк наверное понял.)

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

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


Если Вы посмотрите выше по топику, то этот же вопрос я задавал ЧАЛу. И ответа на него не получил. Отвечаю.
Например посредством ссылки по адресу. Но это уже не идентификация! Это знание того, где в данный момент находится объект. Это доступ к объекту.
И кстати, доступа к объекту в данный момент может и не быть.

А по указателю объект находится легко, причем указатель никаких свойств объекта не содержит.
Ах, как бы я хотел, чтобы это действительно было так. Столько бы проблем сразу решилось... Разместил объект в памяти один раз, и сохранил бы на него указатель. Потом перенёс объект на другую машину, а указатель всё равно на него указывает. Вот это был бы кайф...

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

Как посредством указателя или ссылки Вы сможете это сделать, позвольте Вас спросить?

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


Извините, но "запоминается" и "отделяется", несколько разные вещи.

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

Ну и чем же доступ по указателю, указывающему на адрес ячейки памяти посредством некой отдельно стоящей подсистемы адресации, отличается от SELECT VALUE FROM MEMORY WHERE POINTER = '0xFFFFFFFF' ?

А разница в том, что собственно объект, и доступ к этому объекту нас, и как этот доступ будет осуществлён - нам всё это не интересно. Нам нужны конкрентный свойства этого объекта. Как они будут получены и с помощью чего - неважно. Мы выше этого.
14 дек 07, 22:15    [5052186]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ggv
Member

Откуда:
Сообщений: 1810
Зл0й - по отношению к IMS, COBOL, CICS у меня свой взгяд на вещи.
Немного отличный от общепринятого (ну там про "умерли").
CICS, строго говоря, к базам данных не относится.
Это сервер приложений (типа WebSphere Application Server) но очень узко специализированный. Заточенный под транзакции только.
Определение моё, предназначено в основном для людей, спрашивающих "что такое CICS?" и может вызвать бурю возмущений от адептов.

CICS - putting S in your SOA.
CICS и теперь живее всех живых!

А по отношению к COBOL...
Я С-шник. only.
К сожалению.
14 дек 07, 22:27    [5052217]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
Yo.!
бред
тупой и трусливый недоучка "наблюдатель и"
упертого (или просто больного ?) с127
ggv - трусливый, да еще тупой, недоучка
У vadiminfo осеннее обосрение


вспомнилась народная мудрость: Если вас окружают одни дураки, то вы центральный


Во! Еще у одного осеннее обострение.
15 дек 07, 00:56    [5052552]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
vadiminfo
Бред

Я, честно говоря, действительно встречал людей, которые пытались реализовать КОМД в Oracle.

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

Бред

Это vadiminfo что-то хотел Павлу Воронцову объяснить, из того что сам не понял. Забавно. Детский лепет всегда забавен.

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


Они еще как знали. Это знают все образованные люди.
Ну а дальше привычная чушь в связи с осенним обострением.
15 дек 07, 00:57    [5052554]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
наблюдатель и
Бред
Тупой и трусливый недоучка "наблюдатель и" в связи с осенним обострением упоенно заговорил про любимые какашки. А сначала-то как прикидывался нормальным, интересующимся студентом.
А потом выяснилось кто это такой на самом деле. Не смог разобраться даже в довольно простых статьях Кодда. И свихнулся.

ага
как только посмеял усомнитья
что не все члова бриллиаты
и задал пару вопросов
по-Вашему я недоучка :)
я горд этим

когда Вас просят что либо описать - Вы говорите "Не смешите"!
Вы имеете в виде "Не смешите людей задавая мне такие вопросы все равно я не отвечу и все про это знают"?
да правда смешно


Чушь, связанная с осенним обострением. Я говорю "не смешите", потому что все подробно объяснялось не один раз.
15 дек 07, 00:59    [5052555]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
Зл0й
Бред

Извините, но Вы говорите откровенную неправду. По каждому пункту.

Ну так докажите конкретно и предметно, где неправда и почему. Какие проблемы-то?

Бред

Это Ваше "право", но это Вас не красит. Все очень подробно рассмотрели. Всесторонне.

Формальные определения (как у Дэйта, Кодда и Бахмана) - в студию.

Бред

Кодд, Дейт, Стоунбрейкер и Хеллерштейн весьма поверхностно и не целостно рассматривали теорию баз данных. А Вы слепо "следуете" за ними.

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

Бред

Следуйте на здоровье, но зачем неправду говорить? Лучше и не начинайте про "непротиворечивость данных".

Вы беретесь опровергнуть что в нормальизованной реляционной БД не будет "противоречивости" в смысле наличия "фантомов"? У того же Дэйта это доказывается математически. Есть желание опровергнуть это доказательство? Опровержение - в студию.

Бред

Результат будет такой же, как и с "ключами", "кортежами" и т.д. Будете опять голословно прикидываться, что ничего не поняли, и что "все в порядке с ключами".

Чтобы я "понял" окончательно и бесповоротно, вы мне дайте определение как у Кодда с Дэйтом. Формальное. Хотите - алгебраическое, хотите - в рамках аппарата формальной логики, привлекайте хоть аппарат дифференциальной геометрии если это вам поможет.

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


Бред

P.S. Тем более Вас не красит требование ссылок на "авторитетный учебник" (vadiminfo тоже много раз повторял, что вот был бы я автором "толстого учебника" может тогда со мной и говорили бы по существу, а не шизофреником называли). Я ведь не просто свои мысли высказывал. Моя цель - объективный научный анализ, а вовсе не собственные мысли. Я ясно указал на противоречия и нестыковки у Кодда и Дейта, и объяснил их коренные причины.

Ссылочку можно, где вы "ясно" указали на "противоречия" и нестыковки? Давайте конкретно, ато спор получается беспредметный.


Это Вы принципиально превращаете любой спор в беспредметный, оказываясь обсуждать вопросы по существу и умышленно игнорируя все мои подробные объяснения. А потом вдруг начинаете требовать ссылки. Я все подробно объяснял с подробнейшими цитатами работ Кодда и Дейта. И не один раз.
15 дек 07, 01:02    [5052558]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
Зл0й
Бред

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


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

Так что или вы даете формальные определения понятий которыми вы оперируете, или я прекращаю эту дискуссию ввиду ее очевидной бесперспективности.


Вот видите, опять принципиально проигнорировали. РМД вынуждает, а Вы говорите "никто не запрещает". Несостоятельность Ваша и многих (но не всех) других моих оппонентов уже давно очевидна.
15 дек 07, 01:05    [5052561]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
Павел Воронцов
Бред
Павел Воронцов
Бред
КОМД по всем статьям превосходит РМД.
....
И упорное нежеление обсуждать вопросы по существу.
Описание КОМД в студию! Чтобы по существу.
Не смешите.
Мне Глюка вполне достаточно.
Помилуйте, Андрей Леонидович! За всю долгую историю нашего с Вами общения Вы так и не удосужились четко и ясно изложить свою точку зрения...
Хорошо-хорошо, я скажу по другому! Я, к сожалению, по причине ли врожденной тупости или злоприобретенного слабоумия так и не смог осилить столь блестяще описанную здесь звездоподобным Андреем Леонидовичем. Мне, убогому, не остаётся ничего другого, как взывать и трепетать. О, богоподобный, снизойдите до недостойного и пустоголового недоучки, поднимите свой палец и опишите ещё раз свою непревзойдённую КОМД (кстати, а что это значит? То есть меня в основном интересует буква К).


Четко и ясно излагал свою точку зрения по каждому вопросу, которые мы обсуждали.
Зачем Вы себя называете пустоголовым недоучкой - не знаю.
15 дек 07, 01:09    [5052565]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
Gluk (Kazan)
Павел Воронцов
Бред
Павел Воронцов
Бред
КОМД по всем статьям превосходит РМД.
....
И упорное нежеление обсуждать вопросы по существу.
Описание КОМД в студию! Чтобы по существу.
Не смешите.
Мне Глюка вполне достаточно.
Помилуйте, Андрей Леонидович! За всю долгую историю нашего с Вами общения Вы так и не удосужились четко и ясно изложить свою точку зрения...


Забавно, что Коллега ЧАЛ (в дальнейшем КЧАЛ ) очень живо комментирует мой интерес к грибам и курам, совершенно игнорируя при этом сугубо технические вопросы :)
Так как вы будете в вашей до сих пор неуточненной КОМД реализовывать JOIN не равенству, а скажем по '<' ???
И как вы будете реализовывать n-арные связи ???

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


Молодец! На боевом посту. Я десять раз все это объяснял. А теперь, якобы, "эти вопросы интересуют".
15 дек 07, 01:13    [5052570]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
Gluk (Kazan)
Бред
Так что "слабать" КОМД в MUMPS намного (мягко говоря) проще, чем в "Р"СУБД (если в "Р"СУБД это вообще возможно).


Тоже интересный технический вопрос :) Не соблаговолите ли Вы изложить свое видение причин, по которым "слабать" КОМД на MUMPS проще чем на Oracle ??? Suxx-стори о том, что у кого-то вышло, а у кого-то не вышло как то не канают за доказательства

Всен еще жду определение (или ссылку на определение КОМД)


Супер! "Видение причин". Экстра-класс демагога.
Все причины подробнейшим образом изложены и объяснены. И опять "не соблаговолите ли".
15 дек 07, 01:15    [5052574]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
как же так, дорогая редакция?
Gluk (Kazan)
Так как вы будете ... реализовывать JOIN не равенству, а скажем по '<' ???
А зачем вообще нужно реализовывать join, ведь насколько я понимаю, задача как раз и состоит в том, чтобы не иметь эту операцию? Это все равно, что спросить у разработчика какого-то ОО- или процедурного языка: "А как там будет реализован доступ по произвольному адресу в памяти?". Ответ здесь очевиден, что смысл всего подхода как раз в том и состоит, чтобы не иметь такой операции. Но для любителей клубнички можно такие операции оставить. Например, как в С++ можно получать и использовать адреса, так и в большинстве моделей данных можно так или иначе реализовать некое подобие join.

Вообще, вопросы типа "зачем нужен join" или "что дает использование отношений" задавать не принято, поскольку они затрагивают самые устои. Соответственно, ответы чаще всего сводятся к следующим шаблонам:
- Не трожь святое (Да как же ты мог и т.п.)
- Ссылки на библию (Это уже давно все описано, Читай там-то, Иди в библиотеку и т.п.)
- Ну и кто ты после этого? (А за козла ответилшь и т.п.)

Тем не менее можно рискнуть обсудить этот вопрос (вперемешку с пресловутыми глючными курами, грибами, медсестрами и др. вопросами).

Если все сильно упростить, то данные хранятся в ячейках разных таблиц в разрозненном, т.е. несвязанном виде, и модель ничего в общем не знает и том, что это за единое целое, которое эти данные представляют. Например, таблицы А и Б содержать целочисленные поля. Разработчик знает, что поля ф из А и х из Б призваны связывать эти таблицы. Но модель ничего такого не знает. Чтобы все-таки получить данные в связанном виде, т.е. в виде единых сущностей, предлагается использовать join. Таким образом, это средство реализации связей между фрагментами данных.

Конечно, можно возразить, что есть разные ОЦ, которые позволяют кое-что сделать. Но тем не менее факт остается фактом: join это основа и без этой операции связать нужные данные в нечно осмысленное невозможно. В частности, именно поэтому мы говорим, что БД не обладает достаточной информацией, а модель не обладает семантикой, т.е. для нее это просто значения, раскиданные по таблицам (с ОЦ, которые никак не помогают получить нужные данные).

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

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

Это я все к тому, что возможность реализовать join вовсе не является критерием оценки модели данных. Более того, необходимость join можно рассматриваться как минус в оценке модели. Конечно, можно привести кучу примеров в стиле "Ага, а вот ты без join сделаешь это". Но чаще всего это либо РМ-ориентированные паттерны либо пазлы на развитие смекалки. Здесь опять можно привести пример из программирования. Ведь не является недостатом в С#, что там нельзя получить адрес объекта. Таких нельзя по сравнению с С++ наберется великое множество, и тем не менее хуже подход не считается.

Gluk (Kazan)
И как вы будете реализовывать n-арные связи ???
Тут я вижу два варианта ответов:

1. (Посложнее) n-арных связей нет, т.е. связь определяется как хранение (одного) адреса. Связь это вещь нематериальная, а потому у связи (в таком определении) не может быть адреса. Адрес есть только у материальных вещей, т.е. у сущностей.

2. (Попроще) Точно так же как и в РМ и в других моделях, т.е. с помощью отдельного типа сущностей, который ссылаются на связываемые сущности.


Никаких связей, кроме бинарных, нет и быть не может. Здесь уже многие пытались придумать хотя бы один пример (то есть шли не от теории, а от "практики"), но ничего не получилось. Еще хотел бы напомнить, что результатом "запроса" (в том числе и с использованием некого join) должна быть часть БД с той же семантикой (а не непонятное "отношение", как в случае РМД). Это же очевидно, что запрос не должен "портить" БД. Хотя форма представления (как "результата запроса", так и "исходной БД") может, конечно, быть любой, в том числе и "табличной", по желанию пользователя (а не разработчика).
15 дек 07, 01:27    [5052596]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
ggv
может, отправить КЧАЛ (клонов чала) сюда?
явно оне чего-то упустили....
базовое...
может, по незнанию языка.
так там в переводе.


Это Вы упустили, даже в переводе.
Я обращал внимание на слабые места в этой статье Дейта. А Вы упустили.
15 дек 07, 01:45    [5052622]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
ggv
чал, вы не читатель, вы писатель.
читать вы не умеете.
ещё раз, медленно - не придётся.
первым запросов получаем множество из одной строки, берём нужное нам значение и подставляем его в условие выбора (предложение where) второго запроса.
Выполняем второй запрос безо всяких JOIN, но с условием выбора.
Из полученного множества (опять же, возможно одноэлементного) берём нужное значение и подставляем в условие выбора уже третьего запроса.
Выполняем третьий запрос. Это мы уже на третьем уровне иерархии.
Если какой-то запрос (например, второй) возвращает более чем одну строку - пишем цикл, в котором выполняем третьий запрос каждый раз с новым значением, значения берём из ресультатов второго запроса.
Так мы можем без единого JOIN выполнить обход иерархии любого уровня вложенности.
Это то, что есть в иерархических базах.
Но RDBMS предлагает JOIN (его перепишет оптимизатор и на выходе будет иерархический план доступа)
Ирерахические базы не предлагают JOIN, а предлагают программисту писать иерархический план доступа.


А чал - это кто?
15 дек 07, 01:51    [5052641]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
ggv
Предлагаю перевести диспут на другой уровень.
Господа, предлагаю -
1) С меня:
а) аудитория
b) железо на выбор - intel, system p, system z
c) проектор
d) разработчики IMS (не только теоретики, но и практики) - ну чтобы разбавить реляционную братву
Всё это в Москве
2) с вас:
PoC - Proof of Concept. У вас есть концепт - Proof его.
Опубликуйте здесь документ с основными положениями и сценарием показа (постановка задачи, критерии успеха, и вариант решения задачи удовлетворяющий критерием).
3) Желающим сторонникам РДБМС
Изучите концепт ЧАЛа.
Приготовтесь оппонировать Уясните поставленную задачу. Оцените критерии (подозреваю здесь подводные камни) и предложите альтернативное решение поставленной ЧАЛом задачи
4) Все вместе -
Милости просим на послушать/посмотреть вариант решение ЧАЛа, и на альтернативные варианты

Ну что, господин ЧАЛ, всё по взрослому. Вам - трибуна. Показывайте и рассказывайте.
У вас же есть концепция, есть объектный навигатор, что там было ещё?

Господа реляционщики - берётесь сформировать команду оппонентов?
Господин ЧАЛ, можете привлекать кого угодно. Хотите - сведу с разработчиками IMS, они вполне могут встать на вашу сторону, им тоже "за державу обидно", теоретически подкованы, практически тоже по самое немогу.
Я думаю, что при должном уровне организации всем будет познавательно и полезно.


Всегда готов. Мне никого привлекать не нужно. Я никого, кроме себя, не представляю. А оппонентов может быть сколько угодно. Пока не понял что такое "постановка задачи", "критерии успеха", "вариант решения задачи" применительно к теории баз данных, РМД, КОМД, ключам, кортежам, идентификации, навигации, семантике и т.п. Задача: разработать модель данных? Или что?
15 дек 07, 02:00    [5052657]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 31 32 33 34 35 [36] 37 38 39 40 .. 51   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить