Мне любопытно, стоит ли что-нибудь удалять? Прямо сейчас я создаю сайт (для себя), который позволяет вам подписываться на пользователей, которым вы затем получаете сообщение каждый раз, когда пользователь загружает контент.
Или комментарии, если есть ветка, и кто-то пишет прямой комментарий к вашему комментарию, вы получите сообщение об этом. Должен ли я когда-нибудь их удалить или просто скрыть?
Каждая подписка имеет три (64-битных) int. id, commentId, recipientId. Вы можете узнать, кто вам написал, просмотрев таблицу комментариев через commentId. Если я не использую delete, у него будет 4-е int, говорящее о статусе (показать, скрыть / удалить).
Оставить их или удалить? Если я должен их удалить, то почему? Я могу видеть, может быть, когда есть личный пользователь, которого вы должны удалить по запросу, но кроме того, что я должен удалить?
Я не знаю, какую базу данных SQL я буду использовать.
-редактировать-
Спасибо, парни. Сейчас я ничего не удалю, кроме того, что могу сгенерировать. Например, о подписке.
Компания, в которой я работаю, предлагает программное обеспечение людям из определенных регулируемых отраслей, поэтому обычно у меня есть что-нибудь"отношение, потому что, если вы удалите что-либо, вы потеряете полноту своего контрольного журнала. Вместо этого отметьте информацию как удаленную (или переместите ее в архивную версию таблиц) и запишите, кто ее" удалил "и когда.
Единственные причины действительно удалить материал:
Ваши пользователи могут быть благодарны за то, что на самом деле ничего не удаляется, если они случайно удалят что-то полезное, а вы сможете вернуть это. И если расстроенный пользователь, который ранее предоставил сайту ценную информацию, истерично удаляет все свои сообщения в отместку, вы можете легко отозвать удаления.
Еще один очень важный момент: вы должны четко указать в условиях обслуживания, что информация не может быть действительно удалена, когда пользователь больше не может ее видеть, и указать маршрут (если только «напишите x @ xx и попросите его отправить быть сделано "), чтобы они действительно удалили данные, которые они имеют право в соответствии с действующим законодательством требовать удаления.
Как правило, современные размеры дисков и производительность ввода-вывода не позволяют иметь для удаления записей для экономии места или поддержания производительности. Обычно поле «запись удалена» в записи может пометить запись как удаленную (или как другой статус) с контрольным журналом.
Некоторые отрасли требуют, чтобы вы никогда не удаляли «транзакционные» данные по нормативным причинам. Вы бы уже знали, нужно ли вам это делать. Если есть какая-либо платежная информация, вам, как правило, потребуется хранить данные (или сделать их доступными) в течение 7 лет (закон Великобритании о бухгалтерском учете).
Для других целей на самом деле есть веская причина для физического удаления данных.
Если его там нет, его невозможно обнаружить.
Закон о свободе информации (в Великобритании) гласит, что если данные можно обнаружить, они включаются в сферу любого поиска. Сюда входят «мягко удаленные» записи и исторические резервные копии.
Для некоторых систем мы обеспечиваем ОЧИЩЕНИЕ старых записей и повторное использование / уничтожение старых лент / файлов с резервными копиями по прошествии «стольких» месяцев, чтобы убедиться, что они недоступны для запросов FOI. (Обслуживание запроса FOI, который существует несколько лет назад и требует восстановления сотен старых почтовых ящиков из архивных резервных копий, стоит ОЧЕНЬ дорого).
Это отличается от ОПЕРАЦИОННОГО резервного копирования. Мы храним резервные копии, чтобы мы могли восстановить их в случае аварии. У нас также есть «Магазин записей» как для бумажных, так и для электронных носителей, которые ДОЛЖНЫ храниться, и мы копируем электронные письма и тому подобное в этот магазин.
Мой инстинкт - никогда ничего не удалять. Никогда не знаешь, когда это может понадобиться. Если мне по какой-либо причине приходится удалять данные из рабочих таблиц, я стараюсь переместить их в архивную таблицу.
Сказав это, это может быть излишним, если это данные для вашего собственного использования, и немыслимо, что когда-либо будет какая-либо юридическая причина для просмотра старых данных. Вы не так много говорите о своем приложении, но может ли один пользователь потребовать просмотра старых данных на том основании, что другой пользователь клеветал на них?
JR
Удаление зависит от количества доступных ресурсов и количества данных, которые вы собираете. Раньше я работал над проектами, в которых удаление запрещено. Это просто означало, что все элементы данных получат дату начала и дату окончания. Элемент данных будет действителен в течение этого периода, а не до или после. Таким образом, вы можете «удалить» что-либо, установив дату окончания на сегодняшний день.
К сожалению, это также означает, что вам придется проверять текущую дату с этим периодом для каждого элемента данных, который вы хотите выбрать. С SQL это потребует дополнительных условий для ваших запросов.
На самом деле, что еще хуже, вы можете даже отключить редактирование. Когда элемент данных редактируется, вы просто устанавливаете дату окончания на «сейчас» и создаете новый элемент данных с теми же ключами и изменениями. Таким образом вы соберете огромную коллекцию данных, но она будет очень исторической, и ничего не будет удалено. В этом случае даты начала и окончания также должны содержать компонент времени. (И вы должны беспокоиться о летнем времени, когда часы переводятся на один час назад.) Но в основном ваша система будет только вставлять новые элементы, а не изменять или удалять что-либо.
Вы должны решить, стоит ли сохранять ваши данные навсегда! Все говорят, что диск дешевый, но это не вся правда. Это зависит от вашего решения для хранения данных и вашей среды.
Если вы используете диски Fibre Channel в сети SAN и у вас заканчивается дисковое пространство, это уже не дешево, когда вам нужно добавить еще один дисковый массив из-за нехватки места в вашем массиве.
В вашем случае не похоже, что вы будете хранить большой объем данных, и дисковое пространство может не быть проблемой, но насколько актуальны ваши данные через 10 лет?
Еще одна вещь, о которой следует подумать, - это общая производительность, а не только дисковое пространство. Я считаю хорошей идеей хранить исторические данные в другой таблице или даже в другой базе данных. Таким образом, у меня будет меньше обслуживания и т. Д. Я знаю, что есть и другие решения для архивирования исторических данных, такие как разбиение на разделы, но если эти данные не используются на регулярной основе, зачем реализовывать больше сложности?
Я работаю с большими базами данных последние 6 лет, и стратегия индексации очень удобна, когда у вас есть таблица с 500 000 000 записей. :) Если ваш запрос использует поиск по индексу, но индекс не содержит всех необходимых вам данных, то поиск по кластеризованному индексу будет использоваться для каждой записи, которую вы нашли в индексе. Допустим, у вас есть 10% таблицы, и вы получите 50 000 000 поиск по кластеризованному индексу, а это совсем не дешево. Это не стоит вам денег, но будет стоить вам производительности.
/ Хокан Винтер
Причины, по которым не следует что-либо удалять:
Причины, по которым вам следует что-то удалить:
Это всегда компромисс, но юридические последствия хранения слишком большого количества данных важны. В наши дни о конфиденциальности и безопасности часто забывают. Фактическая производительность базы данных может не потребовать удаления данных, если только наборы данных не огромны. Даже таблица с миллионами строк и десятками столбцов может не нуждаться в удалении, если вы правильно секционируете ее и убедитесь, что ваши запросы всегда используют правильные секции. Что касается постановления суда или запроса FOIA с просьбой предоставить сохраненные данные, что ж, только вы можете решить, что вы думаете об этом и что думают ваши клиенты. Одна из причин, по которой я ограничиваю использование Gmail, как раз по этой причине: мои данные хранятся в США (я нахожусь в Канаде), и американские агентства потенциально могут получить доступ даже к моей удаленной почте.
Также имейте в виду, что законы о конфиденциальности, безопасности и FOIA различаются от страны к стране; вам необходимо знать об этих законах в каждой стране, где вы работаете. Может быть, если все ваши серверы находятся в одной стране, что ограничивает действие иностранных законов, но, возможно, это не так. Проконсультируйтесь с юристом, если ваши данные конфиденциальны.
Вопрос, который вы действительно должны задать себе, заключается в следующем: являются ли затраты на хранение данных (повышенные затраты на хранение, ответственность за сохранение данных, которые могут быть удалены) дешевле, чем затраты на удаление данных (человеко-часы для написания запроса на удаление, ответственность за удаление данных, которые необходимо сохранить, и возможность простоя или снижения производительности из-за выполнения запроса на удаление)? Выбирайте то, что дешевле.
Один из случаев, когда я вижу автономное архивирование и / или удаление данных, - это когда вы запускаете запрос OLAP для обобщения данных и сохраняете их в сводной таблице.
Ежемесячная статистика сайта - отличный тому пример. После того, как вы сгенерировали количество просмотров страниц за июнь 2009 года, это никогда не изменится. И быстрее добавить все просмотры страниц из сводной таблицы, затем просканировать таблицу, содержащую онлайн-транзакции за текущий месяц, чем сканировать журналы за весь год и создать полностью онлайн-отчет. .
Если бы это был я, я бы обязательно скопировал онлайн-таблицу на «июнь 2009», запустил сводный запрос и сохранил данные в сводной таблице, а затем заархивировал скопированную онлайн-таблицу перед удалением всех записей из оригинальная он-лайн таблица. Но я тоже несколько параноик!
Как правило, везде, где более эффективно использовать OLAP для генерации сводки по статическим с этого момента данным, можно архивировать / удалять старые данные. В противном случае, нет, я использую систему отметки удаления, чтобы не нарушить целостность отношений с моими обычно обширными системами регистрации активности.