Имею:
1. Ассортимент товаров на данный момент 5 000 000 в ближайшем неопределенном будущем максимум 15 000 000 позиций.
2. Все позиции можно разделить на товарные линии, которые имеют нормированное кол-во свойств. Кол-во свойств каждой товарной линии конечно (3-10), кол-во товарных линий порядка 500-700.
4. Свойства имеют числовое/текстовове значение или ограниченное кол-во вариантов.
5. Поиск должен производится по любому из свойств или по совокупности свойств.
6. На данный момент свойства товарных линий нормированы частично.
7. Кол-во пользователей у системы на данный момент от 100-200 в минуту. Но будет расти - проект будет выкладываться в сеть.

Требуют:
1. Осуществлять поиск по характеристикам.
2. Выдавать эти характеристики при поиске позиции по ключу.
3. Описывать характеристики товарных линий и добавлять характеристики в БД. (Когда-нить это описание закончится и надобность в пункте отпадет.)

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

В голове два варианта:
1. Сделать одну таблицу:
ID товара
Характеристика1
Характеристика...
Характеристика10
В в полях характеристик хранятся значения или ID варианта значения характеристики. Так же принимается положение о том, какие поля таблицы каким характеристикам соотвествуют, и потом при поиске указав ID товарной линии и связав по нему ID товара осуществить поиск по характеристикам.
Минусы - много пустых полей, нужно согласовать типы данных разных товарных групп с типами данных столбцов
Плюсы - относительно небольшое кол-во строк.

2. Сделать для каждой товарной линии свою таблицу:
Минусы - нереляционно???, множество таблиц.
Плюсы - нет пустых полей, небольшое кол-во строк.

В силу отсутствия качественных знаний и опыта по проектированию БД не могу решить описанную вышу проблему и определиться с вариантом.
Прошу подсказать/ткнуть носом/RTFM:
1. Дополнительные, неозвученные варианты решения?
2. В чем протупил с теми идеями, что озвучил?
3. Если идеи имеют право на существование, то подскажите, пожалуйста, возможные грабли в реализации?

----------------------------------------
Артисты не приехали, приехали цыгане

>Опять пошло.Модель Тенцера: прослушивание №100.Почему никто не пользует поиск...
Я с превеликим удовольствием пойду в Google, но я не знаю ключевых слов, по которым искать. Буду признателен за "волшебные" слова.
----------------------------------------
Артисты не приехали, приехали цыгане

DogenСделать таблицу товаров, таблицу товарных линий, таблицу атрибутов товарных линий (будет использоваться как справочник при динамическом построении интерфейса карточки товара), таблицу значений атрибутов товаров. Чего сложного-то.

А значения характеристик, привязанных к товару как хранить?????

>Ищите на этом форуме по Тенцер - вполне представительное обсуждение.
Уже ищу, спасибо

----------------------------------------
Артисты не приехали, приехали цыгане

>Вот и храните все ваши товары в XML.
Задача "хранить данные" - вторична, потому что первичная задача - цель. А цель - осуществлять максимально быстрый поиск... XML для такого большого кол-ва данных не подходит...

>Получить набор этих значений....
Это я понял.

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

>Мне, честно говоря, неохота рисовать структуру...
Не надо всю струкутур - только таблицу привязки атрибутов товара к конкретному товару.
----------------------------------------
Артисты не приехали, приехали цыгане

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

Какое из решений???

>Имхо если для Вас очень критичны объемы таблиц
Не критичны. бОльший размер таблицы => бОльшая нагрузка на БД => бОльшее время выполнения запроса. Ясное дело, что это понятие относительное...

>Можно поступить более последовательно, сделать одну таблицу для целых....
Насколько глупо и некорректно звучит вариант создания таблицы атрибутов товаров для каждой товарной линии?

Модель Тенцера не подходит - она гибкая и относительно медленная по сравнению с тем же ROT. Роюсь дальше...
----------------------------------------
Артисты не приехали, приехали цыгане

>переходите на нормальную архитектуру, СУБД и платформу.
я не знаю архитектуру, которая называется "нормальная".
я не знаю СУБД, которая называется "нормальная".
я не знаю платформы, которая называется "нормальная".
Есть задача, нужна модель ее решения.... Эту модель и спрашиваю. Ответ в стиле "нормальная СУБД" никому ни о чем не скажет. Для кого-то и Access - самая совершенная СУБД.

>Не будет вопросов по поводу детских объемов данных.
Конструктивно можно ответить? Например:"Кол-во строк с которым вы работаете не считается большим и вам не стоит переживать по поводу скорости обработки запросов, при условии, что вы будете пользоватся такой-то СУБД. Имею опыт работы с такой СУБД и с кол-вом записей, которые больше ваших раз в 100." Простите, что поучаю, но от ваших постов толка - 0.

>А мне как-то вот не удалось телепатически определить
>ни бюджет разработки, ни операционку, ни саму БД автора топика.
Зачем вам это знать?Или принципы реляционности у каждой СУБД глобально различны? А ОСь-то вам чем не угадила????

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

>2. Мы у себя сделали в таблице атрибутов одно поле для integer, одно для
>даты, одно для double, одну текстовую строку... работает достаточно быстро.
>Можно поступить более последовательно, сделать одну таблицу для целых,
>другую для вещественных, третью для дат, четвертую - для блобов... в
>общем, по количеству нужных Вам типов данных. И в таблице атрибутов
>хранить тип значения атрибута и ключ таблицы значений (1:1 получается?).
В такой ситуации я должен знать, из каких полей я должен выбирать характеристики для данной товарной линии, так же должен знать кол-во этих характеристик, что бы составить правильное количество псевдонимов таблицы. или я что-то не понимаю? Буду признателен, если уточните.