Максим Кузнецов

Не очень понятно, откуда берётся и для чего дальше нужна хранимая информация, как долго она хранится. Ещё не ясно, какую СУБД используете. Объёмы у Вас не очень большие.

Когда мы делали учёт рабочего времени для ПАК "Посетитель", там было всё по честному: регистрировались все события входа/выхода, в том числе между контурами внутри организации. Далее эти события обрабатывались, строилась витрина с учётом плана и факта. Была своя логика определения нарушения рабочего графика, так что опоздание на 5 минут, например, прощалось, но регистрировалось и т.п. Допускалось 15 минут в течение дня на "покурить". Вот со всем этим, с настройками и оперативными данными, с витринами обработанных данных, у нас нормально справлялись и MS SQL, и Firebird, и Postgres. Данные хранились лет 5.

В реляционной модели надо делать несколько таблиц. Одну - для корневой сущности. И по одной - для каждого набора значений; записи этих таблиц должны ссылаться на корневую таблицу. Т.е. в Вашем случае будет корневая таблица CVE и две дополнительные prod и referenc, ссылающиеся на CVE.id.
summary, как я понял, содержит просто текст. Но если нужно и это значение парсить, будет третья дополнительная таблица.