Непонятно почему он меньше-то станет, указатели на все ряды с маленьким значением всё равно будут в нём хранится. И насколько это будет быстро работать?
в PostgreSQL нет bitmap индексов. Есть bitmap index scan, который используется при выполнении запросов, чтобы упорядочивать записи по физическому расположению и чтобы пересекать/объединять результаты поиска по нескольким индексам
Глупости, во-первых, можно быстро набирать русский, английский, какой-угодно текст без слепого набора, во-вторых, это не решает.
Если человек считает, что комментарии это неважно, то он и не будет их писать. Не нужно говорить им, что нужно комментировать код. Нужно сделать так, чтобы они поняли, что это реально полезно.
К слову, если ты не понимаешь зачем что-то делать, ты не сможешь ни сделать это толком, ни понять когда этого делать не нужно.
> лучшие программисты до 28 раз превосходят слабейших
выбрав в качестве слабейшего обезьяну, мы получим насколько угодно большое соотношение, поэтому я и говорю о делении на ноль. Задача здесь важна постольку поскольку
На самом деле ещё проблема в подсчёте такой цифры не только в метрике скорости/качества, но и вы в понятие плохой программист. Это попахивает делением на ноль. Обезьяна — плохой программист?
У вас или слабые сервера приложений, или не оптимизированный код. У меня:
1 сервер приложений (2 x Quad Core Xeon 2.5GHz, nginx + apache), он же выдаёт статику
1 сервер БД (Dual Core Xeon 3GHz, postgresql)
42M pageviews/month
кэширование в memcached только нескольких небольших небольших но очень нужных кусочков xml и json.
кэширование в файлах html и xml для нагруженых разделов сайта.
3. Захочешь — получиться, не захочешь — сделаешь такую какую захочешь.
5. Чем-то приходиться жертвовать ради скорости, чтобы не было xss достаточно проверять данные на входе.
1. Выбирайте на свой вкус, мне, например, нравится jinja2.
3. Если уж говорить о велосипедах, то скорее идея сабжа «а вот есть ещё такой быстрый велосипед». Но есть, то и дургие, ничего изобретать не надо.
5. Да там нет никакой xss, данные могут и не от пользователей браться, в конце концов. Просто если заворачивать данные в xml простой конкатенацией строк, то неизбежно будешь ловить такие баги время от времени, а как-то хитрее уже медленнее. Вообще, необходимость все данные заворачивать в xml не особо удобна.
Я не говорю же, что такой подход нельзя использовать, я говорю, что он негибкий, а значит для каких-то типов сайтов будет неэффективен, неудобен и/или порождать кучу извращений, чтобы втиснутся в рамки.
1. Не используйте большинство, используйте удобный.
3. Почему тогда просто не посчитать эти блоки на бекэнде всунуть их в страницу точно также как нгинкс, подтянуть что-то из кеша, тоже всунуть и выдать страницу?
4. Я писал другой багрепорт для libxslt раньше, понял, что всем похуй.
5. Не сразу, а когда возникнет такая ситуация, и в такой ситуации у тебя тупо перестанет отображаться вся страница.
1. SSI + XSLT + шаблоны в бэкенде (без последних если используем только xslt) шаблоны двух видов — гемор. xslt сам по себе не самый удобный шаблонизатор.
3. Такая разница, что если блок не кэшируется принципиально, то придётся запрашивать его с бекэнда каждый раз, и если таких блоков больше одного, то вся эта солянка теряет смысл. И даже если один, она становится очень сомнительной.
4. Тестировали, некоторые трансформации текут. Возможно, если просто подсовывать значения, то с этим не столкнёшься.
5. Намного сложнее, чем html, любой неэкранированный символ, любая неопредённая entity, неправильный utf символ и всё, весь документ сломался.
Во-первых, это гемор, во-вторых xslt — это не так уж быстро, в третьих остаются блочки некэшируемые по другим причинам: число сообщений у юзера, статус онлайн кого-нибудь, просто часто обновляющаяся инфа, в-четвёртых, libxml/libxslt текут, в-пятых, чтобы делать xsl-трансформацию нужно чтобы ssi-скрипты выдавали валидный xml.
Ну и в конце концов, что у нас получится? Бекэнд со своим движком и какими-то шаблонами (предположительно), ssi-шаблончики, xsl-трансформации. жуткий зоопарк.
Если человек считает, что комментарии это неважно, то он и не будет их писать. Не нужно говорить им, что нужно комментировать код. Нужно сделать так, чтобы они поняли, что это реально полезно.
К слову, если ты не понимаешь зачем что-то делать, ты не сможешь ни сделать это толком, ни понять когда этого делать не нужно.
выбрав в качестве слабейшего обезьяну, мы получим насколько угодно большое соотношение, поэтому я и говорю о делении на ноль. Задача здесь важна постольку поскольку
1 сервер приложений (2 x Quad Core Xeon 2.5GHz, nginx + apache), он же выдаёт статику
1 сервер БД (Dual Core Xeon 3GHz, postgresql)
42M pageviews/month
кэширование в memcached только нескольких небольших небольших но очень нужных кусочков xml и json.
кэширование в файлах html и xml для нагруженых разделов сайта.
Всё работает с большим запасом
5. Чем-то приходиться жертвовать ради скорости, чтобы не было xss достаточно проверять данные на входе.
3. Если уж говорить о велосипедах, то скорее идея сабжа «а вот есть ещё такой быстрый велосипед». Но есть, то и дургие, ничего изобретать не надо.
5. Да там нет никакой xss, данные могут и не от пользователей браться, в конце концов. Просто если заворачивать данные в xml простой конкатенацией строк, то неизбежно будешь ловить такие баги время от времени, а как-то хитрее уже медленнее. Вообще, необходимость все данные заворачивать в xml не особо удобна.
Я не говорю же, что такой подход нельзя использовать, я говорю, что он негибкий, а значит для каких-то типов сайтов будет неэффективен, неудобен и/или порождать кучу извращений, чтобы втиснутся в рамки.
3. Почему тогда просто не посчитать эти блоки на бекэнде всунуть их в страницу точно также как нгинкс, подтянуть что-то из кеша, тоже всунуть и выдать страницу?
4. Я писал другой багрепорт для libxslt раньше, понял, что всем похуй.
5. Не сразу, а когда возникнет такая ситуация, и в такой ситуации у тебя тупо перестанет отображаться вся страница.
3. Такая разница, что если блок не кэшируется принципиально, то придётся запрашивать его с бекэнда каждый раз, и если таких блоков больше одного, то вся эта солянка теряет смысл. И даже если один, она становится очень сомнительной.
4. Тестировали, некоторые трансформации текут. Возможно, если просто подсовывать значения, то с этим не столкнёшься.
5. Намного сложнее, чем html, любой неэкранированный символ, любая неопредённая entity, неправильный utf символ и всё, весь документ сломался.
Ну и в конце концов, что у нас получится? Бекэнд со своим движком и какими-то шаблонами (предположительно), ssi-шаблончики, xsl-трансформации. жуткий зоопарк.