«Лучший» способ сохранить историю изменений зависит от ваших конкретных целей / ограничений - и вы их не упомянули.
Но вот некоторые соображения по поводу двух предложенных вами методов:
создать одну таблицу для сообщений и одну для истории сообщений, например:
create table posts (
id int primary key,
userid int
);
create table posthistory (
postid int,
revisionid int,
content varchar(1000),
foreign key (postid) references posts(id),
primary key (postid, revisionid)
);
(Очевидно, будет больше столбцов, внешних ключей,и т.д.) Это просто реализовать и легко понять (и легко позволить СУБД поддерживать ссылочную целостность), но, как вы упомянули, может привести к тому, что posthistory будет иметь слишком много строк для поиска достаточно быстро.
Обратите внимание, что postid является внешним ключом в posthistory (и PK posts).
- Используйте денормализованную схему, где все последние ревизии находятся в одной таблице, а предыдущие ревизиинаходятся в отдельной таблице.Это требует большей логики со стороны программы, то есть
when I add a new version, replace the post with the same id in the post table, and also add this to the revision table.
(Это может быть то, что используют сайты SE, основываясь на дампе данных в SE Data Explorer. А может и нет, я не могу сказать.)
Для этого подхода postid также является внешним ключом в таблице posthistory и первичным ключом в posts таблица.