Сложная структура

[Sergey_2003]

Сложная структура

Доброго времени суток ALL.

Задача вот какая:
1. есть таблица стан
2. есть таблица сайтов
3. есть таблица категорий
4. есть таблица товаров (около 20 000 наименований)
вопрос в следующем: как организовать все это при условии что одна и та же позиция может одновременно находиться в нескольких странах, сайтах, категориях.

Заранее благодарен.

 

[DimbIch]

Re: Сложная структура

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

какая позиция ??? позиция чего ????

 

[Sergey_2003]

один товар

 

[Tsatur]

Каждому товару присвой уникальный номер и вписывай номера в тыблицы стран, сайтов и категорий...

 

[DimbIch]

я бы сделал каждой стране сайту и категории дал свой уникаьный ID
и таблица товаров была бы такой

product_id
product_name
country_id
site_id
category_id

или вроде того....

 

[Sergey_2003]

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

я уже это проверял управлять этим всем не просто, голову уже сломал.

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

-~{}~ 30.10.04 01:28:

что то типа ip/mask

 

[Screjet]

И почему ты думаешь, что "некий хещ" будет занимать меньше места в таблице?

Если уж действительно напряг с дисковым пространством, то сделай типа промежуточной таблицы
address {
id
country_id
city_id
site_id
}
Куда будешь складировать уникальные адреса.

А вообще реализую такие многомерные структуры в деревьях.

 

[Sergey_2003]

и так давайте разобьем по приоритетам:

1. категория - обязательна (продукт может небыть в стране, сайте но котегория ему присваеваиться при рождении, а может и не одна);
2. страна - опционально (потом уже решают в какой стране, странах, можно продавать этот продукт);
3. сайт - опционально (на каких сайтах-партнёрах этой страны предлагать этот продукт);

при предложенной стуктуре промежуточной таблицы:
{
id
category_id
country_id
site_id
product_id
}
(modify)

при добавлении ещё одной категории || страны || сайта количество записей очень увеличивается, я же ищу путь к
{
id
hex
product_id
}
где hex является представлением категории(й), стран(ы), сайта(ов) при котором количество записей неизменно и при добавлении ещё одной категории || страны || сайта нужно будет делать update hex

 

[Screjet]

Сделай реляционно М-М и не заморачивайся.
category_location
{
product_id
category_id
}
site_location
{
product_id
site_id
}
... etc

 

[Sergey_2003]

в данный момент на один из сайтов приходится около 7000 посетителей в день, сколько запросов к БД даже представить трудно. когда я взялся за это был лиш 1 сайт и 1 партнер сейчас 7 сайтов и 5 партнеров, прошло 5 месяцев. судя по динамике роста это скоро вырастет во что то монстроидальное так лучше 1 раз заморочиться чем потом все время разгребать и дело даже не в том , что будет занимать меньше места в таблице а в производительности самой БД.

 

[advocat]

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

 

[Sergey_2003]

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