Уважаемый 3dn! Заставил себя "асилить" Ваш сумбурный бред, а теперь по порядку.
Есть такое понятие, как многопользовательские системы. В зависимости от прав доступа, пользователю показываются или не показываются те или иные разделы системы. На них накладывается маска. Маска к Вашему удивлению (профиль пользователя) также хранится в базе данных.
Ну если в среднем 30-40 тысяч уников в сутки для Вас это мало, то жму руку. Быстро для меня - это не более 0.2-0.3 секунды на общее время выполнения запросов к БД.
Индексы применяются для ускорения сортировки, выборки из базы по ключу и создания связанных запросов (join). Ещё раз повторюсь, что для ускорения работы и уменьшения нагрузки на сервер СУБД часть таблиц денормализуется, что позволяет не использовать связанные запросы и существенно сокращает количество обращений к БД. Плюс поверьте мне на слово, а если не доверяете - поставьте эксперимент и проверьте, что очень часто в системах с большим количеством пользователей и большими массивами информации гораздо эффективнее сделать пять запросов подряд, чем один запрос с тремя джойнами. И ещё, так для пополнения начальных данных о СУБД, - при конфигуроровании СУБД часть памяти мы выделяем под различные кэши, так вот один из них служит для кеширования индексов, другой последних запросов и т.п. Эта система гораздо сложнее и умнее, чем Вы думаете. Приведу протой пример: в таблицу СУБД MySQL нужно добавить 10К записей. Казалось-бы - простая задача. Ан нет, - опытный программист перед этим выключит индексы, сделает добавление, а потом их включит. А знаете почему? Потому что после каждой операции insert кэш индекса заново перестраивается и сбрасывается на диск. А при правильном подходе это будет сделано только один раз. Представляете, какой выигрыш в производительности получается, когда эта таблица содержит сотни тысяч записей? Как минимум- 2-3 порядка. Естественно, программист должен быть уверен в том, что на вход он подаёт правильные данные и индекс потом будет создан. Но это уже другая тема...
Ответ на тему топика другой - запросов должно быть столько, сколько необходимо для максимально эффективного отображения необходимой пользователю информации.
База данных, к Вашему сведению - это тоже файлы. Это раз. Самыми оптимальными являются те системы, которые для выполнения какой-то операции наименьшим образом загружают вычислительные ресурсы . Это два.
Кто бы спорил. Только позвольте сделать одно замечание, когда Вы используете файлы, то по сути создаёте свою миниСУБД, т.к. пишите небольшую надстройку для управления записью-чтением данных из файлов. Чем не СУБД. Иногда, Вы не поверите, для таких файлов делают даже индексные файлы, что ещё больше приближает эту минисистему к стандартам СУБД.
Любой НОРМАЛЬНЫЙ проект, который приносит владельцу стабильный доход (под доходом я понимаю суммы от 1К$ и выше), не будет хоститься на одном компьютере с другими проектами, т.к. не будет ставить свой бизнес в зависимость от того, что какой-то программист на своём хомяке зациклил какую-нибудь процедуру. Такие проекты располагаются на выделенных серверах, а зачастую даже не на одном.
Что касается кеширования, - при правильном написании проекта оно выполняется частично сервером хостера, частично браузером клиента, а частично процедурами, предусмотренными создателем проекта. Огромная роль в это отводится также операционной системе, СУБД и железу сервера. И, по-моему, Вы не совсем представляете, что такое динамическое изменение информации, когда 2/3 выводимой информации изменяется не реже, чем раз в 3-5 минут.
Так что, подводя итог всему могу сказать одно - теоретически Вы сказали правильные вещи, а практически - глупость. Скорее всего, это произошло от того, что Вы пока не имеете понятия о том, что такое большие системы. И ещё, небольшая просьба - не вводите в заблуждение других людей и не давайте советы до тех пор, пока досконально не разберётесь в теме и не приобретёте достаточного опыта.
Жене Путина предложите...
Oniks, ну будет у Вас в таком случае, при самом максимальном раскладе запросов 15 на морде и 7-10 на внутренних. 500-1000 посетителей в день планируете? Можно не париться, если хостинг нормальный.
У меня тоже сильно колбасит по Рамблеру выдачу. В какую сторону пока понять не могу. Что-то в плюс, что-то в минус. Но по заходам картина прежняя.
Не хочу url светить - это один из крупнейших порталов.
А вот почему так получается - объясню.
Основные запросы такие:
1. Информация о заголовках страницы.
2. Главное меню
3. Основное подменю
4. 10 последних новостей
5. Валюта
6. Котировки
7. 5 лучших статей по рейтингу
8. 5 последних статей
9. 10 лучших компаний по рейтингу
10. 5 последних зарегистрировавшихся компаний
11. 5 последних новостей компаний
12. Тематический опрос
13. 5 блоков вставок с региональных подпорталов
14. 10 товаров из магазина
15. 3 блока архивов.
16. Реклама клиентов
17. Общепортальная реклама
18. 10 врезок со специализированных тематических сайтов.
19. 3 врезки с мульти медийной информацией
Ну и так далее. Сначала всё жило на мускуле, потом перевели на Oracle. Но только для того, чтобы организовать хранилище мультимедийной информации. Я мускул сильно зауважал после этого...
Дело не в количестве запросов, а в их виде. Часто приходится плевать на всякие "нормальные формы" и делать таблицы такими, чтобы максимально упростить вывод информации. При добавлении идёт дублирование некоторой инфы, но на скорости это не сказывается. У меня есть проект, где на морде под сотню запросов... Работает очень быстро.
Vetra, не, мимо. Я на Южке, пр.Вернадского. Но это лишний раз доказывает, что ЖКХ в Москве всё-таки работает. Вот у меня сейчас под окном три тётеньки в оранжевых касках бродит, крышу рассматривают. Уже на третий круг пошли :d
Не верю! Уже неделю пытаюсь их увидеть. Тремя разными браузерами. В разное время дня и ночи...
В нашем районе тоже такое практически невозможно. Чуть-что - ленточки, ленточки...
Vetra! Может мы - соседи? :)
Непонятно то, почему нет доступа ко второму сайту, если Вы ему помогаете!!! Т.е., насколько я понимаю, ДЕЛАЕТЕ ВМЕСТЕ!
