Подтвердить что ты не робот

Флаг `active 'или нет?

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

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

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

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

SELECT * FROM people WHERE active=True;

Кто-нибудь может предположить, что неактивные записи будут перенесены в отдельную таблицу и где будет разрешено СОЕДИНЕНИЕ, чтобы присоединиться к двум?

Любопытство...

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

Спасибо

4b9b3361

ОТВЕТЫ

Ответ 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, как новичок, которого я должен спросить, что такое процедура, связанная с непреднамеренными дубликатами?

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

Ответ 8

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

SELECT count(*) FROM users WHERE active=1

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

ALTER TABLE users ADD INDEX index_users_on_active (active)

КРОМЕ!! Этот индекс бесполезен, потому что мощность в этом столбце ровно две! Любой оптимизатор запросов базы данных будет игнорировать этот индекс из-за его низкой мощности и сканирования таблицы.

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

fooobar.com/questions/280191/...

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

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

Ответ 13

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

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

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

Ответ 14

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

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

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

Ответ 15

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

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

Ответ 16

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

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

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

Ответ 17

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

Хитрость заключается в том, чтобы использовать столбец "dateInactivation", в котором хранится timestamp, когда запись деактивируется/удаляется. Как следует из названия, значение равно NULL, когда запись активна, но после деактивации запишите в системную дату и время. Таким образом, индекс в этом столбце имеет высокую селективность по мере увеличения числа "удаленных" записей, поскольку каждая запись будет иметь уникальное (не строго говоря) значение.

Тогда ваш запрос становится:

SELECT * FROM people WHERE dateInactivated is NULL;

Индекс вытянет только тот набор строк, который вам нужен.