Форум MySQL

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

Теперь не могу сообразить, как организовать составной товар?

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

Т.е. объект букет выглядит как-то так:

название => "sajdf"; описание => "werlklejgdfs"; фотографии => array(1,2,3,4,5); состав => array (       1 => array ('id_obect' => 1, 'count' => 7),       2 => array ('id_obect' => 17, 'count' => 3),       3 => array ('id_obect' => 24, 'count' => 1),       4 => array ('id_obect' => 11, 'count' => 1.3),     );

Как это можно организовать, подскажите?
_______
P.S. Ваше замечание
> 3. Если все вышеописаное вам показалось слишком простым, то не плохо будет хранить
> числовые, тестовые и списочные свойства в разных таблицах (указывая при создании
> свойства, каким значением оно обладает числовым, тестовым или списочным).
я принял на вооружение и типы свойств решил таки разделить ) Но "это" вписать не получается как-то.

Сроки ограничиваются потребностями желудка ) Т.е. заказчик - я, но кушать всерн хочется не к концу лета ))))

Все, пока вроде все ясно. Есть над чем подумать! Еще раз спасибо!

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

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

PS Понятное дело, что все реализовывать не обязательно, или не обязательно реализовывать сразу, иначе будет долгострой, а у вас вероятно какие-то сроки имеют место быть :)))

> главное суметь этим воспользоваться
Имеется ввиду правильно составить запросы с нужными типами джойнов?

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

Так и есть )
> CAEDM73-b1666.exe 401.65 MB (421168313)
> CAEDMV73-b5719.exe 15.34 MB (16085865)

Буем качать )

Да похоже, один должен быть 15 Мб, другой - 402 Мб.

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

>И еще. У нас (в таблицах выше) нигде нет связи товара с каталогом. Если товар в 1ом разделе
>каталога, то связь можно и прямо в таблицу товаров добавить: 1 товар -> 1 раздел каталога. А
>если он во многих разделах, что лучше, дублировать товар и все его свойства но с другим
>каталогом или добавить еще одну таблицу связей товар -> каталог ?
Потому, что изначально связать была один ко многим (я так понял, именно она была нужна), много товаров в каталоге и товар принадлежит одному каталогу. Но действительно можно организовать связь многие ко многим, как вы пишите, тогда потребуется таблица связей, а в таблицу товаров не плохо добавить счетчик ссылок, а еще лучше под это дело завести отдельную таблицу, которую заполнять по cron - тогда товары, которые бы остались с 0 ссылок можно было бы удалять и у вас не происходило бы захламление каталога (так и сборщики мусора себя ведут и операционные системы и сложным каталогам это тоже никогда не вредит).

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