форма, массив и MySQL

[ajr]

Не могу понять...
Есть у меня форма с 21 полем, все данные с этой формы передаются в таблицу БД, причём данные из 18-ти полей формы пытаюсь занести в одно поле таблицы в виде массива...
Примерно так:
:

и т.д. всего 18.
...$sql = "insert into makeprog VALUES(NULL,\'$tur\',\'$intro\',\'$progn\',\'$user\',\'$date\',\'$time\')";...

А когда извлекаю эти данные из БД - выдаёт только "Array":

function ReadFromTable () {
    connect ();
    $result = mysql_query( "SELECT * FROM makeprog");
    $num_rows = mysql_num_rows($result);
    print "There are currently $num_rows rows in the table

";
    print "

\\n";
    while ($a_row = mysql_fetch_array($result)) {
    print "\\n";
    print "\\n";
    print "\\n";
    }
    print "

$a_row[progn]

\\n";
    }

А как мне обратно получить и распечатать данные введённые пользователем? Или я что-то не так делаю? Неохота 18 дополнительных полей в таблице создавать...

[Alexandr]

А ты где видел в SQL\'е поля с типом Array?
Ес-но значение переменной $progn=="Array".
Надо заводить 18 доп. полей, либо склеивать массив в конечную строку, либо закидывать в поле все значения массива с разделителями.
Например, $progn=$progn[a1]."|".$progn[b1];А потом после SELECT\'а $progn=explode("|", $progn);

[Covex]

И serialize() можно, наверное.......

[ajr]

Alexandr

Понятно, спасибо...
А чисто практически что лучше, создать 18 полей или сделать массив с разделителями?

[advocat]

Вообще канешно лучше сделать именно 18 полей, намного проще и удобней, но это лично мое мнение, так как я не особо люблю масивы, но всеравно приходится ими пользоваться на каждом шагу.
То, что тебе вывело именно array , дык этого и следовало ожидать, ты же пытаешся вывести масив на печать !
а решение как раз твоей проблеммы написал Alexandr

[Alexandr]

Вообще канешно лучше сделать именно 18 полей

Лучше если только в них потребуются поиск или операции с какими либо полями, а так лучше 1.

[advocat]

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

[Alexandr]

НУ так а для чего ж тогда базу держать ? естественно, что-бы можно было что-то найти

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

[advocat]

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

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

[Меняздесьдавнонет]

картинки вообще в базе хранить не надо

[Alexandr]

RomikChef

картинки вообще в базе хранить не надо

Почему?

[Меняздесьдавнонет]

потому, что это нереляционные данные.
Ты тут нам много и красиво рассказывал про оптимизацию, видимо, тебе этот процесс очень нравится, и тебе хочется пооптимизировать резко выросшую в объеме базу и объем используемой памяти. Флаг в руки.

[Alexandr]

2RomikChef
Можно ведь (и нужно) в отдельной таблице хранить BLOB поля.

[Меняздесьдавнонет]

не нужно вообще хранить блоб поля.
В жигулях тоже МОЖНО песок возить.
Но только идиоты или люди, у которых нет другого выхода, так делают. Потому, что потом эти жигули все равно выбросить придется.
Бинарные данные совершенно нет смысла хранить в базе данных. Это только бессмысленно повышать нагрузку на сервер.

[Меняздесьдавнонет]

Саша.
Я не говорю, что нельзя ни в коем случае, никогда во веки веков, аминь. Я написал - не надо. Если есть возможность обойтись, то конечно же, в базе хранить не надо. и любой здравомыслящий человек это понимает. что не надо писать специальные скрипты, которые занимаются тем, с чемвеликолепно справляется веб-сервер - отдачей картинки клиенту. что не не надо грузить память машины в объеме, равном двум картинкам. Что не надо создавать гепоррой пользователю, которому картинка отдается не по-человечески, а с уродским адресом. Что не надо создавать проблемы себе, в виде невозможности, к примеру, использования функции getimagesize. И этот список можно долго продолжать. Но он же очевиден. Смешно объяснять такие, в общем-то, примитивные вещи.