Активный флаг или нет? - PullRequest
       24

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

20 голосов
/ 19 сентября 2008

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

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

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

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

SELECT * FROM people WHERE active=True;

Кто-нибудь предлагает, чтобы неактивные записи были перенесены в отдельную таблицу, и, где уместно сделать UNION, чтобы объединить эти две таблицы?

Любопытство поражает ...

РЕДАКТИРОВАТЬ: Я должен пояснить, я подхожу к этому с точки зрения пуриста. Я вижу, как архивирование данных может быть необходимо для больших объемов данных, но это не то, откуда я пришел. Если вы сделаете SELECT * FROM людей, для меня будет иметь смысл, что эти записи в некотором смысле «активны»

Спасибо

Ответы [ 16 ]

0 голосов
/ 19 сентября 2008

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

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

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

0 голосов
/ 19 сентября 2008

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

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

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

0 голосов
/ 19 сентября 2008

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

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

0 голосов
/ 19 сентября 2008

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

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

0 голосов
/ 19 сентября 2008

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

0 голосов
/ 19 сентября 2008

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...