Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Еще раз вернемся к вашему увлекательному утверждению: функцию-де реализовать можно, а множество нет. Вы продолжаете настаивать или хватит позориться?

Это не я настаиваю, а позорные разработчики СУБД. Или вы где то видели реализованные множества (не функции) ?.
30 янв 07, 09:22    [3710898]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo
По крайней мере сто пудово не всегда. Имеется в виду на логическом уровне.

Именно всегда и именно на логическом уровне - от dbf до оракла. Иначе просто невозможно работать с таблицей. Например update ... current of. У строки таблицы - неважно базовой или виртуальной всегда есть номер. Вы можете его не использовать, но СУБД будет его использовать.
В сетевых СУБД этот номер используется явно для связи таблиц, в иерархических неявно для тех же целей, в реляционных используется ограниченно (пока).
30 янв 07, 09:35    [3710956]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
mod: Похоже Вы думаете о чем-то о своем. Дайте тогда более развернутое описание своего понимания, прежде всего таблицы как функции (или ссылку на него). Пользователь обычно смотрит на БД (на ее содержимое) как на множество отношений. Конечно для него важно как они отображаются, но совершенно не интересует внутренняя организация. Возможно вы пытаетесь смотреть на БД с какой-то другой стороны? Что это дает?
30 янв 07, 10:11    [3711143]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мод
vadiminfo
По крайней мере сто пудово не всегда. Имеется в виду на логическом уровне.

Именно всегда и именно на логическом уровне - от dbf до оракла. Иначе просто невозможно работать с таблицей. Например update ... current of. У строки таблицы - неважно базовой или виртуальной всегда есть номер. Вы можете его не использовать, но СУБД будет его использовать.
В сетевых СУБД этот номер используется явно для связи таблиц, в иерархических неявно для тех же целей, в реляционных используется ограниченно (пока).


WHERE CURRENT OF cursor_name

Refers to the latest row processed by the FETCH statement associated with the cursor identified by cursor_name. The cursor must be FOR UPDATE and must be open and positioned on a row. If the cursor is not open, the CURRENT OF clause causes an error.

Это "номер" не в таблице, а в курсоре. Т.е. это механизм работы в PL/SQL, облегчающий изменение последней выбранной из курсора строки. В курсорах (указатель на набор записей в памяти), коллекциях тем более есть навигация. А вот сам набор получается из таблиц без использования номеров.
Т.е. номер в таблице пока не нужен. В курсорах есть порядок, есть хождение по порядку от первой к последней. Так что Ваш пример про обработку результатов полученных реляционным путем в не реляционных языках. Т.е. без дальнейших уточнений не может быть принят в качесте необходимомти номеров в таблицах РБД в реляционном языке для доступа к данным. В других языках - да нужен, наверное.
30 янв 07, 10:44    [3711373]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo

WHERE CURRENT OF cursor_name
Это "номер" не в таблице, а в курсоре.

А как по номеру в курсоре найти строку таблицы ? Только по rowid. И forms работает по rowid. И вообще вы не сможете обновлять таблицу с повторениями строк без этого номера.
vadiminfo

Дайте тогда более развернутое описание своего понимания, прежде всего таблицы как функции (или ссылку на него).Возможно вы пытаетесь смотреть на БД с какой-то другой стороны? Что это дает?

Для меня все СУБД (всех типов и видов) работают только с таблицами. Таблица это одномерный массив строк, т.е. функция от целочисленного аргумента во множестве кортежей. Это позволяет однозначно идентифицировать строку независимо от ее содержания, тем самым становится возможным использовать явные и неявные ссылки между таблицами, т.е строить разные МД внутри одной БД. Согласен, что это субъективный взгляд, но имхо он адекватен реальному состоянию дел в СУБД.
30 янв 07, 11:22    [3711701]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

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

WHERE CURRENT OF cursor_name
Это "номер" не в таблице, а в курсоре.

А как по номеру в курсоре найти строку таблицы ? Только по rowid. И forms работает по rowid. И вообще вы не сможете обновлять таблицу с повторениями строк без этого номера.

В связи с тем, что это проблемы СУБД, я думаю, все еще что проблемы физического уровеня. Вот када проггер с помщью MOVE по номерам переходил - это на логическом. А в данном случае для прогера WHERE и условие. А как там ищет СУБД нужную запись - ее дело.

vadiminfo

Дайте тогда более развернутое описание своего понимания, прежде всего таблицы как функции (или ссылку на него).Возможно вы пытаетесь смотреть на БД с какой-то другой стороны? Что это дает?

Для меня все СУБД (всех типов и видов) работают только с таблицами. Таблица это одномерный массив строк, т.е. функция от целочисленного аргумента во множестве кортежей. Это позволяет однозначно идентифицировать строку независимо от ее содержания, тем самым становится возможным использовать явные и неявные ссылки между таблицами, т.е строить разные МД внутри одной БД. Согласен, что это субъективный взгляд, но имхо он адекватен реальному состоянию дел в СУБД.[/quot]
Странный у Вас взгляд. Он не распространен. В иерахических в связи со структурой упоминаются не таблицы, а типы записей. У таблы должны быть строки и заголовки, по крайней мере, у реляционной. И все. Так их должен, по крайней мере проггер, проектировщик БД мыслить. Физическое - к админам.
Массив - индексированное множество. Т.е. там явно или не явно присутсвует индексное множество и отображение, которая ставит в соответствие индексу элемент множества.
Там присутствует как правило перемещение по от элемента к элементу с помощью индексов. MOVE или типа. Я счас как раз с OLAP DML от Оракла парюсь. Вот тут конкретно массивы. - Т.е. измерения предлагается мыслить как массивы. А про таблы никаких таких рекомендаций не поступало.
И какой их смысл таблицами называть? Их и изображают то часто не в виде таблов - т.е. не мыслят как таблы.
Что касается самого СУБД, т.е. как они реализуют на физ уровне. То там конечно навигация.
Блоки она считывает с диска. Ну так пока компы устроены.
30 янв 07, 11:55    [3711959]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

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

Самое главное, по прежнему вы путаете логический и физический уровни представления. Используете термин "таблица" одновременно в разных смыслах. Пора бы навести порядок в мыслях. Если способны.
30 янв 07, 12:06    [3712055]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Т.е. конечно переменны как массив, а измерения типа индексы этих массивов
30 янв 07, 12:06    [3712061]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo

Вот када проггер с помщью MOVE по номерам переходил - это на логическом. А в данном случае для прогера WHERE и условие.

в чем проблема:
where rowid='abcd'
vadiminfo

В иерахических в связи со структурой упоминаются не таблицы, а типы записей.

А еще есть сегменты, файлы, наборы ...терминология понимаешь. А строки и заголовки всегда и везде были и есть.
vadiminfo
Массив - индексированное множество. Т.е. там явно или не явно присутсвует индексное множество и отображение, которая ставит в соответствие индексу элемент множества.

Вообщем да.
vadiminfo
Там присутствует как правило перемещение по от элемента к элементу с помощью индексов.

Необязательно - М - прямой доступ (вычисление функции)
зы я свою позицию изложил, соглашаться, нет, принять к сведению - ваше право. Успехов.
30 янв 07, 12:48    [3712434]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Или честно признайте, что это ваша выдумка.

не моя - откройте любой dbf
mir

Отборный бред. Ни единое утверждение не обосновано. И, замечу, ни единое не соответствует истине.

И как вы с СУБД только работаете (не понимая базовых принципов) !
mir

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

Вот только про физический уровень не надо - вы не понимаете что это такое. Определение таблицы я вам давал - оно совпадает с учебниками и практикой.
30 янв 07, 12:55    [3712501]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

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

чем проблема:
where rowid='abcd'

Вы про так СУБД реализовать WHERE CURRENT OF?
Так это проблема разработчика СУБД. У проггера нет проблемы, есть только таблы и курсор в данном случае. Нашел что-то в курсоре, механизм как найти эту запись в БД берет на себя СУБД.
Про номера в табле проггеру ниче не надо. Ведь Вы про нужность номеров говорили.
Вот када массивы или пусть даже курсоры - там про номера мыслить приходится. А в таблах пока еще не нужно.


мод

А еще есть сегменты, файлы, наборы ...терминология понимаешь. А строки и заголовки всегда и везде были и есть.

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


мод
Там присутствует как правило перемещение по от элемента к элементу с помощью индексов.

Необязательно - М - прямой доступ (вычисление функции)
Детали. Я Move в широком смысле употребил, включая и этот случай - ведь речь шла о номнрах и доступа по ним. Т.е. за Move скрывался доступ по номерам.
30 янв 07, 13:31    [3712819]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
vadiminfo
Про номера в табле проггеру ниче не надо. Ведь Вы про нужность номеров говорили.Вот када массивы или пусть даже курсоры - там про номера мыслить приходится. А в таблах пока еще не нужно.

Из вашего выступления я понял, что эта возможность вам не нужна, а вот другим может понадобиться. Многие возможности СУБД нужны не всем и в этом ничего страшного нет. Успехов.
30 янв 07, 13:58    [3713137]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
vadiminfo
Member

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

Из вашего выступления я понял, что эта возможность вам не нужна

Не выступления, а ответа на Ваши предположения про вложеннные таблы не отличаются от реляционных.
Мне в РМД нужна РМД. В процедурных языках массивы. И т.е. Т.е. мне все на своем месте. И не тока мне. Иначе бы массивы были в РМД.
30 янв 07, 14:22    [3713402]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
Или честно признайте, что это ваша выдумка.

не моя - откройте любой dbf
Диагноз товарища Саахова подтверждается.
мод
mir
Отборный бред. Ни единое утверждение не обосновано. И, замечу, ни единое не соответствует истине.
И как вы с СУБД только работаете (не понимая базовых принципов)!
И как вы только беретесь рассуждать о СУБД, при этом как путаясь в основах математики, так и не имея представления о способах реализации хранения внутри современных СУБД (рассуждения о непременных целочисленных "номерах строк" и внутренней "табличной" организации хранения всех во до единой СУБД). Отсылка к dbf как к главному аргументу особенно впечатлила. Товарищ, похоже, не слыхал ни о B-деревьях, ни о модели TransRelational, ни о хранении "по столбцам" в Sybase IQ... Одни, понимаешь, таблицы у всех унутри, в виде массивов. Как будто с пальмы спустился, чесс-слово...
мод
mir
Самое главное, по прежнему вы путаете логический и физический уровни представления. Используете термин "таблица" одновременно в разных смыслах. Пора бы навести порядок в мыслях. Если способны.
Вот только про физический уровень не надо - вы не понимаете что это такое. Определение таблицы я вам давал - оно совпадает с учебниками и практикой.
Только что-то ни одно ваше определение, которые вы на ходу сочиняете с многочисленными ляпами, вы не подкрепили самой завалящей ссылкой или цитаткой. Многочисленные просьбы привести таковые пока без ответа. Как говорится, слив защитан. Так что слова "совпадает с учебниками" -- просто сотрясение воздуха.
30 янв 07, 14:42    [3713608]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Как говорится, слив защитан.

Если для вас это главная цель обсуждения - да на здоровье. Вы к сожалению не умеете слушать оппонентов и это уже давно замечено. Успехов.
30 янв 07, 15:59    [3714324]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
-dead rowid-
Guest
мод
Таблица это одномерный массив строк, т.е. функция от целочисленного аргумента во множестве кортежей. Это позволяет однозначно идентифицировать строку независимо от ее содержания, тем самым становится возможным использовать явные и неявные ссылки между таблицами, т.е строить разные МД внутри одной БД. Согласен, что это субъективный взгляд, но имхо он адекватен реальному состоянию дел в СУБД.

проблема в том, что значения типа ROWID, как правило, не выживают (т.е. изменяются) при backup/restore.
30 янв 07, 18:56    [3715729]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
-dead rowid-
проблема в том, что значения типа ROWID, как правило, не выживают (т.е. изменяются) при backup/restore.

Это действительно проблема, но оракле уже добился неизменности ROWID при любых обновлениях строк, осталось только решить ее для backup/restore (правда это не просто).
31 янв 07, 10:18    [3717389]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
мод
оракле уже добился неизменности ROWID при любых обновлениях строк


А можно ссылочку на эту шокирующую новость ?

А то может я чего-то проспал, например ROWID в IOT или в партиционированной таблице очень даже легко меняется при банальном UPDATE.

ROWID в кластерных таблицах это вообще отдельный разговор.....

Я конечно в физическом уровне мало что смыслю, в dbf файлах реляционной теории не ищу, не заглядываю даже, но всё-таки интересно :-)

Если вы специалист по какому-нибудь MUMPS-у, CACHE, Pick-у, а Oracle\MSSQL видели только что бы убедится что "SQL бесполезен для доступа к данным" (с) ЧАЛ, тогда вопрос снят.
31 янв 07, 10:43    [3717615]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
Andreww
А то может я чего-то проспал, например ROWID в IOT или в партиционированной таблице очень даже легко меняется при банальном UPDATE.

Может быть я и не прав, не буду спорить - для меня это пока не принципиально.
31 янв 07, 13:49    [3719227]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
Как говорится, слив защитан.

Если для вас это главная цель обсуждения - да на здоровье. Вы к сожалению не умеете слушать оппонентов и это уже давно замечено. Успехов.
Да на этом форуме полным-полно людей, которых я слушаю и молча пытаюсь учиться. Здесь есть приличные математики. Здесь есть живые разработчики современных СУБД (по крайней мере, Firebird, Линтер, MS SQL Server). Это вы им как мега-эсперт порассказывайте, как в СУБД внутри реализовано хранение данных. Про непременные целочисленные номера строк. Про то, что там все сделано на таблицах в виде массивов. И что dbf -- прям-таки эталон формата хранения БД. Это будет шоу "весь вечер на арене цирка -- веселые клоуны".

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

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

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

P.S. Если у кого-то создалось впечатление, что я-де обиделся и в обиде строчу этот ответ, это не так. Пишу я его вполне лениво и даже где-то с улыбкой.
31 янв 07, 14:26    [3719531]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
Andreww


'Changing' rowids
Although a rowid uniquely identifies a row in a table, it might change its value if the underlying table is an index organized table or a partitioned table. Also, rowids change if a table is exported and imported using EXP/IMP. This implies that rowids should not be stored away for later re-use as the corresponding row then might either not exist or contain completely different

Такая вот недоработка :)
31 янв 07, 14:29    [3719562]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
чалик
Guest
SQL действительно бесполезен. Два популярных "инструмента" активно используются людьми, далекими от баз данных: SQL и Excel.
Мы уже обсуждали тему "немодельных вычислений", в свое время. В "Р"СУБД не только "суммирование по колонке" (и др. "агрегирующие функции"), но и соединения являются немодельными вычислениями (если считать, что в БД, как об этом говорили Кодд и Дейт, хранится информация о сущностях и связях между ними). Если Человек-Занимает-Должность, то в результате "запроса" Человек-Занимает-Должность, по-прежнему. То есть "результату запроса", как части БД, должна быть присуща та же семантика (сущности и связи между ними), что и самой БД. Да, "результат запроса" можно представить в виде ОДНОЙ таблицы, при необходимости. Но "запрос" в ОСУБД не искажает информацию, а в "Р"СУБД неизбежно искажает (кроме того, из РБД вообще нельзя извлечь никакой информации без этого самого "запроса", то есть без программиста, который придет, исказит, неизбежно, информацию, а потом для исправления этой глупости еще что-то вынужденно запрограммирует), представляя "результат" в виде отношения с неизбежной необходимостью интерпретации (то есть складывая апельсины с автомобилями).
"Ключи" в "Р"СУБД призваны были снивелировать ущерб от "алгебры", и хоть как-то связать сущности (пусть и лишив БД идентификации, навигации, семантики). Но "алгебра" взяла свое. РМД так и осталась нереализованной, а "Р"СУБД неизбежно приближаются к дореляционным ОСУБД во всех отношениях, но тормоз в виде бесполезного для БД SQL, никогда не даст им превратиться в системы управления базами данных. Они так и останутся электронными таблицами с "развитой системой доступа" (обогнали Excel, молодцы!).
5 фев 07, 21:15    [3742060]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Видимо, в дурдоме травят тараканов и больных временно отпустили.
6 фев 07, 06:15    [3742479]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
чалик
если считать, что в БД хранится информация о сущностях и связях между ними

А не надо так считать. В БД (любой) хранится часть модели предметной области. В связи с этим остальные рассуждения не имеют смысла.
6 фев 07, 09:35    [3742831]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
автор
В БД (любой) хранится часть модели предметной области.


Можно даже уточнить, что хранятся ФАКТЫ модели предметной области, а задача БД предоставить аппарат для манипуляции этими фактами.

Когда начинают "хранить" связи,объекты и т.п. получается фуфел.
6 фев 07, 10:07    [3743000]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить