Какова наилучшая стратегия для получения больших наборов данных?

Question

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

Какая стратегия является оптимальной? Просто скопируйте старые данные в другую таблицу? Или «сверните его» через некоторую консолидацию самих данных (а затем сохраните их в другой таблице)? Или что-то еще?

Дополнительная информация: мы используем SQL Server 2005.

Answer 1

Мы используем оба метода на моей работе, но немного отличаемся, мы сохраняем все данные о продажах в основной таблице в течение 30 дней, а затем ночью (часть ночных заданий) продажи дней сворачиваются в сводки (n qty из x проданного сегодня продукта ect) в отдельной таблице для объяснения причин, а продажи за 30 дней архивируются в другую базу данных, затем один раз в год (мы ищем налоговые годы) запускается новая база данных архива. не совсем идеально, но ..

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

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

Answer 2

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

Answer 3

Если вы используете SQL Server 2005, это может быть хорошим кандидатом для использования partitioned tables.

Answer 4

@Jason - Я не вижу, как хранение данных в простых текстовых файлах позволит вам легко анализировать данные долгосрочного тренда.

@ Джейсон. Я полагаю, что моя точка зрения заключается в том, что если какой-либо специальный анализ (т. Е. Тренд) должен выполняться на данных деловыми людьми, то свертывание или архивирование данных в текстовые файлы действительно не решает какие-то проблемы. Конечно, писать код, чтобы потреблять текстовый файл, легко на многих языках, но эта проблема была решена. Кроме того, я бы сказал, что сегодняшние РСУБД чрезвычайно прочны при настройке и поддержании должным образом. Если бы они не были причиной, почему бы вы запустили бизнес поверх одного (не говоря уже о том, чтобы архивировать данные на него)? Я просто не вижу смысла архивирования в текстовом файле из-за утверждения о том, что долговечность текстовых файлов превосходит надежность баз данных.

Answer 5

В зависимости от ограничений, таких как бюджет и т. Д., Этот звук является идеальным кандидатом для приложения хранилища данных. Это обычно вводит новый сервер для использования в качестве хранилища данных. SQL Server 2005 поддерживает много этой деятельности из коробки, в дальнейшем вы можете использовать дополнительные службы SQL Server (например, службы Analysis Services, службы Reporting Services), чтобы обеспечить дополнительную ценность для ваших пользователей. (см. http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx)