Согласен со Станиславом, база данных спроектированна из рук вон плохо, учитесь делать так как нужно и слушайте что вам опытные товарищи говорят - больше нервных клеток сбережете.
Упрямство это хорошо, но когда более опытный человек говорит вам это не правильно спроектированно, то стоит прислушиваться и не набивать кучу шишек на простых вещах.
Есть несколько Нормальных форм для баз данных. Каждая из них убирает некую избыточность. Минимум база должна соответствовать 3-ей нормальной форме, почитайте про 1НФ, 2НФ, 3НФ и 3,5НФ (или нормальная форма Бойса-Кодда или НФБК). Иногда проводят денормализацию, но для этого нужно понимать для чего и в каких случаях это делается.
Теперь о вашей структуре таблиц.
В вашем случае есть некий товар, есть категории (или группы, ваши видеокарты, кулеры и бог знает что еще) товаров. Вот вам две таблицы - Товар, Категория товара. Ну и связь между ними конечно же один ко многим так, что одной категории соответствует множество товаров, но один товар всегда соответствует одной категории. Если товар может быть в нескольких категориях (связь многие ко многим), то это делается через дополнительную таблицу. Итого имеем удобство добавления новых категорий товаров - добавляем новую категорию и при добавлении товара указываем к какой категории он относится. какие-нибудь теги тоже можно по такой же схеме организовать.
Далее, нужен нам заказ, делаем таблицу Заказ с полями кто заказал, когда заказал, иные примечания и поля, но не что заказал. Табличная часть заказа должна быть в отдельной таблице, где есть ссылка на товар (одну таблицу а не как у вас сейчас), количество, иные поля, и ссылка на заказ к которому та или иная позиция относится.
Если хранить корзину в базе то ее можно реализовывать примерно также, только там в кто заказал будет например идентификатор сессии клиента. Ну и указывать датувремя протухания значений в корзине и с течением времени удалять протухшие или накапливать статистику какие товары чаще всего добавляют в корзину.
Свойства товаров, как сказали, можно хранить в json или в xml, но это не удобно для фильтров каких-нибудь да и добавлять/редактировать значения свойств как-то не удобно - загрузи, десериализуй, измени/добавь, сериализуй и сохрани. Если они никогда не меняются и по ним нет поиска, то я бы сохранил как сериализованный в json или xml объект. Иначе тоже через таблицы, связанные с товаром связью. тут можно накрутить много, и группы свойств для каждой категории и всякое другое.
