Метод SELECT в Rumba DB для cms Rumba Blank
— Да мои орлы газет не читают, книг в глаза не видели.
— Ну, не надо перехваливать.
(© О бедном гусаре замолвите слово)
При дальнейшей проработке структуры базы Rumba Data Base показалось несколько нелогичным, что с ПРИЗНАКОМ работает (для удобства движка) класс rdb, в то время как по логике вещей это делать должен движок. Т.е. класс rdb должен быть более абстрагирован от данных, когда от него требуется, он делает выборку, а уж с выборкой пусть разбирается тот, кто её заказал. Исходя из этого, что хранится в ПРИЗНАКе, базу совершенно не волнует, она только проводит выборку, а как и что сложить в ПРИЗНАК для дальнейшей удобной работы решается на этапе проектирования движка и с помощью его средств.
Как пример в версии 0.8 движок хранит в ПРИЗНАКЕ сериализованный массив с кучей тэгов, описывающих статью: tape, name, desc. Это удобно для обработки - сделал запрос, и получил строку, рассериализовав которую можно сразу обращаться к членам массива. Надо только не забывать, что и запрос должен быть правильно подготовлен, если надо, отсериализован (и тогда из него должны быть удалены кое-какие символы - смотрите пример в Rumba Blank) - как видите, это решается в коде движка.
При этом в массиве, сериализуемом для ПРИЗНАКа, адреса членов массивов не могут быть из двух и более слов, т.е. `tape`=>`Всё о CMS` - это правильно, а `tape news`=>`Всё о CMS` - уже неправильно.
Теперь перейдём к самому методу, который делает выборку: вместо кучи функций мы получили одну - select (название взято из MySQL). Общий синтаксис запроса таков:
select (ЗАПРОС, ГДЕ_ИЩЕТСЯ, ЧТО_ВОЗВРАЩАЕТСЯ, СДВИГ, КОЛИЧЕСТВО)
ЗАПРОС - что ищем, возможно - ключ статьи, возможно - кусок свойства
ГДЕ_ИЩЕТСЯ - варианты key (ищем в ИМЕНи) sign (ищем в ПРИЗНАКе)
ЧТО_ВОЗВРАЩАЕТСЯ - варианты min (массив с ПРИЗНАКом) max (массив с КОНТЕНТОМ)
СДВИГ - сколько записей пропустить с конца
КОЛИЧЕСТВО - возвращаемых записей
Намного поподробней рассмотрим каждый из параметров:
ЗАПРОС
Если ищется конкретная статья, то это просто её имя, но если делается выборка по элементу признака, то тут всё сложнее. Допустим, у нас в составе ПРИЗНАКа есть отсериализованный элемент tape, и мы ищем, когда tape=>rumba. Можно конечно просто искать rumba, но велик шанс, что в текстах ПРИЗНАКа или КОНТЕНТА промелькнет это слово, и выборка будет проведена неправильно (тут на движок возлагается задача по уникализации ПРИЗНАКа). Можно сделать и попроще, внеся в ПРИЗНАК не сериализованный массив, а простою строку вида tape_rumba, уникальность которой уже выше. В Rumba Blank выбран вариант с сериализацией, как дающий высокую степень уникализации плюс удобство работы с рассериализованным массивом.
ГДЕ_ИЩЕТСЯ
Если мы предлагаем опцию key, то при поиске RDB заключает запрос в двойные кинжалы, что совершенно исключает ошибочную выборку по ПРИЗНАКу вместо ИМЕНи. При состоянии sign запрос используется в обычном режиме, подразумевая работу с ПРИЗНАКом.
ЧТО_ВОЗВРАЩАЕТСЯ
Ключи min и max регламентируют, откуда будет делаться выборка (возвращаться результат). При min вся работа проводится с файлом *_map.rdb, который на один-два порядка меньше, соответственно, работа с ним будет проведена быстрее, что самым положительным образом скажется на скорости скрипта. Опцию max надо использовать тогда, когда от базы мы хотим получить КОНТЕНТ, и этот режим конечно же немного медленней (работают два файла, а не один). Но поскольку полный КОНТЕНТ мы обычно хотим получить только при заходе на конечную страничку сайта, то он выбирается в единственной записи, и это может быть даже быстрее, чем выборка десятка записей с возвратом ПРИЗНАКов.
СДВИГ
Этот параметр активно используется для разбиения ленты новостей на страницы, соответственно, для заглавной страницы это всегда ноль, а также для выборки конкретной записи по ИМЕНи.
КОЛИЧЕСТВО
Эта опция увязана со СДВИГом. Например, если СДВИГ==5 а КОЛИЧЕСТВО==6, то будет выбран массив записей со сдвигом из 30 записей количеством 6 штук. Для поиска по ИМЕНи конкретной записи нужно задать СДВИГ=0 а КОЛИЧЕСТВО=1 (или не задавать вообще, так как эти параметры проставлены по умолчанию).
Рассмотрев коротко один, но универсальный метод select, необходимо пару слов посвятить и оптимизации организации БД на конкретном разрабатываемом движке. Есть несколько вариантов:
База будет состоять из небольшого (не более нескольких тысяч) записей, при этом КОНТЕНТ будет велик ~100Кб на одну запись. В этом случае лучше сделать более подробную и удобную модель ПРИЗНАКа, чтобы как можно реже работать с КОНТЕНТом.
Количество записей будет велико - 100к записей, при этом КОНТЕНТ записей будет наоборот мал. Тогда минимизируем размер ПРИЗНАКа, чтобы время на выборку в больших массивах составляло разумную величину.
При прочих равных условиях база из 1000 записей в 10Кб будет работать оптимальней, чем база с 10000 записями в 1Кб, т.е. количество записей более критично, чем их размер, соответственно, при работе с миллионом записей скорость работы будет значительно ниже.
Если общий размер базы предполагается не более десятка мегабайт, на первое место ставьте вопрос удобства организации структур ПРИЗНАКа, так как скорость выборки будет в любом случае высокая.
Все изменения в Rumba Data Base транслированы и в Rumba Blank, соответственно, эту простую CMS вы можете использовать для просмотра вариантов работы с Rumba DB. Лицензия остается прежней, а значит, креативные решения на основе Rumba Blank для новичков приветствуются и поддерживаются. Пробуйте, и получится.Смотри также:
Портал на CMS Rumba Денвер и Zend Opimiser Система управления содержимым Платить или не платить – вот в чем вопрос CMS для html-сайтов Rumba Tree
Комментарии
Маэстро
Thu, 17 Dec 2009 05:57:05
Потянет, но тут вы можете ускорить все это с помощью размещения фалов базы и индекса на других дисках Обратите внимание, что при создании объекта мы указываем путь, где они будут храниться. 10000 записей для RDB - это нормальная цифра. Скорость обработки запроса будет зависеть от скорости работы дисковой системы.
Прохор
Fri, 18 Dec 2009 06:27:47
Подскажите, Маэстро, а полтора гига база потянет? Мне надо кучу художественных текстов в движок пихнуть, все тексты большие, порядка 100 килобайт.
Маэстро
Thu, 17 Dec 2009 09:56:51
База тестировалась на массиве данных размером 200 мегабайт с количеством записей 20000 штук, скорость работы движка была совершенно нормальной (страницы генерировались ~0.05 сек).
Проза жизни
Thu, 17 Dec 2009 10:18:34
Маэстро, вот что мне нравится, так это цитаты перед статьёй - всегда что-нибудь необычное...Унификация SELECT вместо многочисленных GET очень удобна, и остроумно сделана выборка с его же помощью одной записи по ключу. Хотелось бы подобным образом и функции редактирования скучковать.Пробовали ли вы потестировать на большой базе свою BD ? Любопытно, как она будет себя вести при гиговой базе при примерно штуке статей. Т.е. одна запись будет в мегабайт...
Комментировать
