| |
|
|
| | Есть такой вопрос, к примеру:
есть 100 свойств товара, и база данных товаров!
у товара может быть от 1 до 100 этих самых свойств!
очень удобно, если в БД продуктов будет 100 полей, где будет стоять 1 или 0, и использовать форму checkbox для включения или выключения каждого конкретного свойства.
но это слишком, а также запрос на наличие хотя бы одного свойства будет просматривать 100 полей.
можно закладывать десяток свойств в одно поле, типа записи -1-20-35-74-81-4-5 и делать запрос на LIKE '%-$id-%' - , запрос будет выполняться быстрее, но в этом случае чтобы разложить такое поле по отмеченным или не отмеченным формам checkbox для его администрирования, понадобится очень тяжелое регулярное выражение, или функция , которая будет делать 100 запросов в это поле для заполнения 100 форм checkbox
Как тут быть? | |
| |
|
|
| |
|
|
| |
для: AN
(04.04.2008 в 01:24)
| | | Можно формировать одно поле таблицы таким образом, что данные о каждом свойстве товара записывать через некий определитель, например изпользуя ::.
А на странице вывода данных о товаре, динамически формировать такую структуру.
Ну вот пример:
CREATE TABLE itproduct
(
id_goods SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
other TEXT DEFAULT NULL, (поле, содержащее список свойств)
PRIMARY KEY (id_goods)
);
INSERT INTO itproduct VALUES ('0','свойство1::свойство2::свойство3.....');
|
Исполняющий код:
<?php
.......
if (trim($other) != "")
{
$exp_str = $other;
foreach ($exp_str as $value)
{
list($xar) = explode("::", $value);
echo "Свойство товара - ".$xar;
}
}
?>
|
При администрировании тоже не должно быть проблем, просто загружайте данные, например в textarea и редактируйте нужные свойства, а затем сохраняйте. | |
| |
|
|
| |
|
|
| |
для: AN
(04.04.2008 в 01:24)
| | | Можно попробовать сохранять в таблице сериализованный массив, но в таком случае будут сложности с поиском по таблице, если нужно найти товар, имеющий строго определенные свойства. Но плюс в том, что данные сохраняются в формате [имя_свойства]=>[значение_свойства] и после извлечения из базы данных ими легко манипулировать. Конечно, при извлечении можно создать многомерный массив и осуществлять поиск уже в нем - тогда и ограничение на поиск снимается, но ценой быстродействия и сложности кода | |
| |
|
|
| |
автор: rusty_angel (04.04.2008 в 10:08) |
|
| |
для: AN
(04.04.2008 в 01:24)
| | | Познайте перелести декомпозиции. В одной таблице товары, в другой все возможные свойста, в третьей - пары id_товара-id_свойства. | |
| |
|
|
| |
|
|
| |
для: rusty_angel
(04.04.2008 в 10:08)
| | | >декомпозиции
В SQL и базах данных декомпозицию обычно называют нормализацией. | |
| |
|
|
