mirС чего это? Добавляю все данные о разработчике в таблицу «Разработчики». Вы считаете, что это невозможно? Почему это отсутствие проектов помешает мне это сделать? Признайтесь, что тут вы просто ошиблись. Как раз классическая схема из 3 таблиц позволяет вводить данные по обеим сущностям полностью независимо, а затем, по необходимости, добавлять данные об их связях.
Признайтесь уж, что Вы тут ошиблись.

Да, классическая схема позволяет вводить данные независимо. Я нигде это не оспариваю. Схема с nested table, как вариант той же классической, не отличающийся ER-кой, также позволяет их вводить (что, как я понимаю, оспариваете Вы). Названный мной вариант с денормализацией (четыре таблицы вместо трех) тем более позволяет их вводить.

Вы почему-то выдвигаете претензией к такой схеме аномалию, действующую в случае одной таблицы (Проекты_И_Разработчики_Вместе). Я не понимаю Вашей логики.

mirАйн момент. Рассмотрим такой вариант проекта БД:
Айн момент. Давайте уж рассматривать те варианты дизайна, которые назывались, а не те плохие с использованием того или иного инструмента, которые можно придумать. Полагаю, Вы согласитесь с тем, что для абсолютно любого технического приема несложно придумать дизайн, использующий его, и постановку задачи, где этот дизайн будет неудачным.

mirАномалия добавления налицо, а значит и парная аномалия удаления (см. мой пред. пост).
Да, после того как Вы проведете совершенно необязательную денормализацию (в Вашем примере - слили в одну таблицу сущности Проекты и ПроектыРазработчиков) появятся аномалии.

Давайте обойдется также с Вашим классическим вариантом. Удалим таблицу Проекты, включим ее поля в развязочную таблицу - и получим все те же аномалии. Но почему-то к классической схеме Вы эту логику не применяете.

mirВы можете со мной не разговаривать, но способны ли вы возразить по сути вопроса? В частности, вы ничего не сказали по поводу моего пример аномалии обновления.
Я могу обсуждать суть вопроса, но не могу возражать на виртуальный пример, не имеющий к этой сути никакого отношения. Если хотите начать какую-то новую ветвь дискуссии - начните ее явно. Например, сейчас Вы указали новый, ранее не упоминавшийся дизайн - и я согласился с его недостатками, как в случае близкого к классическому решению, так и в случае решения с nested tables.

mirА по поводу цитирования книги... Я не держал перед глазами книгу, если вы об этом. Подобные сведения об аномалиях денормализации у каждого, по моему, в памяти, как 2*2=4. У вас разве нет?
Вопрос не в том, в памяти эти данные или нет. Вопрос в том, что когда информация "из книги" выдается безотносительно обсуждаемой ситуации - возникает подозрение, что она прошла "из глаз в руки", минуя этап осмысления.

_hike_Может надаром в 10ке вместо него ввели XMLType ?
Во-первых, XMLType ввели не в десятке. Во-вторых, его ввели не вместо nested table, и даже не в дополнение, а просто независимо. В-третьих, по реализации он куда проще nested table - это попросту специфический объект, и в принципе начиная с восьмерки никто не мешал написать аналогичный и использовать - XMLType попросту является стандартным решением. Не составляет проблемы реализовать, например, HTMLType или CSVType и точно так же ими пользоваться - а вот реализовать на пользовательском уровне близкую альтернативу nested tables, боюсь, не удастся, разве что через INDEXTYPE.

_hike_
Кстати, неоправданных использований XMLType я бы ожидал встретить куда больше, нежели неоправданных использований nested tables. По той причине, что последний не дает чего-то принципиально нового; просто удобный в некоторых случаях взгляд на старое; XMLType же вызывает у пионеров крики типа "а давайте всю базу сделаем как одну таблицу с xml-ем".

_hike_А разве NESTED TABLE позволяют делать на себе ограничения типа foreign key ??? Если нет то как вы собираетесь поддерживать целосность ?
Тут наблюдается забавная картина - к сожалению, у меня нет под рукой базы, на которой я рискну прогнать соответствующий скрипт, чтобы продемонстрировать.

"Обычный" foreign key специально запрещен к созданию над nested tables. У меня есть подозрение, что дело тут в маркетинге, в продвижении объектных технологий, поскольку если создать его хакерским образом, он работает (я когда-то делал такой эксперимент). Вместо этого предполагается к использованию аналогичный "объектный" constraint (object ref / scope for). Полагаю, в следующих версиях разблокируют и нормальную возможность - поскольку сейчас имхо ясно, что "объектность" особым спросом не пользуется.

mirЯвное недопонимание друг друга, в итоге разговор о разных вариантах.
Видимо, так. У Вас употреблялось слово "или", поэтому в своем тексте я специально выделил "и" - тем не менее, увы..

mirНу, а если говорить о недостатках вашего варианта (вариант 3), то об этом уже сказал _hike_: проблемы с поддержанием целостности.
_hike_ я ответил в силу своего разумения. Что ж, здесь можно написать некий минус, хотя даже в моей схеме (с четырьмя таблицами вместо трех) заметных проблем я не вижу. Это полный список?

mirНу разве что еще избыточность. То есть новые данные о том, что
OK. Что я хотел отметить - естественное следствие денормализации; то же, что можно было бы отметить у четырех обычных таблиц с теми же данными.

Соответственно, если мы теперь уберем избыточность и оставим три таблицы - останется только необходимость использовать object ref вместо foreign key. Ничего априори страшного я в этом не вижу.

mirТо есть делать так по любому хуже, чем классическим путем.
"По любому хуже" - истиной не может быть никогда, если, конечно, Вы не собираетесь отстаивать позицию "любая БД должна находиться как минимум в пятой нормальной форме".

mirОдно не могу пока понять, если есть 3 таблицы, то 2 явно "Проекты" и "Разработчики", а третья, видимо, таблица связности. Вложенных таблиц вроде в таком проекте нет.
Отнюдь. Могут быть - три "обычных" таблицы. Могут быть - две таблицы, в одной из которых вложенная таблица связности (1).

mirОднако я высказал такое резюме только после того, как высказал чисто технические аргументы по поводу того, что для приведенного мной примера все решения с вложенными таблицами имеют недостатки по сравнению с классическим решением
Аргументы - хорошая вещь, но отличающаяся от фактов. Избыточность - относится только к одной структуре, которую я предложил как промежуточную в обсуждении, к названной выше структуре (1) - не относится. Остается целостность. Ваше подозрение по поводу ее отсутствия сводится к фразе "я не знаю, что такое object ref". Итого - обоснованных аргументов, фактов - не остается. Или я что-то пропустил?

(2 таблицы + таблица связности). Замечу только, что вы наличие этих недостатков не оспаривали (т. е. согласились).
Я не оспаривал избыточности в приведенной мной схеме - поскольку для этого ее и строил :) Относительно целостности - я отослал Вас к ответу на этот аргумент; если Вы считаете это "согласились" - хм...

Так почему вы считаете возможным столь снисходительно поучать меня подобным образом?
Хм. Каждый видит то, что он хочет. Единственное, что я могу - если хотите, постараюсь ограничить общение с Вами.

И при чем здесь, черт возьми, 5 нормальная форма?
Возможно, я здесь не понял Вас, поскольку решил, что "по любому хуже" относится в первую очередь к избыточности. А я - так не уверен, что избыточность "по любому плоха".

mirесли при этом декларативно можно обеспечить ссылочную целостность, причем со всеми потребными вариантами реакций вроде ON DELETE/UPDATE CASCADE/RESTRICT
Затруднюсь сходу ответить, поскольку желание сделать каскадную операцию для меня примерно в 100% случаев означает неудачный дизайн БД.

ModelRИнтересно, почему именно неудачный дизайн?
Статистическое наблюдение по моему личному опыту. Я не собираюсь утверждать, что "совсем никогда не нужно", но как-то оказывалось, что в каждом случае предпочтительнее другое решение.

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

ModelRПример delete Документ cascade Строки - вроде с дизайном все в порядке и желание разумное?
Не совсем. Чаще всего документ нужно не "удалять", а "перенести в архив", "пометить как ошибочно введенный" итп. И то, и другое - update. Далее, даже если говорить об удалении, обычно следует проверить какие-то бизнес-правила "можно ли удалять", которые не описываются ограничениями ссылочной целостности.

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


и не иметь потенциальных проблем с тем, что "здесь так, а здесь иначе", или "сосед случайно и незаметно удалил половину базы".

ModelRДругое дело, на строки еще много чего может быть навешено и каскад не прокатит, придется разбираться... - но дизайн то менять не нужно?
Сейчас я пришел к использованию каскадной системы в движке системы, в разработке которой участвую. Там метаинформация грузится в память того, что можно считать "движком" или "промежуточным звеном", связи между объектами задаются так же объектами, выполняющими некоторые каскадные операции - это удобно, поскольку оказывается возможным реализовать на уровне структуры хранения многие бизнес-правила. Но в БД каскадность в результате тем более не требуется. Можно ли было бы сделать то же на уровне каскадных возможностей БД? Вряд ли; во всяком случае задача "найти объект, который не дает удалить данный, и задать вопрос, не нужно ли удалить и его тоже" вряд ли хорошо решается средствами сервера.