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

[venetu]

Ну вообще да, все конечно же зависит от архитектуры - если у тебя там все равно все те же операции с базой происходят, то почему же "под шумок" не выгр***** еще и массив. Согласен, будет быстрее.

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

 

[ziavra]

Ну вообще да, все конечно же зависит от архитектуры - если у тебя там все равно все те же операции с базой происходят, то почему же "под шумок" не выгр***** еще и массив. Согласен, будет быстрее.

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

Да. Вообще все. Автора зовут Том Кайт, который на Оракле ведет рубрику "Ask Tom", ссылку на точный вопрос сходу не нашел, найду - добавлю.

 

[masto]

Файлы в БД хранить - самоубийство, а Oracle - это отдельная песня.

 

[venetu]

Да. Вообще все. Автора зовут Том Кайт, который на Оракле ведет рубрику "Ask Tom"

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

Ну а для нас, простых веб-девелоперов, обычно самая насущная задача - разгрузить mysql. Именно из-за него в первую очередь все и начинает тормозить.. И для разгрузки приходится делать вещи, недопустимые и вообще НЕМЫСЛИМыЕ с точки зрения теории реляционных БД, как например создавать избыточность данных, сознательно переводить таблицы из третьей нормальной формы в первую, а то и вообще в ненормальную, ставить индексы, нарушающие контроль целостности и т.д..

Моя преподша по теории реляционных БД наверняка бы тоже такое не одобрила. Но блин, чего не сделаешь для производительности..

 

[masto]

Oracle - это монстр, это больше чем СУБД. и он спокойно переваривает огромные объёмы данных.

А в мускуле 10 Гб файлов в базе будут некисло ломать средний сервер.

 

[ziavra]

Я тут более внимательно прочитал где форум находится, и соглашусь, что меня немного в сторону с ораклом занесло наверное.

Но, все-таки, даже в случае с mysql вытаскивание всего и вся на уровень файловой системы это не панацея.

P.S. да и на оракле видел несколько веб-сайтов

 

[venetu]

А в мускуле 10 Гб файлов в базе будут некисло ломать средний сервер.

Во-во, у меня так и было. 14 гиговая база innodb - и у сайта время отклика поползло до 30 секунд. Пришлось городить костыли. Благо, структура базы позволила выгрузить самую большую таблицу в файл, и по файлу бинарным поиском через fseek/fread вручную делали выборки - получалось на порядок быстрее, чем mysql. Просто фантастика какая-то, я глазам не верил.

Впрочем ладно, что-то мы совсем в офтоп ушли. Возвращаясь к теме вопроса - есть стандартный язык php, у него есть стандартный механизм сессий, который стандартно хранит многомерный массив $_SESSION путем serialize() / fwrite(). Создается туева хуча файлов, которые действительно очень тормозят на ФАТе, и действительно подтормаживают на ext2. Владельцам линуксовых и bsd серверов эти проблемы неведомы.

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

 

[masto]

P.S. да и на оракле видел несколько веб-сайтов

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

Во-во, у меня так и было. 14 гиговая база innodb - и у сайта время отклика поползло до 30 секунд.

14 гиговая БД - это ещё скромно, если хранится текст и индексы расставлены (кстати зачем именно innodb).
А вот если эти 14 гигов забиты blob'ами да ещё с частыми обращениями, то сочуствую этому серверу.

Что касается SQL - надо трезво оценивать когда его стоит использовать, а когда нет и почему.

 

[DangerD]

я разделяю символом | тупо конечно, но более вменяемого варианта не придумал...

 

[lift]

Хорош гнать про 10 гигов. 250 гигов база работала как часы.