Привет всем!
У меня есть вопрос по структуре таблиц в БД. Может сможете подсказать лучшее решение...
База данных - DB2 8.2, под Win32.

Есть входящиее в некоторую программу сообщения. Каждое сообщения имееют свой номер, в тектовом формате. Размер 36 букофф. Кроме того сообщение содержит в себе куч другой информации, в том числе и приатаченые файлы -они(файлы) кладуться в ДБ как БЛОБы. Основная задача это варехаусинг этих сообщений, но так же в процессе обработки группы сообщений (несколько подряд приходящих сообщений могут составлять группу, которые обрабатываются в одной транзакции) происходит обращение к БД за информацией о уже обработанных ранее в этой транзакции сообщениях. Внизу придуманная мной часть структуры БД в упрощенном виде.

В первую таблицу кладется приходящий ИД, и авторматом генерируется соответствующий ему ИД, но уже в БИГИНТ, затем он выбирается и работа с остальными таблицами ведется уже через это БИГИНТ. Я сделал эту таблицу, исходя из тех соображений, что поиск по ней будет происходить быстрее, нежели если бы я объеденил эту таблицу и таблицу ARCHMSG. Вот тут я ошибаюсь или нет?

CREATE TABLE "MSG2ARCH" (
"MSG_ID" CHAR(36) NOT NULL ,
"ARCH_MSG_ID" BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY
)
ALTER TABLE "MSG2ARCH"
ADD CONSTRAINT "CC1159525283343" PRIMARY KEY
("MSG_ID");

Вторая таблица хранит детали сообщения. Т.е. получив БИГИНТ ИД я вставляю его в эту таблицу, и затем заполняю остальные поля.
CREATE TABLE "ARCHMSG" (
"ARCH_MSG_ID" BIGINT NOT NULL ,
"GROUP_ID" CHAR(50) ,
"FROM" VARCHAR(255) NOT NULL ,
"SUBJECT" VARCHAR(255) ,
"PUT_TIME" TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP ,
"TEXT" CLOB(104857600) LOGGED COMPACT )

ALTER TABLE "ARCHMSG"
ADD CONSTRAINT "CC1159525782374" PRIMARY KEY
("ARCH_MSG_ID");

Есть еще таблицы, которые хранят ARCH_MSG_ID и ссылаются на него.
Как я уже сказал выше, я не совсем уверен, что нужно было разносить эти две таблицы. Но с другой стороны мне кажется что выборка из MSG2ARCH по MSG_ID будет быстрее когда там всего, нежели если бы эти таблицы были объеденены.

Заранее спасибо за любую информацию!

Забыл добавить, что записей будет много. Т.е. ожидается поток 1 сообщение в минуту.

Ну конечно смотря с чем сравнивать... Вообще по ТЗ нагрузка должна быть такая: Количество сообщений размером 100 кб, обрабатываемых центральным узлом в течение суток не менее 100 тысяч. Так что я сообщил инфу по текущей ситуации на опытном участке, и наверное поскромничал... но наверное это сути дела не меняет. Вот только я не понял, я задал слишком дурацкий вопрос, или слишком сложный... что никто ничего не ответил?

2Rin@t: Раз "Скорее" значит сам не уверен... а когда не уверен, то не гони.

А вообще похоже, тут многие наверное сразу родились со знанием арихтектур БД, нормализации и завышенным самомнением... Я наверное вопрос и задал, чтобы если я не прав, чтобы меня поправили...

Возможно мне следовало сразу вставить картинку со структурой, но мне казалось, что вопрос не затрагивает остальной структуры базы. К сожалению Визио не отображает типы полей, но наверное они и не важны в данный момент. Скажу только, что все ПК - БИГИНТ, за исключением таблицы ARCH2MSG, где MSG_ID это char(36)

Сорри, структура в этом файле.

Спасибо всем ответившим.
2DocAl: в поле MSG_ID будет храниться подобная строка: 414d51205344535f42524b5f514d2020f27d8f4520001a04 Кстати мне по ней надо будет делать поиск на сравнение и я думаю может лучше использовать не чар а блоб? По какому типу столбца будет поиск производится быстрее? Мне казалось что CHAR будет работать быстрее чем блоб, поэтому был выбран тип CHAR.
Как я писал выше, по ТЗ должно быть порядка 100 тысяч записей в сутки. По моему это достаточно большая нагрузка. Если не трудно, можно в двух словах тогда сказать в каком направлении двигаться, чтобы сделать данную структуру более оптимизированной для быстродействия или может кто найдет время нарисовать исходя из моей схемы что-то более правильное?
Но первый шаг к более правильной модели, насколько я понимаю, это объеденить таблицы ARCHMSG и MSG2ARCH?
Заранее всем спасибо!

Да правильно, в одном сообщении может быть несколько направлений, таблица DESTINATIONS как раз предназначена чтобы хранить все направления для маршрутизации сообщения. На рисунке не правильно нарисовал :( - естественно ARCH_MSG_ID в таблице DESTINATIONS должен быть внешним ключом.
А вообще я конечно получил совет - объеденить таблицы, но я не понял почему? Разве поиск в таблице (по полю MSG_ID, который имеет тип CHAR) которая содержит меньше столбцов, причем оба столбца имеют фиксированную размерность, не будет происходить быстрее, чем поиск в большой таблице (ARCHMSG) с множеством не фиксированных полей? К тому же количество записей я считаю достаточно большое.
Ну и как все-таки быть с типом полей? Что лучше использовать в данном случае CHAR или BLOB?
Дело в том, что база эта будет крутиться под ДБ2 в 64битном режиме, под AIX 64bit на рSeries, поэтому я и пытаюсь понять есть ли какие способы выиграть в производительности.

у меня есть класс который конвертирует блоб в чар. Т.е.на входе имеется поле MSG_ID (тип БЛОБ)=414d51205344535f42524b5f514d2020f27d8f4520001a04 После конвертации я получаю строку MSG_ID_CHAR = h'414d51205344535f42524b5f514d2020f27d8f4520001a04', так что я могу сохранять этот MSG_ID как чар в базе, и искать уже по нему. Насколько я понимаю, лучше использовать CHAR так как индекс по блобу не строится? Или я ошибаюсь?