dr.riddle написал: Но если расширять функционал и делать что-то помимо статусов, то разделять товары на отдельные заказы можно только через обработчик событий?
А зачем? Вы же можете прикрепить статусы товаров прямо к товару в заказе. У Вас отдельная оплата по каждому заказу? Не вопрос - делите оплату на N частей (по 1 на каждый товар) и отмечайте ID оплаты для товара в свойствах товара. Весь ваш кейс можно реализовать без разделения.
Вы о пользователе подумайте - он же только 1 номер знает, а если кучу привязок и перелинковок делать - это ад.
dr.riddle, если Вам так уж нужно, чтобы у товаров были статусы и менялись именно они, то в целях обратной совместимости и отсутствия будущего геморроя (поверьте моему опыту), лучше сделать полу-костыль. Не скажу что будет сильно удобно в плане обработки, но средства на обновлении оно сэкономит не мало.
1) При создании заказа к товарам добавляйте свойства и их дефолтные значения 2) Сделайте страницу, где по номеру заказа вы бы доставали товары и их статусы (стандартный грид, благо закроет проблему) 3) В самом заказе, при помощи встраиваемых средств (на событиях) либо добавляйте код на отображение, либо ссылку на переход к товарам заказа
Можете конечно отдельную страницу сделать для отображения заказов по товарным позициям.
archon007 написал: Было упоминание от одного из пользователей:
Да, и это количество с тех пор увеличилось до 9 тысяч таблиц. На самом деле, рекомендую использовать только в крайнем случае - потому как хоть они и есть, но допиливать придется много - например не работает (по крайней мере не работало) сохранение UF через объекты, да и в выводе полей нет.