Не переживайте за нас, никого не уволили.
Эти подробности исключительно художественный вымысел ;)
А базы самые разные, как и задачи.
Плюсы и минусы есть в каждой СУБД, какую не выбери.
1. Есть ли гарантии, что мы не забудем раздать всем сестрам по серьгам всем нужным юзерам?
2. Критично ли, что какое-то время данная процедура будет недоступна части посетителей сайта?
А смысл? Подключение таким образом скрипта всё равно, как правило, из другого файла. А для него и счетчик сойдет.
Тем более, что в этом файле наверняка подключается несколько разных скриптов/файлов стилей, так что для каждого будет свой номер.
Вот пример с одного из моих проектов: />
<script type="text/javascript" src="/js102/common.js"></script>
<script type="text/javascript" src="/js112/context_help.js"></script>
<script type="text/javascript" src="/js116/complaint_script.js"></script>
<script type="text/javascript" src="/js034/plugin_fly.js"></script>
Эээ? В указанном подходе Вам будет достаточно менять то, что находится вместо звездочки.
Увеличивайте ручками на единицу и не заморачивайтесь.
При наличии нормального шаблонизатора это делается ровно в одном месте и занимает порядка 3 секунд.
Какой-то ппц пятничный.
Всё описанное реализуется одной строкой кода в каком-нить акселераторе типа 0w или nginx'а и использованием нормального шаблонизатора.
Да не надо в базе аватары хранить. И даже пути к ним — не надо. Головой думать надо.
данный [способ]… не создает лишней нагрузки.
На сервер — практически не создает, да. На сеть и клиента — создает. Второе даже более критично. Юзер будет ждать пока загрузятся несуществующие аватары (открою секрет — они не могут грузиться браузером все одновременно, существуют ограничения на соединения с одним хостом). Считайте это законом сохранения нагрузки — если где-то нагрузки убывает, значит где-то ее прибывает. Вы и перекладываете с больной головы на здоровую.
Уважаемый И.Сысоев писал о том, что nginx сопобен выдержать 10 000 запросов в секунду
Тут ко мне на собеседование приходил один товарищ, утверждал, что написал софт, который выдерживает до 70 тысяч запросов в секунду… А еще я слышал, что Петя Зайцев Мускулом Оракл порвал… Дальше-то что? По-любому, если нгинксу надо выдерживать не N запросов, а 10*N, то эт несколько хуже. Даже если не отражается на нагрузке.
Опираясь на ваш коммент, вы знаете 2 способа
Эт я Вам по доброте душевной два рассказал. Могу больше. Консультации оплатите?
напиши хоть один положительный коммент, а лучше пост, подчеркну, положительный. Достал плакаться.
Положительные посты — это не ко мне.
О своих успехах я не распространяюсь, а ближнего пнуть на путь истинный — милое дело.
Мой способ не юзает базу, работает отдельно, по сути не требует её наличия
В Вашем способе, как и в способах, предложенных в этом топике, присутствует хранилище. Хоть база, хоть мемкеш, хоть файловая система — суть одно. Эффективность доступа к любому из них будет разная в разных проектах. И выбирать конкретный метод — дело архитектора.
Приведу пример.
Если сервис изначально целиком динамический, кеширование применяется незначительно, за данными постоянно нужно ходить в базу, то заложив при проектировании одно поле в таблицу юзеров для различных флагов (а наличие аватара — всего лишь флаг), можно прекрасно обойтись без излишних запросов, выводя где нужно аватар, где его нет — дефолтную картинку, прекрасно кешируемую в браузере. $flags & 0x1 — очень быстрая операция сравнения.
Второй пример.
Сайт — практически статика (или хорошо кешированная динамика), в базу решено ходить по минимуму, мемкеш не нужен, ибо особо нечего там держать, да и лишняя прослойка. Тогда вариант решения — переложить логику отдачи аватаров на быстрый акселератор (например, nginx), повесить его на отдельный ip, врубить небольшой кип-элайв и отдавать аватары в рамках одной TCP-сессии. И всё-таки отправлять команду их кешировать. Хотя бы на среднее время ежедневной жизни на сайте среднего пользователя проекта.
Вы упираетесь в один метод.
Я — знаю несколько методов и могу заранее выбрать подходит ли мне какой-то из них.
Мой подход — правильней.
coalesce входил в стандарт, когда Вы еще в школе учились и вряд ли помышляли об SQL'е.
толку от него как от «семиуровневой модели OSI» — чисто академический, т.е. слабо применимый на практике.
Зачем придумывать отговорки? Так и скажите — никогда не знал про coalesce и мануал не читал.
Большинство широкоиспользуемых СУБД этот стандарт в основных моментах поддерживают. Но нет же, надо обязательно брать решение, которое поддерживается не всеми.
Вьюха позволяет разработчику абстрагироваться от реализации
Да что Вы говорите? Следующие Ваши слова, видимо, будут про ORM.
Для выборки основных данных пользователя Вы так и так будете использовать один основной запрос.
Но нет же, зачем-то нужно вводить промежуточную вьюху.
Я вообще к тому, что способов можно придумать много и лучше выбирать способ под конкретный проект, а не рассуждать о правильности или неправильности сферического метода в вакууме
Сравнивая одни и те же вещи в разных СУБД, очень заметно как сильно уступает Мускул Постгресу и Ораклу.
Эти подробности исключительно художественный вымысел ;)
А базы самые разные, как и задачи.
Плюсы и минусы есть в каждой СУБД, какую не выбери.
Но только, если уже был сделан DROP процедуры, в этом списке этой процедуры не будет.
Особенно, в части работы с перлом.
1. Есть ли гарантии, что мы не забудем раздать
всем сестрам по серьгамвсем нужным юзерам?2. Критично ли, что какое-то время данная процедура будет недоступна части посетителей сайта?
В крайнем случае, замена счетчика в N файлах — одна строка на bash с использованием find + grep + sed + awk
Тем более, что в этом файле наверняка подключается несколько разных скриптов/файлов стилей, так что для каждого будет свой номер.
Вот пример с одного из моих проектов:
/>
<script type="text/javascript" src="/js102/common.js"></script>
<script type="text/javascript" src="/js112/context_help.js"></script>
<script type="text/javascript" src="/js116/complaint_script.js"></script>
<script type="text/javascript" src="/js034/plugin_fly.js"></script>
Достигается ровно то же самое, что предложили Вы, но без излишнего кода.
Можете писать в шаблонах хоть /css/001/style.css, хоть /js002/button.js
Увеличивайте ручками на единицу и не заморачивайтесь.
При наличии нормального шаблонизатора это делается ровно в одном месте и занимает порядка 3 секунд.
Всё описанное реализуется одной строкой кода в каком-нить акселераторе типа 0w или nginx'а и использованием нормального шаблонизатора.
На сервер — практически не создает, да. На сеть и клиента — создает. Второе даже более критично. Юзер будет ждать пока загрузятся несуществующие аватары (открою секрет — они не могут грузиться браузером все одновременно, существуют ограничения на соединения с одним хостом). Считайте это законом сохранения нагрузки — если где-то нагрузки убывает, значит где-то ее прибывает. Вы и перекладываете с больной головы на здоровую.
Тут ко мне на собеседование приходил один товарищ, утверждал, что написал софт, который выдерживает до 70 тысяч запросов в секунду… А еще я слышал, что Петя Зайцев Мускулом Оракл порвал… Дальше-то что? По-любому, если нгинксу надо выдерживать не N запросов, а 10*N, то эт несколько хуже. Даже если не отражается на нагрузке.
Эт я Вам по доброте душевной два рассказал. Могу больше. Консультации оплатите?
О своих успехах я не распространяюсь, а ближнего пнуть на путь истинный — милое дело.
В Вашем способе, как и в способах, предложенных в этом топике, присутствует хранилище. Хоть база, хоть мемкеш, хоть файловая система — суть одно. Эффективность доступа к любому из них будет разная в разных проектах. И выбирать конкретный метод — дело архитектора.
Приведу пример.
Если сервис изначально целиком динамический, кеширование применяется незначительно, за данными постоянно нужно ходить в базу, то заложив при проектировании одно поле в таблицу юзеров для различных флагов (а наличие аватара — всего лишь флаг), можно прекрасно обойтись без излишних запросов, выводя где нужно аватар, где его нет — дефолтную картинку, прекрасно кешируемую в браузере. $flags & 0x1 — очень быстрая операция сравнения.
Второй пример.
Сайт — практически статика (или хорошо кешированная динамика), в базу решено ходить по минимуму, мемкеш не нужен, ибо особо нечего там держать, да и лишняя прослойка. Тогда вариант решения — переложить логику отдачи аватаров на быстрый акселератор (например, nginx), повесить его на отдельный ip, врубить небольшой кип-элайв и отдавать аватары в рамках одной TCP-сессии. И всё-таки отправлять команду их кешировать. Хотя бы на среднее время ежедневной жизни на сайте среднего пользователя проекта.
Вы упираетесь в один метод.
Я — знаю несколько методов и могу заранее выбрать подходит ли мне какой-то из них.
Мой подход — правильней.
А кунфу сильнее, угу.
А Вас я поправил исключительно для того, чтобы те, кто будет читать всё это, не повторяли Ваших ошибок. И читали мануалы.
Зачем придумывать отговорки? Так и скажите — никогда не знал про coalesce и мануал не читал.
Большинство широкоиспользуемых СУБД этот стандарт в основных моментах поддерживают. Но нет же, надо обязательно брать решение, которое поддерживается не всеми.
Пользуйтесь, это бесплатно.
Да что Вы говорите? Следующие Ваши слова, видимо, будут про ORM.
Для выборки основных данных пользователя Вы так и так будете использовать один основной запрос.
Но нет же, зачем-то нужно вводить промежуточную вьюху.