>Дискуссии у нас с Вами,
always welcome ;)
> а человек в довольно короткие сроки сам разобрался с небольшой помощью.
хвала ему! (серьезно!!!) ибо он есть образец сисадмина с коего многим стоит брать пример... IMO
> Хотя согласен, проблема у него неординарная, классическая сборка с поддержкой MySQL не помогла.
вот это меня и удручает :( что за [censored] выходки порта такие!?!
>Прочитайте. Там немного... но полезно.
я предпочитаю первоисточники в лице http://dev.mysql.com/doc/refman/4.1/en/storage-requirements.... да, я ошибался начет 46 байт (только вот сейчас опять спецом перечитал), но тем не менее я думаю что это излишнее раздувательство базы вносящее в неокрепшие умы ненужную _сейчас_ инфу...
>Речь не о экспортируемом протоколе, а о вреде/пользе varchar(45). Вы утверждаете что таблица с varchar(45) разрастется быстрее чем таблица varchar(15) при экспорте IPv4, я убеждаю Вас в обратном
> (см. ссылку). Поэтому НИКАКОГО вреда от моего варианта структуры базы нет, а преимущества очевидны:
> заложенный потенциал, согласованность с внутренними структурами flow-export, косвенная диагностика ошибок...
я выше описал что я таки перечитал линк который дал я и если вас успокоят мои глубочайшие извинения (я уже говорил что ценю Ваш опыт... мускул для меня есть почти M$ Exel (то что это не postgres я думаю глупо спорить) и если Вас это успокоит, то поверьте, бездна моего раскаяния настолько глубока, что начни я говорить сейчас, мои слова шли бы к Вам вечность) то давайте перестанем судить о размере полей (тем паче что каждое поле в своей БД лично я определял с точки зрения оптимального использования памяти/места исходя из мноогих факторов (порой не явных)), а вернемся на грешную землю в лице РФ где IPv6 несмотря на всю "согласованность с внутренними структурами flow-export"(с) Ваша shema не имеет сверхважного (она на это и не претендовала) значения для довольно таки непростой задачи как то "учет IP траффика средствами flow-tools" там же есть еще фильтры и т.д. и т.п. которые человеку надо настроить... опять же перловка (или любой другой знаемый язык, который позволит быстро парсить данные из мускула) для данной этой задачи пойдет как нельзя лучше ;)
> Если уж волноваться о размере таблицы, то следует исключить ненужные/неиспользуемые поля - вот где реальная польза.
я думаю каждому стоит выбрать необходимое ему лично количестово полей для внесения в базу (выше я описал почти самый минимум для анализа, если убрать src/dst порты - то в общем то самый минимум)... но опять таки т.к. Вы специалист в области мускула то вы не сможете не согласиться с тем что большой объем таки проще загружать из файла чем непосредственной вставкой ;) а данные flow-tools - это не маленький объем (тут все конечно зависит от временного периода) а так же с тем что его таки лучше потом всетаки пересохранить в каком нибудь более-менее сжатом виде...

З.Ы. я извиняюсь перед всеми читателями сего за оффтоп!
З.З.Ы. ув. veng, если вы хотите продолжить дискуссии - пишите в мыло (этот форум не знает про ПМ :( ) если же нет - то давайте не будем с вами трясти седыми мудями перед лицом публики, IMHO это неприлично...