Странная сортировка таблиц Mysql

Тема в разделе "PHP программирование", создана пользователем GOsha, 30 окт 2008.

  1. GOsha

    GOsha Гость

    Есть MySQL Таблица:

    Region_ID smallint(5) UNSIGNED NotNull auto_increment
    Region_Parent_Country smallint(5) UNSIGNED NotNull
    Region_Name_Ru varchar(50)
    Region_Name_En varchar(50)

    Все просто - в таблице области. Привязанные к парент-кантри ИД = 2. Т.е. любимая наша РБ. )))

    Region_ID | Region_Parent_Country | Region_Name_Ru | Region_Name_En
    ________________________________________
    | 1 | 2 | Гродненская область | Grogno region |
    --------------------------------------------------------
    | 2 | 2 | Брестская область | Brest region |
    --------------------------------------------------------
    | 3 | 2 | Витебская область | Vitebsk region |
    --------------------------------------------------------
    | 4 | 2 | Гомельская область | Gomel region |
    --------------------------------------------------------
    | 6 | 2 | Минская область | Minsk region |
    --------------------------------------------------------
    | 7 | 2 | Могилевская область | Mogilev region |
    --------------------------------------------------------

    Таблица получена запросом:
    SELECT * FROM `geo_regions` ORDER BY `Region_Name_Ru` ASC LIMIT 0 , 30

    Теперь объясните мне, пожалуйста, каким образом Гродненская область оказалась впереди планеты всей, када сортировка задана по русскому полю в прямом порядке. Обратите внимание, что Гомель - после Витебска и Бреста. Т.е. правильно

    Та же ситуация и с таблицей городов - всю голову сломал. )))
    Подскажите, куда копать. А?
     
  2. Vovochka

    Vovochka Гость

    Если в общем и целом сортировка работает правильно, но за редким исключением, то скорее всего стоит присмотреться к этим исключениям.
    Может какой-нибудь левый нечитаемый символ затисался в ряды буков?
    Попробуй сделать UPDATE опять вручную (не копируя) набрав область. Или DELETE + INSERT, но не копируя название области, а забивая руками.
     
  3. GOsha

    GOsha Гость

    А вот фокус в том, что "Гордненская" - ортирует правильно. А вот "Гродненская" нет. Никаких символов там нет - все запросы писал вручную.
     
  4. GOsha

    GOsha Гость

    Дело было в кодировках таблиц MySQL.
    mysql_query("SET NAMES cp1251");
    ПОсле коннекта.
     
  5. Vovochka

    Vovochka Гость

    И когда народ перейдет на utf-8 :)
     
  6. GOsha

    GOsha Гость

    Никогда. )))
    ПОчитайте тут:
    http://proekt.org/art_093.htm - Много интересного по кодировкам.
    А вообще win-1251 используется потому что самая распространенная.
    + к этому прошу поругать Кирилла и Мефодия за изобретение кириллицы, заставляющей нас:
    - Переключать раскладки
    - Мучаться с кодировками
    - Пользоваться Пунто-свитчером
    - ПИсать транслитом
    - Мучаться со шрифтами
    ...... и ты ды....
     
  7. etc

    etc Гость

    Vovochka А лучше уйдет от MySQL. :)
     
  8. GOsha

    GOsha Гость

    Интересно, что ты предлагаешь взамен?
     
  9. etc

    etc Гость

    Т.е. вы хотите сказать что MySQL - единтвенная в мире?
    А если в "общеобразовательском" плане, то все от задачи зависит. PostgreSql например получше будет.
     
  10. Kmet

    Kmet Well-Known Member

    Регистрация:
    25 май 2006
    Сообщения:
    1.017
    Симпатии:
    1
    в упор не вижу плюсов от использования 1251 кодировки. а вот проблем при возможной i18n огрести получится.
     
  11. Vovochka

    Vovochka Гость

    +1

    Да и сего бы это MySQL не поддерживала utf8?
    Все время работаю с этой кодировкой.

    А из-за таких товарищей как некоторые здесь, доблестная эра юникода еще долга не наступит :(
     
  12. GOsha

    GOsha Гость

    2 etc: Я не говорил, что единственная в мире. Вы когда-нибудь пытались посадить цветок в горшок с помощью экскаватора? )))
    Для тех задач, которые приходится решать - мускуль самое удобное средство не требующее экзотики. Достаточно хостинга за 4-7 УСД/мес.

    2 Vovochka: Скорее всего вы просто любитель никсовых систем. ПОэтому для вас и Юникод в радость. ))) Просто я говорю, что у каждого на это своя религия. Позвольте мне остаться при моей. )))
    Я не говорю, что УТФ8 не поддерживается. Все там поддерживается. Просто если мы имеем БД с кодировкой вин-1251 а пришлем данные утф-8, то получим крякозяблы в базе. И наоборот. Поэтому выхода 2 - либо проверять и конвертить данные на входе, либо использовать на сервере и отправлять данные в кодировке такойже как и Мускуль. Я выбрал второе. Хотите первое - пожалуйста.
    По поводу доблестной эры. Я не вижу объективных причин отказываться от цп1251, но и не вижу причин привязываться к утф8.

    Кстати:
    Некоторые модули не готовы работать с unicode, взять для примера smarty. Функция «trancate», которая урезает строку не N-символов (удобно использовать для вывода абзаца новости, например), не умеет работать с многобайтовыми кодировками. Если сказать ей вырезать первые 30 символов от русской строки, то она вернет 15 по понятным причинам;
    *Конечно вопрос решается. Приделыванием "костылей".

    Цитата с php.net: Строка — это набор символов. В PHP символ это то же самое, что и байт, это значит, что возможно ровно 256 различных символов. Это также означает, что PHP не имеет встроенной поддержки Unicode’а. Некоторую поддержку Unicode’а обеспечивают функции utf8_encode() и utf8_decode().

    Все минусы UTF-8 - это издержки создания PHP и прочих языков до создания UTF-8. Так что это временное явление.

    *Купил бы ты сейчас электромобиль? Экологично, дешево. НО! Где ты его заряжать будешь? Хотя все знают, что в будущем они будут прекрасны.

    В итоге имеем единственный вопрос = "То, что за утф-8 будущее - это точно. Уже переходить или еще подождать? )))".
     
Загрузка...
Похожие Темы - Странная сортировка таблиц
  1. acs-nexus
    Ответов:
    0
    Просмотров:
    385
  2. acs-nexus
    Ответов:
    0
    Просмотров:
    303
  3. acs-nexus
    Ответов:
    0
    Просмотров:
    425
  4. acs-nexus
    Ответов:
    0
    Просмотров:
    451
  5. acs-nexus
    Ответов:
    0
    Просмотров:
    446

Поделиться этой страницей