Вопрос по sql, mysql, postgresql – Активный флаг или нет?

20

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

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

<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, для меня будет иметь смысл, что эти записи являются в некотором смысле «активными».

Спасибо

Ваш Ответ

16   ответов
1

столбец во многих наших таблицах, в основном, чтобы показать «последние»; строка. Когда вставляется новая строка, предыдущая строка T помечается буквой F, чтобы сохранить ее для целей аудита.

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

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

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

Все это говорит о том, что новая система, с которой я работаю, записывает совершенно отдельную таблицу аудита, которая просто записывает все изменения «автоматически». запись "столбец X изменен с Y на Z" для всех важных (не всех) изменений данных.
Я также хочу перейти к подходу с двумя таблицами, поскольку я работаю со старой, плохо спроектированной базой данных, в которой некоторые таблицы имеют "активный =" T / F ". столбец для целей аудита, и они не имеют первичных ключей. Как вы обрабатывали удаленные записи, используете ли вы флаг, чтобы пометить строку как активную / удаленную, или вы также перемещаете удаленную запись в таблицу истории? Кроме того, вы каскадно перемещаете все связанные данные в таблицы истории? Спасибо!
ничего не удаляется, вы перемещаете все записи в таблицу истории и ставите на них флажки. Если вам нужно записать удаление (а не впоследствии изменять), вам просто нужен новый столбец, чтобы пометить их как удаленные. Однажды кто-нибудь спросит о мертвых данных, и вы сможете ответить на них правильно. Мы не каскадно связываем записи - если они изменяются, то их данные необходимо обновлять, но если отношения не изменяются, вам не нужно это делать - однако наша схема данных была достаточно простой, чтобы это сделать, YMMV.
0

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

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

0

и от конкретных требований (но вы уже рассмотрели их):

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

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

21

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

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

Вместо "активного" flag Я бы рекомендовал использовать другое имя поля, например & quot; удалено & quot ;. Причина в том, что, когда следующий человек работает над этим, он может быть смущен тем, что «активно» средства. Кроме этого +1 отличный пост.
@NotMe удален кажется одинаково неоднозначным. Если что-то удалено, почему оно все еще рядом? Похоже, такие вещи лучше обрабатываются в документации.
Не могли бы вы более подробно рассказать о том, как «разбить» на разделы? стол. Я имею в виду предоставление кода для того, что вам нравится.
По запросу добавлен пример секционированной таблицы. Посмотрите руководство Oracle по концепциям для получения подробной информации о секционировании таблиц и индексов. Я использую Oracle 10.2 и ссылаюсь на всю документацию отсюда - & gt;oracle.com/pls/db102/homepage
0

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

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

8

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

1

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

Количество элементов не должно влиять на использование индекса. Селективность делает.
2

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

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

0

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

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

0

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

2

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

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

0

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

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

0

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

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

схемы именования являются предпочтительными. Я думаю, что просто рекомендуется придерживаться того, как вы решаете для всех столов. Многим нравится считать, что отношение содержит много вещей.
0

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

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

1

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

3

«INACTIVE», «DELETED») в большинстве таблиц, поэтому у нас фактически есть флаг с 3 путями. Я считаю, что это хорошо работает для нас в разных ситуациях. Ваш пробег может варьироваться.

Похожие вопросы