|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Решил создать новую тему, т.к. явно обсуждающейся такой темы нигде не нашел.
Собственно вопрос в заголовке. В дополнение картины хочу упомянуть о том что в базе в основном храним русс язык. Английский, Украинский, Белорусский - в основном исключения (отзывы пользователей и т.д.) База большая - около 500 тыс наименований + к ним описания для каждого.. отзывы, рейтинги итд.
В итоге ну 99% - русские символы. Я понимаю лишь что такая база в UTF будет в 2 раза больше весить. По логике будет кушать в 2 раза больше оперативки. В два раза менее эффективнее будет расходоваться отведенные кэши таблиц (если взять эти кеши равного объема)...
почему тянет к UTF ? - в некоторых моменах не надо делать лишние движения с "iconv", + ajax с которым еще не познакомился на "ты", но он вроде не любит 1251.. ему бы UTF..
Я понимаю что кодировка базы и вебсервера - это разное.. но как по мне надо или все в UTF или все в CP 1251
Кто имел дело, кто обжегся, кто намучился... просьба... помогите толковым советом. Хочу понять, и осознанно сделать выбор. Спасибо!
Неактивен
UTF будет занимать в 3 раза больше. В MySQL на каждый UTF символ отводится 3 байта, даже если он двухбайтовый. Также длина индексов увеличится, что не в плюс.
Вы можете сконвертить в любую кодировку при обращении к базе. Скажите SET NAMES UTF8 и MySQL будет все перед отправкой клиенту перекодировать в UTF8, и также принимать информацию в UTF8, а хранить в той кодировке, в которой определена таблица.
Минус 1251 - неуниверсальность, некоторых символов нет (например, некоторые немецкие буквы, длинное тире из ворда).
Неактивен
еще.. по моему не совпадение.. но 1251 был когда-то почти стандартным вариантом.. сейчас utf гораздо более популярен нежели 5 лет назад..
(это больше относительно сайтостроения, хотя в мюскл возможно также таже тенденция)
Отредактированно Sasha_ch (09.02.2012 19:58:42)
Неактивен
Скажите SET NAMES UTF8 и MySQL будет все перед отправкой клиенту перекодировать в UTF8
да да, знаю, пользовал несколько раз такое. Единственно что не хотелось бы лишний раз перекодировать.. все-таки нагрузка от этого не уменьшается.. да и как-то боязно мол это геморойно может оказаться (еще не знаю где именно, но беспокойно)
хотя это вариант конечно сделать базу в 1251 + setnames utf + сам сайт на utf...
делать например для каталога cp1251 а отзывы например хранить в utf таблице - тоже как-то ахти красиво выходит..
Неактивен
>>Минус 1251 - неуниверсальность, некоторых символов нет (например, некоторые немецкие буквы, длинное тире из ворда).
..подтолкнуло на идею "а сохраниться ли длинное тире на аналогичных сайтах? " )) ...
Неактивен
гм... добавил пару отзывов сейчас с длинным тире (нажимаю альт+0151 получается вот — )
так на сайтах с кодировкой 1251 уже на 2-х, сохранился отзыв удачно... тю..
Неактивен
вот читаю:
http://www.sd-company.su/article/html_c … _vs_cp1251
...думаю.. может махнуть на накладные ресурсы и пустить все в UTF-8 ?
..боюсь SET names... да и как-то не понятно ну как вот на входе в PHP допустим имеем данные utf (с возможными UTF символами, и символами не поддерживаемые 1251) которые потом суем в мюскл базу 1251...
Это же винегрет или как?
Неактивен
Sasha_ch написал:
вот читаю:
http://www.sd-company.su/article/html_c … _vs_cp1251
...думаю.. может махнуть на накладные ресурсы и пустить все в UTF-8 ?
..боюсь SET names... да и как-то не понятно ну как вот на входе в PHP допустим имеем данные utf (с возможными UTF символами, и символами не поддерживаемые 1251) которые потом суем в мюскл базу 1251...
Это же винегрет или как?
В том документе не все относится к MySQL. В MySQL каждый символ UTF8 будет занимать ровно три байта памяти.
У UTF8 преимущество - универсальность и отсутствие необходимости перекодировать. В описанном вами примере часть символов потеряется при вставке.
Неактивен
rgbeast написал:
В MySQL каждый символ UTF8 будет занимать ровно три байта памяти.
- кроме тех символов что умещаются в одном байте (латинские, цифры итд)
Я вот смотрю на свои таблицы, и думаю что увеличится ведь объем фактически только "дополнительного описания", основные фильтры / выборки используют цифровые столбцы, а потом уже цифрам находятся их сопоставления в виде текстовых значений из других таблиц... которые уже будут скорее всего 3-х байтовые...
Неактивен
вот:
freemarket.kiev.ua/186722/comment/p2/amazon-kindle-3-wi-fi.html
( возле слова "отличная читалка" иероглиф )
кодировка страницы 1251, как иероглиф то отображается? )) что за шайтанство то? ))
Неактивен
Из ваших слов следует, что увеличение объема текста для вас не будет критическим, поэтому лучше использовать utf-8.
Насчет иероглифа - возможно, что браузер содержит средства для отображения инфы в неправильной кодировке - не могу проверить, так как сейчас на той странице иероглиф мне не виден.
Неактивен
Страниц: 1
