up!

Den1xxx, думаю любой вариант подходит, но надо учитывать и другие параметры
какие варианты использование диллерских цен будут, к примеру - сортировка товаров по цене для диллера, в таком случае хранить в одном поле невыгодно
кол-во товаров в базе, кол-во диллеров, расширяемость самой системы

а точно надо иметь разные цены на товары, а не скидку для конкретного диллера?

Клиент утверждает, что:
1. Кроме розничной, будет (уже есть) 4 ступени дилера — у каждого своя цена на конкретный товар.
В перспективе при наборе, скажем, на 1000 у.е. простой покупатель становится дилером №1, при наборе ххх — №2 и так далее.
Клиент утверждает, что 4 дилерских цены — оптимально и больше не будет. Но мы-то с Вами знаем, что аппетит приходит во время еды.
Так что надо и на будущее думать.
2. Снижение на процент пришло мне в голову сразу (конечно не хотелось заводить по 5 цен на каждый товар, проще же скидку посчитать на весь каталог), но было сразу отвергнуто клиентом.
3. Количество товаров в БД — 356. Это запчасти для ремонта. Могут вырасти и до 500, но не скоро. В любом случае не на порядок.

при таком количестве думаю проще добавить просто поля в таблицу товаров, даже если появится новый уровень дилера, точно также добавится еще одно или несколько полей

Типизация делается очень просто - если где-то используется подобный тип данных то он выделяется отдельно(заводится еще одна таблица со связью 1:1 или 1:N из разных сущностей). В ином случае лучше завести N полей в основной таблице и хранить все в ней.
Сами по себе доп. поля в таблице оверхеда не создают(экономия на спичках).
Т.е. решение 1 - если цены это свойство товара
решение 2 - если цены это свойство товара и еще чего-нибудь отличного от товара по набору полей(сложно это представить - например если делается наследование вида Товары1, Товары2, Товары3 причем они по структуре целиком разные и лежат в разных таблицах) - тогда лучше цены хранить отдельно просто потому что так удобнее этот зоопарк поддерживать. Обоснование нормализации вообще есть и было только одно - экономия на данных. Т.е. вместо того чтобы каждая различная сущность ссылалась на различные цены - делается одна запись цены, и на ее id ссылаются различные сущности. В итоге вместо 3 записей получается 1. На самом деле то же самое в плане скорости выборки достигается использованием BTREE-индекса. В противном случае - это окажется тупо как минимум лишним JOIN'ом - более сложными запросами, накладными расходами(даже с учетом индекса) и т.п.

При проектировании БД используются два понятия - название(имя таблицы) и тип данных(поля таблицы). Их смешивание в любых вариациях означает денормализацию.
Но это вообще, у Вас с ценами ситуация крайне простая и предельно ясная.

Замечание модератора: Эта тема была закрыта автоматически ввиду отсутствия активности в ней на протяжении 100+ дней. Если Вы считаете ее актуальной и хотите оставить сообщение, то воспользуйтесь кнопкой или обратитесь к любому из модераторов.