Обрезание по живому
#1
Отправлено 11 July 2012 - 18:13
"О внесении изменений в Методические указания по определению кадастровой стоимости вновь образуемых земельных участков и существующих земельных участков в случаях изменения категории земель, вида разрешенного использования или уточнения площади земельного участка, утвержденные приказом Минэкономразвития России от 12 августа 2006 г. N 222"
И как бы произвольно менять название это не правильно. Проблема соответственно не только при импорте, но и при ручной правке.
Не будучи большим специалистом, нуждаюсь в совете - как с этим жить..
#2
Отправлено 11 July 2012 - 18:40
Учить MySQL и жить без заботНе будучи большим специалистом, нуждаюсь в совете - как с этим жить..
ALTER TABLE `префикс_вашей_таблицы_zoo_item` CHANGE `name` `name` VARCHAR( 1000 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL
Этот оператор, выполненный в вашей базе данных (например, в phpMyAdmin) увеличит максимальное количество символов до 1000. Не знаю, возможно где-то еще устанавливается ограничение и могут вылезти глюки, но при редактировании вроде все ок прошло.
http://puu.sh/HGq3
«Ну и зачем все это, лучше бы водки выпили». Из писем Белинского Гоголю.
#3
Отправлено 11 July 2012 - 19:16
Еще спрошу - значение 255 по умолчанию - имеет какой то философский смысл? и увеличение этого параметра на что то может дурно повлиять?
#4
Отправлено 11 July 2012 - 19:28
Конечно имеет 255 - это 2 в 8-ой степени минус 1. 0-255 - это в прошлом столетии был диапазон длины символьных полей для БД, используемых в компьютерах с 8-битной архитектурой Те времена уже давно прошли, а вот традиции остались - вот и вся философияГениально! Премного благодарен
Имеет какой то философский смысл? и увеличение этого параметра на что то может дурно повлиять?
«Ну и зачем все это, лучше бы водки выпили». Из писем Белинского Гоголю.
#5
Отправлено 11 July 2012 - 19:32
Да, я в первом ответе написал, что могут быть глюки. Я не помню наизусть сотни тысяч строк кода Joomla и ZOO и не могу утверждать, что название материала не обрезается где-то в коде, потому гарантий никаких.увеличение этого параметра на что то может дурно повлиять?
«Ну и зачем все это, лучше бы водки выпили». Из писем Белинского Гоголю.
#6
Отправлено 12 July 2012 - 09:24
Вообще то это не философия, а тип данных. Архитектура компьютера тут совсем не причем, до сих пор пол мира сидит на x86 (этой архитектуре уже десятки лет).Конечно имеет 255 - это 2 в 8-ой степени минус 1. 0-255 - это в прошлом столетии был диапазон длины символьных полей для БД, используемых в компьютерах с 8-битной архитектурой Те времена уже давно прошли, а вот традиции остались - вот и вся философия
По вашему можно все подряд поля делать text по несколько мегабайт. Будут огромные проблемы с индексацией базы данных, полнотекстовому поиску на уровне mysql и длинной индекса, он ограничен 1000. Как следствие очень медленный поиск среди больших объемов, внезапные глюки при сохранении текста.
Отключайте проверку лицензий как можно скорее!
— Есть два типа людей: Кто еще не делает бекапы и кто уже делает бекапы.
#7
Отправлено 12 July 2012 - 09:47
Денис, вы делаете какие-то далекоидущие выводы из моей реплики Я просто ответил, почему именно 255, а не 200, 220, 300 или 330 (каждому) Я с базами данных работаю еще со времен dBase, Paradox и Clarion и за свою карьеру ИТшника успел поработать со многими СУБД, например Oracle, MSSQL, Informix, DB2. И даже сейчас, во времена гигабайтных обьемов памяти и терабайтных винтов осталась привычка экономить на размерах полей Но если человеку надо было увеличить одно конкретное поле, то тут как бы без вариантов...По вашему можно все подряд поля делать text по несколько мегабайт. Будут огромные проблемы с индексацией базы данных, полнотекстовому поиску на уровне mysql и длинной индекса, он ограничен 1000. Как следствие очень медленный поиск среди больших объемов, внезапные глюки при сохранении текста.
«Ну и зачем все это, лучше бы водки выпили». Из писем Белинского Гоголю.