Я бы посмотрел не только на скорость, но и на функциональность. Кому интересно, если это быстро, если это слишком сильно ограничивает тебя, чтобы быть полезным. Например, что, если вы хотите просмотреть заказ дважды (возможно, при первом отклонении чего-либо)? Или что делать, если вы обрабатываете заказ на две части? Если у вас не будет бизнес-кейса, почему у вас никогда не будет кратных из них, я бы предложил ваш второй вариант.
Кроме того, не забывайте, что обратное тоже может быть правдой. Например, один человек может обрабатывать три заказа одновременно. Или они могут одобрить три заказа одновременно. Может быть, этого не происходит сейчас, но вам нужно оценить будущее. Убедитесь, что модель базы данных работает для вас и ваших вариантов использования.
Наконец, когда я сомневаюсь, я обычно выбираю расширяемую модель. Я редко сталкиваюсь с тем моментом, когда я бью себя за то, что у меня слишком нормализованная структура базы данных (я не преувеличиваю), но я сталкивался с рядом моделей, которые меня бесили, потому что они не работали с (теперь изменено) варианты использования, которые они должны поддерживать.
Что касается скорости, чем больше у вас присоединений, тем медленнее она будет идти. Тем не менее, мы не говорим о больших проблемах со скоростью, если ваша база данных невероятно велика. Делайте свои индексы правильно, и вы, скорее всего, никогда не заметите разницу.