Yuri Morozov

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

Достаточно несложно, однако есть нюансы.

SELECT MAX(id) FROM random тупо добывает максимальный id в таблице (обозначу его как $max).
RAND() * $max дает нам некий произвольный ID из таблицы.

Сложная скобочная конструкция, с которой джойнится таблица random создает временную таблицу, в которой, грубо говоря, лежит заданное кол-во произвольно выбранных (при помощи rand() * $max) ID.

Условие вида r1.id >= r2.id позволяет учесть потенциальные пропуски в ID (какие-то из записей были удалены, к примеру).

Теперь нюансы:
1. Я не уверен, что все БД схавают джойн по нецелому ID. Возможно, имело бы смысл сначала округлить.
2. На первый взгляд, нет контроля за дубликатами.

А не жирновато так хранить?
Может, на многие-ко-многим перейти?

Во-первых, org_id у Вас в этой таблице нет, так что UNIQUE (org_id) выдаст ошибку.
Во-вторых,

CREATE TABLE person (
p_id INT not null auto_increment primary key , 
p_name VARCHAR ( 25 ) not null ,
p_login VARCHAR ( 15 ) not null ,
password VARCHAR ( 15 ) not null , 
org INT not null REFERENCES org ( org_id ) ON UPDATE CASCADE ON DELETE CASCADE ,
UNIQUE (org, p_login , password ) 
)

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

Зависит от того, что именно Вы делаете.

Если это, грубо говоря, лабораторная работа по нормализации таблиц - тогда ТОЛЬКО через промежуточную таблицу, за иные варианты Вам снимут голову.

Many-to-many через pivot table чаще всего не нравится тем, что для добычи результата приходится делать двойной джойн, а потом каким-то образом разгребать дублирующиеся данные "основной" таблицы.

Если не требуется искать блюда по ингредиентам ("найти все блюда, в которых есть чеснок") - тогда можно и схитрить немного.

Обычный вариант обхода - добавить немного скриптовой части:
- выгребаем данные основной таблицы: select * from meals where ...;
- скриптом собираем полученные ID в массив и выполняем второй запрос: select * from ingredients inner join meals_ingredients where meals_ingredients.meal_id IN (...тут список полученных на первом шаге id)
- разгребаем полученные данные по конкретным meal_id.

Немного более извращенный - сериализовать список использованных ингредиентов в отдельное поле блюда (например, тип text). При этом в базах, отличных от mysql, можно будет еще и отлично искать по этому полю. Этакий noSQL в условиях, максимально приближенных к боевым.

Фишка в том, что классическая нормализация many-to-many заранее учитывает тот факт, что первичные ключи могут (внезапно!) меняться. На практике же это ооооочень редкий случай.

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

Так что, как говорится, не Коддом единым.