>Вы хвастаетесь?
Нет, пытаюсь сказать вам, что в данном вопросе не имеет значение ни ОСь, ни СУБД, ни что-то еще. проудкты не указваю, что бы топик не правратился в религиозные войны, по поводу, какая СУБД быстрее, "нормальнее".

>Это не постановка задачи.
Постановка задачи была в первом моем посте.

>Реализацию, при которой нужно менять структуру данных при незначительном
>увеличении объема данных - в ведро.
что сейчас и делается. и ищется вариант корректной структуры БД. Требования к стуркутуре - выдавать максимально быстро результаты запроса при прочих равных условиях.

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

>храните их в разных tablespace.
Т.е. для каждого товарной группы своя таблица?

>Сорри - к Вам то как раз никаких претензий.
И вам - извините.

>У товарной линии есть перечень характеристик, но у них нет значений.
>Значения есть у характеристик товаров.
Верно, согласен.

>Кстати, Вы ланируете давать возможность один тип характеристик
>использовать в разных товарных линиях?..
>Это еще более усложнит структуру :)
Я это понимаю - все характеристики уникальны.

>Правильное количество псевдонимов таблицы - это здесь зачем?
Пример:
Таблица характеристик товара
ID товара
ID характеристики
поле1 число
поле2 текст
поле3 вещественное
полеn.....

Я должен создать запрос на поиск товара по харктеристикам:
Т.е. в условии я должен проверять перечень полей, в которых хранятся значения характеристик.
Как должен выглядеть запрос??? Какое поле проверять с искомым значением? Если все характеристики хранятся в поле1, то я должен создать псевдонимы, что бы вытянуть все характеристки... Другуим словами, для каждой товарной линии я должен построить соотвествующие конструкции... или я не прав???
----------------------------------------
Артисты не приехали, приехали цыгане

>Ну типа это и есть пропагандируемый тупой вариант.
Тупой???? Я описывал то, как я понял предлагаемый вами вариант.

Откуда вы узналаи, что нужно проверять поле value ? Я правильно понимаю, что:

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

>Ну я запишу это где-нибудь рядом с ИД характеристики
>в таблице характеристик товарных линий
Что именно вы запишите?

Моделирую ситуацию.
Товаров 5 000 000
Для всех них кол-во товарных линий 500
Каждая товарная линия характеризуется 10 параметрами. Вы осуществляете поиск по характеристикам товарной линии. у которой все поля - целые числа, т.е. вы объеденяете таблицу атрибутов с самой собой 10 раз.
Считаем кол-во строк в таблице атрибутов:
5 000 000 * 10 = 50 000 0000 - размер таблицы атрибутов товаров.
в процессе объединения манипулируем с таблицей неслабых размеров.

В случае разделения свойств манипулируем таблицей состоящей всего навсего из строк для данной товарной линии. Только таблиц конечно же не 1, а 500.


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

>Почему для товара обязательно все атрибуты будут заполнены?

У каждой товарной линии свои нормированные атрибуты, по которым нужно производить поиск. И тип значнения атрибута - различный.

Насчет большого кол-ва записей-товаров. Вы представляете, сколько один завод, например, по производству запчастей к технике, производит позиций товара в ассортименте???? Так я вам могу сказать - от 3 000 до 3 000 000.
----------------------------------------
Артисты не приехали, приехали цыгане

>Это наводит на мысли о том, что Вы собираетесь систему складского и
>производственного учета для такого завода разработать. Я ошибаюсь?..
Не знаю, что вы вкладываете в понятия "складской и производственный" - это будет проект по систематизации продукции основных заводов-изготовителей.

gardenmanМожет все-таки посмотреть на поля типа XML?...
Не понимаю, о чем вы говорите, более того, считаю применение XML в данном случае неуместным. Если я не прав - прошу поправить меня примером.

Я это уже понял. Просто думал, что есть готовые решения и я буду изобретать велосипед или прикручивать костыли.
Кстати, я начинаю думать в сторону разделения характеристик по таблицам соотвествующих типов данных.
В любом случае не составит большого труда изменить структуру БД и потестировать предложенные подходы.
Еще раз спасибо за идеи.
----------------------------------------
Артисты не приехали, приехали цыгане