Как грамотно хранить массив

[Апокалипсис]

Как грамотно хранить массив

Как грамотно хранить такой массив в базе? (я использую serialize())
Array
(
[0] => rd|nd|bd|qd|kd|bd|nd|rd
[1] => pd|pd|pd|pd|pd|pd|pd|pd
[2] => | | | | | | |
[3] => | | | | | | |
[4] => | | | | | | |
[5] => | | | | | | |
[6] => pl|pl|pl|pl|pl|pl|pl|pl
[7] => rl|nl|bl|ql|kl|bl|nl|rl
)

 

[Андрейка]

и что? не хранится он в таком виде?

 

[Апокалипсис]

Хранится, просто охото узнать еще способы, если таковые есть

 

[zerkms]

Апокалипсис
элемент массива == запись в БД

 

[Андрейка]

zerkms
зачем?

 

[Апокалипсис]

элемент массива == запись в БД

в данном случае будет сложно оперировать элементами и их значениями

 

[hermit_refined]

вообще всё зависит от метафизического смысла этой хренотни (что в массиве).
а то, бывает, встречаются люди - пишут данные в одно поле, а потом по нему лайком ищут.

 

[Апокалипсис]

Смысл этого массив - это массив шахматных фигур

 

[Андрейка]

Апокалипсис
да хоть коды к компутеру зеона... весь вопрос - че с ними в бд делать будут

 

[Апокалипсис]

В БД будет хранится и постоянно (как идет новый ход массив будет перезаписываться)

 

[zerkms]

Андрейка
а почему бы и нет?

а так - если данные из массива не будут служить критериями поиска - тогда сериалайз самое то

 

[Lexx_DN]

Если массив оч. большой, то лучше делать
$toDb = implode('Уникальный разделитель', $value);
$toDb = gzcompress($toDb, 9);

implode быстрее serialize больше чем в 2 раза, а gzcompress уменьшит размер хранимых данных в несколько раз

 

[MadMike]

Lexx_DN
Очередной раз напишу:
"жжошь"!!!!!!

 

[astellar]

$toDb = gzcompress($toDb, 9);

gzcompress лучше делать средствами самого MySQL, используя фнкции COMPRESS/UNCOMPRESS

это будет быстрее

 

[chira]

Апокалипсис

В БД будет хранится и постоянно (как идет новый ход массив будет перезаписываться)

с этого места поподробней ...
тебе нужно записывать порядок ходов?

 

[Lexx_DN]

MadMike
ты проверял, что быстрее - implode или serialize?

astellar,
не знал про mysql COMPRESS/UNCOMPRESS

 

[MadMike]

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

зачем ты хранишь gif'ы в MySQL? ты будешь делать по ним полнотекстовый поиск? (с) Фанат, по-моему

 

[astellar]

Автор оригинала: Lexx_DN
MadMike
ты проверял, что быстрее - implode или serialize?

А не все равно? Если конечно это не yahoo games.

astellar,
не знал про mysql COMPRESS/UNCOMPRESS

Будешь теперь знать

 

[Lexx_DN]

Автор оригинала: MadMike
Lexx_DN
Имхо, более идиотской идеей, чем хранить в БД заархивированные данные, будет только идея хранить там картинки.
Зачем вообще данные хранятся в базе? Для того, чтобы их как-то обрабатывать. Как ты будешь обрабатывать сжатые данные? Может, все-таки, стоит продумать другую структуру таблиц?

зачем ты хранишь gif'ы в MySQL? ты будешь делать по ним полнотекстовый поиск? (с) Фанат, по-моему

Реальная задача - хранить временные списки пользователей, которых около 50000. Если хотя бы десятая часть создаст себе такой список из всех пользователей, то, один список будет около 600К, дальше сам можешь посчитать. Архивированные данные требуют почти в 3 раза меньше места. А обработывать их не обязательно в MySql-запросах.
Так что если тебе это не нужно, то это еще не означает, что идея идиотская и гифы здесь ни при чем, а от использования implode вместо serialize скорость ощутимо повышается.

 

[MadMike]

Lexx_DN
Судя по всему, ты пишешь датинг )
Кеширование, кеширование рулит
В таблицы объемом в 600K как и в 6M, и в 60M, меня нисколько не пугают