А что: этот пример прекрасно ложится на определение, данное нами с funikovyuri.
несоставной ключ имеет смысл ввести если эта таблица не просто реализует связь - но, так же, соответствует какой-то сущности в системе С поправкой: наверное, все же не в системе, а в реальном мире. Строка заказа сама по себе не соответствует какой-то сущности реального мира (ибо без заголовка заказа смысла не имеет). Поэтому можно не вводить несоставной ключ.
С другой стороны, на строку заказа может ссылаться строка оплаты, например (представим, что каждую строку закрывают отдельной оплатой). В этом случае несоставной ключ уже смысл имеет.
В двух последних КИС, с которыми мне довелось работать (в одной и той же компании, кстати) были применены разные подходы, и они работали по-разному (то, что делалось быстро в первой КИС, происходило с большим количеством join'ов - и медленнее - во второй, зато вторая работала быстрее в других случаях).

Ну, то есть мы рассматриваем вопрос не совсем религии, как я раньше выразился, а скорее вопрос выбора с учетом преобладания в системе одних задач над другими, оптимизации, так сказать ;-)