LifterВопрос вроде простой, но все же...

Есть две таблицы, который сейчас связаны как 1:N

Первая таблица - справочник событий, которые могут возникнуть на устройстве (отказ, ребут, ..т.п.). Числовой код события здесь - PK.
Вторая таблица - собственно события возникающие на устройстве, (PK составной из даты события и кода устройства). Числовой код события здесь - FK.

БД на Oracle 10g, вторая таблица секционирована по диапазонам дат и по хэшу кодов устройств. В неё записывается порядка 400 строк в секунду.

Теперь задача: изменить связь между таблицами на N:M, т.е. теперь допускается что в один момент времени на одном устройстве может произойти несколько событий.

Не знаю как лучше реализовать:
1) стандартная таблица связка, с миграцией в неё составного ключа и партицированием как-то не очень привлекает, с учетом огромного количества данных;

2) отказаться от нормализации и писать коды событий в один столбец с каким-либо разделителем - тоже не очень;

3) подумываю насчет nested table, в общем нужен совет )

Для начала напомню, что в Oracle связи не поддерживаются, так как в РМД просто нет ни объектов, ни связей, а есть только отношения:)
Так вот совет (на будущее) давно дал Дейт: нужно создавать отдельное отношение (в логической схеме БД) для каждой связи (в концептуальной схеме, которую СУБД не поддерживает).
Тогда бы у Вас не было той проблемы, которая сейчас возникла:)
При этом мощность связи "управляется" простыми ограничениями на пару внешних ключей в отношении, моделирующем связь.
Но, правда, тогда у Вас был бы вариант 1), который Вас не привлекает.
Лучше всего перейти на Cache, там много вариантов решения будет, в зависимости от постановки задачи, от которой Вы сообщили только маленький кусочек:)

lLocustБредятина,

Для решения такой задачи
авторперейти на Cache?

Возможно переписать тонны текста, переделать логику, нанять/переобучить персонал?
и все это для решения такой задачи?
Тонны??? Логика??? Персонал???
Значит мое предположение о "кусочке" - это не то слово:)
Хотя логика и персонал уж точно совершенно не при чем. А вот кода в Oracle, действительно, намного больше:) Как выясняется, тонны:)

lLocustБредятина,

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

LifterСпасибо всем.
Пожалуй остановлюсь на совете lLocust, тем более что у самого параллельно возникла подобная мысль.
СУБД менять естесственно не буду, а вот за отсыл к Дейту спасибо, освежу в памяти на досуге =)
В Вашем случае и не стояла задача "переходить к связи M:М" так как событие связано с типом события, конечно же, связью 1:1. У Вас обычная ситуация, когда событие связано с участниками события (иногда говорят - схема "звезда"); в данном случае с устройством и с типом события .
Так что, коллега конечно, прав, что я влез не по делу:)