万智牌数据库设计

我想为我拥有的 MTG 卡创建一个数据库。设计会是什么样的？ 我想存储每张卡的以下信息：

1. Name of card.
2. Set the card belongs to.
3. Condition of card.
4. Price it sold for.
5. Price I bought it for.

以下是有关 MTG 卡的一些一般信息：

1. Every card has a name. 
2. Every card belongs to a set.
3. A card may have a foil version of itself. 
4. Card name, set it belongs to, and whether it's foil or not makes it unique. 
5. A card may be in multiple sets.
6. A set has multiple cards. 

噱头是，在我的收藏中，我可能有同一张卡的多张副本，但条件不同，或者购买价格或出售价格可能不同。

我还会收藏另一张已在 eBay 上出售的 mtg 卡。该系列将有价格/状况/日期/是否是“立即购买”或出价等。

我的想法是根据 eBay 收藏找出我应该以什么价格出售我的卡片。

这不是一个编程问题，而是一个建模问题。任何从事编程而不是建模的人都是编码员，而不是程序员。这仅比数据输入高出一步。建模是编程的一个基本方面，因为它直接涉及抽象，而抽象是计算机编程的真正天才。

规范化和数据库设计是人们更好地进行编程的一个很好的方法，因为规范化也是一个抽象过程。

抽象可以说是计算机编程中最困难的方面，特别是因为计算机编程要求一个人既要特别迂腐又要字面意思（以便正确地处理计算机的顽固和愚蠢）以及在一个计算机中处理和工作。非常高层次和抽象的空间。

例如，设计会议中的争论不是关于语言语法的。

所以，就是这样说的。我已经以较小的方式更新了架构来解决这些变化。

create table card (
    card_key numeric not null primary key,
    name varchar(256) not null,
    foil varchar(1) not null); -- "Y" if it's foil, "N" if it is not.

create table set (
    set_key numeric not null primary key,
    name varchar(256) not null);

create table cardset (
    card_key numeric not null references card(card_key),
    set_key numeric not null references set(set_key));

create table condition (
    condition_key numeric not null primary key,
    alias varchar(64),
    description varchar(256));

create table saletype (
    saletype_key numeric not null primary key,
    alias varchar(64),
    description varchar(256));

create table singlecard (
    singlecard_key numeric not null primary key,
    card_key numeric not null references card(card_key),
    condition_key numeric not  null references condition(condition_key),
    purchase_date date,
    purchase_price numeric,
    saletype_key numeric references saletype(saletype_key),
    sell_date date,
    sell_price numeric,
    notes varchar(4000));

更详细的解释。

牌桌是牌与实际牌的概念。您可以在手上没有任何实际牌的情况下拥有牌排。它对所有卡片共有的卡片的任何细节进行建模。显然，MTG 卡有很多细节（正如有人提到的彩色文本），但这些对于这种模型来说可能并不重要，因为这是为了收集和销售而跟踪实际卡。但是，如果需要添加任何其他属性（例如卡牌稀有度），“卡牌”表将是放置它们的地方。

集合表是用于集合的。我不知道什么是集合，只知道这里提出的内容（也偶尔提到一个系列，我不知道它们是否相关）。集合有一个名称，用于对卡片进行分组。所以，我们有一个“固定”表。

卡集表是多对多连接表。由于一个集合可以包含多张卡片，并且一张卡片可以属于多个集合，因此模型需要某种东西来表示这种关系。这是关系数据库中非常常见的模式，但对于新手来说也不是显而易见的。

有两个简单的查找表：条件表和销售类型表。此处这两个表是为了标准化目的，让用户标准化这两类数据的术语。他们每个人都有一个“别名”和一个“描述”。别名是简短的英文版本：“好”、“差”、“拍卖”、“立即购买”，而描述是较长的英文文本“差的卡片显示磨损、弯曲和摩擦痕迹”。显然，出于自己的目的而这样做的人可能不需要描述，但这是一种习惯。

最后，系统的核心是单卡表。单牌表代表您手上实际的牌。它模拟了使每张实际卡彼此不同的所有特征。单个卡牌不是集合的成员（至少从描述来看不是），而是一个更高级别的概念（例如它是如何发布的 - 所有“英雄：斧头挥舞者巴泰克”卡牌都是“黑暗”卡牌的一部分之谜”和“死亡小丑”集，或其他）。因此，单卡只需参考其父卡表即可，具有实际常用卡的特性。

这张卡包含对卡的状况的参考以及如何通过外键将其出售到相应的表。它还具有其他数据，例如必要的日期和价格。

根据给出的情况，这应该可以满足基本需求。

自己改造它将是一个很好的练习。从您最基本的需求以及您了解的最佳模型开始。然后将其与我在这里写的内容进行对比，然后使用这本书来尝试理解无论您的简单设计如何变成这个设计。

请注意，没有办法实际强制一张卡是任何集合的成员，或者一个集合具有任何卡。这将是一个应用程序逻辑问题。这是多对多连接表的问题之一。它可以对关系进行建模，但不能强制执行。