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

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

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

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

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

Для n мерного масива нужно n + 1 колонов в талице n колонок объединены в PRIMARY KEY а последняя колонка значение.
 
Идея про дерево во все не бред. А для дерево хватит такой структуры: id, parent_id, level, order. Уже на 5-мерном массиве мы получим выгрыш по памяти, да выбрать дерево гораздо проще, чем строить выборку по ключу, который содержит n-полей
 
тю - тотже OLAP представляет собой если можно так сказать "многомерную модель"... Есть таблица фактов есть словари(то бишь таблички в каторых хранится набор каких нить данных для ключа)... поэтому для создания 3д хранилища достаточно "мерность хранилища" минус 1 таблиц... таким образом чтобы хранить 5мерную таблицу - достаточно 4 таблицы (таблица фактов и 3 словаря)... или я может не уловил суть проблемы?
 
тю - тотже OLAP представляет собой если можно так сказать "многомерную модель"... Есть таблица фактов есть словари(то бишь таблички в каторых хранится набор каких нить данных для ключа)... поэтому для создания 3д хранилища достаточно "мерность хранилища" минус 1 таблиц... таким образом чтобы хранить 5мерную таблицу - достаточно 4 таблицы (таблица фактов и 3 словаря)... или я может не уловил суть проблемы?

Дада, ни кубов, ни деревьев в реляционных базах данных не бывает :D , я про чего и говорю, что народ как-то однобоко на базы данных смотрит. :)
 
Конечно serialize. Никаких ощутимых проблем со скоростью нет.
 
Извините, возможно не в тему влажу, но вопрос: какого хрена вы храните сериализованые массивы в БД? Вот зачем, на фига? Вы что, ищете по ним потом? Делаете какой-то сложный fetch с условиями? Джойните на что-то?

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

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

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

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

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

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