select A.*
from B-1-A
where (B-1-A)=1

Бредятинаselect A.*
from B-1-A
where (B-1-A)=1
Благодаря П-Л: это авторы, которые написали хотя бы одну книгу без соавторов. Пропустил "ни ко одной"(( Для этого схему нужно расширить:

select A.*
from B-1-A-1-B-1-A
where (B-1-A-1-B-1-A)=1

БредятинаБредятинаselect A.*
from B-1-A
where (B-1-A)=1
Благодаря П-Л: это авторы, которые написали хотя бы одну книгу без соавторов. Пропустил "ни ко одной"(( Для этого схему нужно расширить:

select A.*
from B-1-A-1-B-1-A
where (B-1-A-1-B-1-A)=1
Естественнее, конечно:

select A.*
from A-1-B-1-A
where (A-1-B-1-A)=1

lLocustБредятинапропущено...

Благодаря П-Л: это авторы, которые написали хотя бы одну книгу без соавторов. Пропустил "ни ко одной"(( Для этого схему нужно расширить:

select A.*
from B-1-A-1-B-1-A
where (B-1-A-1-B-1-A)=1

Я ничего не понял в этой терминологии... Бредятина какая-то.... ))))

почему не сделать стандартно:


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

Естественнее, конечно:

select A.*
from A-1-B-1-A
where (A-1-B-1-A)=1

В схеме БД два объекта Автор (A) и Книга (B). И связь между ними многие-ко-многим 1 (Написал/Написана).
Запрос делается к схеме Автор-Написал-Книга-Написана-Автор. Очевидно, что если для Автора в начале схемы получаем того же автора в конце, то это и есть нужный нам автор))) Зачем же писать так громоздко, как у Вас?

lLocustАааа )))

Просто иной раз понять ansi запрос проще чем связь (A-1-B-1-A)=1.
Тем более что связей (A-1-B-1-A) (где Автор в начале и Автор в конце один для одной и той же книги просто не может быль больше 1 даже в теории, а для разных книг не совсем понятно как это учтено...)

без sql я бы как-то так описал:
все авторы (у которых нет книг (у которых есть другой автор)). Фактически аналог sql`я но понять сложнее.....
Что же непонятного)) Ведь у Автора много книг, и если хотя бы у одной из них есть еще один автор, то мы получим двух авторов для данного автора в этой схеме БД)))

АнатоЛойБредятина))) Мы здесь, кажется, договорились, что речь в этом подфоруме идет о проектировании баз данных, а не о проектировании реляционных баз данных.
Простите, не слежу за всеми темами. Не дадите ссылочку, где это "здесь"?
Я полагал и полагая, что в этом форуме речь идёт как о проектировании баз данных, так и о проектировании реляционных баз данных...
http://www.sql.ru/forum/1081429/kak-izbezhat-mnozhestva-znacheniy-v-odnoy-yacheyke
Из Вашего текста следует, что реляционная база данных - не база данных))) Мне кажется, что этот подфорум (раз его не переименовывают в "Проектирование реляционных баз данных") посвящен именно проектированию баз данных. То есть, в каждой теме следует рассматривать альтернативные решения с использованием различных МД.

БредятинаlLocustАааа )))

Просто иной раз понять ansi запрос проще чем связь (A-1-B-1-A)=1.
Тем более что связей (A-1-B-1-A) (где Автор в начале и Автор в конце один для одной и той же книги просто не может быль больше 1 даже в теории, а для разных книг не совсем понятно как это учтено...)

без sql я бы как-то так описал:
все авторы (у которых нет книг (у которых есть другой автор)). Фактически аналог sql`я но понять сложнее.....
Что же непонятного)) Ведь у Автора много книг, и если хотя бы у одной из них есть еще один автор, то мы получим двух авторов для данного автора в этой схеме БД)))
(схема) - это сокращенный синтаксис - значение системного атрибута Количество привязанных.

rockclimberП-Лпропущено...

Это не соавторы. ТС, думай сам.Точно. Тогда решение даже проще.
Намного)))

АнатоЛойБредятинапропущено...

http://www.sql.ru/forum/1081429/kak-izbezhat-mnozhestva-znacheniy-v-odnoy-yacheyke
Из Вашего текста следует, что реляционная база данных - не база данных)))

Не следует. Поскольку вывод неоднозначен. Поскольку достаточно уточнить: "Я полагал и полагаю, что в этом форуме речь идёт как о проектировании баз данных, так и о проектировании реляционных баз данных, поскольку реляционные базы данных тоже можно называть базами данных..."

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

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

БредятинаТо есть, в каждой теме следует рассматривать альтернативные решения с использованием различных МД.
Непонятно, откуда появился предикат "каждый" в вашем логичном, вроде бы, выводе.
По идее, название и содержание темы - подмножество из области обсуждений, связанных с общей тематикой форума.
И если в название темы присутствует "SQL", то это "как-бы намекает", что речь в теме идёт, в-первую очередь, всё-таки о реляционных базах данных :). Где я ошибаюсь?
Вы не ошибаетесь. А просто своим "в первую очередь" подтвердили мое "в каждой"))
Вот, например, тема: "Связь многие ко многим и проблемы с выборкой на SQL".
1) В реляционных БД в принципе нет никаких связей, а есть ограничения целостности.
2) Судя по заголовку, есть проблемы))
3) Структурированный язык не противоречит никаким МД...

АнатоЛойХм. Я понял что меня на самом деле зацепило. "Следует" - это ваш лозунг, применительно к публике эту фразу корректнее было бы строить с использованием предиката "можно"... :).
Да.