>А это что такое? Давайте не умножать сущности, а оперировать в множестве
>уже определенных (и известных обеим участникам) понятий. не понял, что вы хотели этим сказать
>По вашему, SQL==RDBMS? Ответ неверный ...
я в курсе что такое СУБД и что такое язык структурированных запросов
>Вот и выходит, что SQL не нужен, а нужны тривиальные вторичные индексы,
>которые не только к SQL, но и к реляционной модели вообще
>никакого отношения не имеют.
еще раз.мне не нужны никакие индексы!индексы на все поля не навесиш, а мне именно интересно работать со всеми полями!
хорошо.давайте абстрагируемся от этого
1230760536.211 71 192.168.2.6 TCP_MISS/200 4309 GET http://vkontakte.ru/mail.php? - NONE/- text/html
поля 3,4,6,8,9,10 могут быть значениями из других таблиц (в частности у меня в самописном биллинге так оно и есть, ибо за 4 месяца squid+net-acct+ulog+netflow=85Gb в майскуеле)
это вам не реляция?
далее.поле 3 участвует в других таблицах (в частности net-acct,ulog,postfix,таблица пользователей)
сделано это для того, чтобы при смене айпи адреса, не нужно было ковырять около 20 таблиц (в том числе таблицы по описанию компа)
идем далее.
прекарсно осознаю, что в том виде, что я привел это просто плоская таблица, но! когда таких записей за сутки 180 мегабайт, а вам нужно быть готовым выдать отчет быстро (пользователь через веб-морду посмотрел куда и когда он ходил), вам проще будет выполнить 1 запрос или провести кучу текстовых операций?причем эти операции могут завершиться ошибкой из-за, например, невозможности поместить в переменную 20Mb промежуточных данных(не надо предлагать баловаться в размерами буферов и т.д.,т.к. на каждый сиюминутный фишкозапрос не понастраиваешся и , в конце концов, не сервер должен подстраиваться под инструмент, а наоборот).
надеюсь, сейчас я доступно объяснил почему могут возникнуть ситуации, когда плоскую таблицу необходимо перевести в реляционную и пользовать sql запросы вместо текстовых операций.
