Программирование, т. 8

а причем тут вообще скл тогда?

ты изобретаешь сам себе какой-то способ передачи данных и теперь задаешь вопрос, как с ним бороться

Есть гуру MySQL? Какие могут быть потенциальные проблемы смены collation с utf8 на general latin для varchar (помимо неподдерживаемых символов)?

На innoDb если что.

мгновенная анальная кара разве что

мгновенная анальная кара разве что

Да, лол inner join varchar при этом у этих колонок разный collation. В итоге скорость работы query замедляется в 25 раз. Бтв, можно сменить с latin на utf8, но скорость будет ниже чем для c utf8 на latin. Т.е. особых проблем ожидать не стоит?

Есть гуру MySQL? Какие могут быть потенциальные проблемы смены collation с utf8 на general latin для varchar (помимо неподдерживаемых символов)?

На innoDb если что.

нахуя?

 

мгновенная анальная кара разве что

Да, лол inner join varchar при этом у этих колонок разный collation. 

 

это с индексом?

помоему сравнивать скорость collation это дебилизм

гораздо большие проблемы привносит то что сделано не как везде (тоесть не utf8) чем какие-то сэкономленные наносекунды

 

во-первых, в таблицах не переменные, в таблицах столбцы, это же таблицы

во-вторых, каким же таким чудодейственным способом ты общаешься с базой, что единственное, что тебе приходит в ответ, это поток байт? На брейнфаке пишешь?

Не в ответ приходит поток байт, а я отправляю с сервера, который общается с бд, на клиент поток байт и на клиенте обрабатываю его.

Связь Бд->сервер->клиент

 

отправляй с сервера json...?

 

Есть гуру MySQL? Какие могут быть потенциальные проблемы смены collation с utf8 на general latin для varchar (помимо неподдерживаемых символов)?

На innoDb если что.

нахуя?

 

мгновенная анальная кара разве что

Да, лол inner join varchar при этом у этих колонок разный collation. 

 

это с индексом?

помоему сравнивать скорость collation это дебилизм

гораздо большие проблемы привносит то что сделано не как везде (тоесть не utf8) чем какие-то сэкономленные наносекунды

 

во-первых, в таблицах не переменные, в таблицах столбцы, это же таблицы

во-вторых, каким же таким чудодейственным способом ты общаешься с базой, что единственное, что тебе приходит в ответ, это поток байт? На брейнфаке пишешь?

Не в ответ приходит поток байт, а я отправляю с сервера, который общается с бд, на клиент поток байт и на клиенте обрабатываю его.

Связь Бд->сервер->клиент

 

отправляй с сервера json...?

 

с 25 секунд до 1 секунды если все на utf8 и с 25 секунд на 0.7 если latin. Вся идея в том, что разное количество байт на каждый символ в latin и utf.

 

мгновенная анальная кара разве что

Да, лол inner join varchar при этом у этих колонок разный collation. В итоге скорость работы query замедляется в 25 раз. Бтв, можно сменить с latin на utf8, но скорость будет ниже чем для c utf8 на latin. Т.е. особых проблем ожидать не стоит?

 

ну так и проблема в том, что коллейшн разный и базе приходится постоянно реконверт делать при сравнениях, удачи быстро это сделать

https://stackoverflow.com/a/24891326/4887918

вон тебе даже сравнения, если у тебя паранойя по поводу скорости и тебе насрать на то, что по разному введенные комбинации например буквы и апострофа не найдутся, то юзай utf8_bin

Да, не я понял, что в этом проблема, просто она для меня не супер очевидная была. Я просто беспоколся за смену типа. 

Бля я в sql не шарю, короче переменные которые в таблицах задаются и процедурах, типа Id, название, дата изменения и прочее. И меня подзаебало что у них разный тип данных, из-за чего мне на клиенте постоянно нужно высчитывать определенное количество байт (1,2,4,8)

 

Бля я в sql не шарю, короче переменные которые в таблицах задаются и процедурах, типа Id, название, дата изменения и прочее. И меня подзаебало что у них разный тип данных, из-за чего мне на клиенте постоянно нужно высчитывать определенное количество байт (1,2,4,8)

 

 

Чувак, ты должен знать какой тип приходит с базы, а не вычислять его по байтам

 

ебать  zemlyapuhom

тоже не понял проблем побайтовости, у базы есть тип в таблице, большинство драйверов его нормально конверитируют при получении с базы, а при отправке один хуй оно в текст попадает в запросу

может он новый драйвер пишет

чо доебались

ну хочет байты гонять в бд/из бд

один хуй все ваши типы это набор байтов 

может он новый драйвер пишет

чо доебались

ну хочет байты гонять в бд/из бд

один хуй все ваши типы это набор байтов 

ща адепты си подъедут  feelsdefrelman

НУ ЧО ТАМ С ДЖАВОЙ ПОСАНЫ?! 

Пару лет осталось

https://www.java.com/ru/download/release_notice.jsp

НУ ЧО ТАМ С ДЖАВОЙ ПОСАНЫ?! 

Пару лет осталось

 

https://www.java.com/ru/download/release_notice.jsp

наконец-то умрет как флеш и макромедиа директор

ну так это именно SE8, на днях выйдет SE11 и туда будут мигрировать

убунту ЛТС каждые 2 года умирает какая-то версия и ничё вроде

так se11 тоже lts за $$$

остается openJdk

Щас бы платить за возможность писать 2839 строк кода для объявления переменной. Земля пухом

с линцезированием 11 что-то изменилось по сравнению с 8 чтоли?

с линцезированием 11 что-то изменилось по сравнению с 8 чтоли?

теперь только за $$$ для SE версий или как там

ну крч ток за бабки LTS версию можно получать

иначе open jdk

я кидал пару страниц назад анонс