Какое проектирование БД более верное?

Discounts нужно связать двумя "многие-ко-многим", это делается при помощи двух вспомогательных таблиц. Таким образом, у вас один Discount может
1) не иметь связи ни с товаром ни с категорией
2) быть связанным с множеством товаров
3) быть связанным с множеством категорий
4) быть связанным как с несколькими товарами, так и с несколькими категориями
Кстати стоит иметь в виду, что в реальной жизни зачастую "скидка на скидку" неприменимо.
Посему лучше заблаговременно подойти к "правилам скидок".
Как один из вариантов:
1. таблица групп(категорий) скидок rules_groups (id, descr, [ordering])
2. таблица "правил применения скидок" rules(id, group_id, descr, ordering, percent [условия])
Подразумевается что из каждой группы может быть применено одно правило (первое по порядку). 
тогда соответственно (упрощенно)
select top 1 percent from rules where group_id=xx and (кучка условий на соответствие правилу) ORDER BY ordering 
притом колонок условий для правил может быть множество и оно легко расширяемо. Навскидку от общих типа категорий, товарных групп, цветов, остатков/запасов/оборота, ABC классификации  и т.п., заканчивая сроками истечения годности, количеством и даже данными контрагента, его группы и категории.
По вкусу можно на уровне групп или правил предусмотреть признак мультипликативная (умножение на коэффициент) это скидка или аддитивная (вычитание суммы) и "за единицу" или "за партию".
Ну и с учетом танцев с финокруглениями на тему НДС - неплохо иметь признак "С НДС"/"Без НДС" (но это подразумевает ньюансы хранения цен.
Еще элементом тюнинга будут флаги или коэффиценты на предмет применять ли правило при снижении отпускной цены ниже себестоимости"