ChAsphinx_mv...Мне жаль, что Ваша воинствующая глупость была ошибочно принята мною всего лишь за заблуждение.Это Вы так завуалировано именуете Вашу неспособность вменяемо излагать свои мысли?
А Вы точно уверены, что хоть какие-то мысли у Вас были?
ChAК отсутствию у Вас упомянутых ранее положительных качеств добавились сугубо отрицательные, как-то активное враньёО, как! И это я, оказываеся, с враньем тут засветился... А цитатку не слабо?
ChA и безудержная, высосанная из пальца, чушь.Ваша? Факт!
Вы ее придумали. Вы ее приписали оппоненту. Вы начали с пеной ее опровергать. Справшивается: кто кому ССЗБ?!

SERG1257sphinx_mv По самым скромным оценкам, примерно полей, этак на 100... И большая часть из из этих полей - "строки".И чем вас это напрягает?Гигабайтами выделенного для хранения места. Особенно с учетом того, что "плоские" таблицы получатся весьма разряжеными.
Ну, и потом периодически появляются новые типы оборудования, появляются новые типы обрабатываемых пакетов и услуг, появляется необходимость обслуживания дополнительных атрибутов, в которых сначала не было необходимости, и они игнорировались... Таблицы будем расширять? Ну, а куда деваться!
Вот только физическое ограничение на размер записи в MSSQL - 8 килобайт. Аналогичные ограничения есть и для серверов других производителей. Так что упереться в "предел" можно легко и непринужденно - при таких типах данных и при таком ожидаемом количестве полей.
SERG1257sphinx_mv список словарей одних только вендорских атрибутов, которые поддерживает небезызвестный freeradius, приближается к двум сотням штук...Опять не вижу проблемы. Когда используются банальные запрос на вставку записи на 100 полей - в принципе это не проблема, хотя и не очень удобно.
Но значимые атрибуты могут повторяться (с другими значениями) - это уже одной "плоской" таблицей не обойтись.
SERG1257По мне что иметь две сотни "логических" объектов, что две сотни физических таблиц разница небольшая.Логические объекты проще поддерживать, чем такое же количество физических - для внесения изменения в схему, как минимум, нет необходимости физически перестраивать структуру таблиц. А так как спроектировать "хорошо", "сразу" и "надолго" вряд ли получится, то изменять структуру таблиц придется.

К тому же... Принимать решение о вставке данных в одну из множества физических таблиц будем? А то! И займется этим radius-сервер - больше некому/нечему. Вот только условия анализа могут быть весьма "ветвистыми" - а этот анализ занимать лишнее время и отжирать ресурсы сервера, а из-за особенностей протокола (используется UDP однако) это может привести к потерям данных. Проще просто залить данные по атрибутам "как есть" - "без долгих раздумий".
А обслуживание логической модели вполне можно вынести в отдельное приложение - прозрачно и незаметно для radius-сервера.
SERG1257То есть задача вполне себе легко решается и без EAV.Решается.
Вот только решение "не на атрибутах" получается, мягко говоря, "странным" и "хрупким".

SERG1257sphinx_mv Гигабайтами выделенного для хранения места. Особенно с учетом того, что "плоские" таблицы получатся весьма разряжеными.Насколько я знаю null поля места не занимают. Так что место расходуется ровно столько же как и для EAV.Для ЛЮБОЙ базы данных? И это гарантированно ни когда не изменится при переходе на другую версию?
Зуб дадите? ;)
SERG1257sphinx_mvТаблицы будем расширять? Ну, а куда деваться!Например сделать таблицу наследник со связью 1:1 с основной. Так что деваться есть куда.Чего уж там: по одной таблице-наследнику со связью 1:1 к основной под каждый атрибут. А потом (сугубо потому что держать 100500 физических таблиц в базе не по фэншую) просто собираем все эти отдельно взятые таблицы в одну "супер-таблицу" (с добавлением поля-идентификатора атрибута) и наслаждаемся вариациями EAV... :)
Какой смысл огород городить?
SERG1257sphinx_mv Но значимые атрибуты могут повторяться (с другими значениями) - это уже одной "плоской" таблицей не обойтись.Это вообще непонятно.
Имя - Вася
Имя - Петя
Сохранить это можно, но как потом с этим дальше жить.Конкретно вот с этим? Возможно, что никак.
Хотя даже тут могут быть варианты: в некоторых задачах бывает важен не порядок следования, а сам факт наличия и сколько раз встречается...
SERG1257sphinx_mv А так как спроектировать "хорошо", "сразу" и "надолго" вряд ли получится, то изменять структуру таблиц придется.Если в таблице данных нет, то кроить несложно. Если данные есть, то лучше пусть меня остановит движок СУБД, чем я найду мусор в данных.Немеряное и практически неуправляемое количество пустых значений в полях записи - это уже само по себе мусор в данных...
SERG1257sphinx_mvПроще просто залить данные по атрибутам "как есть" - "без долгих раздумий".Еще проще залить все сообщение целиком.Зачем?! Чтобы потом ОПЯТЬ парсить для обработки?!
RADIUS-сервер все УЖЕ распарсил на список пар "атрибут-значение", когда получил пакет...
sphinx_mvВы как то обходите стороной запросы к вашей EAV базе. Если этим будет заниматся другое приложение, а может и на другом сервере - так пусть оно и парсит и думает куда что записать, чтобы удобно было читать.База данных - ОБЩАЯ. И хранится в ней уже распарсеные наборы данных, на основании которых по простой и очень гибкой логической модели можно выполнять любые обработки.

Вот Вы меня в чем убеждаете?
Что, уже имея вполне нормализованные данные, нужно сначала применить героические усилия, чтобы их денормализовать, а после этого где-нибудь и когда-нибудь "на стороне" опять с не менее героическими усилиями начать заниматься "нормализацией", но уже под какую-то "другую" задачу?! Не смешно! :)

SERG1257Вы сказали, что задача идеально подходит под EAV и я пытаюсь понять как оно работает и как бы я это реализовал я.
Что имеем - есть сервис занятый важным и нужным делом. Вы настраиваете сервис писать лог в СУБД. Больше сервис в СУБД не ходок, он делом занят. Затем другая программа (отчет) идет в эту базу и делает по ней отчет или гибкую обработку.
Я правильно понял?В общих чертах... Но это мы пока только с логами разобрались...

Но логи - это еще не все. Это даже не бОльшая часть реализуемого функционала.
Сервис не только пишет лог, но и по запросам от коммуникационного оборудования проверяет (по базе!) пользователей, определяет статус и параметры их услуг, настраивает параметры сессии - и еще много чего "интересного"... И в зависимости от результатов проверки отдает (в виде все того же пресловутого списка "атрибут-значение") на инициировавшее запрос коммуникационное оборудование некоторые данные...
SERG1257Как бы это стал делать я - заставил бы сервер скидывать данные (отпарсенные) в текстовый файл (это быстро, дешево, надежно), который бы тащил на другую машину (нечего у сервиса ресурсы отбирать) там обрабатывал и заносил в структуру удобную для отчетов, ибо делать отчеты по EAV базе неудобно и медленно.Кроме отчетов и прочих обработок по логам нужно обеспечивать поток данных в обратном направлении, чтобы выполнять управление ресурсами по предварительно сконфигурированным или динамически генерируемым профилям... Фактически, профиль - "enity", набор пар "атрибут-значение" говорит сам за себя.

guest_20040621> Господа удавы, не стоит переходить на личности.

Это не переход на личности, это оценка квалификации. Ваше право искать жемчуг в дерьме никто не оспаривает.

Стратегически важно, чтобы потолок карьерного роста быдла был ограничен подметанием трамвайных путей. Нужно объяснять, почему это так, или вы самостоятельно воспользуетесь историческими параллелями?Вашего потолка карьерногороста не хатит даже на помощника младшего золоторя.