string <-> array

[TDionis]

string <-> array

Здравствуйте. Мне приходиться хранить в базе данных некоторые многомерные массивы. Но mysql не поддерживает, увы, многомерных массивов, а поддерживает только стринговый тип. Следовательно требуеться кодировать массив в стрингу, а потом обратно. Однако проблемма всеже есть: скорость такой операции.
Вопрос:
Как можно сделать хранение массива в стринге так чтобы, на ее преобразование в массив требовалось как можно меньше времени.
Примечание: массивы ассоциативные, т.е. требуется хранить/извлекать также и индекс.
Зарание спасибо.

 

[boombick]

http://ru.php.net/serialize

 

[FreeSpace]

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

Иначе, например, поиск по этим данным будет невозможным... точнее, крайне затруднительным.

Поподробнее задачу описать можешь? Что это за данные такие?

 

[msdn11]

заведи в базе табличку, клади в неё эл-ты массива и его ид...
потом по ид извлекай...

 

[Фанат]

mysql, как и любая реляционная БД, ПРЕКРАСНО поддерживает многомерных массивов.

 

[TDionis]

> http://ru.php.net/serialize
благодарю.

> заведи в базе табличку, клади в неё эл-ты массива и его ид...
> потом по ид извлекай...
Возможно я чего-то не понял, но извлечь из таблицы типа того:
1 0 Корень
2 1 Элемент 1
3 1 Элемент 2
4 3 Под элемент 1
Или даже типа того:
1 0 Корень
2 1 Элемент 1
3 1 Элемент 2
4 1|3 Под элемент 1
В многомерный массив в пхп - это если не затруднительно, то во всяком случае не очень рационально.

> mysql, как и любая реляционная БД, ПРЕКРАСНО поддерживает многомерных массивов.
я бы попросил подробнее, как там цивилизованно хранить многомерные (желательно ассоциативные) массивы?


> Я бы сначала порекоммендовал попытаться разработать структуру для БД, которая бы позволяла хранить нужные данные без сериализации.
>
> Иначе, например, поиск по этим данным будет невозможным... точнее, крайне затруднительным.
>
>Поподробнее задачу описать можешь? Что это за данные такие?

Я расчитывал использовать преобразование string->array для двух вещей:
1. Например: таблица пользователи, для каждого пользователя содержаться например личные настройки или подобные поля нужные только системе. То есть поиск по ним осуществляться не будет. Однако, вопрос, можно ли через сериализацию сделать атаку на сервер? Всеже база данных защищена, как правило, хуже чем ftp доступ, а совершенно не хочеться однажды не увидеть ни базы данных, ни сайта вообще.

2. При создании многомерных запросов, например:
Есть таблица новостей, каждая новость относится к каталогам. То есть при извлечении новости я еще делаю подзапрос на таблицу категории откуда получаю дополнительные данные (несколько полей). Иногда новость может относиться к нескольким категориям - тогда подзапрос выбирает несколько строк из таблицы каталогов. Но так как подзапрос должен возвращать только одно значение - приходиться использовать group_concat + concat_ws (Итого: многомерный полуассоциативный массив записанный через сепараторы... ). В пхп мне же удобнее обрабатывать многомерные массивы.. Согласен накладно получаеться однако благодаря индексации и сохранении того что вернули подзапросы(типа кеширования) надеюсь добиться приемлемой скорости - но это проблема уже как минимум для следующего топика))

 

[Фанат]

Возможно я чего-то не понял, но извлечь из таблицы типа того:
В многомерный массив в пхп - это если не затруднительно, то во всяком случае не очень рационально.

Ты чего-то не понял.

Однако, вопрос, можно ли через сериализацию сделать атаку на сервер?

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

Есть таблица новостей, каждая новость относится к каталогам. То есть при извлечении новости я еще делаю подзапрос на таблицу категории откуда получаю дополнительные данные (несколько полей).

непонятно. а джойны ты не используешь принципиально?

 

[TDionis]

непонятно. а джойны ты не используешь принципиально?

использую - уверяю, не люблю, но использую. Я пробовал писал и такой и такой запрос: по понятности и скорости оказалось быстрее через подзапросы. К тому же если, скажем, к новости относится 2+ категорий, то с джоинами получаеться проблема

 

[Фанат]

это всё просто от неумения работать с бд.
и "быстрее" и "проблема"