Ваш подход подходит для ваших текущих требований, если две сводки сохраняют разделенную скидку, индексы будут обеспечивать скорость выборки данных, но недостатком является то, что вам потребуется запросить из 2 таблиц, чтобы получить все скидки (было бы немного медленнее).
Ниже приведена просто возможность, вы можете ее игнорировать, но попробуйте прочитать ее
Но я бы хотел упомянуть несколько возможностей
- что, если владелец магазина захочет применить скидки к указанному бренду c? (предположим, что вы согласны добавить эту функцию), например, он хочет, чтобы на все продукты Raymond была скидка? В текущей схеме вам нужно будет найти все продукты с помощью
brand_id Рэймонда и добавить отдельные записи в таблице discount_product для всех этих продуктов (не очень сложно, но данные в таблице станут очень большими) или создать новый сводный стол для брендов. - Аналогичным образом, если продавец хочет получить скидку на все рубашки Raymond (брендовые) (категория I), опять же нет другого выбора, кроме как применить скидку к отдельным товарам.
- И Что делать, если скидка только для определенного пола или возрастной группы?
- Или размер одежды
(хорошо, я знаю, что я все это слишком обдумываю, так как шансы на такие требования малы. Если так Есть много требований, может быть, лучше использовать библиотеку или перейти на WordPress / Magento).
Поэтому я хочу сказать, что присоединение этих скидок к отдельным продуктам кажется простым выходом (если вы не t создать сводные таблицы для каждого типа скидки), если вам нужна большая гибкость (что лично мне кажется важным т тоже. Гибкий проект легче расширить, и люди, которым придется работать над проектом в будущем, будут вас гораздо меньше проклинать) не лучше ли вести единую сводную таблицу и дифференцировать их по типу? (aaargghhh звучит как боль ...... но так ли это?)
Хорошо Laravel имеет решение для вас, Polymorphi c Отношения . Да, теперь вам нужна только одна таблица для опорных точек, и пусть Laravel делает волхвы c (ну, в ней просто хранится имя модели с пространством имен в столбце типа). Это становится намного сложнее, если вы не хотите использовать Laravels Polymorph, вам понадобится таблица для типа, сохраните каждый тип в этой таблице, а затем поместите внешний ключ в сводную таблицу.
Но прежде чем прыгнуть и выбрать следовать этому методу, подумайте, действительно ли он вам понадобится? (Я признаю, что большая часть этого даже не в вашем вопросе, я только упомянул об этом из-за того, что я переосмыслил это) Вы уверены, что вам понадобятся только эти два типа скидок? Не могли бы вы просто отклонить какие-либо запросы для других типов? Тебя не волнует, кто бы ни убрал твой беспорядок? Если ваш ответ «да», просто придерживайтесь текущей схемы.
Итак, выберите то, что вам кажется более подходящим