Вы удивитесь, но писать оригинальные названия можно без UTF.
HTML-entities это вполне позволяют, причем прозрачно (!) для пользователя. То есть, можно писать хоть на иврите, хоть на катакане, браузер сам отправит нужные entities на сервер.
А теперь попробуйте прикинуть какой объем текста на рутрекере пишется латинскими и русскими буквами, а какой — на иврите, катакане и прочих языках, символов которых нет в cp1251. И получите, что ради 0.001% текстов вы раздуваете хранилище, излишне напрягаете процессор, гоняете больше данных по сети.
Впрочем, опять же — я не призываю отказаться от utf-8.
Я призываю с головой подходить к проектированию систем и использовать то, что требуется, там, где это действительно необходимо, и тогда, когда это нужно, а не только потому, что «все так делают».
P.S. А еще этот комментарий нужен тем (не текст, а наличие комментария), кто лепит минусы тем, чье мнение отличается от их. Лепите, лепите, коль иного мнения вы не приемлите, а все другие мои комментарии в этом топике уже заминусовали. Как дети, ей богу.
А Вы хоть понимаете, что основная зарубежная русскоязычная аудитория будет как раз у того 1% процента проектов, для которых использование UTF не только желательно, но и обязательно?
Смотрите, в рунете порядка нескольких миллионов доменов, процент от них — десятки тысяч. В эти тысячи вполне попадает большинство соц.сетей, больших форумов, новостных ресурсов, почтовых служб и инстант-мессенджеров. Выкиньте их, и увидите, что зарубежная аудитория оставшихся не такая и большая, чтобы задумываться.
А всё зависит от индексов, которые будут использоваться для запроса.
Поэтому действительно, в каждом конкретном случае может быть как LIMIT быстрее, так и MAX не медленнее.
Не, у Яндекса всё умнее.
Они по возможности используют КОИ (и это в большинстве случаев оправдано, хотя не очень понятно почему кои, а не цп1251), но если в письме встречаются символы, которых в КОИ нет, отправляют письма в UTF.
Насчет одноклассников не уверен, проверить не могу.
В целом, Вам ответили — хэ его зэ как будет себя вести клиент, не поддерживающий полноценную работу с транзакциями, в среде с кучей параллельных этих самых штук. Да еще с разными уровнями изоляции, откатами, коммитами итп. Но эт точно не проблема InnoDB
Да понятно, что можно. Можно даже залезть в сорцы и реализовать более стойкий к коллизиям алгоритм генерации псевдослучайного числа. Но сам факт меня опечалил, да.
Начните для начала разделять тех, у кого «нет cp1251», от тех, кто «находится зарубежом и не смог ее включить». 95% аудитории Рунета сидит на Винде, с чего бы у них не было 1251?
Какбэ объяснимо почему поправить таблицу указателей на записи фиксированной длины (если нет Varchar) сильно быстрее, чем копирование данных в новое место. Эт также как любимый аргумент myISAM'щиков, что count(*) работает быстрее, чем в InnoDB.
В целом, конечно, холиварить о сферическом движке в вакууме можно долго.
Главное, чтоб потом при проектировании включали голову.
По-моему, такое только для ситуации, когда надо уменьшить место, а не увеличить. Не?
Что-то такое помнится встречалось в документации к работе с InnoDB.
Никогда, у меня для поездок ноут, но в этом плане я нерепрезентативен, признаюсь.
Возможно, мою цитату не очень поняли.
Я имел ввиду, что проекты Рунета в большинстве своем рассчитаны на русскоговорящее население, а не на носителей китайского языка, например. Поэтому в большинстве случаев вполне хватит cp1251. Естественно, если у проекта есть значительная иноязычная аудитория, в текстах для которой используется большое количество символов не из cp1251, то UTF будет рулить. Но на практике дефолтное использование этой кодировки — тоже самое, что пытаться сразу использовать Oracle для домашней гостевой книги.
Дык вернуть могло в рамках той сессии, которая сделала вставку.
Но если стоит уровень изоляции REPEATABLE READ и параллельная сессия не делала commit (даже если исходная закоммитила данные), то она не увидит вставки.
Не видя конректного скрипта, мне сложно точно сказать, что же там было, но описанный мной сценарий весьма вероятен, можете попробовать в двух параллельных сессиях к базе его воспроизвести при отключенном автокоммите. Потом попробуйте поменять уровень изоляции на READ COMMITED и снова повторить действия (insert + commit). Будет разница даже, казалось бы, на одном движке.
Дык это, опять же, характерно и для Оракла — если много удалять/вставлять в таблицу (например, используя её для организации очереди), то со временем даже SELECT * FROM tbl WHERE rownum < 100 будет тормозить, пока не сделаешь analize. Именно по причине фрагментации.
HTML-entities это вполне позволяют, причем прозрачно (!) для пользователя. То есть, можно писать хоть на иврите, хоть на катакане, браузер сам отправит нужные entities на сервер.
А теперь попробуйте прикинуть какой объем текста на рутрекере пишется латинскими и русскими буквами, а какой — на иврите, катакане и прочих языках, символов которых нет в cp1251. И получите, что ради 0.001% текстов вы раздуваете хранилище, излишне напрягаете процессор, гоняете больше данных по сети.
Впрочем, опять же — я не призываю отказаться от utf-8.
Я призываю с головой подходить к проектированию систем и использовать то, что требуется, там, где это действительно необходимо, и тогда, когда это нужно, а не только потому, что «все так делают».
P.S. А еще этот комментарий нужен тем (не текст, а наличие комментария), кто лепит минусы тем, чье мнение отличается от их. Лепите, лепите, коль иного мнения вы не приемлите, а все другие мои комментарии в этом топике уже заминусовали. Как дети, ей богу.
Это плохо?
Смотрите, в рунете порядка нескольких миллионов доменов, процент от них — десятки тысяч. В эти тысячи вполне попадает большинство соц.сетей, больших форумов, новостных ресурсов, почтовых служб и инстант-мессенджеров. Выкиньте их, и увидите, что зарубежная аудитория оставшихся не такая и большая, чтобы задумываться.
Поэтому действительно, в каждом конкретном случае может быть как LIMIT быстрее, так и MAX не медленнее.
Они по возможности используют КОИ (и это в большинстве случаев оправдано, хотя не очень понятно почему кои, а не цп1251), но если в письме встречаются символы, которых в КОИ нет, отправляют письма в UTF.
Насчет одноклассников не уверен, проверить не могу.
Кстати, Яндекс и Одноклассники юзают UTF, насколько мне известно.
Но именно по той причине, что они относятся к тому самому одному проценту проектов.
В целом, конечно, холиварить о сферическом движке в вакууме можно долго.
Главное, чтоб потом при проектировании включали голову.
Что-то такое помнится встречалось в документации к работе с InnoDB.
Возможно, мою цитату не очень поняли.
Я имел ввиду, что проекты Рунета в большинстве своем рассчитаны на русскоговорящее население, а не на носителей китайского языка, например. Поэтому в большинстве случаев вполне хватит cp1251. Естественно, если у проекта есть значительная иноязычная аудитория, в текстах для которой используется большое количество символов не из cp1251, то UTF будет рулить. Но на практике дефолтное использование этой кодировки — тоже самое, что пытаться сразу использовать Oracle для домашней гостевой книги.
А у меня вот проблема — rand() стал изредка выдавать коллизии всего после пары миллионов айдишников =))
Каких символов в UTF-8, по-вашему, не хватает для рунета в cp1251?
У Мэйл.Ру одно из самых больших хранилищ в Восточной Европе.
Было бы самым большим, если б везде использовали UTF, ага =)
(А откаты — частыми и большими, гы-гы).
Ну да, проблема с фрагментацией будет. А почему у MyISAM ее не может быть? =)
Но если стоит уровень изоляции REPEATABLE READ и параллельная сессия не делала commit (даже если исходная закоммитила данные), то она не увидит вставки.
Не видя конректного скрипта, мне сложно точно сказать, что же там было, но описанный мной сценарий весьма вероятен, можете попробовать в двух параллельных сессиях к базе его воспроизвести при отключенном автокоммите. Потом попробуйте поменять уровень изоляции на READ COMMITED и снова повторить действия (insert + commit). Будет разница даже, казалось бы, на одном движке.