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

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

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

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

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

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

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

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

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