'активный' флаг или нет?
Просто хотел отметить, что я новичок в этом, но, возможно, это может помочь:
Вы можете использовать
...
или
Примечание: Как и многие другие комментарии, это не совсем возможно, но я оставлю этот код на всякий случай, если он поможет в вашем конкретном случае.
как скрыть мой исходный код, чтобы его нельзя было скопировать
https://www.codeproject.com/Articles/11222/Disabling-the-right-click -он-веб-страница
15 ответов
Вы делите таблицу на активном флаге, так, чтобы активные записи были в одном разделе, и неактивные записи находятся в другом разделе. Тогда Вы создаете активное представление для каждой таблицы, которая автоматически имеет активный фильтр на нем. Механизм запроса базы данных автоматически ограничивает запрос разделом, который имеет активные записи в нем, который намного быстрее, чем ровное использование индекса на том флаге.
Вот пример того, как создать разделенную таблицу в 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)
);
, Если Вы хотели Вам, мог бы поместить каждый раздел в различные табличные области. Можно также разделить индексы также.
Кстати, это кажется повторением этот вопрос как новичок, которого я должен спросить, какова процедура по контакту с непреднамеренными дубликатами?
Редактирование: Согласно просьбе в комментариях, предоставленных пример для создания разделенной таблицы в Oracle
С 'пуристской точки зрения' реляционная модель не дифференцируется между представлением и таблицей - оба - отношения. Так, чтобы использование представления, которое использует различитель, было совершенно значимо и допустимо, если объекты правильно называют, например, Person/ActivePerson.
кроме того, с 'пуристской точки зрения' таблицу нужно назвать человеком, не людьми, поскольку название отношения отражает кортеж, не весь набор.
Нет - это - довольно общая вещь - несколько изменений в зависимости от конкретных требований (но Вы уже покрыли их):
1), Если Вы ожидаете иметь целый НАБОР данных - как несколько терабайт или более - не плохая идея сразу заархивировать удаленные записи - хотя Вы могли бы использовать подход комбинации маркировки, как удалено тогда копирования для архивации таблиц.
2), Конечно, опция трудно удалить запись все еще существует - хотя нас разработчики склонны быть воришками данных - я предлагаю, чтобы Вы посмотрели на бизнес-процесс и решить, существует ли теперь какая-либо потребность даже сохранить данные - если существует - делают так..., если нет - необходимо, вероятно, не стесняться только выбрасывать материал..... снова, согласно определенному бизнес-сценарию.
Ситуация действительно диктует решение, мне кажется:
, Если таблица содержит пользователей, то несколько полей "флага" могли использоваться. Один для Удаленного, Отключенного и т.д. Или если пространство является проблемой, то флаг для отключенного был бы достаточен, и затем на самом деле удаление строки, если они были удалены.
Это также зависит от политик для того, чтобы хранить данные. Если бы существуют политики для хранения заархивированных данных, то отдельная таблица, скорее всего, была бы необходима после любого большого отрезка времени.
Мы используем оба метода для контакта с неактивными записями. Метод, который мы используем, зависит от ситуации. Для записей, которые являются чрезвычайно справочными значениями, мы используем Активное битовое поле. Это позволяет нам деактивировать записи так они привычка использоваться, но также и позволяет нам поддерживать целостность данных с отношениями.
Мы используем "перемещение для разделительного метода" таблицы, где данные больше не необходимы, и данные не являются частью отношения.
Отъезд к отдельной таблице и возвращение их занимают время. В зависимости от того, сколько записей идут офлайн и как часто необходимо возвратить их, это могло бы или не могло бы быть хорошей идеей.
, Если главным образом не возвращаются, как только они прокладываются под землей, и только используются для summaries/reports/whatever, тогда он сделает Вашу основную таблицу меньшей, запросы более простой и вероятно быстрее.
В большинстве случаев двоичное полевое удаление указания достаточно. Часто существует механизм уборки, который удалит те удаленные записи после определенного количества времени, таким образом, можно будет хотеть запустить схему с удаленной метки времени.
Двоичные флаги как это в Вашей схеме являются ПЛОХОЙ идеей. Рассмотрите запрос
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
Да, мы были бы. У нас в настоящее время есть "активный ='T/F'" столбец во многих наших таблицах, главным образом для показа 'последней' строки. Когда новая строка вставляется, предыдущая строка T отмечена F для хранения ее для целей аудита.
Теперь, мы перемещаемся в подход с 2 таблицами, когда новая строка вставляется, предыдущая строка перемещена в таблицу истории. Это дает нам лучшую производительность для большинства случаев - рассмотрение текущих данных.
стоимость является немного больше, чем старый метод, ранее необходимо было обновить и вставить, теперь необходимо вставить и обновить (т.е. вместо того, чтобы вставить новую строку T, Вы изменяете существующую строку со всеми новыми данными), таким образом, стоимость является просто стоимостью передачи в целой строке данных вместо того, чтобы передать в просто изменениях. Это едва собирается сделать любой эффект.
выигрыш в производительности - то, что индекс Вашей основной таблицы значительно меньше, и можно оптимизировать табличные области лучше (они не вырастут вполне так!)
Активный флаг является видом ужасных, но это просто и работает хорошо.
Вы могли переместить их в другую таблицу, как Вы предположили. Я предложил бы смотреть на процент активных / неактивные записи. Если у Вас есть более чем 20 или 30%-е неактивные записи, то Вы могли бы рассмотреть перемещение их в другом месте. Иначе, это не имеет большого значения.
Я думаю, смотря на него строго как на часть данных тогда путь, который показывают в исходном сообщении, является надлежащим. Активная часть флага данных непосредственно зависит от первичного ключа и должна быть в таблице.
, Что таблица содержит данные по людям, независимо от текущего статуса их данных.
Перемещение неактивного материала обычно является глупой идеей. Это - много издержек с большим потенциалом для ошибок, все становится более сложным, как разархивирование материала и т.д., Что Вы делаете со связанными данными? При перемещении всего, что также необходимо изменить каждый запрос. Если Вы не перемещаете его, какое преимущество Вы надеялись получить?
, Который приводит к следующему вопросу: ПОЧЕМУ Вы переместили бы его? Правильно индексируемая таблица требует одного дополнительного поиска, когда размер удваивается. Любое повышение производительности обязано быть незначительным. И почему Вы даже думали бы об этом до времени далекого будущего, когда у Вас на самом деле есть проблемы производительности?
Мы используем перечисление ('АКТИВНЫЙ', 'НЕАКТИВНЫЙ', 'УДАЛЕННЫЙ') в большинстве таблиц, таким образом, у нас на самом деле есть флаг с 3 путями. Я нахожу, что это работает хорошо на нас в различных ситуациях. Ваш пробег может варьироваться.
Ну, чтобы гарантировать, чтобы Вы только потянули активные записи в большинстве ситуаций, Вы могли создать представления, которые только содержат активные записи. Тем путем намного легче не не учесть активную часть.
Мы используем активные флаги довольно часто. Если Ваша база данных будет очень большой, я видел значение в миграции неактивных значений к отдельной таблице, все же.
Вы тогда только потребовали бы объединения таблиц, когда кто-то хочет видеть все записи, активные или неактивные.