| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Firebird, Interbase > Помогите спроектировать |
| Автор: Gorcer 9.8.2004, 03:04 | ||
| Здраствуйте, вопрос у меня следующий: Нужно составить базу данных по товарам, причем каждый товар имеет свои свойства, и все их обязательно нужно указывать! Я сделал следующее: 
Создавать для каждого товара свою таблицу невозможно, т.к. их очень много! Мож у кого будут более удачные предложения? Буду рад любому мнению, заранее благодарен! |
| Автор: <Spawn> 9.8.2004, 05:19 |
| Дак пиши все товары в одну таблицу и идентифицуируй каждый из них по его имени. И зачем делать такую глубокую нормализацию? Например, название свойства и содержание свойства связаны как один к одному? Если так, то их можно в одной таблице держать. |
| Автор: Gorcer 9.8.2004, 05:47 |
| Неочень понял, ты предлагаешь держать таблицу свойств такого типа: 1:Цвет:красный 2:Цвет:Желтый 3:Литраж:2л. Если так, то не слишком ли избыточная будет база? По имени каждый товар писать немогу, т.к. не у всех есть имена! |
| Автор: Kesh 9.8.2004, 14:56 |
| Свойства несут описательную или смысловую нагрузку?.. |
| Автор: Gorcer 10.8.2004, 01:05 |
| Да, в информации о товаре будет выдаваться список свойств и их описание! Типа Джинсы: Цвет-Черный, Размер-46, Производитель - Франция! |
| Автор: Kesh 10.8.2004, 22:54 |
| А выборка по какому-нить свойству производится?.. А то можно было бы их просто все разом в text загнать... |
| Автор: Gorcer 11.8.2004, 00:27 |
| А можно поподробней, что ты предлагаешь сделать? Что даст загоняние в текст? |
| Автор: Kesh 11.8.2004, 09:29 | ||
| К сожалению ты не указал тип базы... Я думаю, что можно организовать в таблице поле типа text, varchar, varchar2... и туда для каждого товара загонять его свойства... Т.о. для вывода свойств надо будет выбрать только одно поле... Но это решение не подходит, если необходимо будет делать выборку по определенному свойству... Для поиска по определенному свойству можно конечно написать что-то типа...
Но жрать оно будет на таких выборках... Будь здоров... |
| Автор: Gorcer 11.8.2004, 13:45 |
| Да по свойствам выборку надо будет делать! А мой вариант нелучше будет? таблицы "свойства" и "описание", я прикреплю JOIN-ом к таблице с товарами, и из этого буду работать, можно также представления создать объединяющие 3 таблицы! Или это тоже много жрет?  |
| Автор: Kesh 11.8.2004, 15:05 |
| Можно так: Таблица 1 - товар... Таблица 2 - название свойства... Таблица 3 - возможное значение свойства... Таблица 4 - связь Товар-Свойство-Значение_свойства Но я бы все-таки рекомендовал сделать по-другому... Товар, какой бы он ни был, может иметь ограничеггое количество свойств... Цвет, размер, цена... Так почему бы не зарегистрировать все эти возможные свойства в таблице товара... Даже если поля таблицы заполняться не будут, то (по крайней мере в Oracle точно) они и места не займут (просто тип им надо дать переменной длины, типа varchar2() )... Тогда и искать можно будет быстро... Вот только одна проблема возникнет - при заполнении/изменении полей много полей придется оставлять пустыми... |
| Автор: Gorcer 12.8.2004, 07:13 |
| Пойдем дальше! Пользователь добавляет новый товар и ему должны выдаться возможные свойства товара, значения которых он введет. В своем варианте я создаю таблицу "категории товара" и "соответствия категории и свойств", чтобы пользователь допустим выбрав товар ВОДКА (принадлежащий категории АЛКОГОЛЬ), получил список свойств водки (производитель, литраж, градус)! Тоже самое касается выборки значения свойств в зависимости от выбраного свойства. Как решить этот вопрос в вашем варианте базы? |
| Автор: Kesh 12.8.2004, 08:43 |
| Да точно также... Просто состав полей на вставку свойств будет выбираться из соответсивия категории и свойств товара... Вообще, хорошо бы разделить общие свойства для всех товаров и качества, уникальные для товара... Так, например для Водки "Производитель" - общее свойство, "Литраж", "градус" - уникальные... |
| Автор: Гость_Владимир 11.10.2004, 03:13 |
| LIKE много жрать не будет. Проверено на базе 30к записей - примерно 50 миллисекунд. |