Типа таблица Код (Text): +------+------------+ | key | data | +------+------------+ | tree |{"page":{...| +------+------------+ | .... | .......... | key - varchar, data - blob. Доступ через объект с минимумом методов - set, get, check, remove. Результаты get и check кешируются в переменную, для быстрого последующего доступа. Целесообразно ли использовать такое?
а это не велосипед хранилищ типа key->value , а что хранить в blob ? почему не на диске? во http://rediska.geometria-lab.net/
Костян Что-то типа первого memcached, только хранение данных в mysql. не, там в примере JSON для примера только. Тип поля - BLOB, который работает быстрее чем TEXT, но никаких операций с ним провести нельзя. Суть в том, что обычно для хранения любых данных заводится таблица в БД со своей структурой. Если это данные небольшие по объему, например, настройки, перечень разделов сайта, какая-нибудь таблица групп с правами доступа, то можно хранить их целиком в строках вот такой вот таблицы. Дергать целиком и выбирать нужные значения или выполнять сортировку в скрипте. Вместо того, чтобы заводить отдельную таблицу. Ensiferum обязательно)
Редис это хорошо, но встречается он на хостингах еще реже, чем memcache. upd. и речь идет о постоянном хранении, а не кэшировании.
баян, вп использует такой метод для хранения настроек там даже пошли дальше, есть поле autoload - свеобразный прекеш
в мадженте есть таблица core_config_data (scope, scope_id, path, value) валюэ - то ли текст то ли варчар даже, не помню. Во всяком случае есть возможность Чем тебе не нравится нормальная модель + кеширование?
есть такая буква. имею oid и objtype все равно требуется ненормализовывать для поиска. помимо части полей в основной таблице потребовалась дополнительная вида oid paramname paramvalue поскольку у разных типов объектов разное кол-во разных полей, по которым требуется искать, и не надо их все добавлять в одну таблицу. структура имеет смысл при а) неизвестных видах данных и сколько когда их будет. б) стандартной обработке разных типов данных. хотя тут и разными таблицами можно обойтись. в общем надо хорошо подумать что тебе надо чтобы быть увереным.
Строки удобнее создавать и удалять, чем таблицы. Похоже, кроме очевидной потери возможности обработки данных средствами sql, минусов у этой системы нет, буду юзать