мод 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, облегчающий изменение последней выбранной из курсора строки. В курсорах (указатель на набор записей в памяти), коллекциях тем более есть навигация. А вот сам набор получается из таблиц без использования номеров.
Т.е. номер в таблице пока не нужен. В курсорах есть порядок, есть хождение по порядку от первой к последней. Так что Ваш пример про обработку результатов полученных реляционным путем в не реляционных языках. Т.е. без дальнейших уточнений не может быть принят в качесте необходимомти номеров в таблицах РБД в реляционном языке для доступа к данным. В других языках - да нужен, наверное.

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

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

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

Т.е. конечно переменны как массив, а измерения типа индексы этих массивов

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

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


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

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


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

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

Не выступления, а ответа на Ваши предположения про вложеннные таблы не отличаются от реляционных.
Мне в РМД нужна РМД. В процедурных языках массивы. И т.е. Т.е. мне все на своем месте. И не тока мне. Иначе бы массивы были в РМД.