Бинарный collation при поиске - это фатально???

[Flexis]

Здравствуйте, уважаемые господа!

Возник вопрос следующего характера. Буду Вам признателен, если Вы выскажете своё мнение.
При попытке перенести форум с бесплатного хостинга на платый столкнулся с тем, что по прежнему адресу в базе был, видимо, установлен метод сравнения по столбцу word_text таблицы search_wordlist чувствительный к регистру, поскольку под разными word_id числятся одинаковые слова, написанные со строчной и прописной буквы. Например: слова Работа и работа - это две разные записи в таблице.
В новой базе по умолчанию регистр при сравнении не учитывается, соответственно, когда пытаешься выгрузить дамп, возникает ошибка о дублировании записей, поскольку в запросах INSERT INTO попадаются слова, которые уже встречались в таблице ранее, а теперь фигурируют в дампе с большой или, напротив, с маленькой буквы.
Пытаясь найти выход из положения, я установил для поля word_text в таблице search_wordlist атрибут BINARY, после чего дамп спокойно выгрузился и поиск заработал.
Но потом на одном форуме по MySQL меня напугали, что из-за такой меры, могут возникнуть всякого рода проблемы с сортировкой данных по этому полю и всякие другие, и посоветовали просто поставить сравнение, чувствительное к регистру, что я и сделал, прописав в запросе, создающем таблицу

Код: Выделить всё

word_text varchar(50) NOT NULL collate cp1251_general_cs

Это тоже дало тот эффект, что дамп выгрузился на сервер без ошибок, поиск заработал. Насколько корректно, правда, не знаю.
Но как я понимаю, оба этих способа приводят к тому, что поиск ведётся с учётом регистра написания слова.
Теперь, просмотрев Ваш форум, я вижу, что таблицы поиска вообще можно не выгружать дампом, а восстановить переиндексацией с помощью соответствующего мода, что представляется мне в высшей степени разумным. Данный мод решил все мои проблемы. Но вот вопрос, касающийся того, насколько корректно было бы назначать бинарность столбцу word_text остался.
Поэтому я был бы Вам очень признателен, если бы Вы ответили мне:
1. Будет ли корректно работать форум и поиск, если у столбца word_text в таблице search_wordlist будет назначен атрибут BINARY?
2. Если с бинарностью поиск работать будет, какие негативные последствия может повлечь за собой установка этого атрибута, кроме того, что поиск будет происходить с учётом регистра?
3. Если просто прописывать для поля word_text

Код: Выделить всё

word_text varchar(50) NOT NULL collate cp1251_general_cs

отразится ли это на работе форума, если не считать, что поиск будет происходить с учётом регистра?
Заранее благодарю за ответ.

[Rayden]

А как вам вариант не переносить поисковые таблицы, а на новом хостинге просто переиндексировать форум?

[Flexis]

А как вам вариант не переносить поисковые таблицы, а на новом хостинге просто переиндексировать форум?

Вы, вероятно, не очень внимательно прочли мой пост. В частности, следующий его фрагмент:

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

Данный вариант мне пришёлся очень даже по душе, и я так и сделал. Но вопросы, как уже сказано не в этом. Если, конечно, это Вас не слишком затруднит, то я бы очень попросил Вас вернуться к пунктам 1,2,3 из моего предыдущего поста. Очень уж любопытно.

[VVVas]

Flexis
http://dev.mysql.com/doc/refman/5.0/en/ ... inary.html
Обратите внимание на первый абзац, там объяснено в чем отличие и ниже по тексту какие могут быть последствия. Но я лично не понял. Так же как вариант возможно не на то указываю.

[Палыч]

В догонку

For the CHAR, VARCHAR, TEXT, ENUM, and SET data types, you can declare a column with a binary collation or the BINARY attribute to cause sorting and comparison to use the underlying character code values rather than a lexical ordering.

[Flexis]

Уважаемые Палыч и VVVas!
Большое спасибо за внимание к моему вопросу. Я изучил указанные Вами фрагменты и даже нашёл соответствующие разделы документации по MySQL на русском языке, с которыми также в какой-то степени ознакомился.
То, что я понял из всего написанного, это, главным образом, то, что бинарность влияет на способ сравнения по столбцу и способ сортировки по столбцу.
В русской документации нашёл фрагмент, похожий на тот, что приводит Палыч:

При задании атрибута BINARY величины в столбце сортируются и сравниваются с учетом регистра в соответствии с порядком таблицы ASCII на том компьютере, где работает сервер MySQL. Атрибут BINARY не влияет на процессы хранения или извлечения данных из столбца.

Отсюда я делаю вывод, что если полю word_text из таблицы поиска search_wordlist задать атрибут BINARY, то, по идее, это должно повлиять лишь на то, что:
а) в таблице будет больше записей, т.к. повторяющиеся с большой буквы слова будут заноситься под собственными word_id;
б) при поиске будет учитываться регистр, следовательно, он (поиск) станет более "жёстким";
в) сортировка по столбцу будет происходить на основе сравнения бинарного кода значений;
Поскольку, как я понимаю, сортировать весь набор слов, встречающихся в форуме, нам вряд ли потребуется, то актуальны только первые два пункта. И если нас устраивает поиск, чувствительный к регистру и не особенно беспокоят "лишние" слова в базе, то катастрофы при назначении атрибута binary, произойти не должно.
Более того, в документации сказано:

Если необходимо, чтобы столбец всегда обрабатывался в с учетом регистра, объявите его с типом BINARY (см. Раздел 6.5.3, «Синтаксис оператора CREATE TABLE»)

Просто хотелось знать мнение специалистов, которые со скриптом форума "на ты", мало ли какие могли всплыть нюансы.
Спасибо, что уделили внимание.

[VVVas]

Flexis
По идее верно. То бишь ничего критичного нет, если не устраивает - чистим таблицы, снимаем атрибут, переиндексируем.
А насчёт "на ты" - меня переоценили.

[Палыч]

А насчёт "на ты" - меня переоценили.

Меня тем паче... (смотри подпись)
Flexis
я бы ещё на само поле сравнение поставил cp1251_bin... (не на всю таблицу)