_модDML всегда декларативный. Это его использование в ЯП императивно, просто потому что сами ЯП императивны.

Вот DML в SQL декларативный потому, что без использования в императивных ЯП обходится для доступа к данным. А если для этого надо использовать еще и императивный ЯП, то, скорее всего, либо там нуно букву L убирать (это не совсем язык, а тока чаить), либо они с этим ЯП и есть этот DML императивный.
Так или иначе языки БД делились на имепративные и декларативные, как впрочем и ЯП. И одурачить всех иерахичискими хитростями, чтобы прировнять иерархические и реляционные просто так, по видимому, не удастся.

_модИзначально SQL был придуман для консоли оператора. Другие DML аналогично. Т.е они все были "декларативными".
И только потом их вставили в императивные ЯП и они стали "императивными"
Но видители, есть другие сведения: SQL изначался задумывался деклароативным и именно этим противопоставляся имеративным.


И стория с "консолью оператора", скорей всего, не сможет преодолеть эти предрассудки, ввиду малозначимости этой самой "консоли" в технологиях БД. Тем более что SQL так и остался декларативным. А сразу были императивными, т.е. минолвали "консольный" период.

Другие языки БД не реляциоонные изначально были императивными.

ViPRosvadiminfo,

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

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

Декларативность в моем понимании - "Выбери то то и то то" и все

Ну хорошо. А как тада быть с тем, када приходится писать:

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

Это считать более императивным, чем соединение в "императивеном" SQL?

Мне каэтся отнесение к императивному и соединение и его навигационную реализацию к имерартивному все же может привести к утрате пользы от деления на декларативный и императивный.

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

_мод И все DML на это были ориентированы. Вы просто не в курсе.
Ну не тока я не в курсе, что другие кроме реляционных языков были в свое время декларативными и вдруг стали с императивными. Тем более что SQL стал императивными (иначе он другой).
Это и авторы толстых книг писали и на лекциях вроде читали. Че Вы там делали? Чуствую, у Вас много более интерсных дел было в то время.

Нет, конечно, были ЯП декларативные: Липс, Пролог, но это не языки БД, Хотя может и с БЗ могут типа работать.

Иерархические, ООМД - главное навигационный доступ и циклы. Там теперь есть конесьно и декларативные для проформы, но моложе SQL (наприме OQL) и не основное там, судя по всему.

_мод, все еще не думаю, что Вам просто буит всех одурачить эдаким примиренчеством иерархистов. Многие будут по прежнему не в курсе, что РМД типа эквивалента иерархическим.

_модПредположить-то можно :). Но ! Сначала была рел. алгебра, потом соот.в. ей язык алфа, а потом уже SQL, как практическая реализация, пригодная для набирания с консоли.
Особенно "пригодность для набирания с консоли" делает всякие предположения уязвимыми.
Был еще пригодный язык для такого "набирания": Наимри -2. Консоль производилась вроде в армении.