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


Результат реляционой операции - реляционное отношение, а не таблица.
Сортировка (и как частный случай в порядке выборки строк) позволяет работать с выборкой как с массивом или списком элементов-записей, тогда как записи в таблице - множество, причём в многопользовательской БД, это множество меняется в произвольные моменты времени.
Собственно, мы никогда с таблицей не работаем, это удел СУБД. Мы, даже выполняя DML запросы оперируем выборками, которые СУБД применяет на таблицу.

мод mcureenab
Только чел сейчас хочет построить модель, а не приложение. Т.е. он хочет поработать на уровне ER модели и модели классов.
Т.е. работать не с таблицами, а с объектами ? Так тоже можно, но тогда надо забыть о таблицах, рел. модели и пр. Можно использовать какую-нибудь ОСУБД или сделать собственную.

Делать СУБД нет нужды. Достаточно над реляционным движком создать объектный интерфейс. Так, например поступил оракл. И забывать ни о чём не надо, ибо хранимые объекты по прежнему хранятся в таблицах. Обычно, при создании хранимого объекта нужно указать имя таблицы в БД, где он будет сохранён, когда процесс завершит работау с ним.

Объекты приложения отличаются от объектов БД. В процессе копирования записи из БД в процесс приложения (через интерфейс курсора БД, который возвращает выборку) происходит преобразование типов данных, структуры и т.п. Даже если мы на высоком уровне абстракции говорим о том, что запись в базе данных и объект в приложении имеют один и тот же класс, то на уровне реализации мы создаём разные типы - например тип struct в C++, и DDL оператор create table в SQL. Наконец в результате сборки, мы получаем исполняемый код для работы со структурой данных на ПК и таблицу как объект схемы БД.

Чтобы привнести конкретики, рассмотрим Oracle Forms.
Во время разработки мы создаём блок формы (block) и добавляем в него элементы (item). По сути мы конструируем новый класс. Определённо блок формы, это совсем не таблица БД. Он может даже содержать записи, которых и нет вовсе в БД, да и SQL запросы к нему не применимы. Но на более высоком уровне абстракции мы видим, что блок формы реализует некоторую часть поведения хранимого объекта, обычно связанную с его редактированием в GUI.

В отличии от классов C++ блоки и элементы формы имеют предопределённые виртуальные методы - триггеры, которые разработчик может перегрузить своим кодом. Объекты C++ живут в стеке, глобальной памяти или в куче, объекты Forms, живут только в блоке формы. Есть и другие отличия. Кто то может сказать, что аналогия вообще притянута за уши, однако подход вполне продуктивный и пока он позволяет решать задачи моделирования и генерации кода, я его буду использовать.

мод mcureenabОпределённо блок формы, это совсем не таблица БД.
Это просто таблица - результат select-a - но всяко не класс.

Короче, Вы всё сущее называете таблицами, а раз так, обсуждать различия разных видов "таблиц" непредставляется возможным.

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

мод mcureenabКороче, Вы всё сущее называете таблицами
Совсем нет. Возьмем пример: сущность: счет-фактура, в РБД представлена 2-мя таблицами: заголовки и строки. Приложение работает с этими таблицами вместе или по отдельности.
"Объектный вариант: в ОБД СФ хранится как объект класса СФ, никаких таблиц нет, приложение работает с каждым СФ как с единым объектом.
Можно сравнить эти два варианта.

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