История изменений

Можешь сделать «по-простому»,по первому варианту, забив на нормализацию и храня всё в одной таблице. К плюсам можно отнести потенциально большую скорость работы.

Можешь сделать «реляционно», по второму варианту. Следить там ни за чем не нужно, всё будет работать автоматом.

create table event(
id int not null,
PRIMARY KEY (id) 
);

create table event_warning(
id int not null,
event_id int not null,
PRIMARY KEY (id) ,
FOREIGN KEY(event_id) REFERENCES event(id) ON DELETE CASCADE
);

От случаев, когда добавлена новая строка в event, но возникла ошибка при добавлении в event_% защищается транзакциями. Описанного недостатка «надо следить» здесь нет и в помине. Следить будет сама СУБД. Есть другой недостаток, снижение общего быстродействия за счёт того, что операции будут производиться не с одной таблицей, а с несколькими.

Можешь сделать «по-простому»,по первому варианту, забив на нормализацию и храня всё в одной таблице. К плюсам можно отнести потенциально большую скорость работы.

Можешь сделать «реляционно», по второму варианту. Следить там ни за чем не нужно, всё будет работать автоматом.

create table event(
id int not null,
PRIMARY KEY (id) 
);

create table event_warning(
id int not null,
event_id int not null,
PRIMARY KEY (id) ,
FOREIGN KEY(event_id) REFERENCES event(id) ON DELETE CASCADE
);

От случаев, когда добавлена новая строка в event, но возникла ошибка при добавлении в event_X* защищается транзакциями. Описанного недостатка «надо следить» здесь нет и в помине. Следить будет сама СУБД. Есть другой недостаток, снижение общего быстродействия за счёт того, что операции будут производиться не с одной таблицей, а с несколькими.

Можешь сделать «по-простому»,по первому варианту, забив на нормализацию и храня всё в одной таблице. К плюсам можно отнести потенциально большую скорость работы.

Можешь сделать «реляционно», по второму варианту. Следить там ни за чем не нужно, всё будет работать автоматом.

create table event(
id int not null,
PRIMARY KEY (id) 
);

create table event_warning(
id int not null,
event_id int not null,
PRIMARY KEY (id) ,
FOREIGN KEY(event_id) REFERENCES event(id) ON DELETE CASCADE
);

От случаев, когда добавлена новая строка в event, но возникла ошибка при добавлении в event_x защищается транзакциями. Описанного недостатка «надо следить» здесь нет и в помине. Следить будет сама СУБД. Есть другой недостаток, снижение общего быстродействия за счёт того, что операции будут производиться не с одной таблицей, а с несколькими.