`активный 'флаг или нет?

Question

ОК, поэтому практически каждое приложение на базе базы данных должно иметь дело с «неактивными» записями. Либо, мягкие удаления, либо маркировка чего-то как «игнорируемого». Мне любопытно, есть ли какие-либо радикальные альтернативные мысли в «активном» столбце (или столбце состояния).

Например, если у меня был список людей

CREATE TABLE people (
    id  INTEGER PRIMARY KEY, 
    name  VARCHAR(100), 
    active BOOLEAN, 
    ... 
); 

Это означает, что, чтобы получить список активных людей, вам нужно использовать

SELECT * FROM people WHERE active=True; 

ли кто-нибудь предположить, что неактивные записи будет быть отодвинута на отдельную таблицу и где будет одобрен СОЮЗ для присоединения к двум?

Любопытство ударив ...

EDIT: я должен пояснить, я иду на это с точки зрения пуристов. Я вижу, как архивирование данных может потребоваться для больших объемов данных, но это не то, откуда я. Если вы делаете SELECT * FROM людей это будет иметь смысл для меня, что эти записи являются в некотором смысле «активные»

Благодаря

Answer 1

Вы разбиваете таблицу на активном флаге, так что активные записи находятся в одном разделе, а неактивные записи находятся в другом разделе. Затем вы создаете активное представление для каждой таблицы, которая автоматически содержит активный фильтр. Механизм запросов базы данных автоматически ограничивает запрос разделом, в котором есть активные записи, что намного быстрее, чем даже использование индекса этого флага.

Вот пример того, как создать секционированную таблицу в 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) 
); 

Если вы хотите, чтобы вы могли разместить каждый раздел в разных табличных пространствах. Вы также можете разбить свои индексы.

Кстати, это, похоже, повторение вопроса this, как новичок, мне нужно спросить, какая процедура имеет дело с непреднамеренными дубликатами?

Edit: Как было предложено в комментариях, при условии, пример для создания секционированной таблицы в Oracle

Answer 2

Мы используем активные флаги довольно часто. Однако, если ваша база данных будет очень большой, я могу увидеть значение при переносе неактивных значений в отдельную таблицу.

Тогда вам понадобится только объединение таблиц, когда кто-то захочет просмотреть все записи, активные или неактивные.

Answer 3

Ну, чтобы в большинстве ситуаций вы делали только активные записи, вы могли создавать виды, содержащие только активные записи. Таким образом, гораздо легче не оставлять активную часть.

Answer 4

Активный флаг является своего рода уродливым, но он прост и хорошо работает.

Вы можете перенести их на другой стол, как вы предложили. Я бы предложил посмотреть процент активных/неактивных записей. Если у вас более 20 или 30% неактивных записей, вы можете переместить их в другое место. В противном случае это не имеет большого значения.

Answer 5

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

Answer 6

Переход на отдельный стол и возврат их обратно требует времени. В зависимости от того, сколько записей отключено и как часто вам нужно вернуть их, это может быть или не быть хорошей идеей.

Если в основном они не возвращаются после их захоронения и используются только для сводок/отчетов/независимо от того, что сделает ваш основной стол меньше, запросы будут проще и, вероятно, быстрее.

Answer 7

Да, мы бы хотели. В настоящее время во многих наших таблицах есть столбец «active = 'T/F», в основном для отображения «последней» строки. Когда новая строка вставлена, предыдущая строка T помечена F, чтобы сохранить ее для целей аудита.

Теперь мы переходим к подходу с двумя столами, когда вставлена ​​новая строка, предыдущая строка перемещается в таблицу предыстории. Это дает нам лучшую производительность для большинства случаев - глядя на текущие данные.

Стоимость немного больше, чем старый метод, ранее вы должны были обновлять и вставлять, теперь вам нужно вставлять и обновлять (т.е. вместо того, чтобы вставлять новую строку T, вы изменяете существующую строку со всеми новыми данными) , поэтому стоимость - это просто передача целой строки данных, а не передача только изменений. Это вряд ли повлияет.

Преимущества производительности является то, что индекс вашей главной таблицы является значительно меньше, и вы можете оптимизировать ваш табличные лучше (они не будут расти совсем так!)

Answer 8

Мы используем оба метода для работы с неактивными документами. Метод, который мы используем, зависит от ситуации. Для записей, которые по существу являются значениями поиска, мы используем поле бит бит. Это позволяет нам дезактивировать записи, чтобы они не использовались, но также позволяет нам поддерживать целостность данных с отношениями.

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

Answer 9

Ситуация действительно диктует решение, мнится мне:

Если таблица содержит пользователей, а затем несколько полей «флаг» может быть использован. Один для удаленных, отключенных и т. Д. Или, если пространство является проблемой, тогда флаг для отключенного будет достаточным, а затем фактически удалит строку, если они были удалены.

Это также зависит от политики хранения данных. Если существуют политики хранения данных в архиве, то, вероятно, потребуется какая-то отдельная таблица после какого-либо значительного периода времени.

Answer 10

Нет - это довольно распространенная вещь - несколько вариаций в зависимости от конкретных требований (но вы уже покрыли их):

1) Если вы планируете иметь целую кучу данных - как нескольких терабайт или более - Неплохая идея сразу архивировать удаленные записи - хотя вы можете использовать комбинированный подход маркировки как удаленный, а затем копировать в архивные таблицы.

2) Конечно, возможность жесткого удаления записи по-прежнему существует - хотя мы, разработчики, как правило, являемся упаковщиками данных - я предлагаю вам посмотреть на бизнес-процесс и решить, есть ли в нем необходимость даже поддерживать данные - если есть - сделайте это ... если нет - вы должны, вероятно, не стесняться просто выбросить вещи .....опять же, согласно конкретному бизнес-сценарию.

Answer 11

В большинстве таблиц мы используем перечисление («АКТИВНО», «НЕАКТИВНО», «УДАЛЕНО»), поэтому у нас есть 3-позиционный флаг. Я считаю, что это хорошо работает для нас в разных ситуациях. Ваш пробег может отличаться.

Answer 12

Перемещение неактивных материалов - это, как правило, глупая идея. Много накладных расходов с большим количеством ошибок для ошибок, все становится более сложным, например, разборки и т. Д. Что вы делаете со связанными данными? Если вы все это перемещаете, вы также должны изменить каждый запрос. Если вы не переместите его, какое преимущество вы надеялись получить?

Это приводит к следующему пункту: ПОЧЕМУ вы его переместите? Правильно проиндексированная таблица требует дополнительного поиска, когда размер удваивается. Любое повышение производительности должно быть незначительным. И почему вы даже думаете об этом до отдаленного будущего времени, когда у вас действительно проблемы с производительностью?

Answer 13

Я думаю, что глядя на него строго как часть данных, тогда путь, который показан в оригинальной записи, является правильным. Активная часть данных флага напрямую зависит от первичного ключа и должна находиться в таблице.

В этой таблице хранятся данные о людях, независимо от текущего состояния их данных.

Answer 14

С точки зрения «пуриста» реальная модель не различает вид и таблицу - оба являются отношениями. Таким образом, использование представления, которое использует дискриминатор, совершенно значимо и справедливо, если сущности правильно названы, например. Человек/ActivePerson.

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

Answer 15

Двоичные флаги, подобные этому в вашей схеме, представляют собой идею BAD. Рассмотрим запрос

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

Answer 16

Что касается индексации булево, почему нет:

ALTER TABLE users ADD INDEX index_users_on_active (id, active) ; 

Would что не улучшить поиск?
Однако я не знаю, насколько этот ответ зависит от платформы.