>>не вижу проблемы...
>а ее и небыло... надо было просто человеку сказать как порт собрать
>с мускулом, а тут все вдарились в дискуссии...
Дискуссии у нас с Вами, а человек в довольно короткие сроки сам разобрался с небольшой помощью. Хотя согласен, проблема у него неординарная, классическая сборка с поддержкой MySQL не помогла.
>>Прежде чем писать сей бред, ознакомтесь с различиями в типах MySQL char
>>и varchar http://www.mysql.ru/docs/man/CHAR.html
>читал и? в чем смысл меня тыкать туда где я бываю счасто
>ибо всего не упомнишь?
Прочитайте. Там немного... но полезно.

>>Думаю излишне объяснять что произойдет при экспорте IPv6 адресов в 15-и
>>символьное поле. И как раз таки новичкам совсем ни к чему
>>такие проблемы. А таблица, в случае IPv4 адресов будет занимать ровно
>>столько же, сколько и в случае с типом varchar(15). Это я
>>вам говорю как человек, что-то в этом понимающий за 6 лет
>>API-программирования mysql.
>преклоняюсь перед Вашими знаниями но, скажите честно - Вы используете IPv6? а
>новички используют? кетайцы конечно этот форум посещают, им это точно пригодится,
>но вот у нас в стране (Россия) вообще есть реально работающий
>IPv6? скажите где, я очень хочу посмотреть...

Речь не о экспортируемом протоколе, а о вреде/пользе varchar(45). Вы утверждаете что таблица с varchar(45) разрастется быстрее чем таблица varchar(15) при экспорте IPv4, я убеждаю Вас в обратном (см. ссылку). Поэтому НИКАКОГО вреда от моего варианта структуры базы нет, а преимущества очевидны: заложенный потенциал, согласованность с внутренними структурами flow-export, косвенная диагностика ошибок...
Если уж волноваться о размере таблицы, то следует исключить ненужные/неиспользуемые поля - вот где реальная польза.