Есть база с заголовками столбцов:str, pos0, pos1, pos2,....
И есть двумерный массив:


Количество членов  массива разное ,т.е может быть как 3, 4, так и 10 .... членов (на втором уровне тоже).
Как наиболее рационально засунуть значения этого массива в базу данный?

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

P.S. Заранее спасибо за помощь.

Это сообщение отредактировал(а) MOTORIST - 13.6.2009, 12:58

MOTORIST, используй функции serialize и unserialize (http://php.su/functions/?serialize).

Это сообщение отредактировал(а) lukas - 13.6.2009, 09:17

Каким образом использовать эти функции...?

MOTORIST, искать по этому массиву не надо? Какого объема этот массив (100 строк, 1000,  больше)?

Я немного не правильно выразился, нужно в db засунуть не массив, а значения массива, т.е. раскидать их по базе данных.
Массив имеет два уровня вложенности. На первом уровне членов не более 1000, на втором не более 20ти.

Это сообщение отредактировал(а) MOTORIST - 13.6.2009, 12:55

MOTORIST, Проектировать базу надо начинать с потребностей поиска-вывода информации. 
Какие данные нужны для каждой конкретной операции, которая будет использована?

Если сразу спроектировать базу сложно, можно поставить временную затычку - типичный, достаточно универсальный, но не самый оптимальный во многих местах способ - таблица по 20 элементов в строке. Все неиспользуемые поля будут помечены NULL-ами. Потом, после написания интерфейсной части, список "потребностей" пользователя базы будет примерно определен, и базу можно передизайнить...

В таблице будет 20 столбцов pos1, pos2, pos3......

Но в массиве на втором уровне не всегда будет 20 значений. 

Если бы я знал точное число значений на втором уровне, проблемы вообще бы не было..


а надо 


С названиями столбцов проблем нет 


А вот со значениями что то не получается...

Сделай две таблицы в базе для связи один ко многим. В одну складывай элементы первого уровня ( id и любую необходимую информацию ), во вторую элементы второго уровня. Тогда не имеет значения сколько вложенных элементов и поля придумывать не надо

Тут не нужно создавать 2 таблицы (с какой целью?), чтобы в первой хранить числа от 0 до 1000 ....
Что за бред?   

бредом это вы занимаетесь товарищ MOTORIST, вам говорят, надо изначально структуру планировать, а не пытаться неизвестное запихнуть в непонятно что

для подобной задачи достаточно было бы сделать одну таблицу с полями id, id_parent, value
и раскидать по принципу: одно значение - одна строчка в БД

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

Мне нужно универсальное решение!!!!!
Поиск будет.
Число элементов массива будет постоянно меняться. 
Что тут не понятного???
Если бы массив был статичный, то я бы тут не писал (тогда решение простое).

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

Одно значение одна строчка мне не подходит (это и ребенок сделает).

----------------------------------------------------------------------
 pos1 | pos 2 | pos3    | .......
    1    | янв.   | 1.03.09|........    
    2    | фев.   | 2.03.09|........
    3    | мар.   | 4.03.09|........
......     .......       .......
___________________________________________

Это сообщение отредактировал(а) MOTORIST - 13.6.2009, 15:54

а вы видать не можете из нескольких значений сделать одно?

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

Мне нужно общее решение. Перебрать массив и засунуть в базу. 
До поиска еще дело не дошло.

Решил методом отпративного.
Допустим у меня в таблице создано 20 поле pos.
А в массиве второго уровня 3 или 5 или 10 или 20 записей.
То есть сначала проверяю сколько есть, затем насильно забиваю недостающие пустыми.
Затем засовываю в базу. 

Идею подсказал модератор на joomlaforum.ru под ником beliyadm.

Спасибо и поклон ему за это.

P.S. но мне кажется все таки есть более рациональное решение   

Это сообщение отредактировал(а) MOTORIST - 13.6.2009, 17:57