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

[DarkFlint]

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

 

[n42]

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

ИНХО бред, а не совет.

В обычной базе есть таблица одномерная, а деревьев нет.

И зачем нужно сколько то связаных таблиц вместо одной не понятно.

Для n мерного масива нужно n + 1 колонов в талице n колонок объединены в PRIMARY KEY а последняя колонка значение.

 

[01ssv]

Идея про дерево во все не бред. А для дерево хватит такой структуры: id, parent_id, level, order. Уже на 5-мерном массиве мы получим выгрыш по памяти, да выбрать дерево гораздо проще, чем строить выборку по ключу, который содержит n-полей

 

[ziavra]

А функция подобоные serialize функции есть в JS или AS?

Для просмотра ссылки Войди или Зарегистрируйся, например. А вообще в любом языке можно сериализацю реализовать при отсутсвии встроенных решений, было бы желание.

 

[gavss]

тю - тотже OLAP представляет собой если можно так сказать "многомерную модель"... Есть таблица фактов есть словари(то бишь таблички в каторых хранится набор каких нить данных для ключа)... поэтому для создания 3д хранилища достаточно "мерность хранилища" минус 1 таблиц... таким образом чтобы хранить 5мерную таблицу - достаточно 4 таблицы (таблица фактов и 3 словаря)... или я может не уловил суть проблемы?

 

[ziavra]

тю - тотже OLAP представляет собой если можно так сказать "многомерную модель"... Есть таблица фактов есть словари(то бишь таблички в каторых хранится набор каких нить данных для ключа)... поэтому для создания 3д хранилища достаточно "мерность хранилища" минус 1 таблиц... таким образом чтобы хранить 5мерную таблицу - достаточно 4 таблицы (таблица фактов и 3 словаря)... или я может не уловил суть проблемы?

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

 

[koder110]

Конечно serialize. Никаких ощутимых проблем со скоростью нет.

 

[venetu]

Извините, возможно не в тему влажу, но вопрос: какого хрена вы храните сериализованые массивы в БД? Вот зачем, на фига? Вы что, ищете по ним потом? Делаете какой-то сложный fetch с условиями? Джойните на что-то?

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

Пожалейте мускул, он и так обычно загружен дальше некуда. В данном случае можно и нужно каждый массив хранить в отдельном файле, название которого совпадает с ключом, по которому к этому массиву нужно иметь доступ. Идеальный вариант, конечно, memcached, но и с файлами будет намного быстрее чем с базой.

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

 

[masto]

такого хрена, что мне не нужно на диске 10 000 файлов размером в несколько сот байт.

такого хрена, что кроме сериализованного массива в этой же записи ещё целый ряд данных. или ты будешь уверять что выборка из БД + поиск и чтение из файла будет быстрее и легче для сервера?

 

[ziavra]

такого хрена, что мне не нужно на диске 10 000 файлов размером в несколько сот байт.

такого хрена, что кроме сериализованного массива в этой же записи ещё целый ряд данных. или ты будешь уверять что выборка из БД + поиск и чтение из файла будет быстрее и легче для сервера?

Абсолютно согласен, это не считая того, что при хранении в базе разграничение доступа к данным реализуется более логично. И, опять же, не считая того, что кроме mysql бывают и другие базы, и некоторые уважаемые люди рекомендуют вообще все данные хранить в БД. Из плюсов централизованное управление бэкапами и правами доступа.