Таблица состоит из 2-х столбцов.
В колонке 1 - свойства товара
В колонке 2 - цена (индекс)



ОПИСАНИЕ ПРОБЛЕМЫ:

Когда клиент выбирает товар (печатная продукция) он должен выбрать отличительные свойства, например:
- размер визитной карточки
- метод печати
- тип бумаги

В зависимости от комбинации выбранных опций - обуславливается цена.

К ПРИМЕРУ:

если выбранный товар имеет:
• стандарт. размер
• полноцвет
• глянец

то его цена (индекс) будет: 1


ТАБЛИЦА ДЛЯ УПРОЩЕНИЯ:



ЗАДАЧА:

Имеем свойства товара:
a, b, x

Надо найти его цену (которая будет равна 1).


ЗАПРОС (который работает):



Тему я уже открывал ранее:
http://deforum.ru/forum/viewtopic.php?t=44048

и мне сказали что у меня неправильная структура и надо описать саму задачу. На том топик и закончился. Поэтому вот открываю еще. Можно ли сделать иначе (и лучше) чем сейчас?

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

В этом случае выборка делается по хэшу, что существенно ускоряет запрос. И к хэшу можно привязать несколько других свойств - например, изображение.

diezel2005,
с хешами никогда не работал, надо будет посмотреть.
По английски это HASH называется?

Свойства не обязательны к заполнению.
Их можно сделать обязательными, включив "NULL" как одну из опций свойства.

Но товар может менятся: свойства могут добавляться и удаляться.
В идеале цены не связанные с удаленным свойством должны остаться.

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

Цитата:

Но товар может менятся: свойства могут добавляться и удаляться.

Строго говоря, в таком случае тебе нужно будет сначала пересчитать хеши без удаленного свойства, а потом уже чистить саму базу.
Вообще, хэш - это общий случай. Тебе могут помочь даже упорядоченные комбинации свойств в поле Varchar. Как пример - реализация свойств текстуры и цвета на http://www.myfoofstore.com/fuf-chaise-lounger-p-57.html - здесь, зная что в комбинации свойств первым всегда идет текстура, затем цвет, я не заморачиваюсь с просчетом хешей, а просто храню их в виде "([код текстуры], [код цвета])". Естественно, что в базе это храниться вместе с кодом товара и, скажем, картинкой-примером.

diezel2005,
попробую суммировать:

Просто перечислить свойства через запятую + знать порядок свойств.

Некоторые продукты будут иметь свои уникальные свойства, которых другие продукты не будут иметь.
Поэтому в базе сделать таблицу, где порядок будет описан для каждого продукта (естественно индексами), например:

Порядок свойств не критичен для нахождения цены - потому что цена все равно будет искаться по уникальной комбинации цыфр.
Но логика заложенная в упорядочивании свойств - ускорит просчет при удалении свойства и добавления новых. Плюс удобно просматривать БД.

Теперь надо подумать о целостности БД и возможных ошибках.

Например ошибка, где продукт имеет такие свойства:

С точки зрения уникальности - эти две строки уникальны. Значит при поиске цены - надо будет тоже учитывать прорядок свойств (на всякий случай).

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

Но чем мне нравится твоя схема:
- скорость нахождения цены
- компактность таблицы (вариантов)
- легкое чтение неворуженным глазом (даже такие ошибки легко выявить простой сортировкой )
А что бы проверять целостность, пару триггеров можно написать.

Ну, тут уже вопрос приоритетов.
Для меня всегда критична

Цитата:

скорость нахождения цены.

поскольку не хотелось бы обновлять код при резко возросшей нагрузке на сайт. IN - не самая быстрая проверка для частого использования, поэтому мне проще один раз вычислить что-то в коде, а потом это искать, чем делать ресурсоемкие запросы для нахождения элемента.
Вопрос целостности, наоборот, критично не стоял, поскольку основная база - на сервере или рабочем месте. Когда я начну писать 100% веб-сервисы - тогда уже я буду задавать вопросы про проверку целостности