Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 21 22 23 24 25 [26] 27 28 29 30 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
osse
Member

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

6. Для реализации такой, наконец-то формализованной, РМД достаточно выполнить одно ограничение:

отношение не может содержать ОДИН внешний ключ

Количество внешних ключей в отношении может быть либо 0 (простой объект), либо > 1 (составной объект).


А, в таком случае, как быть, например, с
-------------
Теплота(#Теплота,....) ,
Цвет(#Цвет,Название,#Теплота),
Изделие(#Изделие,Название,#Цвет)
-------------
Три отношения, у отношений Цвет и Изделие по одному внешнему ключу. А в чем здесь недостаток или противоречие, требующее вместо внешних ключей вводить отношения Цвет_Изделия и Теплота_Цвета? (Разумеется, если ввести дополнительное условие, например, цвет у изделия может меняться, и мы должны, например, иметь возможность знать, какой цвет был у изделия на определенную дату, то такое отношение Цвет_Изделия с соответствующими атрибутами необходимо).
31 авг 04, 03:45    [919906]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Вопрос об уникальности кортежей в мире "чито" реляционых СУБД время от времени поднимается. Вопрос дурно пахнущий, зато легко решаемый. Заводить суррогатный ключ или обходиться естественным? Ответ зависит от резутьтатов полученных при анализе задачи, на начальном этапе проектирования. Например номер паспорта клиента не подходит на роль естественного первичного ключа, ибо паспорта теряются и заменяются. А номер социального страхования/ИНН для физ. лиц вполне канает. И вся любоффф-моркофф.

А вот слабо сранить кашу с IMS? В чем ея радикальное преимущество над мэйнфреймовыми иерархическими СУБД 70х годов прошлого века? Объектной ориентированностью прошу не пенять, ибо её при желании можно приклячить к любой СУБД. Данные в деревьях я могу и в Oracle хранить, и даже в Ingres, а в мэйнфреймовых "наборах данных" по аглицки именуемых datasets (ISAM, VSAM) и подавно . А как в каше насчет чего-то нового, чего в реляционных и иерархических СУБД нет? Где ейное преимущество над предшественниками? Где ихий, атамый killer app? Гже что-то что каща может, а остальные нет? Где оно, где? Преимущество где?
31 авг 04, 09:09    [920100]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

Структура, ограничения целостности, манипулирование данными - это все есть в РМД. Зачем же мне это повторять ? Я же говорю о том, что Вы и Ваши преподаватели неправильно понимаете роль ключей и кортежей в РМД. Потому что РМД плохо формализована. Что именно у меня слишком неформально, и слишком не строго ? По существу. Я вот ждал от Вас вопроса: а что предствляет собой первичный ключ в отношении, которое представляет составной объект ? Конечно, он должен состоять из внешних ключей ! (Хотя Дейт считает, подразумевая, что такое отношение представляет СВЯЗЬ между сущностями, что возможен и суррогатный ключ). Использование суррогатного ключа приводит к той же самой "перегрузке" ключей и нарушает формализацию. Но и это еще не все.
Рассмотрим "традиционный" пример с товарной накладной, упростив его максимально. Полностью исключим из рассмотрения первое отношение Накладная(Накладная#,...), а так же партии, склады, материально ответственных лиц, планы отгрузки,...
Отношение Отгрузка(Накладная#,Товар#,Цена,Количество) представляет составной объект, и его первичный ключ состоит из внешних ключей. Но как быть, если один и тот же товар по одной накладной нужно отгрузить по разным ценам ? Можно было бы:

1) создать отношение Цена(Цена#);
2) расширить первичный ключ в отношении Отгрузка(Накладная#,Товар#,Цена#,Количество).

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

Поэтому решение должно быть таким:

1) создаем отношение Продажа(Номер продажи#,Цена,Количество);
2) и отношение Отгрузка принимает вид Отгрузка(Накладная#,Товар#,Номер продажи#).

Итак, для реализации формализованной РМД (основанной на гипотезе "мир состоит только из объектов") нужно поддерживать еще одно ограничение:

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

Так Вы продолжаете настаивать, что ключи нужны для ограничений целостности ? И внешний ключ DEPT# в отношении EMP не предствляет связь "Работает в" между Служащим и Отделом ?
1 сен 04, 08:53    [923675]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

Зачем нужно, чтобы Николай не повторялся ? Ведь кортежи итак уникальны.
Те, кто придумали ключи, как раз понимали, что что-то не так. Но алгебра для них оказалась дороже.
1 сен 04, 08:55    [923682]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
SergSuper !

Так зачем у меня есть табельный номер ???

(Хотя у меня-то, как раз, есть ИДЕНТИФИКАТОР, и Вы об этом прекрасно догадываетесь).
1 сен 04, 08:58    [923688]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
osse !

Недостаток в неопределенности роли кортежей и ключей в РМД. В плохой формализации РМД. Мы об ЭТОМ говорили. Вы почитайте внимательнее всю дискуссию...
1 сен 04, 09:00    [923697]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Андрей Леонидович
>Структура, ограничения целостности, манипулирование данными - это все есть в РМД. Зачем же мне это повторять ?

Потому что это главное, что должно быть формализовано в любой модели данных. И это формализовано в РМД лучше, чем где либо еще.

>Я же говорю о том, что Вы и Ваши преподаватели неправильно понимаете роль ключей и кортежей в РМД. Потому что РМД плохо формализована.
Если Вы верите, что можно ставить между любыми предложениями слово Потому, то мой ответ Вам в Вашем духе:
Я же говорю о том, что Вы не понимаете в РМД ничего. Потому что РМД хорошо формализована.

>Что именно у меня слишком неформально, и слишком не строго ?
Все. Посмотрите математику - может узнаете, что такое формализация.

>По существу. Я вот ждал от Вас вопроса: а что предствляет собой первичный ключ в отношении, которое представляет составной объект ? Конечно, он должен состоять из внешних ключей ! (Хотя Дейт считает, подразумевая, что такое отношение представляет СВЯЗЬ между сущностями, что возможен и суррогатный ключ). Использование суррогатного ключа приводит к той же самой "перегрузке" ключей и нарушает формализацию. Но и это еще не все.

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

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

>Так Вы продолжаете настаивать, что ключи нужны для ограничений целостности ? И внешний ключ DEPT# в отношении EMP не предствляет связь "Работает в" между Служащим и Отделом ?

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


>Зачем нужно, чтобы Николай не повторялся ? Ведь кортежи итак уникальны.
Те, кто придумали ключи, как раз понимали, что что-то не так. Но алгебра для них оказалась дороже
.
Ну, вот нужно мне чтобы он не повторялся - такое задание дал заказчик. А в Вашем примере кортежи, то уникальны, а Николай повторяется. Я не педагог, и не знаю как еще можно Вам объяснять такие элементарные вещи. Ну, попробуйте заменить Имя на Табельный номер, а Фамилия на Текущая зарплата. Если бухгалтер вместо того, чтобы исправить зарплату наберет еще раз уже имеющийся табельный номер с новой зарплатой (уникальный кортеж), то хорошо ли будет? Вам хорошо, мне нет. Там останется старая зарплата и появится новая у одного сотрудника. Потом кто-то посчитает общую сумму просто сложив зарплату всех сотрудников. Получит большую сумму (вместе со многими старыми зарплатами). Ну можно послать этого человека к Вам послушать о том, зачем ему правильная сумма зарплат? Ведь кортежи итак уникальны. Возможно, это утешит в чем-то директора, когда он заплатит больше налогов. Но не меня. С тем же успехом Вы могли бы спросить: "Зачем Вам нравятся девушки с красивыми ногами? Ведь кортежи итак униукальны."
Я уже не говорю, про то, что их уникальность не обязательна в расширенной РМД, т.е. даже это не верно. Но Вы не привыкли обращать внимание на то, что Вам пишут.

Настаиваю, что Вам нужно получить хоть какое-то образование по РМД. И не рекомендую до того делать на эту тему никаких публичных высказываний. Я давно не слышал ничего более наивного.
1 сен 04, 11:16    [924296]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

1. Зачем нужен первичный ключ, если кортеж итак уникален. По определению.
Зачем нужен табельный номер, в качестве первичного ключа, если кортеж, представляющий меня, итак уникален ? (SergSuper не ответил).
Зачем нужен номер страницы, если можно просто привести ее полный текст, который наверняка уникален ?
Почему такие простые вопросы ставят Вас в тупик, и вынуждают рассуждать о девушках ?

2. Внешний ключ накладывает ограничение на связь. Отлично ! Пока не будем говорить о внешних ключах, а будем говорить о СВЯЗЯХ (они же первичны, раз ключ накладывает ограничение на уже существующую связь). Так что за связь представляет собой атрибут DEPT в отношении EMP ? Особенно с учетом того, что отношения не представляют собой никаких объектов и никаких связей между объектами реального мира.
2 сен 04, 14:29    [929650]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Андрей Леонидович
Зачем нужен табельный номер, в качестве первичного ключа, если кортеж, представляющий меня, итак уникален ?

Для удобства и для отделения сущности от описания.
Замечу что табельные номера и номера страниц придумали несколько ранее реляционной теории и на мой взгляд ничего особо принципиального во взгядах на первичные и внешние ключи она не внесла.
2 сен 04, 15:00    [929829]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
SergSuper !

ДЛЯ УДОБСТВА ! Весьма разумное объяснение. То есть никакой теории. Но vadiminfo с этим не согласен, и он нас поправит. А пока естественным образом возникают следующие вопросы.

1. Для удобства ЧЕГО ? ЧТО будет удобнее с ключами ?
2. Вам не кажется, что удобства удобны всегда ? Зачем нужны не удобные отношения ?
2 сен 04, 16:51    [930450]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Пожалуйста вот Вам немного теории: Ключ(табельный номер) отражает сущность, ФИО - это аттрибуты сущности. Почему удобнее работать с табельным номером - можете спросить в плановом отделе или того кто у вас этим занимается.

Что касается Зачем нужны не удобные отношения ?
Мне например было бы удобнее сидеть дома и не ходить на работу, тем не менее я хожу, трачу больше 2-х часов в день. Действительно зачем мне такие неудобные отношения с работой?
2 сен 04, 18:00    [930821]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
SergSuper !

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

1. Для удобства ЧЕГО нужны ПРОСТЫЕ первичные ключи ? ЧТО будет удобнее с ними ?
2. Вам не кажется, что удобства удобны всегда ? Зачем нужны не удобные отношения, то есть отношения, не содержащие ПРОСТЫХ первичных ключей ?
2 сен 04, 21:45    [931216]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Андрей Леонидович
Спросил. У нас нет табельных номеров, и поэтому в нашем плановом отделе не знают зачем они нужны.

Не верю, но да не важно

1. Для удобства ЧЕГО нужны ПРОСТЫЕ первичные ключи ? ЧТО будет удобнее с ними ?
Вобще-то табельные номера(а значит и ключи) придумал не я, и не Дейт. Я написал для чего они нужны:
1. Для удобства - весьма субъективное объяснение и не думал что Вы к нему серьёзно отнесётесь
2. Более объективное объяснение - для отделения сущности от аттрибутов сущности. Сущность - это нечто что в модели программы по расчету зарплаты соответствует конкретному физическому лицу.


2. Вам не кажется, что удобства удобны всегда ? Зачем нужны не удобные отношения, то есть отношения, не содержащие ПРОСТЫХ первичных ключей ?

Отвечу в Вашам стиле:
Мне кажется что удобства всегда удобны, а неудобства всегда неудобны, но так же мне кажется что использование неких удобств часто свзано с использованием некоторых неудобств, хотя в результате получается всё равно удобней чем не пользоваться удобствами и не испытывать неудобств. Т.о. то, что нечто является неудобным еще не говорит о том что оно является ненужным.
Я не знаю что Вы подразумеваете под неудобными отношениями, не содержащими ПРОСТЫХ первичных ключей , но если кто-то их использует не исключаю что это кому-то нужно(т.е. он испытывает меньше неудобств чем получает удобств)
3 сен 04, 01:31    [931301]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
SergSuper !

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

ДЛЯ ЧЕГО НУЖНО ОТДЕЛЯТЬ СУЩНОСТЬ ОТ АТРИБУТОВ СУЩНОСТИ ?

На всякий случай напомню Вам и vadiminfo теорию. Вот как теория преподносит ОТНОШЕНИЯ ДО (!!!) ввода понятия КЛЮЧА.

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

Codd E.F., CACM, June, 1970, 13, N6 (стр. 379):

An array which represents an n-ary relation R has the following properties:
...
(3) All rows are distinct.
...

Дейт К.Дж. Введение в системы баз данных. Седьмое издание. Пер. с англ. -М.: Издательский дом "Вильямс", 2001 (стр. 166):

Свойство 1. Отсутствие одинаковых кортежей
... таблица (в общем случае) может содержать одинаковые строки (при отсутствии правил, запрещающих это), в то время как отношение НЕ МОЖЕТ содержать одинаковые кортежи В ПРИНЦИПЕ. (Суть в том, что "отношение", содержащее одинаковые кортежи, по определению НЕ БУДЕТ ОТНОШЕНИЕМ !).

Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. Пер с англ. -М.: Издательский дом "Вильямс", 2003 (стр. 123):

3.2.4. Свойства отношений
...
Каждый кортеж является уникальным, т.е. дубликатов кортежей быть не может.
-------------------------------------------------------------------------

Свойство уникальности кортежей существует без всяких ключей. Это ТЕОРИЯ. Та самая, которую мне постоянно советуют изучать. А ключи - это практика (УДОБСТВО; ОТДЕЛЕНИЕ СУЩНОСТИ ОТ АТРИБУТОВ), которую попытались замаскировать под теорию, но ничего не получилось (пока).

Первичный ключ определяется ДЛЯ УДОБСТВА, а не для обеспечения уникальности кортежей. А уже дальше для предотвращения явного противоречия, а не для "целостности сущностей", не допускаются NULL-значения в любой части первичного ключа.
Коннолли Т., Бегг К. (стр. 129):

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

С ключами в РМД просто беда. А заодно и с кортежами. РМД (скажем мягко - В ЭТОЙ ЧАСТИ) плохо формализована. Поэтому ее сложно реализовать. Во всяком случае пока это еще никому не удалось.

Вы, наверное, хороший практик.
ДО"реляционные" ООСУБД (ОСУБД) справляются с прикладными задачами.
"Р"СУБД справляются с прикладными задачами.
ПОСТ"реляционные" ООСУБД и ОРСУБД справляются с прикладными задачами.

В историческом плане не корректно задавать вопрос:

Зачем нужны эти ПОСТ"реляционные" СУБД, если "Р"СУБД итак справляются со ВСЕМИ (?) задачами ?

Сначала нужно ответить на вопрос:

Зачем предпринимались попытки создать РСУБД, если ДОреляционные ООСУБД (ОСУБД) итак справляются со ВСЕМИ (?) задачами ?

Но давайте не отвлекаться от роли ключей, все-таки несколько месяцев уже не можем разобраться. Итак:

ДЛЯ ЧЕГО НУЖНО ОТДЕЛЯТЬ СУЩНОСТЬ ОТ АТРИБУТОВ СУЩНОСТИ ?
3 сен 04, 15:21    [933601]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
С ключами в РМД просто беда. А заодно и с кортежами. РМД (скажем мягко - В ЭТОЙ ЧАСТИ) плохо формализована. Поэтому ее сложно реализовать. Во всяком случае пока это еще никому не удалось.

В чем беда то? Я тогда могу написать: с табельными номерами в плановом отделе просо беда.
Я уже не раз писал: ключи - это не изобретение РБД. И мне вобще-то всё равно полностью реализована РМД или нет - возможностей например MS SQL мне достаточно для решения большинства моих задач.

Вы, наверное, хороший практик.
Нет, просто я не читал Дейта, Кода и др. :) Когда начинал работать с SQL этих книг у нас еще не было, потом уже не интересно было.
Кстати такой термин как кортеж я для себя не использую и должен ли он быть уникальным или нет - мне всё равно.

Зачем предпринимались попытки создать РСУБД, если ДОреляционные ООСУБД (ОСУБД) итак справляются со ВСЕМИ (?) задачами ?
Наверное справлялись слишком дорогой ценой

ДЛЯ ЧЕГО НУЖНО ОТДЕЛЯТЬ СУЩНОСТЬ ОТ АТРИБУТОВ СУЩНОСТИ ?
Чтоб работать с одной сущностью, а не с набором аттрибутов

Вы то как на вопросы которые тут назадавали ответите?

А вообще бросайте этот тон учителя, как будто только Вы знаете истину, а все остальные студенты у Вас на экзамене. Если Вам что-то не нравиться - предложите лучшее решение, а то заладили "С ключами в РМД просто беда". Может и беда(в чем только?), но может есть и плюсы которые минусы перекрывают?
3 сен 04, 17:33    [934350]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
SergSuper !

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

Что значит "чтоб работать с одной сущностью, а не с набором атрибутов" ? Видимо это важно ? "Работать с одной сущностью" ?

Но Вы же знаете, что в ОМД нет ключей. Там "сущность отделена от атрибутов" всегда - это фундаментальное свойство ОМД. И об этом не нужно думать при создании приложений. Значит (в этом плане) ОМД лучше РМД ? Или в том, что сущность приходится вручную отделять от атрибутов есть какие-то плюсы, которые перекрывают минусы ?
4 сен 04, 01:06    [934821]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
ОСУБД не "справлялись", а справляются. И не менее эффективно, чем "Р"СУБД.
"не менее эффективно" - это Ваша субъективная оценка. Более объективная оценка - анализ рынка - это не подтверждает.

Я же просто Вас информирую о том, чего Вы явно не знаете.
Интресный способ информирования задавая вопросы :)

И всегда готов к обмену опытом, к обсуждениям, к спорам. Потому что истину, конечно, хотелось бы постичь. И на любой Ваш вопрос на пути к истине готов ответить...
Ну тогда ответьте на такой вопрос: чем Вам ключи неугодили? В чем же беда то?

Что значит "чтоб работать с одной сущностью, а не с набором атрибутов" ? Видимо это важно ? "Работать с одной сущностью" ?
Это например когда Вы храните только номер страницы в книги, а не её содержание.

Но Вы же знаете, что в ОМД нет ключей. Там "сущность отделена от атрибутов" всегда - это фундаментальное свойство ОМД. И об этом не нужно думать при создании приложений. Значит (в этом плане) ОМД лучше РМД ? Или в том, что сущность приходится вручную отделять от атрибутов есть какие-то плюсы, которые перекрывают минусы ?
Дык в ОМД и отношений нету :)
По Вашему надо что бы ключевое поле явно не объявлялось при создании таблиц, а внешний ключ сразу бы указывал на первичную таблицу. Ну и соответственно при запросах связи бы ставились автоматически. Я не думаю что это сильно бы упростило создание таблиц и написание запросов, а значение ключей всё-таки иногда полезно видеть при отладке. Ну и к тому же есть исторически сложившийся синтаксис, да и привычки людей. Это Вы так красиво написали "сущность приходится вручную отделять от атрибутов", а на самом деле надо просто добавить в таблицу одно поле.
Вобщем не принципиально всё это
4 сен 04, 03:03    [934865]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
SergSuper !

1. Это подтверждает анализ приложений. "Анализаторы рынка" таким анализом не занимаются. Давайте сделаем "объективно": я проанализирую Ваше приложение, и выскажу свое мнение (как оно выглядело бы в среде ОСУБД, и почему это более эффективно), а Вы проанализируете наше, и выскажете свое мнение (как оно выглядело бы в среде РСУБД, и почему это более эффективно).

2. Какие вопросы я Вам задавал про ОМД ? Именно информировал.

3. Ключи:

а) нужны для удобства (для "отделения сущностей от атрибутов");
б) при этом их почему-то нужно определять вручную;
в) возникают проблемы с NULL;
г) так как ключ - это ТОЖЕ АТРИБУТ (то есть сущность не отделена на самом деле).

Я это называю бедой. Могу сказать научнее: ошибочная концепция.

Вы это называете:

1) исторически сложившимся;
2) привычками людей;
3) и "не принципиально это все".

Странный способ постижения истины.
5 сен 04, 01:24    [935250]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович
Guest SergSuper !

>3. Ключи:

а) нужны для удобства (для "отделения сущностей от атрибутов");
б) при этом их почему-то нужно определять вручную;
в) возникают проблемы с NULL;
г) так как ключ - это ТОЖЕ АТРИБУТ (то есть сущность не отделена на самом деле).

Я это называю бедой. Могу сказать научнее: ошибочная концепция.


Как-то интересно получается: построили отцы-основатели реляционную модель, дали формальное изложение и теперь модель можно хотя бы в принципе аргументированно критиковать. А где бы посмотреть формализацию так называемой ОМД, у которой правильная концепция, или какая там альтернатива РМД осуждается? Дайте хоть одну ссылку на формальное изложение. Надоело просить. Ну чтоб можно было предметно поругать либо влиться в ряды сторонников.
5 сен 04, 08:13    [935307]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

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

1. Это подтверждает анализ приложений. "Анализаторы рынка" таким анализом не занимаются. Давайте сделаем "объективно": я проанализирую Ваше приложение, и выскажу свое мнение (как оно выглядело бы в среде ОСУБД, и почему это более эффективно), а Вы проанализируете наше, и выскажете свое мнение (как оно выглядело бы в среде РСУБД, и почему это более эффективно).

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



а) нужны для удобства (для "отделения сущностей от атрибутов"); - согласен
б) при этом их почему-то нужно определять вручную; - согласитесь что это не обременительно
в) возникают проблемы с NULL; - во-первых можете делать поле не допускающее NULL, а во-вторых - чё за проблемы то?
г) так как ключ - это ТОЖЕ АТРИБУТ (то есть сущность не отделена на самом деле). - внешний ключ может быть, насчет первичного можно поспорить. Но даже если и так - что в этом плохого(в смысле какие неудобства несёт)?

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



Вы это называете:

1) исторически сложившимся;
2) привычками людей;
3) и "не принципиально это все".

Странный способ постижения истины.

Один пунктик то выкинули...
Ну и что странного? В чем я не прав? Если это так принципиально - чего ж Вы не приведёте пример где бы всё наглядно демонстрировалось?
6 сен 04, 01:03    [935679]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
SergSuper !

При чем здесь "копаться в коде" ? Мне же ясно дали понять, что лучше написать

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

чем

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

что же мы будем раскапывать ?

Я хочу понять ваш (реляционистов) "принцип действия". Пока складывается такая картина.

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

с127 !

Что Вам не понятно в ОМД ? Все концепции Вам известны. Что не понятно ? Спросите, я отвечу.
6 сен 04, 23:15    [938205]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

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

Я не "реляционист", я "декларативист" :)
Если Вы работаете с одной записью, то наверное РМД Вам не нужна. А если нужно работать не с записями, а с данными - то замучаетесь циклы писать.
Например есть таблица с приходом денег по клиентам и надо пересчитать их остатки. Вы уже будете вложенные циклы писать, а мне дастаточно
update c set ostatok=ostatok + summa from Prihod p, Clients c where p.cln=c.cln
Все примеры которые Вы приводите - выбрать одну запись с определёнными аттрибутами(ARCRUS то совсем другую задачку приводил, попробуйте её решить, может поймёте тогда). Но СУБД(в моём понимании) предназначена для более сложных задач. SQL позволяет мне работатьс данными, я говорю серверу что нужно получить, а не как нужно делать. Вот и весь принцип. А всякие ключи, кортежи, отношения, все удобства - меня это мало волнует. У меня кстати есть таблицы без первичного ключа(например проводки) - может Вам от этого легче станет :).

Пока складывается такая картина.

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

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

Все это вы называете эффективной разработкой, ссылаясь на "анализ рынка", который просто подсчитывает ваше количество. А вас действительно много, что "позволяет" вам не обращать внимание на другие технологии...
Называем, потому что сами разрабатываем.
Ну ладно нас, дураков, много, но чё-то умных то до смешного мало... По-моему что-то тут не так. Я б задумался.
Хотя что удивительного если у умных все примеры - это обращение к одной записи. Нас, дураков, это никак не впечатляет. Нам циклы лениво писать, нам надо чтоб сервер за нас думал, мы ж дураки такие

с127 !

Что Вам не понятно в ОМД ? Все концепции Вам известны. Что не понятно ? Спросите, я отвечу.


Ой, а можно я за с127 отвечу?
Стандарт ОМД в студию!
7 сен 04, 01:04    [938268]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович

>Что Вам не понятно в ОМД ? Все концепции Вам известны. Что не понятно ? Спросите, я отвечу.

Были бы известны - не спрашивал бы. Так что вот вопрос, на который я хотел бы получить ответ:
"А где бы посмотреть формализацию так называемой ОМД, ... или какая там альтернатива РМД осуждается?"

Если вдруг нет ссылок, изложите формальную модель сами, я не возражаю.
7 сен 04, 08:10    [938373]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
SergSuper !

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

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

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

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

с127 !

Я изложил концепции ОМД. Что Вам не понятно. Спросите, я отвечу.
7 сен 04, 12:32    [939338]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
SergSuper !

Давайте на пчел не отвлекаться. Почему Вы не хотите проанализировать приложения ?

При чем здесь "копаться в коде" ? Мне же ясно дали понять, что лучше написать

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

чем

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

что же мы будем раскапывать ?

Я хочу понять ваш (ДЕКЛАРАТИВИСТОВ) "принцип действия". Пока складывается такая картина.

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

Где я ошибся ? И причем здесь пчелиный мед ?
7 сен 04, 12:45    [939392]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 21 22 23 24 25 [26] 27 28 29 30 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить