access to MySQL via ODBC
default-character-set
см.
//johnny/public/Docs/DataBase/MySQL/mysql_manual-13_06_2001.pdf
стр. 401
см.
//johnny/public/Docs/DataBase/MySQL/mysql_manual-13_06_2001.pdf
стр. 401
не помогает 
ставлю default-character-set=cp1251 и koi8-r - все равно одно и тоже. ему похоже пофиг на это дело.
ставлю default-character-set=cp1251 и koi8-r - все равно одно и тоже. ему похоже пофиг на это дело.
Нужно немного пропатчить MyODBC или как там оно зовется.
С помощью библиотеки libiconv перекодировка делается легко
и просто
С помощью библиотеки libiconv перекодировка делается легко
и просто
естественно. ведь таким образом, ты сообщаешь серверу, что база у тебя лежит в koi8-r (это нужно, например, для правильной сортировки
а крутить надо клиента, т.е. что бы он каким то образом востпринимал эту самую кодировку.
а крутить надо клиента, т.е. что бы он каким то образом востпринимал эту самую кодировку.
то есть патчить ODBC-драйвер виндовый? это ж геморрой наверное, там srpm-ок нет. неужели никто такое не вылечил еще, у всех кодировки совпадали?
а хранить все в cp1251 ?
Имхо, лечить надо сервер, это его дело -- перекодировать.
В постгре, например, можно после коннекта задать переменную типа клиент-кодепэйдж и сервер сам будет заниматься перекодировкой ( правда вплоть до 7.0 эта фенька не работала и когда такая нужда возникла, пришлось исходники править
В постгре, например, можно после коннекта задать переменную типа клиент-кодепэйдж и сервер сам будет заниматься перекодировкой ( правда вплоть до 7.0 эта фенька не работала и когда такая нужда возникла, пришлось исходники править
можно базу перефигачить в cp1251 и default-character-set поставить cp1251
а потом класть все в cp1251 туда
если ты конечно не испоьзуешь там ничего кроме одной это базы..
imho это легче чем патчить odbc..
а потом класть все в cp1251 туда
если ты конечно не испоьзуешь там ничего кроме одной это базы..
imho это легче чем патчить odbc..
ну дык то ж postgres, а то mysql
Ну дык вопрос, что патчить -- клиент или сервер видимо, идеологически правильно сервер
видимо, идеологически правильно серверне согласен
Проблема в том, что база постоянно обновляется на этом юниксовом сервере, причем все поступающие данные в кодировке koi8-r. Так что хранить в cp1251 все тоже геморно. Если кто не понял - речь идет чтобы из MS Access лазить по внутренностям SMBSearch.
Можно когда кладешь в базу перекодировать на лету.
Функция перекодировки займет всего пару строк.
Не знаю правда как это на нагрузку на сервер скажется..
Хотя это же все offline-работа. Думаю перемен в худшую сторону не случилось бы.
Функция перекодировки займет всего пару строк.
Не знаю правда как это на нагрузку на сервер скажется..
Хотя это же все offline-работа. Думаю перемен в худшую сторону не случилось бы.
А используются ли символы из блока koi8-r в протоколе MySQL?
Если нет, то можно между клиентом и сервером поставить
что нибудь типа cyrproxy. Или можно написать свой mysql-cyr-proxy, который будет перекодировать запросы и ответы
и стоять между клиентом и сервером. но это меня уже понесло
Если нет, то можно между клиентом и сервером поставить
что нибудь типа cyrproxy. Или можно написать свой mysql-cyr-proxy, который будет перекодировать запросы и ответы
и стоять между клиентом и сервером. но это меня уже понесло
а перейти на postgres не хочешь ? оно это умеет
Интересная мысль! Надо подумать. Киньте мне URL на какую-нибудь статью о сравнении MySQL и PostgreSQL. Больше всего меня интересует, конечно же скорость. Причем скорее даже не SELECT-ов, а INSERT-ов.
MySQL быстрее Postgres-а на маленьких базах - где-то до нескольких десятков тысяч строк. Зато на базах побольше - Postgres "лучше".
Странное заявление: базы не исчисляются в количествах строк
из личног опыта: когда был выбов, использовал постгрю. если кому интересно, мого обьяснить, почему.
из личног опыта: когда был выбов, использовал постгрю. если кому интересно, мого обьяснить, почему.
> базы не исчисляются в количествах строк
Да ну?
Очевидно, что можно сделать одно поле 1Mb, а строку из 1000000 таких полей. И одна такая строка будет больше занимать чем 10000 строк из одного поля int.
Это не точный критерий, а примерная рекомендация - "условная строка".
Да ну?
Очевидно, что можно сделать одно поле 1Mb, а строку из 1000000 таких полей. И одна такая строка будет больше занимать чем 10000 строк из одного поля int.
Это не точный критерий, а примерная рекомендация - "условная строка".
Вот конкретные цифры: в базе примерно 3,4 миллиона записей. Общий объем - 125 Мб (+ еще индексы на 55 Мб). Как в таких условиях PostgreSQL vs MySQL?
Если бы все базы были плоскими, как хорошо было бы жить на свете и тогда кроме мускула ничего не надо было бы...
и еще -- выборка по инту или варчару принципиально отличается.
2Алекс: если у тебя только плоские выборки, то постгря выигрыша не даст. А вот инсерты на больших таблицах у постгри быстрее по моим тестам (но я тестировал под свою задачу, так что модет это в общем и не верно). А так несколько милионов записей для постгри фигня.
Кстати, в постгре не рекомендуется вешать индексы на строковые типы.
и тогда кроме мускула ничего не надо было бы...и еще -- выборка по инту или варчару принципиально отличается.
2Алекс: если у тебя только плоские выборки, то постгря выигрыша не даст. А вот инсерты на больших таблицах у постгри быстрее по моим тестам (но я тестировал под свою задачу, так что модет это в общем и не верно). А так несколько милионов записей для постгри фигня.
Кстати, в постгре не рекомендуется вешать индексы на строковые типы.
> Если бы все базы были плоскими
Это ты о многомерных что ли? Тут о них речь не шла: вопрос о смысле миграции с MySQL на Postgres, а какая нах. многомерность в MySQL?!
> и тогда кроме мускула ничего не надо было бы...
Великое заблуждение: тот же самый oracle (без использования многомерности) гораздо быстрей мускула на больших базах. Мало того - мускул не сможет работать (тратя на операции "не мыслимое" время) на тех базах, с которыми оракл справляется на ура. Очень много зависит от сервера. А фишку многомерности можно прикрутить к любой РБД и называется это ROLAP.
Это ты о многомерных что ли? Тут о них речь не шла: вопрос о смысле миграции с MySQL на Postgres, а какая нах. многомерность в MySQL?!
> и тогда кроме мускула ничего не надо было бы...
Великое заблуждение: тот же самый oracle (без использования многомерности) гораздо быстрей мускула на больших базах. Мало того - мускул не сможет работать (тратя на операции "не мыслимое" время) на тех базах, с которыми оракл справляется на ура. Очень много зависит от сервера. А фишку многомерности можно прикрутить к любой РБД и называется это ROLAP.
плоские == отднотабличные (от плоских выборок)
Тогда это уже не база данных, а просто таблица.
Какой смысл здесь рассмотривать самый простой тривиальный случай?
Какой смысл здесь рассмотривать самый простой тривиальный случай?
Бери Berkeley DB
о! вот в строках таблицы измеряются, а не бд.
изначально ты утверждак, что база в количествах строк измеряется. дык это -- фигня:
база измеряется в количестве сущностей, их размером, количестве отношений, характерными выборками.
изначально ты утверждак, что база в количествах строк измеряется. дык это -- фигня:
база измеряется в количестве сущностей, их размером, количестве отношений, характерными выборками.
Я о первом приближении. А кол-во строк в баже = сумме кол-ва строк по всем таблицам. Чего тут не понятного?
Оставить комментарий
Landstreicher
Есть такой трабл: на юниксовой машине стоит MySQL-сервер, в котором лежит база данных. На другой виндовой машине эту базу нужно юзать через ODBC. Все видно замечательно, таблицы открываются, НО все строчки выглядят неправильно из-за того что на сервере кодировка koi8-r, а в винде cp1251. Как это вылечить? Кто-нибудь с подобным явлением сталкивался. Помогите плз, очень надо.