Дизайн базы данных: разница между использованием логических полей и дубликатов таблиц

Question

Мне нужно спроектировать схему базы данных для приложения, которое я создаю. Я буду использовать MySQL. В этом приложении пользователи вводят данные, и они, очевидно, сохраняются в базе данных. Однако эти данные не доступны для общественности, пока пользователь не опубликует данные. В настоящее время у меня есть один столбец для хранения всех данных. Мне было интересно, является ли логическое поле в этой таблице, указывающее, были ли опубликованы данные, хорошей идеей. Или гораздо лучше создать одну таблицу для сохраненных данных и одну таблицу для опубликованных данных и переместить сохраненные данные в таблицу опубликованных данных, когда пользователь нажимает Publish.

Каковы преимущества и недостатки использования каждого из них, и считается ли один из них лучшим дизайном, чем другой?

Answer 1

Корпус: бинарный

Они примерно равны. Используйте это как учебное упражнение - реализуйте его одним способом; посмотри какое-то время, затем переключись на другой путь.

• (то же самое) Пробел: поскольку строка существует ровно один раз, ни один из вариантов не является «лучшим».
• (таблица предпочтений 1) При "публикации" требуется транзакция для атомарного удаления из одной таблицы и вставки в другую.
• (предпочитают 2 таблицы) Некоторые SELECTs будут тратить время на фильтрацию записей с другим значением для published. (Это относится к deleted, embargoed, approved и множеству других возможных логических флагов.)

Случай: история изменений

Если в записи много ревизий, лучше использовать две таблицы: Current data и History. Это связано с тем, что «важные» запросы включают выборку только текущих данных.

(PARTITIONs вряд ли поможет в любом случае.)