Работа с массивами. Хранение в базе

[dig555]

После парсинга одной страницы на руках остаётся одномерный массив с характеристиками товара. Каждый элемент - какая-то характеристика.

<?
$goos_features=array("Красный","Быстрый","Мятный","Квадратный","Железный");
?>

Их количество может быть произвольным, но все возможные варианты известны. Т.е. у товара есть 30 возможный опций. Они могут быть или не быть.

Всё это безобразие нужно хранить в БД (MySQL), чтобы потом делать выборки из товаров по нужным характеристикам.
Как именно организовать хранение?
Вижу два варианта:
1). Создать кучу полей TINYINT(1) под каждую из возможных опций. Н-р: is_red, is_fast, is_mint, is_square, is_iron... Есть характеристика - значит 1, нет характеристики - значит 0.
2). Использовать тип поля SET. Даже не знаю, как с ним работать и делать выборки.

И даже в первом случае непонятно, как имея на руках такой массив, заполнить нужные поля в БД. Полагаю, что нужно иметь ассоциативный массив с парами ключ-значение вида название_поля_в_БД - характеристика. И что дальше?

 

[PapaJoe]

можно каждой опции назначить определенное значение, например Красный=2, Мятный=10, и загонять в базу строку в отдельную колонку, например ":2:20:3:4:11:9:10:", а искать уже по ней,

where options like "%:2:%" and options like "%:11:%" и т.д.

 

[AlexMist]

Т.е. у каждого товара есть 30 характеристик, которые могут принимать различные значения или просто как бы 30 чекбоксов?

 

[dig555]

Т.е. у каждого товара есть 30 характеристик, которые могут принимать различные значения или просто как бы 30 чекбоксов?

30 чекбоксов. Значения только два. Или опция есть или опции нет.

 

[AlexMist]

Ну если товаров много и требуется быстрый поиск то вот так Для просмотра ссылки Войди или Зарегистрируйся хранить битовую маску из 30 01001.... (бинарный тип поля).
А так думаю проще 30 TINYINT(1) default 0
А дальше как то так можно :

...
//это как константа соответствия полей значения      
$data_mapper = array(
            'Синий' => 'имя_поля_в_бд',
            'Быстрый' => 'имя_поля_в_бд'
        );
        $sql = 'INSERT INTO good_features
                SET ';
// это получаем из парсера
        $good_features=array("Красный","Быстрый","Мятный","Квадратный","Железный");
        $sql_dobavlen = false;
        foreach ($data_mapper as $value => $db_col) {
              if (array_search($goos_features, $value)) { //ищет с учетом регистра !!!
                  $sql .= $db_col . ' = 1, ';
                  $sql_dobavlen = true;
              }
        }
        if ($sql_dobavlen) {
            substr($sql, 0 , -1); // если добавляли значения отрежемзапятую
        }
        //выполняем запрос
        ...

Для просмотра ссылки Войди или Зарегистрируйся

 

[latteo]

Мне казалось like не самый быстрый в исполнении запрос, лучше всё же SET, он примерно с такой же логикой, но значения назначать не придётся.

Как альтернатива, большинство CMS для этой цели используют отдельную таблицу с 2 колонками
tovar_id,option (может быть много строк с tovar_id для каждой опции)
И для выборки используют JOIN

Вот немного из гугла по теме:
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся

 

[dig555]

Использовал принцип, AlexMist. Всё получилось. Удалось даже сделать проще, чем предложенный вариант. Всё нашлось и всё записалось куда нужно. Но хотелось бы прояснить для себя один нюанс

[Разобрался со всем]

 

[pavlin]

А что мешает хранить в таком виде id(Степень двойки) - Название свойства:

1-"Красный"
2-"Быстрый"
4-"Мятный"
8-"Квадратный"
16-"Железный"
32-.....
64-.....
128-.....

и в поле описания товара хранить сумму этих значений? я сейчас не помню название этого метода.


или
таблица 1: перечень возможных описаний товара
таблица 2: перечень товаров
таблица 3: таблица соответствий (1 товар-> 1 свойство)

 

[dig555]

А что мешает хранить в таком виде id(Степень двойки) - Название свойства:

1-"Красный"
2-"Быстрый"
4-"Мятный"
8-"Квадратный"
16-"Железный"
32-.....
64-.....
128-.....

и в поле описания товара хранить сумму этих значений? я сейчас не помню название этого метода.


или
таблица 1: перечень возможных описаний товара
таблица 2: перечень товаров
таблица 3: таблица соответствий (1 товар-> 1 свойство)

По первому предложению - товар может обладать рядом опций, а не только одной из 30. Второй вариант не подошёл бы из-за нежелания делать кучу запросов к базе, чтобы выбрать все нужные данные. Впрочем я уже решил свою проблему. Создал нужное количество полей и всё. Выборки теперь делать просто, всё находится в одной таблице.

 

[pavlin]

Про первый вариант вы меня не правильно поняли...
Товар Х обладает к примеру свойствами: 16-"Железный" 4-"Мятный" 2-"Быстрый"....
В базе в поле описания товара хранить сумму этих значений: "22" (16+4+2).

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