вернемся к вопросам-ответам. мне надо выбрать все ответы для вопроса №23.
я запуская запрос с двумя join'ами(если мне надо ещё и название вопроса) и получаю результат.
или
я запускаю запрос к базе, выдираю вопрос №23. парсю строку с описанием списка ответов и запихиваю номера в массив. потом обращаюсь к базе и получаю по номерам нужные мне ответы. так, что ли? я правильно понял?

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

и выполнить один запрос.

Ignat, но парсинг строки происходит на стороне клиента! то есть данные надо прогнать в одну сторону, выделить под них буфер, записать, а потом - обратно. уверен, что будет быстрее?

Добавлено @ 18:44 
Ignat, значит, по-твоему, IN (подмножетсво) выполняется медленне INNER JOIN по первичному ключу? хм...   

  
Всё зависит от количества строк и использования индексов. Есть случаи оправданной "денормализации".

Ignat, конечно. пролистай страницу и убедись, что я не фанат. 
но в приведенном тобой примере количество бирж должно быть просто нереально малым, чтоб оправдать обработку на стороне клиента(2-3), если больше, то уже должно быть нехорошо...
И в примере muzerа тоже не все однозначно. Точнее, далеко не однозначно. 
Я ж не спорю с тем, что панацеи не бывает. Я просто желаю получить "жЫзненный" пример, когда денормализация - единственный выход, а НФ тормозят роботу с БД.

Добавлено @ 19:08 
Ignat, а IN разве будет быстрее UNION ALL?

Добавлено @ 19:09 

вопрос снимается. на самом деле, может быть быстрее, а может и нет. при UNION несколько сканирований, при IN(как мне кажется) не применяются ключи.

Добавлено @ 19:14 

ошибся. применяется. наверное, "разворачивается" в UNION.

Совсем не 2-3, но, спешу заметить, бирж и так не много 
На самом деле если число заведомо ограничено, до сотни строк в подчиненной таблице, то имеет смысл подумать о том, чтоб хранить её в памяти. Например, список регионов, областей, бирж, валют и т.д.

Я тоже не фанат, сам предпочитаю хранить в НФ, но повторюсь: таких случаев больше, чем хотелось бы.

а кеширование-то при чем? что мне мешает загрузить ответы, которые используются более, чем в 40% вопросов в память? что мне мешает записать все биржи у клиента и "делать JOIN" на стороне клиента, чтоб разгрузить базу? только каким боком использование и концепция кеша к НФ?

ещё одно "ЗА" для НФ: в MySQL при помощи group_concat можно "перейти" от НФ к неНФ, а обратное "преобразование на лету" невозможно 

Добавлено @ 00:10 
надо бы в holy wars скинуть часть, а то разошлись тута слегка 

Как-то получилось много абстракций.
Давайте чётко определим, на какие вопросы хотим ответить.
Я вижу следующие:
1. Какой должна быть система, удовлетворяющая след критериям: минимальное время ответа, возможность изменять списки. Два варианта решения: 
а) сделать всё в базе по НФ с помощью трёх таблиц.
Минусы:

•  при большом количестве данных промежуточная таблица становится сама по себе очень большой для mysql'я, растёт линейно
•  внесение изменений требует редактирования промежуточной таблицы
•  для получения ответа необходимо выполнить запрос с двумя джойнами между большими таблицами

Плюсы:

•  fixed таблицы => лучше восстанавливаются, лучше фулл-сканятся
•  не нужен умный сервер, загружающий все данные в память

б) сделать две таблицы, сделать промежуточный сервер, умеющий загружать необходимые данные в память
Минусы:

•  трудоёмкость

Плюсы:

•  при увеличении данных, таблицы растут медленнее промежуточной таблицы в пред варианте
•  возможность моментального ответа на вопрос, ибо без джойнов

Ответа на вопрос нет, есть плюсы и минусы. Я считаю, что второй вариант предпочтительнее.

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

skyboy,
Жизненный пример: сеть контекстной рекламы на разных сайтах, типа Бегуна, гугл эдсенс и т.д. Есть страница какого-то вёбмастера, который установил у себя блок рекламы. Робот сети определил для этой страницы набор ключевых слов, по которым должна отбираться реклама. Задача: когда посетитель зашёл на сайт, нужно показать n объявлений. Чтобы найти объявления, нужно узнать ключевые слова для этой страницы. Что проще, выбрать одну строку со списком слов или выбрать десять строк по слову на строку? Сколько в инете страниц? Миллионы, миллиарды, сколько в среднем слов определяется на каждую страницу? Пусть десяток.. Где и как хранить миллионы помноженные на десяток слов? 

muzer, надеюсь, твой пример - это не разглашение? :-|

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

как это выглядит? рекламный блок N связан со словами "world", "hello" и "happy", а страница M ассоциирована со словами "tree", "frieands" и "world" - потому и возникает соотвествие и реклама N отображается на сайте M? Т.е. определение пересечения подмножества? или четкое совпадение? если четкое совпадение требуется, могут ли слова в строке для блока и для сайта иметь разный порядок? 

хороший вопрос. положим, используем неНФ форму. Что хранится в неатомарном поле? списк индексов слов или(о, Боги!) сами слова? если сами слова, то на хранение требуется намного больше места, чем НФ-варианта. Впрочем, я так, с перепугу предположил. Не думаю, что так кто-нить делать будет при миллионе строк. Хотя... в среднем на такое поле из 10 слов 100 символов + 11 на идентификатор = 111 байт на строку или 111 * (количество сайтов == 1 000 000) = 100 Mb. Но не надо хранить слова. Но и группировка по словам такая, что проще застрелиться. И безопаснее для мозга.
Возьмем вариант, где в неатомарном поле хранятся индексы. 10 индексов по 10 символов + 9 символов-разделителей = 29 байт + 11 байт идентификатора = 40 байт на строку * (количество сайтов == 1 000 000) = 35 Mb. 
Примемся за НФ-вариант. на каждую строку: 11 +  11 = 22 байта, строк на сайт == 10, т.е. 220 байт; плюс отдельно хранятся идентификаторы сайтов(по 11 байт на сайт), где эти идентификаторы генерируются. Итого - 231 байт на сайт. 231 * (количество сайтов == 1 000 000) = 220 Mb. В самом деле, более, чем в два раза больше, чем для случая, когда записываем САМИ СЛОВА в таблицу. А ведь была ещё забыта таблица слов... 
Вот такая она, НФ-форма. 

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

Что я имел ввиду под парсингом:
SELECT word_id_list FROM table;  (разделитель в неатомарном поле - запятая)
SELECT word FROM dictionary WHERE word_id IN (word_id_list);
Это простейший пример. Только с помощью базу и простейшей обёртки. На деле же обе таблицы грузятся в память, ну а дальше всё то же самое только в синтаксисе языка.

По какому алгоритму идёт сравнение слов тут даже не важно, это другая задача.

Все необходимые для сравнения цифры ты, в общем-то, сам уже привёл 

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

Добавлено @ 15:16 
ещё заметка: у неатомарного хранения большое ограничение: нельзя определить характеристики связей, если они есть. Например(для "вопросов - ответов") нельзя определить "вес" ответа и прочие характеристики(кроме порядка, пожалуй, потому как в неатомарном поле порядок как раз задан). Это просто, заметки на полях. 

php не входит в список языков, которые я подразумевал 
си, питон, ява на худой конец.. перл и пхп не для этих целей.

про разнесённые на диал-ап сервера мы тоже не говорим  это каким надо быть извращенцем, чтобы поставить сервера одной сравнительно небольшой системы не на 100 Мбитный канал минимум)

про цифры - объём конечно не единственное. но помимо объёма уже недонократно обсуждали, два джойна делать.