体育馆藏数据库

Question

我正在创建一个不同体育项目的体育收藏数据库，我对使用以下要求的表和主键/外键组合感到困惑：

应该是第三种正常状态，或者至少在3NF中。

以下是我想要做的事情的全部描述：

1. 为运动卡片集合设计一个数据库。
2. 您只购买至少100.00美元的当前市场价值(在购买时)的卡。你收集的大约1000张卡片
3. 你收集各种运动卡，从足球，篮球，曲棍球等等。
4. 这些卡您收集是由不同的供应商，如?Topps，上甲板，叶子和帕尼尼。
5. 这个收藏跨越了许多年的收藏，有些甚至可以追溯到20世纪初，但是在此之前就已经有卡片了。
6. 您的卡的情况也不同，并按照10点PSA分级标准进行分级.(分级表)
7. 每次你购买一张卡，你必须知道购买日期，购买成本，市场价值，你从谁购买它，体育，个人卡，卡号码等。
8. 购买完毕后，约一星期后，你就会把卡寄出去进行评分，你希望能够跟踪何时寄出卡片进行评分、评分的状况、给卡片的评分、评级公司何时退货和收到退货卡。就税务而言，你亦想知道所缴付的评级服务费用(薪级表)。
9. 你确实买卖卡片，所以你也想知道你卖了多少卡，卖给了谁，运费(如果适用的话)，以及任何与销售交易相关的数据。您可以自由地包含您认为对表很重要的任何其他数据。

这是我目前的数据库..。我觉得我错过了一些东西，我没有按照要求做好。

​

​

Answer 1

看上去是个很好的开始。我对你们的表格/结构有以下看法：

CardSellers：应该只存储关于CardSeller的信息；它应该拥有的唯一值是SellerID和SellerName。

供应商：不应该有CardId

等级：SellerID不属于这里

卡：好看

CardBuyers不应该收取DateOfPurchase、CostOfCard或船运费；这三个成员属于CardTransaction。事实上，"DateOfPurchase“应该是"DateOfTransaction”

另外，由于Vendor表应该只存储供应商数据，而card表应该只存储卡片数据，您还需要一个M2M (多到多)表来连接这两个表；这个表应该有三个成员: ID (PK)、CardId (FK)和VendorId (FK)。

更新

记住关于表设计的两件事：

(0) A table should only contain data about the object its named for and only references to other tables (via a FK - see below)
(1) DRY (Don't Repeat Yourself - IOW, don't store the same data in multiple places; instead, store a link to it, where needed, via FK (Foreign Key) fields referencing PK (Primary Key) fields).

就这些桌子的实际设计而言，这对我来说是有意义的：

CARDS
-----
CardId (PK)
VendorId (FK)
CardFirstName
CardLastName
CardType
CardYear
MarketValue
Rarity
CollectionNumber    

COLLECTORS (Buyers and/or Sellers; no need to have separate tables for them)
---------
CollectorId (PK)
CollectorName
CollectorAddress    

TRANSACTIONS
------------
TransId (PK)
CardId (FK)
BuyerId (FK) <= CollectorId in the Collectors table
SellerId (FK) <= CollectorId in the Collectors table
TransactionDate
Price (if it may differ from CARDS.MarketValue)

GRADE
-----
GradeId (PK)
CardId (FK)
Points
AssignedGrade
Qualifiers
Status
CardFee
GradedDate
ReturnedDate

VENDORSLU ("LU" stands for "Lookup")
---------
VendorId (PK)
VendorName
CARDTYPESLU
-----------
CardTypeID (PK)
CardTypeDescription

RARITYLU
-----------
RarityID (PK)
RarityDescription

您可能会发现，您也需要添加其他字段，但应该是接近的。您甚至可能需要额外的查找表，例如GradeTable中的“限定符”和“状态”。

您还可能需要一个SPORTSLU表，然后向CARDS表中添加一个SportId FK (其中，如果SportId == 1，它是足球卡，如果是2，它是篮球卡，&c)。

不过，请注意，与关系数据库一样普遍和具有历史意义的是，还有另一种名为“非SQL”数据库(如MongoDB)的动物，它们更自由形式/松散-goosey/I‘s好--你是好的/无政府主义者，它允许你拥有记录，或者“文档”，它们可以忽略或添加它想要的任何成员。关系数据库可以与古典音乐(巴赫、莫扎特和c)相比较，而非SQL则更像Jazz (自由流动、即兴创作)。

为什么不提Tiddlywinks呢？足球、棒球等都很好，但是没有？？