C # Large Data стратегия резервного копирования для освобождения базы данных

Question

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

Несколько баллов:

• Я бы оставил базу данных в покое, так как она могла или не могла иметь dba, и было бы много решений с задействованной базой данных. Когда мы развернем приложение у клиента, я бы меньше всего хотел поговорить с dba и принять участие в неприятных вещах ... Так что я мог бы просто сказать им через год, что "эй, размер БД слишком большой", так что теперь просто сделайте дамп в текстовый или XML-файл и очистите таблицу, как только решение. Отчеты убегают другая главная таблица .. Я думаю, что в долгосрочной перспективе, как через 4 года, у меня может быть огромная база данных с таблицей, в которой количество дерьмовых транзакций возрастает, так как сотрудники увеличивают X за смену X за такт в блоахах ... так что, если они смогут следить за дампом в текстовый файл в месяц или за что-либо .... то есть.

Answer 1

Я думаю, это зависит от того, как вам нужен доступ к старым данным.

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

Answer 2

Многие базы данных могут выполнять эту работу.Я могу упомянуть Firebird SQL , у которого есть хороший поставщик C #

Answer 3

Я постараюсь разбить свой ответ на два варианта в зависимости от особенностей вашей среды.

1. Встроенная база данных в вашем приложении без БД - MS Access, Berkely DB и т. Д.
2. Сетевые СУБД (с БД или без) - SQL Server, Oracle, MySQL и т. Д.

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

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

Во втором случае (сетевая СУБД) вам следует обратиться к администратору базы данных за сохранением данных. У администратора базы данных должен быть план для этого. Если у вас нет администратора базы данных, у вас есть несколько вариантов.

Вы могли бы пойти с вашей идеей экспорта текстовых файлов. Вы можете разделить таблицу и развернуть сегменты сегментов (это зависит от того, как вы это делаете в СУБД - Oracle будет табличным пространством, SQL Server будет файловой группой, я не имею представления о MySQL). Вы можете иметь вторую базу данных либо в качестве архивной базы данных, либо в качестве фактического хранилища данных.

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

Answer 4

SQL Server 2008 поддерживает разбиение таблиц.

http://msdn.microsoft.com/en-us/library/dd578580.aspx

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