2Oracle - зачем заводить справочник для 20 позиций, не тот объем походу (Кстати ,автор мог бы предположить средний объем обрабатываемой информации, размер таблицы)
ID тоже имхо не особо целесообразно - в базе данных из 2-3 таблиц искусственные примари ключи имеют сомнительную ценность, обращение к 1 строке достигнется и оидом. К тому же вряд ли там нужно будет смотреть по строкам - скорее за период будут суммироваться траффики и выдаваться результаты... ОЧень похоже на траффикорезалку =) ..
Тут несколько вариантов - если
авторЗатем надо будет из этой таблицы брать данные, и каждому IP из ip_from сопоставлять тип трафика (int2, всего возможных типов не более 20), т.е. соединять эту таблицу с другой таблицей по полю ip_from (тип inet).

нужно будет сопоставлять часто и вторая таблица есть то можно повесить триггер на события вставки, который бы заполнял поле tr_type , не важно что данные тулзой бросаются - на каждый инсерт это поле заполняется триггером....
Если нужна статистика по суммам траффика для каждого ип и нужна часто, то можно на крон повесить ф-цию, которая агрегирует статистику раз в 1-2 минуты или чаще и складывает в отдельную табличку, а на основе этой небольшой таблицы (все ип адреса как строки - и по кол-ву столбцов -типов траффика - суммы за периоды времени) уже делаются выводы.
для простой задачи решения не должны быть универсальными и всеобъемлющими =)) Лучше применять бритву оккама, чем грабли оккама.

2фффф
=)а сделав дамп-ресторе этой базы без оидов мы их уплотним и можно получить еще 10 лет пользования =) , если конечно не количество записей в таблице превысит 4 млрд =).... А если так то и сериал не думаю что долго продержится - инт4 все таки, тогда uunid нужен =), но думаю там задача проще, судя по описанию

2Дмитрий: А данные потом будут убиваться ? сколь долго нужна будет тзапись вставленная "сегодня" т.е. актуальность, если вчерашние записи будут удаляться то можно сделать "грязно" но быстро, если же нужно строить каркас БД и она потом будет расти и вырастать в терабайтных монстров, распределенных в пространстве - тогда да - и справочники и желательно "шифры", т.е. не числовые а строковые идентификаторы. и проектирование желательно.. Качественное.

Да, триггера не срабатывают при копи, надо будет писать тогда процедуры обработки, которые бы по готовой таблице ее шерстили.
Хотя опять же оцени - так ли медленно это : твои 2 млн введутся за 25.000*4*10*2 - 80 минут на все -5.5% всего времени в сутки, если тулза тебе это за раз выкатывает - плохо, а если по 10.000 записей каждые n минут - ну и инсерти себе потихонечку, распределяя нагрузку... копи дороже будет писать =).. Ты не торопись - оцени как сильно будет развиваться проект, если это "сдал забыл" - делай все просто и быстро, если это твоя основная работа - делай так чтобы потом не переделывать

2Oracle не надо повторять заученные вещи, поработай с 10-20 справочниками в две записи, а я руками check повешу. и будет та же целостность, меньшая гибкость и расширяемость, но опять же - если для задачи этого хватит, и в дальнейшем больше ничего не понадобится - зачем усложнять себе жизнь.. А если объем справочников будет как у нас, 250(и растет) при этом в каждом от 200 записей до 40.000 с иерархией , то тут конечно чеками не обойдешься... Да и справочники нужно тоже не банально ваять, ибо всякая взаимная репликация с 2-3 мастерами приводит к большому кол-ву матов, когда на одном мастере сериал такой, на другом еще дальше убежал, а на третьем с места не сдвинулся, а данные приходят проклассифицированные по одному из - вот и начинается увязка справочников...

да забыл - Without oids чуть быстрее, но потом если они понадобятся - нужно будет делать дроп таблицы и перекачку данных,

Хмм. про копи лично не тестил, но когда у нас встал такой вопрос коллега авторитетно заявил - триггеры не живут (было ~7.3.8 и сейчас 7.4.1 постгрес)
На новом завтра потестирую... Если ввел в заблуждение - извиняйте..

И вообще я всегда думал что скорость копи обуславливается именно тем, что игнорируя все ограничения и ключи эта команда пишет чуть ли не напрямую в файлы таблицы... Завтра тоже уточню у спеца нашего, который субд дорабатывает.

2Дмитрий - ну тогда все основательно делай, раз на этом дальше вертеться...

А параметр можешь попробовать передавать как еще один столбец копи. как вариант

Скрябин ДмитрийВ доках нашел, что триггеры выполняются при COPY:

COPY FROM will invoke any triggers and check constraints on the destination table. However, it will not invoke rules.

Это вот тут: http://www.postgresql.org/docs/7.4/interactive/sql-copy.html

спасибо, пойду "позорить" коллегу.
offtop^ рекомендую хелп из pgAdmin он в compiled html - очень удобно..

wbear
Centur
offtop^ рекомендую хелп из pgAdmin он в compiled html - очень удобно..

только не факт что эти доки к той версии ПГ которая на сервере.. 7.4 и 8.0 не очень сильно, но отличаются. а так вобщем поддерживаю рекомендации :)


В 1.0 лежат к 7.4.beta4
в 1.2 - 8.0 beta2 (или beta3,не помню)

Если надо но лень ставить - могу выложить все на хост - скачай и пользуйся...

PS есть тут спецы кто может объяснить почему копи работает быстрее (у меня ранее сложилось мнение, что эта команда пишет чуть ли не напрямую в файлы, игнорируя все ограничения, поэтому и быстрая такая.)