Всем известно что такое таблица умножения. Умножаем число а на число b - находим в верхней строке число a, в первом столюце число  b и на их пересечении получаем результат.
Допустим в БД есть такая таблица - как с ней работать, т.е. когда пишем запрос мы указываем название столбца и значение = на выходе результат несколько строк, в которых значение в данном столбце равно заданному в условии. 
А тут получается надо найти сначала нужный столбец, потом строку и на перекрестье получить их значение.
Перебиваить таблицу, так что бы указывать все комбинации идея плохая.
Как в БД работают с такими таблицами?

shuttle, что то мне кажется сомнительным что в бд могут понадобиться подобные таблицы. их всегда можно представить в более логичной(с точки зрения реляционной модели) формы. в какой реальной задаче может понадобится таблица с подобным устройством?

отступление: коль уж сильно надо, то выбери столбец и отсчитай количество строк, получится требуемая ячейка. т.е. если 3х4 то выбираем столбец № 3 и в этом столбце смотрим результат 4.

угу, нечто вроде

Я бы сделал это так:

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

Это конечно же офтопик, но тем не менее...

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

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

Всё чисто субьективно.

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

Экскалупатор, мне только один раз понадобилась такая конструкция - это был отчет по датам в mssql2000 (он не поддерживает PIVOT)

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