ProDomainer.ru - Клуб Домейнеров  
     

Войти через OpenID
Left Nav Справка ПортфолиоАукцион (39) Календарь Поиск Сообщения за день Все разделы прочитаны Right Nav

Left Container Right Container
 
Старый 09.05.2010, 16:44   #1
Член Клуба ProDomainer.ru
 

lang.class.php

mysql vs file
mysql как? Нужно одну - берем одну фразу? Или Забираем всю таблицу в массив?
Я пока думаю, что майскуэль ибо удобство. Потом делим на категории фразы. Подгружаем только фразы с нужными категориями. И того, чего не хватает - подгружаем по одной?
Или сейчас в голову пришло. Записывать фразы в массив и в конце программы всех их через in забрать?
VaseninM вне форума   Ответить с цитированием
Старый 09.05.2010, 21:15   #2
Член Клуба ProDomainer.ru
 

У меня организовано так:
Есть статика (забирается всегда), это хедер, футеры, различные части страницы, вроде меню.
И есть динамика, она забирается в зависимости от загружаемой страницы, таким образом делается два запроса к БД, но их можно и совместить в один. Выбирается строго то, что нужно выбрать для этой страницы, не более.
Шуранов вне форума   Ответить с цитированием
Старый 10.05.2010, 02:50   #3
Член Клуба ProDomainer.ru
 

Немного не в том ключе ставишь вопрос.
База или файл это лишь носитель. Вопрос реализации.
Работа со строками изначально должна продумываться на уровне стратегии.
На примерах:
парадигма "нужна строка - подгружаю" не является исключительной привилегией базы. Вполне можно создать для каждой строки по одному файлу. Неудобно? А в базе удобно?
Пример посложнее:
Лично мой выбор - подгрузка строк методом lang('имя')
При этом парсится файл "имя.lng" из которого отбрасываются комментарии, формируется целый список строковых переменных, структурированных так, как удобно (например массивы типа "main_menu[/help.html] = Справка")
Переменные сразу попадают в пространство имен шаблонизатора.
Шаблоны кстати тоже хранятся в файлах вызываемых по имени соответсвующими методами.
Команда подгрузки того или иного файла со строками выполняется там где нужно, т.е. строки модуля профиля не загрузятся при работе модуля статей, поскольку они инициируются в инициализации модуля профиля.
На первый взгляд такая схема подразумевает файловую модель.
Однако если имя файла заменить на примари-кей некоей таблицы, то заменив в одном-двух местах что-то вроде файл_гет_контент(имя_файла) на что-то вроде дб->реад(айди=имя_файла) - мы получаем тоже самое, но в базе.

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

Добавлено через 19 минут
Цитата:
Сообщение от Шуранов Посмотреть сообщение
Выбирается строго то, что нужно выбрать для этой страницы, не более.
Уверен что эта строгость рентабельна?
Индекс это конечно хорошо, но индекс тоже имеет цену и лишь заменяет O(n) на O(ln(n))

т.е. выбирая все записи определенной категории мы имеем рост от количества "лишних" записей, а при выборе "строго нужных" мы имеем рост от количества нужных записей.
В результате как не крути а асимптотическая сложность в обоих случаях O(n*ln(n)) и тут уже все зависит от конткретной реализации и от конкретных цен на те или иные операции.

Кстати Матвея модель "отбирать по ключу-категория" как оказалось незначительно уступает моей "псевдофайловой" модели по ресурсоемкости, поскольку поиск по индексу то будет делаться только один раз, а там уже все записи идут подряд. Излишек нагрузки будет только потому, что одна запись менее фрагментирована чем группа записей, но это уже нанооптимизация.

В любой ситуации выбор всегда за вами. Вы либо гуляете под дождем, либо просто под ним мокнете.

Последний раз редактировалось Mendel; 10.05.2010 в 02:51..
Mendel вне форума   Ответить с цитированием
Старый 10.05.2010, 15:02   #4
Член Клуба ProDomainer.ru
 

Цитата:
Сообщение от Mendel Посмотреть сообщение
Добавлено через 19 минут

Уверен что эта строгость рентабельна?
Индекс это конечно хорошо, но индекс тоже имеет цену и лишь заменяет O(n) на O(ln(n))

т.е. выбирая все записи определенной категории мы имеем рост от количества "лишних" записей, а при выборе "строго нужных" мы имеем рост от количества нужных записей.
В результате как не крути а асимптотическая сложность в обоих случаях O(n*ln(n)) и тут уже все зависит от конткретной реализации и от конкретных цен на те или иные операции.
Строгость рентабельна вполне, в базе хранятся не фразы, а сериализованные языковые массивы для конкретных страниц. Запросов всего два, и они используют ключ этой таблицы, так что все очень и очень оправдано. И плюс, в итоге память не загромождается лишними элементами.
Шуранов вне форума   Ответить с цитированием
Старый 10.05.2010, 15:17   #5
Член Клуба ProDomainer.ru
 

Ну ок, а строки "Извините, но текущих тендеров нет" и "Данные по тендеру номер:"
ты будешь в разных массивах держать?
Есть строки которые МОГУТ быть использованы в этой странице, но из-за конкретных данных использоваться не будут. Тогда будет либо слишком много массивов, либо "строгость" пострадает.

В любой ситуации выбор всегда за вами. Вы либо гуляете под дождем, либо просто под ним мокнете.
Mendel вне форума   Ответить с цитированием
Старый 10.05.2010, 15:24   #6
Член Клуба ProDomainer.ru
 

Да, но такие сообщения достаточно единичны, чтобы позволить себе держать их в памяти, на деле таких сообщений на странице оказывается не более 3-5, что вполне позволительно держать в памяти, не утруждая БД дополнительными сложными выборками. К тому-же, загрузка языка происходит на раннем этапе инициализации ядра, когда еще не загружаются компоненты и неизвестно, какие элементы на странице будут отображены, так что здесь я вполне могу пойти на небольшое засорение памяти, чтобы избавиться от избыточной нагрузки путем совершенно строгой выборки.
Шуранов вне форума   Ответить с цитированием
Старый 10.05.2010, 15:36   #7
Член Клуба ProDomainer.ru
 

Ну да. Полностью согласен
Это совпадает с моей моделью. Берем только те массивы которые могут понадобится на странице. Чем строже ты разделяешь эти массивы тем меньше избыточность. И хоть на практике их не 3-5 а 10-15 (банально массив категорий пользователей мы грузим весь, а используем только одну. Ну и т.п.) но все равно избыточность этих данных минимальна. Это не весь язык грузить.
Меня просто ввело в заблуждение слово "строго". Я его понял как действительно "строго" а не "почти строго"
Для полной строгости реально можно только сначала скомпилировать шаблон, оставив только язык, а уже потом исходя из нужных строк делать запрос. А это нерентабельно.

В любой ситуации выбор всегда за вами. Вы либо гуляете под дождем, либо просто под ним мокнете.
Mendel вне форума   Ответить с цитированием
Ответ


Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
 
Опции темы
Опции просмотра

Ваши права в разделе
BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения
Быстрый переход


Часовой пояс GMT +4, время: 04:46.