kretsu

я думаю (и это решние используется в реальных проектах) вам надо таблица для календаря, в бизнес системах это еще делается, чтоб отмечать рабочие/не рабочие дни.
связав вашу таблицу с таблицей календаря можно нормально получить "пропуски"
одна проблема - календарь надо поддерживать.

Я не думаю, что правильно начинать проект с дизайна базы.
Опишите сначала объекты которыми вы будете оперировать: пользователь, топик, сообщение и тд
Опишите все свойства объектов
Далее опишите отношения между ними
Потом напишите сценарии использования
Т.е. предлагаю для начала попробовать UML

А потом уже можно все это пробовать "мапить" на базу. С другой стороны, современные фреймворки позволяют это делать автоматический. Правда часто получается мусорка. Но всем пофиг на это, пока работает и не тормозит.

Как по мне совершенно не нормальная структура:
Товар в принципе ничего не должен знать о поставщике.
Цена в таблице товара, цена чего? стоимость товара от поставщика или то, по чем мы будем продавать? не должно быть этого поля у товара
Ордер тоже не очень должен что либо знать о товаре.
По мне, структура должна быть примерно такой:

Поставщики:
id
название

Товары:
id
название

Ордер:
id
... (всякая общая фигная типа даты и тд)
поставщик id - если ордер может быть только от одного поставщика

Позиция_Ордера:
id
Ордер id
Поставщик id - если каждая позиция ордера может быть от различных поставщиков
Товар id
Кол-во
Цена за позицию

Это примерная структура и не касается вопросов образования цены , единиц измерения, амортизации товара и тд

ну в общем случае (не учитывая синтаксис MySQL) примерно так

update tableName
set price1=300,
price2=300

commit

но может я не понял проблему?