Проектировать схему хранения данных следует исходя из кейсов их дальнейшего использования, объема и скорости добавления данных.
Например, я бы задался след вопросами:
1. После того как я положил в базу товары что мне с ними надо будет делать?
Если просто показать названия заказанных товаров в странице админки, то достаточно будет денормализованной формы хранения.
Если же на основании данных, которые содержит в себе заказ хочется строить динамическую аналитику - например, в админке товаров простым запросом показывать сколько раз этот товар покупали, либо что то в этом духе - то будет удобнее нормальная форма. Ну либо обновлять какой то счетчик заказа у товара, тогда нормальная форма не нужна.
2. Сколько строк в заказе будет в среднем? если очень много позиций в заказе - например по 1000 и заказов много - то очень скоро объем данных в таблице с элементами заказа будет большой, и выборка по нему будет деградировать. Если данных очень много - то лучше будет денормализованная форма. Если данных мало - то наоборот.
и т.д.
И я бы лучше использовал в базе для хранения списка ID не строку с разделителями, а JSON - поле такого типа есть в Postgres, с Mysql давно не работал - но кажется тоже есть. Либо тупо в текстовое сохранять json. Если такой тип данных поддерживает база, на него можно даже строить индексы. Либо если есть, то можно рассмотреть тип данных Array если поддерживает БД.
p.s. Реляционная база данных не обязывает хранить все только в нормальной форме - ее мощь как раз в том, что можно хранить и в нормализованной форме и в денормализованной.
Простой
