Структура БД - вопросец

Spear

почемучка
Структура БД - вопросец

Здравствуйте,
я сейчас прорабатываю структуру БД, появился такой вопросик:
на портале будет некий справочник по различному ПО,
у каждого ПО может быть куча параметров, от необходимых системных требований и официального сайта до различных спец. параметров.
по некоторым их них необходимо реализовать поиск, неккоторые же будут только отображаться в информации об объекте,.
Реализовать я это, пока что, удмаю так:
делаю 4 таблицы.
1 таблица это библиотека парметров, со стректурой:
айди_параметра / название
например:
1 / homepage
2 / screen_resolution_1024_768
3 / sound_51
ну, например.

2 таблица - это связть параметров, по которым может выполняться поиск,
все данные - только числа.
структура:
айди_объекта / айди_параметра
например, объект под номером 8 поддерживает разрешение 1024х768 и звуковую систему 5.1:
8 / 2
8 / 3

3 таблица - библиотека параметров, по которым поиск выполняться не будет,
структура:
айди_параметра / название
например:
1 / официальный сайт

4 таблица - это уже параметры уникальные для каждого объекта (не всегда, конечно).
структура:
айди_объекта / айди_параметра / значение
например, официальный сайт объекта номер 743:
743 / 1 / http://www.homepgae.com/~some

понятно, что записей в 1 и 3 таблицах будет не очень много (в сумме, может, под 30),
в таблицах связей, конечно, поболее. Предполагается около 2 млн в сумме.

Подскажите, пожалуйста, насколько такая реализация будет верной?
 

White Rabbit

белый кролик
Я думаю, лучше добавить каждому параметру флаг поиска.
Т.е. структура такая:
таблица options
option_id | option_name | allow_search ... все постоянные при описании самих параметров поля.

таблица объектов: objects
object_id | object_name ... и т.д

таблица соответствий параметров объектам: object_options
object_id | option_id

Тогда искать можно по ...WHERE object_options.object_id = '$id' AND ... AND AND options.option_id = object_options.option_id AND options.allow_search = 1
 

Spear

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

а для второй группы параметров нужно ещё и задавать значение.

Ну вот, например.. я постараюсь объяснить пдробнее, на примере.

Есть какое-то ПО. Официальный сайт производителя: http://www.mysterysoft.com,
для использования ПО нужна система WinXP/2000, поддержка Directx 9.
Это ПО поддерживает звуковую систему 5.1 и разрешения 480p, 720p, 1080i, Widescreen.
(это пример от "фонаря", я незнаю что это такое вообще я тут придумал :), просто первое что в голову пришло).

Из всех этих параметров при поиске будет использоваться только разрешение и звуковая система. То есть пользователь входит в поиск в разширенный режим и в опциях поиска ставит галочку в чекбоксе напротив полей Sound 5.1, 480p, 720p, 1080i, Widescreen.
То есть достаточно чтобы в БД была запись что в свойствах такого-то объекта есть привязка к параметру Sound 5.1, например это параметр под номеров 234.

То есть, так как это представил себе я, то достаочно 2 таблиц. В первой просто описаны все параметры, а во второй идет привязка 'объект-номеР_параметра', то есть задавать тут какие-то дополнительнвые величины не нужно будет.

А вот свойства типа официального сайта, используемой версии direct X и прочих каких-то свойств объекта нужно выносить в отдельную таблицу (наверно, я же сам по этому и спрашиваю т.к. не уверен), в отдельную потому что тут уже будет недостаточно лишь привязать объект к параметру, а нужно будет ещё указывать данные параметра.
То есть, предположим что параметры directx, os, homepage имею номера 1,2,3 в таблице additional_info_library, назовем её так, а номер нашего объекта, этого космического девайса :) будет 108.
и чтобы сохранить все допольнителньые свойства объекта мы записываем данные в такую таблицу (связь параметр+объект+значение):
1 | 108 | DirectX9
2 | 108 | WinXP\2000
3 | 108 | http://www.mysterysoft.com

-~{}~ 19.03.06 13:36:

White Rabbit
просто в предложенном Вам варианте не предусмотрены конкретные значения некоторым свойствам.

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

-~{}~ 19.03.06 13:38:

Если у кого есть возможность и время - посмотрите, вот тут - http://hardware.gamespot.com/Microsoft-Xbox-360-15016-S-4-4
это страница, на котиорой показаны характеристики лишь одного объекта. Как видите их много. Но это лишь пример.
 

White Rabbit

белый кролик
Допустим, есть мегадевайс c id=1;
Делаем таблицу objects:
object_id | object_name ... и т.д. Всё, что есть общего у всех девайсов.

У девайса есть набор параметров со значениями:
Таблица relations:
relation_id | option_id | object_id | option_value ... + все свойства, описывающие
отношение данного параметра к данному девайсу.
Про option_value, я, кстати забыл в предыдущем посте;)

Далее.
Название параметров их ID(для предыдущей таблицы) и прочие
свойства, описывающие параметр абстрактно от девайса,
храним в таблице options:
option_id | option_name ...

Девайс поддерживает WindowsXP, Windows2000, разрешение 1024dpi, 1280dpi, звук 5.1, 7.1, DirectX 8, 9, url производителя http://somesite.com, итд.

Заполняем:
objects:
1 | Мегадевайс

options:
1 | resolution
2 | directx
3 | os
4 | url
5 | sound

relations:
relation_id | option_id | object_id | option_value
1 | 1 | 1 | 1024dpi --Разрешение
2 | 1 | 1 | 1280dpi --Еще одно
3 | 3 | 1 | WindowsXP --OS
4 | 3 | 1 | Windows2000
5 | 2 | 1 | 9 --DirectX
6 | 4 | 1 | http://somesite.com
7 | 5 | 1 | 5.1 --Звук
8 | 5 | 1 | 7.1

Можно, например найти все девайсы, у которых
значение DirectX == 9, или больше 8,
или url== http://somesite.com,
или и то и другое(как я понял, именно это и требуется)
Можно выбрать все параметры для девайса(напр, разрешение,
даже если их несколько)

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

Что касается того, какие параметры будут доступны для поиска,
и их range(сорри за ломаный русский;) ),то, имхо,
это лучше вообще не ставить в зависимость от структуры БД.

Использовать для этого отдельную таблицу., слабо связанную со всем остальным
на том основании, что признак, что параметр используется в поиске, и допустимые значения для поиска не имеют никакого отношения ни к девайсам, ни к параметрам для конкретного девайса,
напр.:
табл. search_values:
----------------------------------------------
search_id | option_id | option_value
1 | 1 | 1024dpi
2 | 1 | 1280dpi
----------------------------------------------
Что-то вроде того.

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

Единственное, что меня лично беспокоит в данном случае,
это количество записей в таблице relations.
Но от этого никуда не денешься.
Так или иначе придется где-то хранить эти данные.

-~{}~ 19.03.06 17:36:

[offtop]
Гы. Ничего себе, написал;)
[/offtop]
 

Spear

почемучка
White Rabbit
большое спасибо за такой полный ответ!

Единственное, что меня лично беспокоит в данном случае,
это количество записей в таблице relations
Вот и я об этом. Потом и думал разделить все свойства на две таблицы - данные одной из которых будут использоватьсяч при поиске, а вторая только для вывода на экран.

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

Хотелось бы улышать ещё мнения ;)

-~{}~ 20.03.06 23:01:

Люди, помогите, пожалуйста
 
Сверху