Перейти к содержимому


- - - - -

СУБД


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 37

#1 Ear

Ear
  • Пользователь

  • Пользователь
  • 130 сообщений
  • Пол:Мужчина

Отправлено 31.08.2006 - 10:37

Предлогаю сюда кидать вопросы по базам данных.
У самого в этом деле познаний не много... а вот вопросы есть.

Например: как настроить кодировку в MySQL, чтобы инфа, напечатанная кириллицей нормально отображалась в браузере( средствами PHP) и наоборот?

#2 depp

depp
  • Мыслитель

  • Power User
  • 2 149 сообщений
  • Пол:Не определился

Отправлено 31.08.2006 - 11:04

Просмотр сообщенияEar (31.8.2006, 11:37) писал:

Предлогаю сюда кидать вопросы по базам данных.
У самого в этом деле познаний не много... а вот вопросы есть.

Например: как настроить кодировку в MySQL, чтобы инфа, напечатанная кириллицей нормально отображалась в браузере( средствами PHP) и наоборот?
cp1251 - general ci - русская кодировка с поддержкой регистра
чтобы нормально отображалась у тебя кодировка при соединении с базой ты должен сопостовлять cp1251. тогда база у тебя и соединяться по русски будет и инфу заносить в таблицы на русском будет.

кодировку в MySQL настроить с помощью любого администратора можно.

средствами php ты можешь выбрать как соединяьтся с БД, напр.:
$ms = mysql_pconnect(HOST,USER,PSWD) or die(__LINE__." - Нет связи с БД");
if (mysql_get_server_info()>"4.1") 
					mysql_unbuffered_query("SET NAMES cp1251");
здесь мы выбрали чтобы при соединении он использовал cp1251, но при этом и таблицы тож должны быть у тебя с поддержкой cp1251.

#3 (Faust)

(Faust)
  • Знаток

  • Пользователь
  • 1 340 сообщений
  • Пол:Мужчина
  • Город:Нагатино
  • Интересы:Охота, IT, Web DEvelopment, Спорт (бары).

Отправлено 31.08.2006 - 15:16

Просмотр сообщенияEar (31.8.2006, 11:37) писал:

Например: как настроить кодировку в MySQL, чтобы инфа, напечатанная кириллицей нормально отображалась в браузере( средствами PHP) и наоборот?
На самом деле, если такое присходит, значит косяк на стороне хостера (или глобальный косяк в скрипте) и их нужно заклевать досмерти, пока они не исправят все это. Проблемма в том, что данные в БД хранятся в UTF-8, и перед выдачей из БД самим сервером должны перекодироваться в 1251, если этого не происходит, значит трабл у них, с такой дурью столкнулся на днях, у хостера Арбатек, они обновили БД и слетел один из моих сайтов, пришлось делать
mysql_query("SET NAMES cp1251");
Но после того как отписал в суппорт решение проблеммы все седалали, хотя сказали, мол нету такой проблеммы,
mysql_query("SET NAMES cp1251");
убрал.

#4 Ear

Ear
  • Пользователь

  • Пользователь
  • 130 сообщений
  • Пол:Мужчина

Отправлено 31.08.2006 - 17:02

Попробовал...Вышло что-то странное:)
С одной стороны, что я хотел, то получилось.А хотел я сделать сортировку имён по алфавиту.Вышло!Работает!

Но в рабочей области MySqL'а вижу вот чтоПрикрепленный файл  001.jpg   55,5К   147 Количество загрузок:.

Т.е. если данные из браузера(точнее из формы) передаются в мускул, а потом извлекаются из неё(браузером же), то всё нормально:)Но в мускуле одни знаки вопроса...

Цитата

На самом деле, если такое присходит, значит косяк на стороне хостера (или глобальный косяк в скрипте) и их нужно заклевать досмерти, пока они не исправят все это.
А сервак мой:PСебя клевать не поможет:P

Сообщение отредактировал Ear: 31.08.2006 - 17:06


#5 (Faust)

(Faust)
  • Знаток

  • Пользователь
  • 1 340 сообщений
  • Пол:Мужчина
  • Город:Нагатино
  • Интересы:Охота, IT, Web DEvelopment, Спорт (бары).

Отправлено 31.08.2006 - 17:53

1. Смотрим кодировки:  show variables like 'char%';
Если там не то что нужно.

2. Вписываем в my.ini строчку  init-connect="SET NAMES cp1251"
После этого рестарт бд, если опять косячит (а под root будет косячить) удаление всех баз и юзеров и  создание их заново и все будет нормально.

Сообщение отредактировал (Faust): 31.08.2006 - 17:55


#6 Ear

Ear
  • Пользователь

  • Пользователь
  • 130 сообщений
  • Пол:Мужчина

Отправлено 31.08.2006 - 18:25

Тут то что нужно?Или не так что?
Прикрепленный файл  002.jpg   53,16К   137 Количество загрузок:

#7 artgeniy

artgeniy
  • Изучает местность

  • Пользователь
  • 84 сообщений
  • Город:127.0.0.1

Отправлено 31.08.2006 - 20:58

Чо набрать в Пуск==Выполнить, чтобы зайти в MySQL клиент????

#8 Ear

Ear
  • Пользователь

  • Пользователь
  • 130 сообщений
  • Пол:Мужчина

Отправлено 31.08.2006 - 22:15

А где у тебя MySQL Command Line Client?
Почему через него не можеш?Или не хочеш?

#9 (Faust)

(Faust)
  • Знаток

  • Пользователь
  • 1 340 сообщений
  • Пол:Мужчина
  • Город:Нагатино
  • Интересы:Охота, IT, Web DEvelopment, Спорт (бары).

Отправлено 01.09.2006 - 09:33

Просмотр сообщенияEar (31.8.2006, 19:25) писал:

Тут то что нужно?Или не так что?
Прикрепленный файл attachment
Кодировка неверная latin1.

#10 Igorek

Igorek
  • Пользователь

  • Пользователь
  • 378 сообщений
  • Пол:Мужчина
  • Город:СССР
  • Интересы:Охота и Стендовая стрельба, Python w Django.

Отправлено 01.09.2006 - 14:25

Вообще лучше изначально заставить себя работать с UTF-8, если ты начинаешь только разбираться в mysql, между прочим есть куча GUI приложение для работы с mysql (EMS, mysqlcc, Mysql Manager);
Кирилицу можно попробовать сделать еще вот как
в my.cnf/my.ini в разделе [mysqld]
прописать
default-characterset=cp1251
Для точности возьми любую документацию и поиском поищи default-charset
и все какие наедешь тупо ставь в cp1251, но все таки советаю использовать UTF-8.

#11 (Faust)

(Faust)
  • Знаток

  • Пользователь
  • 1 340 сообщений
  • Пол:Мужчина
  • Город:Нагатино
  • Интересы:Охота, IT, Web DEvelopment, Спорт (бары).

Отправлено 01.09.2006 - 20:34

Просмотр сообщенияIgorP (1.9.2006, 15:25) писал:

Вообще лучше изначально заставить себя работать с UTF-8, если ты начинаешь только разбираться в mysql, между прочим есть куча GUI приложение для работы с mysql (EMS, mysqlcc, Mysql Manager);
Кирилицу можно попробовать сделать еще вот как
в my.cnf/my.ini в разделе [mysqld]
прописать
default-characterset=cp1251
Для точности возьми любую документацию и поиском поищи default-charset
и все какие наедешь тупо ставь в cp1251, но все таки советаю использовать UTF-8.
Про UTF-8 полностью поддерживаю.

Про клиенты: Mysql Front, реккомендую, подглючивает он, но мне нравится.  :)

#12 Тьяв

Тьяв
  • Пользователь

  • Пользователь
  • 181 сообщений
  • Город:Q7, Нагатино

Отправлено 20.09.2006 - 00:38

1. Чем Unicode лучше прочих?
2. Можно ли задавать имена баз данных и названия таблицы кириллицей и какими глюками аукнется?

Сообщение отредактировал Тьяв: 20.09.2006 - 00:44


#13 Igorek

Igorek
  • Пользователь

  • Пользователь
  • 378 сообщений
  • Пол:Мужчина
  • Город:СССР
  • Интересы:Охота и Стендовая стрельба, Python w Django.

Отправлено 20.09.2006 - 08:19

1. Лучше тем, что когда ты начнешь писать многоязычное приложение, или вдруг тебе очень сильно захочется написать правильное немецкое название (к примеру) u с аумляутом, то UTF-8 тебя ой как спасет. И вообще это правильнее. В конце концов кодировку на выходе ты всегда можешь сменить на cp1251
2. Задавать можешь попробовать хоть китайскими иероглифами, но ничего хорошего из этого не выйдет. Все базы создаются только латинскими буквами, например cms_новости - нельзя, а вот cms_novosti можно.
Старайся при создании баз использовать только маленькие буквы, иначе если ты используешь myisam могут возникнуть проблемы при переносе твоей базы на *nix, т.к в *nix в отличии от Windows Novosti и novosti отличаются друг от друга.

#14 Joshua5

Joshua5
  • Paranoid Android

  • Пользователь
  • 189 сообщений
  • Город:Ясенево

Отправлено 20.09.2006 - 22:10

Просмотр сообщенияIgorP (20.9.2006, 9:19) писал:

2. Задавать можешь попробовать хоть китайскими иероглифами, но ничего хорошего из этого не выйдет. Все базы создаются только латинскими буквами, например cms_новости - нельзя, а вот cms_novosti можно.
Старайся при создании баз использовать только маленькие буквы, иначе если ты используешь myisam могут возникнуть проблемы при переносе твоей базы на *nix, т.к в *nix в отличии от Windows Novosti и novosti отличаются друг от друга.

Имхо, зависит от БД. В том же MySQL базы - это директории, а таблицы - файлы. Так что если у системы всё нормально с русскоязычными именами фалов, то и база сможет прочитать.

#15 Igorek

Igorek
  • Пользователь

  • Пользователь
  • 378 сообщений
  • Пол:Мужчина
  • Город:СССР
  • Интересы:Охота и Стендовая стрельба, Python w Django.

Отправлено 23.09.2006 - 19:56

Просмотр сообщенияJoshua5 (20.9.2006, 23:10) писал:

Имхо, зависит от БД. В том же MySQL базы - это директории, а таблицы - файлы. Так что если у системы всё нормально с русскоязычными именами фалов, то и база сможет прочитать.
Кто тебе сказал такую глупость ?
А если ты будешь работать с innodb или ndb ?
Не надо делать заведомо неверно. Как бы у тебя не была настроена кодировка, проблемы с названиями БД или таблиц будут, если не у тебя то у других.

#16 Joshua5

Joshua5
  • Paranoid Android

  • Пользователь
  • 189 сообщений
  • Город:Ясенево

Отправлено 25.09.2006 - 11:49

IgorP, с InnoDB два варианта - если у тебя всё в одном файле и если у тебя каждая таблица находится в отдельном файле. Это во-первых.

Во-вторых, я сейчас не поленился и проверил: под виндой прекрасно создаётся таблица с русским именем MyISAM (кстати, имя файла записывается юникодом), в InnoDB, когда вся база одним файлом - тоже. По таблице в файле для InnoDB проверять лень, можешь сам попробовать, прежде чем в следующий раз поучать людей :) SELECT из этой таблицы тоже проходит на ура.

Для SLES9.3 не прокатило - сказал, что некорректное имя таблицы. Почему так - проверять опять же лень, но может и можно заставить.

Вопросы? :Р

#17 Igorek

Igorek
  • Пользователь

  • Пользователь
  • 378 сообщений
  • Пол:Мужчина
  • Город:СССР
  • Интересы:Охота и Стендовая стрельба, Python w Django.

Отправлено 25.09.2006 - 13:19

Я не поучаю, а говорю про то, что не надо так делать.
Хорошо.
Форум у нас web-прог, так что возьмем PHP - PERL.
Давайте-ка поработаем с базами и табличками.
Сначала скрипт пишем все в Windows, соответственно для начинающего скриптера кодировка = win1251, а потом переезжаем под линух и работаем там, ну к примеру в koi8-r, хотя перетянуть локаль можно и на 1251.
запрос в типа
"SELECT * FROM моя_первая_таблица"
может быть по разному интерпретирован в разных системах, запрос
"SELECT * FROM my_first_table" -
будет для всех них одинаков.
Ход мысли я думаю вам понятен.
Хотя как говорил старина Альберт Иванович Эйнштейн :)- Все в этом мире относительно.

Ваше личное дело как вы назовете таблицы (я же написал - "хоть в китайских иероглифах"). Но не надо так делать.

ВСЕ ЧТО ОБСУЖДАЛОСЬ С Joshua5 ИСКЛЮЧИТЕЛЬНО ТЕОРИЯ.

#18 Joshua5

Joshua5
  • Paranoid Android

  • Пользователь
  • 189 сообщений
  • Город:Ясенево

Отправлено 25.09.2006 - 14:44

IgorP, я не спорю, что так делать не стоит, но теоритически (и местами практически) это возможно.

А писать лучше всегда в юникоде - не будет никаких проблем :)

#19 Oldwin

Oldwin
  • Восставший из бана

  • Power User
  • 637 сообщений
  • Пол:Мужчина

Отправлено 12.10.2006 - 00:12

Просмотр сообщенияartgeniy (31.8.2006, 21:58) писал:

Чо набрать в Пуск==Выполнить, чтобы зайти в MySQL клиент????
Путь до mysql и ключи -u -p -h (Юзер, пароль, хост). Не нужные опускаются. У тебя скорей всего будет что-то типа:
Имя_диска:\usr\local\mysql\bin\mysql.exe -u root

Просмотр сообщенияEar (31.8.2006, 18:02) писал:

Но в рабочей области MySqL'а вижу вот что
Пропиши SET NAMES cp866;

Просмотр сообщенияIgorP (20.9.2006, 9:19) писал:

1. Лучше тем, что когда ты начнешь писать многоязычное приложение, или вдруг тебе очень сильно захочется написать правильное немецкое название (к примеру) u с аумляутом, то UTF-8 тебя ой как спасет. И вообще это правильнее. В конце концов кодировку на выходе ты всегда можешь сменить на cp1251
О да. Призрочная возможность в будущем написать что-нибудь на китайском? в настоящем увеличит время выполнения запросов.

#20 Igorek

Igorek
  • Пользователь

  • Пользователь
  • 378 сообщений
  • Пол:Мужчина
  • Город:СССР
  • Интересы:Охота и Стендовая стрельба, Python w Django.

Отправлено 12.10.2006 - 10:05

Просмотр сообщенияOldwin (Сегодня, 1:12) писал:

О да. Призрочная возможность в будущем написать что-нибудь на китайском? в настоящем увеличит время выполнения запросов
Прости, что сделает ?
Ты будешь замечать время на ответ ?
Оптимизация батенька и еще раз оптимизация.

#21 downGRADE

downGRADE
  • Знаток

  • Пользователь
  • 1 092 сообщений

Отправлено 12.10.2006 - 14:33

Просмотр сообщенияOldwin (12.10.2006, 1:12) писал:

О да. Призрочная возможность в будущем написать что-нибудь на китайском? в настоящем увеличит время выполнения запросов.
UTF - Системная кодировка(и в *NIX'ах, и виндусе), исполняется быстрее всего, остальные кодировки переводятся к UTF библиотеками.

#22 (Faust)

(Faust)
  • Знаток

  • Пользователь
  • 1 340 сообщений
  • Пол:Мужчина
  • Город:Нагатино
  • Интересы:Охота, IT, Web DEvelopment, Спорт (бары).

Отправлено 12.10.2006 - 18:16

:)  :) Хорошо конечно что известны такие тонкости...
Но я думаю 99% процентам пользователей читающих/пишущих в этой ветке никогда не придется заниматься разработкой веб-приложений в которых, такого рода оптимизация принесет хоть какой - нибудь существенный прирост производительности и экономию ресурсов.  :P

#23 Oldwin

Oldwin
  • Восставший из бана

  • Power User
  • 637 сообщений
  • Пол:Мужчина

Отправлено 19.10.2006 - 16:56

Просмотр сообщенияIgorP (12.10.2006, 11:05) писал:

Прости, что сделает ?
Ты будешь замечать время на ответ ?
Оптимизация батенька и еще раз оптимизация.
Это и есть оптимизация, дорогой. Главной целью оптимизации является сокращение операций доступа к жесткому диску. А, теперь немного подумав, сделай выводы, какие проблемы в себе несут многобайтные кодировки.

Просмотр сообщенияdownGRADE (12.10.2006, 15:33) писал:

UTF - Системная кодировка(и в *NIX'ах, и виндусе), исполняется быстрее всего, остальные кодировки переводятся к UTF библиотеками.
Жесткий диск "исполняется" медленней всего.

Просмотр сообщения(Faust) (12.10.2006, 19:16) писал:

Но я думаю 99% процентам пользователей читающих/пишущих в этой ветке никогда не придется заниматься разработкой веб-приложений в которых, такого рода оптимизация принесет хоть какой - нибудь существенный прирост производительности и экономию ресурсов
Я думаю, что этим 99% никогда не придется заниматься разработкой веб-приложений, в которых им понадобятся китайские иероглифы... Зато, в случае выбора многобайтных  кодировок, у них записи будут занимать больше места на жестком диске со всеми вытекающими отсюда последствиями.

#24 drnet

drnet
  • ♞♞♞♞♞♞♞♞♞

  • Динозавр Форума
  • 8 810 сообщений
  • Пол:Мужчина
  • Город:
  • Интересы:В детстве был конструктор Лего, увлечение осталось.<br />Создал свой Лего для взрослых :)

Отправлено 19.10.2006 - 18:31

Просмотр сообщенияOldwin (19.10.2006, 17:56) писал:

Это и есть оптимизация, дорогой. Главной целью оптимизации является сокращение операций доступа к жесткому диску. А, теперь немного подумав, сделай выводы, какие проблемы в себе несут многобайтные кодировки.

Жесткий диск "исполняется" медленней всего.

Я думаю, что этим 99% никогда не придется заниматься разработкой веб-приложений, в которых им понадобятся китайские иероглифы... Зато, в случае выбора многобайтных  кодировок, у них записи будут занимать больше места на жестком диске со всеми вытекающими отсюда последствиями.
Использую UTF-8 для хранения  русских данных. Решаются проблемы, если нужно вставить особые символы. Кроме того, при хранении адресов и имён в других странах нет ничего лучше. Лучше  imho  диск  потратить,  чем  решать  кучу дурацких проблем с кодировками ради лишнего полупроцента прироста производительности.

#25 downGRADE

downGRADE
  • Знаток

  • Пользователь
  • 1 092 сообщений

Отправлено 19.10.2006 - 19:05

Просмотр сообщенияOldwin (19.10.2006, 17:56) писал:

Жесткий диск "исполняется" медленней всего.
Бр-р-р-р! Есть много параметров оптимизации, скорость доступа к диску - только один из них. Размер кэш-линий процессора, размер страницы подкачки, размер кластера файловой системы - это дискретные порции аппаратного обмена информации, будет это полная порция или пол-порции совсем неважно... только процессорное время не перекодировку-то все равно потратишь, при пол-порции, да и класс-перекодировщик в другую кэш-линию подгружен будет при обработке потоков пулами совсем недетская нагрузка. К тому же не следует забывать про загрузку каналов связи.

#26 Joshua5

Joshua5
  • Paranoid Android

  • Пользователь
  • 189 сообщений
  • Город:Ясенево

Отправлено 20.10.2006 - 11:30

Просмотр сообщенияdownGRADE (19.10.2006, 20:05) писал:

Бр-р-р-р! Есть много параметров оптимизации, скорость доступа к диску - только один из них.

Но один из cамых важных. Зачем иначе вообще придумали кеширование?

#27 Igorek

Igorek
  • Пользователь

  • Пользователь
  • 378 сообщений
  • Пол:Мужчина
  • Город:СССР
  • Интересы:Охота и Стендовая стрельба, Python w Django.

Отправлено 20.10.2006 - 14:47

Просмотр сообщенияOldwin (Вчера, 17:56) писал:

Главной целью оптимизации Это и есть оптимизация, дорогой.
Фу противный. Давай все таки уважать друг друга.

Просмотр сообщенияOldwin (Вчера, 17:56) писал:

Главной целью оптимизации является сокращение операций доступа к жесткому диску.
Где ты взял эту фразу ?
НЖМД - является самым узким местом во всей системе при производительности, но ни как не оптимизации.

Сделайте один и тот же запрос на одном и том же винте, но с разными процессорами ?
Одинаковый проц, разные винты.
Тоже самое и с - одинаковый винт, одинаковый проц, разные ОС.
Я думаю что тебя удивят результаты.
Давай-те вспомним про запросы через LAN, а еще, еще....
Так что друг мой, главной целью является не "сокращение операций доступа к жесткому диску", а совокупное сокращение времени чтения/записи ко всем аппаратным и програмным комплексам.

Короче, флуд уже пошел. Сколько людей столько и мнений. мое мнение, что изначально работать надо начинать сразу под UTF-8, не все являются программерами-любителями.
Ведь нормальный форум поддерживающий к примеру русский-английский-немецкий - есть хорошо.
При написании имен-фамилий актеров в видео-скриптах - корректнее было бы использовать их правильное написание.

Сообщение отредактировал IgorP: 20.10.2006 - 15:15


#28 Oldwin

Oldwin
  • Восставший из бана

  • Power User
  • 637 сообщений
  • Пол:Мужчина

Отправлено 20.10.2006 - 16:02

Просмотр сообщенияIgorP (Сегодня, 15:47) писал:

Где ты взял эту фразу ?
НЖМД - является самым узким местом во всей системе при производительности, но ни как не оптимизации.
Конечно производительности, не правильно выразился. Сути это не меняет.

Просмотр сообщенияIgorP (Сегодня, 15:47) писал:

Давай-те вспомним про запросы через LAN, а еще, еще....
Темболее. При использовании многобайтных кодировок объемы информации, передаваемые через сеть увеличиваются...

Просмотр сообщенияIgorP (Сегодня, 15:47) писал:

Так что друг мой, главной целью является не "сокращение операций доступа к жесткому диску", а совокупное сокращение времени чтения/записи ко всем аппаратным и програмным комплексам.
Жетский диск рассматривается как самое медленное место во всей системе, ибо таковым он и является в большинстве случаев.
Никто не отрицает, что нужно совокупное сокращение времени... Только опять же многобайтные кодировки это время увеличивают, и если нужды острой в такой кодировке нет, то и использовать ее не разумно.

#29 downGRADE

downGRADE
  • Знаток

  • Пользователь
  • 1 092 сообщений

Отправлено 20.10.2006 - 18:00

Просмотр сообщенияJoshua5 (20.10.2006, 12:30) писал:

Но один из cамых важных. Зачем иначе вообще придумали кеширование?
Чтобы ускорить обработку единичного запроса, но нельзя забывать и о цене этого ускорения - снижение количества одновременно обрабатываемых запросов. Нужно помнить о конкретной задаче оптимизации, иначе система способная обрабатывать запросы 1000 юзеров одновременно, будет переполняться при 100. Оптимизация - распределение нагрузки по аппаратным ресурсам системы, и любое утверждение "это оптимально" должно употреблятся в контексте поставленной задачи.

Сообщение отредактировал downGRADE: 20.10.2006 - 18:02


#30 Joshua5

Joshua5
  • Paranoid Android

  • Пользователь
  • 189 сообщений
  • Город:Ясенево

Отправлено 23.10.2006 - 12:11

Просмотр сообщенияdownGRADE (20.10.2006, 19:00) писал:

Чтобы ускорить обработку единичного запроса, но нельзя забывать и о цене этого ускорения - снижение количества одновременно обрабатываемых запросов. Нужно помнить о конкретной задаче оптимизации, иначе система способная обрабатывать запросы 1000 юзеров одновременно, будет переполняться при 100. Оптимизация - распределение нагрузки по аппаратным ресурсам системы, и любое утверждение "это оптимально" должно употреблятся в контексте поставленной задачи.

Я имел в виду кеширование операций ввода/вывода для жёсткого диска, а не кеширование запросов и их результатов. Что толку кешировать запрос, если у тебя несколько десятков тысяч подключений к БД в секунду? Что толку кешировать результат, если для его хранения не хватает оперативки и ОСь кидает в своп? Тут только наращиваение аппаратных ресурсов, никая оптимизация кода или БД не спасёт, в первую очередь - памяти для сокращения дисковых операций, иначе начнутся тормоза с отдачей контента клиенту.

P.S.: BTW, я сейчас говорю о реальной системе, с которой я работаю, а не о теории.




Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 скрытых пользователей