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


И, как обычно, не по моей вине.
15 дек 07, 02:02    [5052661]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ggv
Member

Откуда:
Сообщений: 1810
ЧАЛ - у вас есть что рассказать и показать?
Есть - готовтесь.
Делайте Proof of Concept.
Звиздесть - не мешки ворочать. (и не на форуме слюной брызжать)
Дерзайте.
Лично я с удовольствием посмотрю на объектный навигатор.
Да - дополнение. Результаты события опубликуем в журнале.
Присутсвие журналистов тоже возможно.
Вы только представьте - вы, весь в белом, и вещаете, вещаете. А все замерли и слушают...
15 дек 07, 11:15    [5052869]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

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

Ключи формально не определяются как ОЦ. Если ключи не выделять, они все равно будут ключами (потенциальными), но ОЦ не обеспечат. С помощью выделения ключей можно обеспечить ОЦ - целостность отношения. Навязать ФЗ. Тип ключам по барабану.
Может лучше все же узнать предмет получше прежде, чем открывать Америку насчет беды?

ответ...

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

Тоже самое в том же смысле, что и предыдущий абзац.
15 дек 07, 16:03    [5053248]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

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

Разница в том, что JOIN не ручная навигация - запросы в РМД обеспечивают ассоциативный, а не навигационный доступ. Без этого, возможно, РМД не смогла занимать таких позиций как теперь (реляционная эпоха в БД.
"Иерархические запросы" не осноное его назначение. Вообще "иерархические запросы" не выразимы в реляционнй алгебре (транзитивное замыкание), потому в SQL для них используют либо специальные "иерархические запросы" как в Оракле или рекурсивные как в Скуле.
15 дек 07, 16:14    [5053263]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

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

Никаких связей, кроме бинарных, нет и быть не может. Здесь уже многие пытались придумать хотя бы один пример (то есть шли не от теории, а от "практики"), но ничего не получилось. Еще хотел бы напомнить, что результатом "запроса" (в том числе и с использованием некого join) должна быть часть БД с той же семантикой (а не непонятное "отношение", как в случае РМД). Это же очевидно, что запрос не должен "портить" БД. Хотя форма представления (как "результата запроса", так и "исходной БД") может, конечно, быть любой, в том числе и "табличной", по желанию пользователя (а не разработчика).

В ДОМД кроме бинарных никаких, еще один ее недостатк. В ER есть связи любой арности.
В литерате по БД давно все придумали. Коннолли то у Вас есть.
Прежде чем что-то напоминать стоит подумать а не лучше ли подобные мысли вообще не высказывать. Про "часть БД" совсем уж не теоретично. Запрос должен возвращать инфу. Тот кто его пишет, например для отчетов а не "части БД" получает то, что хотел вместе с семантикой, иначе бы он не понял, что получил. Т.е. понятное ему отношение, понятный пользователям результат (последние могут вообще не знать, что такое БД). Никакие "части БД" не меняются, если запрос на чтение. Например, получить среднюю зарплату по отделу. Соеденил таблы отделов с зарплатами сотрудников и вывел среднюю: полученное отношение из двух полей: Отдел и средняя зарплата. Что непонятного в этом отношении? Что не так с семантикой? Какую "часть БД" он испортил?
15 дек 07, 16:41    [5053307]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
реляционист
Guest
vadiminfo
Например, получить среднюю зарплату по отделу. Соеденил таблы отделов с зарплатами сотрудников и вывел среднюю: полученное отношение из двух полей: Отдел и средняя зарплата.
Вопрос в том, зачем их собственно соединять, если и так всем ясно, что сотрудники и зарплаты изначально связаны совершенно определенным образом? Ответ ясен: поскольку РМ просто не имеет полноценных средств для представления и управления связями (связанностью). Как уже было многог раз сказано, это собственно не беда самой РМ, поскольку она на это вовсе и не претендует, поскольку работает со значениями, кортежами и множествами. А если надо представлять и управлять связями, то нужно исходить из другого понимания данных и использовать другую модель.

vadiminfo
Что непонятного в этом отношении? Что не так с семантикой? Какую "часть БД" он испортил?
Непонятно следующее:

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

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

- с семантикой проблем нет, по причине ее отсутствия, т.е. СУБД просто не знает как связаны и что означают хранящиеся в множествах кортежей значения.
15 дек 07, 17:10    [5053351]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
мнение
Guest
vadiminfo
Разница в том, что JOIN не ручная навигация - запросы в РМД обеспечивают ассоциативный, а не навигационный доступ.
Основное применение Join состоит в ручной навигации, чтобы достать нужные фрагменты данных из различных таблицы. Ручная она потому, что надо каждый раз указывать какие таблицы по каким полям связывать. В подавляющие большинестве случаев join применяется к полям-идентификаторам, т.е. это обычный доступ по ссылкам, но только модифицированный для применения к множествам. Также не надо трещать по поводу "ассоциативного" или какого-то "гиперболического" доступа. Есть идентификаторы, которые используются для связывания, в РМ это все сделано весьма криво. И это факт, хотя бы потому, что РМ на такие функции никогда не претендовала.

vadiminfo
"Иерархические запросы" не осноное его назначение.
А что, кто-то утверждал обратное? Говорилось, что в РМ для связывания данных есть join, который предоставляет средва для ручной (и мучительной) навигации, в т.ч. по иерархии.

vadiminfo
Вообще "иерархические запросы" не выразимы в реляционнй алгебре (транзитивное замыкание), потому в SQL для них используют либо специальные "иерархические запросы" как в Оракле или рекурсивные как в Скуле.
Ну вот, каждый начинает о чем-то своем трещать. Кто-то на Microstrategy съехал, а кто-то слово "иерархический запрос" выучил.
15 дек 07, 17:20    [5053363]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
чал
Guest
vadiminfo
В ДОМД кроме бинарных никаких, еще один ее недостатк.
Само по себе это не недостаток и не преимущество, а всего лишь вопрос определений. Можно сказать, что связей вообще нет, ну или любая вещь это связь.

vadiminfo
В ER есть связи любой арности.
Осталось только мелочь. А именно, как отличить связь от сущности. Не подскажете, любезный, является ли запись из n колонок сущностью или связью? Учитывая, что формального критерия отличия нет, то какой смысл одну и ту же штуковину иногда называть связью, а иногда вещью? Например, брачный контракт это связь или вещь? Ясно, что и то и другое. Конечно, это опять вопрос терминологии, но в этом смысле гораздо более экономным с точки зрения количества терминов и их покрытия было предположить что связь по определению бинарная. Ну вернее связь это вообще не вещь и на самом деле бинарность это не совсем правильная характеристика, поскольку связь несимметрична. Я бы сказал, что связь в отличие от сущности нематериальна и не имеет адреса, который позволяет ей манипулировать как сущностью (мы не можем передать ссылку на связь, получить свойства связи и т.п.) В этом случае брачный контракт это сущность, а вот ссылки в нем на супругов это уже связи.

vadiminfo
Про "часть БД" совсем уж не теоретично. Запрос должен возвращать инфу.
Все правильно ЧАЛ говорит, у Вас просто очень ограниченный взгляд на моделирование данных. Есть разные подходы к этой проблеме, так же как к определению связи и мн. других вопросов. Один из таких подходов как раз и состоит в том, что результатом запроса является подмножество данных вместе с их исходной структурой. Этот подход очень интуитивен и естественнен для большинства приложений, хотя конечно не единственный. Например, в РМ он абсолютно неприменим, поскольку следствием запроса всегда является потеря идентичности сущностями и потеря структуры.
15 дек 07, 17:40    [5053404]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
реляционист
Вопрос в том, зачем их собственно соединять, если и так всем ясно, что сотрудники и зарплаты изначально связаны совершенно определенным образом? Ответ ясен: поскольку РМ просто не имеет полноценных средств для представления и управления связями (связанностью).

Если кому-то ясно, т.е. это у него в голове, то не надо. А если данные в БД, то в РМД лучше все же соеденить. Благо затранты на это минимальны.
Ассоциативность соединения компенсирует с лихвой всякие представления и уравления связями.


реляционист

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

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

реляционист
Непонятно следующее:

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

Ну оно и получается практичеки на просто сказать, что хочу среднюю зарплату по отелам.
Слово Зарплата - это одно отношение, Отношение Отдел - второе слово. Джойн соеденил их в предложении.
Циклов то писать не надо.

реляционист

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

А зачем в каждом из сотен и тысяч предложений надо каждый раз соединять слова в пердложения?
Например использовать союзы И, ИЛИ и проч.
При мерно затем же и тут.

реляционист

- с семантикой проблем нет, по причине ее отсутствия, т.е. СУБД просто не знает как связаны и что означают хранящиеся в множествах кортежей значения.

Я тоже думаю, что нет проблем, потому что тот кто хотел узнать среднюю узнал таки ее.
СУБД не знает также, что означают объекты хранящиеся в коллекциях. Вопрос достижений в области искуственного интеллекта.
15 дек 07, 17:57    [5053428]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ggv
Member

Откуда:
Сообщений: 1810
чал, я правильно понял, что вы не покажете имеющуюся у вас реализацию КОМД (что бы это не значило) и объектный навигатор?
То есть вы $%здун, а не челове, отвечающий за свои слова.
$%здеть не мешки ворочать.
ваши слова ничего не стоят, как бы наукообразно вы их не подавали (между научным и наукообразным такая же разница, как между человечным и человекообразным)
ЧАЛ - вы наукообразный $%здобол?
15 дек 07, 18:03    [5053438]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мнение
Основное применение Join состоит в ручной навигации, чтобы достать нужные фрагменты данных из различных таблицы.

До сих пор под ручной навигацией понимались явное описание переходов в упорядоченных так или иначе множествах по ссылкам и указателям. Т.е. надо прописывать КАК переходить от записи к записи или от объекта к объекту. Писать циклы. Join не предполагает ничего подобного. Потому до сих пор его к ручной навигации не относили.

мнение

Ручная она потому, что надо каждый раз указывать какие таблицы по каким полям связывать. В подавляющие большинестве случаев join применяется к полям-идентификаторам, т.е. это обычный доступ по ссылкам, но только модифицированный для применения к множествам.

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

мнение

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

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

мнение
А что, кто-то утверждал обратное? Говорилось, что в РМ для связывания данных есть join, который предоставляет средва для ручной (и мучительной) навигации, в т.ч. по иерархии.

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

мнение

Ну вот, каждый начинает о чем-то своем трещать. Кто-то на Microstrategy съехал, а кто-то слово "иерархический запрос" выучил.

А некоторые о чужом трещат? Выучили чужое слово "ручная новигация", поняли по своему, и называют им что захотят.
Если бы Джойн был ручной навигацией, о навигации бы вообще никто не говорил при сравнении иеарархических МД и РМД. Ить тада они в этом одинаковы, отличий нет. А говорят и пишут в толстых книгах по БД. На экзаменах спрашуют. Двойки ставят за называние Джойна "ручной навигацией". Вот дураки. Сюда бы пришли, узнали бы как на самом деле обстоят дела.
15 дек 07, 18:58    [5053591]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
чал
Само по себе это не недостаток и не преимущество, а всего лишь вопрос определений. Можно сказать, что связей вообще нет, ну или любая вещь это связь.

Любая ОМД претендует и на концептуальное моделирование. А там связи есть сто пудово.

чал
Осталось только мелочь. А именно, как отличить связь от сущности.

Вы не обратили внимание на название МД - ER. Называется Сущность-Связь. Видите там это слово даще в названии МД есть. Там связь от сущности отличить совсем легко. Они так и называются.

чал
Не подскажете, любезный, является ли запись из n колонок сущностью или связью?

Не подскажу. Есть записи из n колонок, которые не являютя, ни сущностью, ни связями. Например, факты в сводной табле.

чал

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

Эконмичнсть количество терминов не всегда может заменить выразительность. Некоторые племена людоедов пошли по этому пути. У них в языке всего 33 слова. В Двенадцати стульев про это упоминается.

чал

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

Бинарность говорит о том, в асооциации принимает участие две сущности разного типа. Связь между сущностями одного типа назвают к примеру унарной. А трех - тернарной.
Я в тол не возьму. Вы что потеряли книгу Коннолли? Там все это разжовано.




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


Вполне возможно, что у меня взгляд ограничен на моделирование. Но не до такой степени, чтобы не понять, что ЧАЛ все не правильно говорит.
Подходы есть разные. И подход где только бинарная связь, если, конечно, этот термин употребляется в общепринятом в области БД смысле, менее выразителен, чем там где есть произвольной арности связи.
Не знаю как в следствии запроса потерялись сущености и структура. Они как были так и остались все на своем месте в БД. А запрос вернул ответ на вопрос, который требовался. Что требовалось, то и получилось.
Не вкурил что потерялось.
15 дек 07, 19:33    [5053659]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
студент.ааа
Guest
vadiminfo
чал
Осталось только мелочь. А именно, как отличить связь от сущности.

Вы не обратили внимание на название МД - ER. Называется Сущность-Связь. Видите там это слово даще в названии МД есть. Там связь от сущности отличить совсем легко. Они так и называются.
Ну так брачный контракт это связь (между супругами) или сущность (документ)?

vadiminfo
чал
Не подскажете, любезный, является ли запись из n колонок сущностью или связью?

Не подскажу. Есть записи из n колонок, которые не являютя, ни сущностью, ни связями. Например, факты в сводной табле.
А брачный контракт это факт, связь или сущность?

vadiminfo
Бинарность говорит о том, в асооциации принимает участие две сущности разного типа. Связь между сущностями одного типа назвают к примеру унарной. А трех - тернарной.
Я в тол не возьму. Вы что потеряли книгу Коннолли? Там все это разжовано.
Ну зазубрить библию можно, а вот мне понять хочется. Вот если предположить, что брачный контракт это связь, то она унарная или бинарная? Я это к тому, что вроде бы связь между одним типом (Человек), а с другой стороны, их же все-таки двое (обычно).

vadiminfo
Не знаю как в следствии запроса потерялись сущености и структура. Они как были так и остались все на своем месте в БД. А запрос вернул ответ на вопрос, который требовался. Что требовалось, то и получилось.
Не вкурил что потерялось.
Результат запроса содержит новую структуру, а старая теряется (она там и остается в базе).
15 дек 07, 20:14    [5053775]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
вечный(?) студент
Вот если предположить, что брачный контракт это связь, то она унарная или бинарная? Я это к тому, что вроде бы связь между одним типом (Человек), а с другой стороны


Я вам сочувствую. Правда сочувствую. Искренне.
15 дек 07, 20:40    [5053827]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
как же так, дорогая редакция?
Тем не менее можно рискнуть обсудить этот вопрос (вперемешку с пресловутыми глючными курами, грибами, медсестрами и др. вопросами).

Можно попробовать ))

Отказ от JOIN в явном виде и замена его оператором навигации - точкой "." можно считать очень полезным синтаксическим сахаром. Так например сделал Microsoft в своем LINQ для C#.

Вой блюстителей чистоты веры вызван не столько этим, как дальнейшими следствиями. Трактовка связи как указателя ведет к превращению реляционной модели в сетевую. Пресловутый EAV перестанет быть проблемой ))) Вот к примеру один из возможных путей развития этого дела: https://www.sql.ru/forum/actualthread.aspx?bid=36&tid=341538&hl=
15 дек 07, 21:46    [5053999]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
shuklin
Member

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

У объекта не просто может, а должно быть много разных идентификаторов. И мало того не просто для галочки должно, а это очень полезная на практике функциональность ООСУБД:
https://www.sql.ru/forum/actualthread.aspx?tid=310465
15 дек 07, 21:53    [5054020]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Бред
Это же очевидно, что запрос не должен "портить" БД.

Данный тезис не совсем верен. Запрос может "не портить" схему БД, если это требуется в данном конкретном случае. Но в общем случае, например для поддержки legacy приложений в процессе выполнения запроса может возникнуть необходимость трансформировать схему.
15 дек 07, 21:58    [5054035]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
студент.ааа
Ну так брачный контракт это связь (между супругами) или сущность (документ)?
...
А брачный контракт это факт, связь или сущность?

В конкретном проекте ответ на этот вопрос хорошо подходит для раздела проектирование БД.
Важно, что выбор проетировщика не ограничивается выразительными возможностями МД.

студент.ааа

А брачный контракт это факт, связь или сущность?

Про факты имелось в виду просто запись вообще. Мало ли разных записей бывают? На заборе тоже записи есть.


студент.ааа

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

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

студент.ааа

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

Новую структуру чего он создает? Базы данных? Запросы на чтение не могут изменить ее структуру. По крайней мере, в РМД.
15 дек 07, 23:08    [5054133]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
студент...
Guest
shuklin
Отказ от JOIN в явном виде и замена его оператором навигации - точкой "." можно считать очень полезным синтаксическим сахаром. Так например сделал Microsoft в своем LINQ для C#.
А вот инетерсно, если вместо этого
myObject.myMethod(myParameter);
написать вот это
myMethod(myObject, myParameter);
то это тоже синтаксический сахар? Получается, что переход от процедурного к ОО программированию это всего лишь синтаксические преобразования. В конце концов, очень часто компиляция ОО языка выполняется путем трансляции кода в процедурный или сразу ассемблер. Например, С++ может транслироватья в Си. А процессор вообще ничего не знает о языках программирования.

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

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

В конкретном проекте ответ на этот вопрос хорошо подходит для раздела проектирование БД.
Важно, что выбор проетировщика не ограничивается выразительными возможностями МД.

студент.ааа

А брачный контракт это факт, связь или сущность?

Про факты имелось в виду просто запись вообще. Мало ли разных записей бывают? На заборе тоже записи есть.


студент.ааа

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

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

Ваша фамилия не Горбачев случайно?

Я всего лишь хотел узнать, в чем разница между сущностью и связью? У Вас есть какие-то четкие критерии для того, чтобы можно было их отличить?
16 дек 07, 00:52    [5054341]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

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

Ваша фамилия не Горбачев случайно?

Я всего лишь хотел узнать, в чем разница между сущностью и связью? У Вас есть какие-то четкие критерии для того, чтобы можно было их отличить?

А Ваша не Чернышев случайно?

Сущность - отдельный тип объекта, Связь - это то что объединяет несколько сущностей.
В этом и разница.

В рамках ER в спроектированнной МД у меня есть критерии их отличить: они обзначаются по разному.

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

Думаете, что если может, то это каким-то образом доказывает, что связи могут быть только бинарными? Или что?

Давайте сразу доказательство. К чему тратить время на пустые препирательства?
16 дек 07, 03:03    [5054646]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
ggv
ЧАЛ - у вас есть что рассказать и показать?
Есть - готовтесь.
Делайте Proof of Concept.
Звиздесть - не мешки ворочать. (и не на форуме слюной брызжать)
Дерзайте.
Лично я с удовольствием посмотрю на объектный навигатор.
Да - дополнение. Результаты события опубликуем в журнале.
Присутсвие журналистов тоже возможно.
Вы только представьте - вы, весь в белом, и вещаете, вещаете. А все замерли и слушают...


Я всегда готов, наглый хам!
Напоминаю темы, которые вы с "коллегами" здесь успешно забрызгали слюной, чего у вас гарантированно не получиться на очных семинарах:

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

И мы будем тщательно разбирать каждую идею, учитывая каждое слово и каждую запятую, так что демагогам не удастся препятствовать продвижению к истине так эффективно, как они делают здесь. Берите темы, составляйте план и вперед.
16 дек 07, 12:40    [5054829]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ggv
Member

Откуда:
Сообщений: 1810
пардон, ЧАЛ --- это у ВАС есть концепция, это у ВАС есть что сказать о КОМД, это у ВАС есть что показать.
Я предоставляю то, что обещал, с вас же одидаю доказательств ващей концепции с демонстрацией.
Называйте дату, я думаю, ваши оппонетны к ней подготовятся.
Но что-то вы перкладываете с больной головы на здоровую.
Вместо того, чтобы демонстрировать, как ВАША концепция позволяет красиво работать избегая недостатков, присущих РМД и РДБМС, вы требуете с меня выбора темы и составления плана.
Позвольте, я не критикую вашу концепцию (КОМД) и её реализацию, и этого никто здесь не делает - никто их НЕ ВИДЕЛ и НЕ СЛЫШАЛ!
Именно по этой причине я иду вам на встречу и предоставляю трибуну.
Мне всё равно - пусть хоть shuklin демонстрирует свою концепцию и её реализацию.
Сравним по всем параметрам (и уровни изоляции не забудем).
Господа сторонники РДБМС - есть желающие оппонировть?
Или подождём, пока господин Чернышев определится со сценарием и опубликует его?
Я бы предложил тест на аналитику, господин Чернышев.
OLTP это сфера моих интересов, и я довольно хорошо представляю себе возможности до-реляционных технологий при работе в стабильной (не изменяемой) OLTP системы, их сильные и слабые стороны (ничего не имею сказать про MUMPS, но про IMS только. Интереснейшая, надо сказать, системы)
Но мне даже в випившем состоянии не придёт в голову предлагать до-реляционную технлогию (равно как и пост-реляционную) для сферы анализа данных. Хранилища и витрины, например.
Может, вы продемонстрируете нам как прекрасно реализация вашей КОМД и объектный навигатор справятся с анализом данных, ну например, в телекоме?
Данные в большом объёме предоставим, не беспокойтесь, сколько надо TB - столько и предоставим.
Госопда, ведь это революцией в индустрии попахивает....
Крупнейшие компании тратят кучу денег на построение систем по анализу своей корпоративной памяти - хранилищ данных.
А ну как КОМД это сделает гораздо эффективней???
16 дек 07, 13:28    [5054872]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
студент...
А вот инетерсно, если вместо этого
myObject.myMethod(myParameter);
написать вот это
myMethod(myObject, myParameter);
то это тоже синтаксический сахар?

Если говорить об ООП - не всегда, т.к. под точной может скрываться полиморфизм, т.е. вызов виртуального метода. Логичной эволюцией точечной нотации в "Р"БД будет введение adhoc полиморфизма. "Р" при этом весьма пострадает в концептуальном плане в сторону расширения возможностей )))

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

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

Полностью согласен. Культурные аспекты (культура разработки ОО приложений, РМ приложений и т.д.) диктуют разработчику совершенно различные паттерны. При этом воспользовавшись по сути эквивалентными в вычислительном плане средсвами, решения могут оказаться совершенно неэквивалентны.

студент...
Отсюда, если мы говорим о join, то речь конечно не о способе записи этой операции, а ее сути. А суть ее применения в РМ в том, что необходимо указывать поля, по которым происходит соединение. А это связано с тем, что в РМ нет встроенного механизма представления связей.

Скажем по другому, текущие реализации РСУБД не поощряют автоматическое использование этого механизма. Не знаю, почему natural join существует, а его эквивалента точечной нотации нет. Не отказываясь от текущей концепции РМД можно трактовать foreign key как определение связи, и трактовать точку, после поля включенного в FK как навигацию по этой связи, заменяя в оптимизаторе эту навигацию на join. Если поле одновременно участвует в нескольких связях то неоднозначность можно снять указав имя FK. А при особом желании для связи по нескольким полям можно было бы придумать дополнительный синтаксический сахар, например {field1, field2}.field3

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

Полностью согласен. Мало того, во многом догматизм обусловлен страхом возврата в эпоху императивного программирования в СУБД. Народ почемуто считает, что возврат к сетевой модели обязан отменить декларативные запросы к БД. Сетевая модель это просто другой взгляд на модель данных, SQL никто отбирать не собирается ))))
16 дек 07, 13:59    [5054911]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ggv
Госопда, ведь это революцией в индустрии попахивает....
Крупнейшие компании тратят кучу денег на построение систем по анализу своей корпоративной памяти - хранилищ данных.
А ну как КОМД это сделает гораздо эффективней???

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

Для революции, скорее всего, как минимум нужно что-то поновее.
16 дек 07, 15:03    [5055002]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 32 33 34 35 36 [37] 38 39 40 41 .. 51   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить