【发布时间】：2017-06-27 18:02:50
【问题描述】：
我在 stackoverflow 中阅读了一些答案。但仍有疑问。 我想写一些类似彩票游戏的东西。
在设计中 - 用户可以选择游戏。并买票。 现在用户可以购买很多门票。假设用户可以购买 1000-2000 张门票。 （例如 50 场比赛 * 40 票） 不，我只是考虑当我有 100 万用户并且每个用户购买 2K 票的情况 （我知道这听起来像是不可能的情况，但想在投入生产之前检查每一个想法）
1M 用户 * 每个用户 2K 票 = 2B 票。
现在我有这样的表：
Id | UserId | GameId | TicketId | IsActive | TimeInsert
UserId 和 Gameid - 是索引
今天我为每张票做排。它的平均值在 2B ticekts 的情况下 - 我将有 2B 行。
在我的设计中，票证具有唯一编号——用户可以取消/删除 1 张特定票证。
问题： 我知道数据库中有 2B 行 - 不好。 （非常糟糕））））
问题 - 像这样存储数据的最佳做法是什么。
我看到它要存储的选项之一 它在 BLOB 中的商店门票。 例如 50 场比赛 * 40 张门票 ===> 50 行。并且在 BLOB 商店有 40 张门票。
P.S 对不起我的英语语法。
【问题讨论】：
-
通常情况下，彩票发行固定数量的彩票。实际发出的票需要单独跟踪。我所知道的彩票实际上不会每场发行 20 亿张彩票，所以这不是问题。票的总数，而不是用户购买的票数，是重要的因素。同时进行 50 种不同的游戏似乎也不大可能。即使如果您必须存储 20 亿行，但 -- 那又如何？我维护了一个包含超过 60 亿行的表的数据库。
-
谢谢。我在 C# 上编写代码。所以最好的方法是编写 SQL 查询（ADO .NET）而不使用任何 ORM，对吧？
-
采用简单的解决方案，每行一张票。这就是数据库的构建目的，并为此进行了优化。通过将数据捆绑到 blob 中，您的生活将变得糟糕透顶。想象一下您将如何从这些数据中进行选择。没有索引可以帮助您。如果你真的会碰壁，那么 SQL Server 中还有partitioning。所以我不会担心这个。正如文档所说，行的限制是可用存储。
-
@MaxA：这与您的问题完全不同，是一个完全独立的问题。 “最佳”本身就是一个无用的术语。在什么方面最好？发展速度？原始性能？可维护性？在性能方面，没有什么能比使用
SqlCommand和SqlDataReader的手写代码更好，但 ORM 的存在是有原因的。 -
使用直接 SQL，您可以更好地控制您正在做什么，尤其是当您使用其他人创建的数据库但必须小心 SQL 注入和其他问题时。使用 ORM，我有时会看到一些疯狂的事情，比如三次读取相同的数据，有时很难说服它做你想做的事。 ORM 试图让你的生活更轻松，而且大多数时候它们都这样做了。但我们在这里有点跑题了。
标签： sql-server database database-design