我正在寻找管理日志文件的大型数据集。我想保留每月平均150万个新事件。我过去曾使用过访问权限，虽然它显然不适用于此，管理数据集是一场噩梦，因为我不得不将数据集分成几个月。
在大多数情况下，我只需要过滤事件类型并计算数字。但在我对数据导入方面做了大量工作之前，我想看看是否有人可以验证这个SQL Server是一个不错的选择。我应该避免和存档条目的入口限制吗？有没有归档条目的方法？
另一部分是我从多个来源输入日志，有了这么多的条目，将它们全部放在同一个表中是明智的，还是每个来源都有自己的表，以便更快地进行查询？ / p>
...编辑
没有连接，大约10列。数据将通过视图进行过滤，我很想知道基于一列或多列过滤的select查询的结果是否会有合理的响应时间？创建一组视图是否可以加快频繁查询的速度？
答案 0 :(得分：5)
根据我的经验，SQL Server是一个很好的选择，你可以期待SQL Server比MS-Access更好的性能，通常有更多的优化方法供您使用。
我可能会继续把这些东西放到SQL Server Express中，如你所说，希望安装在你可以使用的最好的机器上（虽然你确实只提到了2GB的RAM）。使用一个表只要它只代表一件事（我认为飞行员的飞行日志和软件错误日志不会在同一个“日志”表中，作为一个荒谬的人为例子）。检查你的表现。如果这是一个问题，请继续使用您的SQL Server版本提供的任意数量的优化技术。
以下是我最初可能会这样做的事情：
如果您在日志表上使用PK，则使用非群集主键创建表 - 我通常使用identity column为我提供有保证的事件顺序（与重复日期时间不同）并显示日志插入失败（缺少身份）。在主日期时间列上设置clustered index（您提到您已按月拆分为单独的表，因此我假设您也会以这种方式查询）。如果你经常在这个表上运行一些查询，那么一定要查看它们，但不要指望通过这样做来加速。您很可能希望根据这些查询中的where子句查看indexing your table。在这里，您将为SQL Server提供有效运行这些查询所需的信息。
如果您无法通过优化查询，索引，使用尽可能小的数据类型（特别是在索引列上）并在合适的硬件上运行来获得所需的性能，那么可能需要尝试partitioned views（这需要某种形式的持续维护）或partitioning your table。不幸的是，SQL Server Express may limit you关于你可以用分区做什么，你必须决定是否需要转移到more feature-filled edition的SQL Server。您始终可以使用Enterprise评估或开发人员版本测试分区。
<强>更新
在大多数情况下，我只需要过滤事件类型并计算数字。
由于过去的日志没有变化（有点像过去的销售数据），因此在这种情况下，存储过去的总数是一种常用的策略。您可以创建一个表格，该表格只存储每个月的计数，并且每月（或一周，一天等）使用某种计划的作业插入一次新计数。使用日期时间列上的聚簇索引，SQL Server可以更轻松地从实时表中聚合当前月份的数字，并将它们添加到存储的聚合中，以显示总计数的当前值等。
答案 1 :(得分：1)
对我来说听起来像一张桌子，需要在你要过滤的列集上完成索引。限制通过视图访问通常是一个好主意，并确保您的索引实际上得到使用。
将每个源放入自己的表中将在以后的查询中使用UNION，并且SQL-Server不是很好地优化UNION查询。
“存档”条目当然可以手动完成，方法是将日期范围内的条目移动到另一个表（可以存在于另一个磁盘或数据库中），或者使用“分区”，这意味着您可以放置部分不同磁盘上的表（例如，由日期范围定义）。在规划SQL-Server安装时，必须规划分区。
请注意，Express版本限制为4GB，因此每月150万行可能会出现问题。
如果使用索引，我有一个像你这样的表，有20M行，查询甚至加入的问题都很少。