Все кто хотел - уже высказал своё мнение. Здесь, действительно, никто никому уже ничего не докажет.
А тема начинает напоминать оргию на кладбище...
Один в один ситуация...
Evis, Гугль не знает такого тега, как NOINDEX. Только в заголовке страницы. Для того, чтобы PR не утекал ссылки должны быть оформлены другим образом: к ним необходимо добавить rel="nofollow".
Всё ОК. Вечером скину. Сейчас на другом компе сижу.
З.Ы.
Но есть совет - лучше перейти на другой скрипт. В сети полно бесплатных гостевух...
Наверно много новых пользователей добавилось. Тему найти не смог, приведу картинку заново:
Почти. Может стоять и Ваш адрес, только через редирект, например после знака ?. Прямая ссылка - это когда тег href содержит только адрес сайта, который Вы дали.
Прямая. А onclick используется, например, для учёта количества переходов и т.п.
О! Ну вот и я от "своей" Наташки письмо получил!
Уважаемый 3dn! Заставил себя "асилить" Ваш сумбурный бред, а теперь по порядку.
Есть такое понятие, как многопользовательские системы. В зависимости от прав доступа, пользователю показываются или не показываются те или иные разделы системы. На них накладывается маска. Маска к Вашему удивлению (профиль пользователя) также хранится в базе данных.
Ну если в среднем 30-40 тысяч уников в сутки для Вас это мало, то жму руку. Быстро для меня - это не более 0.2-0.3 секунды на общее время выполнения запросов к БД.
Индексы применяются для ускорения сортировки, выборки из базы по ключу и создания связанных запросов (join). Ещё раз повторюсь, что для ускорения работы и уменьшения нагрузки на сервер СУБД часть таблиц денормализуется, что позволяет не использовать связанные запросы и существенно сокращает количество обращений к БД. Плюс поверьте мне на слово, а если не доверяете - поставьте эксперимент и проверьте, что очень часто в системах с большим количеством пользователей и большими массивами информации гораздо эффективнее сделать пять запросов подряд, чем один запрос с тремя джойнами. И ещё, так для пополнения начальных данных о СУБД, - при конфигуроровании СУБД часть памяти мы выделяем под различные кэши, так вот один из них служит для кеширования индексов, другой последних запросов и т.п. Эта система гораздо сложнее и умнее, чем Вы думаете. Приведу протой пример: в таблицу СУБД MySQL нужно добавить 10К записей. Казалось-бы - простая задача. Ан нет, - опытный программист перед этим выключит индексы, сделает добавление, а потом их включит. А знаете почему? Потому что после каждой операции insert кэш индекса заново перестраивается и сбрасывается на диск. А при правильном подходе это будет сделано только один раз. Представляете, какой выигрыш в производительности получается, когда эта таблица содержит сотни тысяч записей? Как минимум- 2-3 порядка. Естественно, программист должен быть уверен в том, что на вход он подаёт правильные данные и индекс потом будет создан. Но это уже другая тема...
Ответ на тему топика другой - запросов должно быть столько, сколько необходимо для максимально эффективного отображения необходимой пользователю информации.
База данных, к Вашему сведению - это тоже файлы. Это раз. Самыми оптимальными являются те системы, которые для выполнения какой-то операции наименьшим образом загружают вычислительные ресурсы . Это два.
Кто бы спорил. Только позвольте сделать одно замечание, когда Вы используете файлы, то по сути создаёте свою миниСУБД, т.к. пишите небольшую надстройку для управления записью-чтением данных из файлов. Чем не СУБД. Иногда, Вы не поверите, для таких файлов делают даже индексные файлы, что ещё больше приближает эту минисистему к стандартам СУБД.
Любой НОРМАЛЬНЫЙ проект, который приносит владельцу стабильный доход (под доходом я понимаю суммы от 1К$ и выше), не будет хоститься на одном компьютере с другими проектами, т.к. не будет ставить свой бизнес в зависимость от того, что какой-то программист на своём хомяке зациклил какую-нибудь процедуру. Такие проекты располагаются на выделенных серверах, а зачастую даже не на одном.
Что касается кеширования, - при правильном написании проекта оно выполняется частично сервером хостера, частично браузером клиента, а частично процедурами, предусмотренными создателем проекта. Огромная роль в это отводится также операционной системе, СУБД и железу сервера. И, по-моему, Вы не совсем представляете, что такое динамическое изменение информации, когда 2/3 выводимой информации изменяется не реже, чем раз в 3-5 минут.
Так что, подводя итог всему могу сказать одно - теоретически Вы сказали правильные вещи, а практически - глупость. Скорее всего, это произошло от того, что Вы пока не имеете понятия о том, что такое большие системы. И ещё, небольшая просьба - не вводите в заблуждение других людей и не давайте советы до тех пор, пока досконально не разберётесь в теме и не приобретёте достаточного опыта.
Жене Путина предложите...
