Вопрос по sql, mysql, postgresql – Активный флаг или нет?
Итак, практически каждое приложение на основе базы данных имеет дело с "неактивным" записей. Либо мягкое удаление, либо пометка чего-либо как "игнорируемого". Мне любопытно, есть ли какие-нибудь радикальные альтернативные мысли о «активном»? столбец (или столбец состояния).
Например, если бы у меня был список людей
<code>CREATE TABLE people ( id INTEGER PRIMARY KEY, name VARCHAR(100), active BOOLEAN, ... ); </code>
Это означает, что для получения списка активных людей, вы должны использовать
<code>SELECT * FROM people WHERE active=True; </code>
Кто-нибудь предлагает, чтобы неактивные записи были перенесены в отдельную таблицу, и, где уместно сделать UNION, чтобы присоединиться к ним?
Любопытство поражает ...
EDIT: Я должен прояснить, я подхожу к этому с точки зрения пуристов. Я вижу, как архивирование данных может быть необходимо для больших объемов данных, но это не то, откуда я пришел. Если вы выберете команду SELECT * FROM, для меня будет иметь смысл, что эти записи являются в некотором смысле «активными».
Спасибо
столбец во многих наших таблицах, в основном, чтобы показать «последние»; строка. Когда вставляется новая строка, предыдущая строка T помечается буквой F, чтобы сохранить ее для целей аудита.
Теперь мы переходим к подходу с двумя таблицами: когда вставляется новая строка, предыдущая строка перемещается в таблицу истории. Это дает нам лучшую производительность в большинстве случаев - если смотреть на текущие данные.
Стоимость немного больше, чем у старого метода, ранее вам приходилось обновлять и вставлять, теперь вы должны вставить и обновить (т.е. вместо вставки новой строки T вы изменяете существующую строку со всеми новыми данными), поэтому стоимость это просто передача целого ряда данных вместо передачи только изменений. Это вряд ли даст какой-либо эффект.
Выигрыш в производительности заключается в том, что индекс вашей основной таблицы значительно меньше, и вы можете лучше оптимизировать свои табличные пространства (они не вырастут так сильно!)
который мы используем, зависит от ситуации. Для записей, которые по сути являются поисковыми значениями, мы используем битовое поле Active. Это позволяет нам деактивировать записи, чтобы они не использовались, но также позволяет нам сохранять целостность данных в отношениях.
Мы используем & quot; перейти к разделительному столу & quot; метод, в котором данные больше не нужны, и данные не являются частью отношения.
и от конкретных требований (но вы уже рассмотрели их):
1) Если вы ожидаете, что у вас будет целая куча данных - например, несколько терабайт или более - неплохая идея немедленно архивировать удаленные записи - хотя вы можете использовать комбинированный подход, помечая как удаленные, а затем копировать в архивные таблицы.
2) Конечно, возможность жесткого удаления записи все еще существует - хотя мы, разработчики, как правило, являемся пакетами данных - я предлагаю вам взглянуть на бизнес-процесс и решить, есть ли необходимость в сохранении данных - если есть - сделайте так ... если нет - вы, вероятно, не стесняйтесь просто выбросить вещи ... опять же, в соответствии с конкретным бизнес-сценарием.
чтобы активные записи находились в одном разделе, а неактивные - в другом. Затем вы создаете активное представление для каждой таблицы, которая автоматически имеет активный фильтр. Механизм запросов к базе данных автоматически ограничивает запрос разделом, в котором находятся активные записи, что намного быстрее, чем даже использование индекса для этого флага.
Вот пример того, как создать секционированную таблицу в Oracle. В Oracle нет булевых типов столбцов, поэтому я изменил структуру вашей таблицы для целей Oracle.
CREATE TABLE people
(
id NUMBER(10),
name VARCHAR2(100),
active NUMBER(1)
)
PARTITION BY LIST(active)
(
PARTITION active_records VALUES (0)
PARTITION inactive_records VALUES (1)
);
Если вы хотите, вы можете поместить каждый раздел в разные табличные пространства. Вы также можете разделить ваши индексы.
Кстати, это кажется повторениемэтот вопрос, как новичку мне нужно спросить, какова процедура обращения с непреднамеренными дубликатами?
Edit: Как и просили в комментариях, приведен пример создания секционированной таблицы в Oracle
зависимости от того, сколько записей отключено от сети и как часто вам нужно возвращать их, это может быть или не быть хорошей идеей.
Если большинство из них не возвращаются после того, как они похоронены и используются только для сводок / отчетов / чего угодно, тогда ваша основная таблица будет меньше, запросы будут проще и, вероятно, быстрее.
SELECT count(*) FROM users WHERE active=1
Выглядит достаточно просто. Но что происходит, когда у вас большое количество пользователей, так много, что добавление индекса к этой таблице будет необходимо. Опять же, это выглядит прямо вперед
ALTER TABLE users ADD INDEX index_users_on_active (active)
КРОМЕ!! Этот индекс бесполезен, потому что количество элементов в этом столбце ровно два! Любой оптимизатор запросов к базе данных будет игнорировать этот индекс из-за его низкой мощности и выполнять сканирование таблицы.
Прежде чем заполнять вашу схему полезными флагами, подумайте, как вы собираетесь получить доступ к этим данным.
https://stackoverflow.com/questions/108503/mysql-advisable-number-of-rows
как правило, глупая идея. Это накладные расходы с большим количеством потенциальных ошибок, все становится более сложным, например разархивирование материала и т. Д. Что вы делаете со связанными данными? Если вы все это тоже переместите, вам придется изменить каждый запрос. Если вы не перемещаете его, какое преимущество вы надеялись получить?
Это приводит к следующему пункту: ПОЧЕМУ вы бы это переместили? Правильно проиндексированная таблица требует одного дополнительного поиска, когда размер удваивается. Любое улучшение производительности должно быть незначительным. И почему вы вообще об этом думаете, пока в далеком будущем не возникли проблемы с производительностью?
Если таблица содержит пользователей, то несколько «флагов» поля могут быть использованы. Один для «Удалено», «Отключено» и т. Д. Или, если пробел является проблемой, то будет достаточно флага «Отключено», а затем фактически удаляется строка, если они были удалены.
Это также зависит от политик хранения данных. Если существуют политики для хранения данных в архиве, то, скорее всего, по прошествии длительного времени потребуется отдельная таблица.
дставлением и таблицей - оба являются отношениями. Таким образом, использование представления, которое использует дискриминатор, является совершенно осмысленным и допустимым при условии, что сущности правильно названы, например, Человек / ActivePerson.
Кроме того, с точки зрения «пуристов»; В таблице должно быть указано имя пользователя, а не люди, поскольку имя отношения отражает кортеж, а не весь набор.