运动系列数据库

Question

我正在创建一个不同体育项目的体育馆藏数据库，我对某些表和主键/外键组合使用要求的情况有所困惑如下：

应为第3范式或至少3NF。

以下是我想要做的完整描述：

1. 为体育卡片系列设计数据库。

2. 您只购买当前市场价值（购买时）至少100.00美元的卡片。您的收藏大约有1000张卡

3. 你收集各种运动牌，包括足球，篮球，曲棍球等。

4. 您收集的这些卡片是由不同的供应商生产的，例如Topps，Upper Deck，Leaf和Panini。

5. 该系列涵盖了多年的收藏，有些卡甚至可以追溯到20世纪初，但是在此之前还有卡片

6. 您的卡的状况也有所不同，并根据10分PSA评分标准评分。 （评分表）

7. 每次购买卡时，您都必须知道购买日期，购买成本，购买的市场价值，购买者，运动，卡片上的个人，卡号等。

8. 购买完成后，您会在一周后发送卡片进行评分，您希望能够跟踪卡片发送时的评分，评分状态，评分分配给卡，当它由评级公司返回并收到退回的卡。出于税收目的，您还想知道为评级服务支付的费用（成绩表）

9. 您确实买卖卡片，因此您也想知道您出售卡的数量，售出时间，销售对象，运费（如果适用）以及与销售相关的任何相关数据交易。您可以随意添加您认为对表格很重要的任何其他数据。

到目前为止，这是我当前的数据库...我觉得我错过了一些东西而且我没有正确地遵循这些要求

Answer 1

这看起来是个不错的开始。关于你的表格/结构，我有以下观察：

CardSellers ：只应存储有关CardSeller的信息;它应该具有的唯一值是SellerID和SellerName

供应商：不应该有CardId

成绩：卖家ID不属于此

卡：看起来不错

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表，然后将一个SportId FK添加到CARDS表（如果SportId == 1，那么它是一张足球卡，如果它是2，它是一张篮球卡，＆amp; c）。

但请注意，与关系数据库一样普遍且具有历史意义的是，还有另一种称为“非SQL”数据库的动物（如MongoDB）更自由形式/松散 - 鹅/我没关系 - 你是好的/无政府主义的，它允许你有记录，或“文件”可以省略或添加它想要的任何成员。关系数据库可以与古典音乐（Bach，Mozart，＆amp; c）进行比较，而非SQL更像是爵士乐（自由流动，即兴）。

顺便说一下，为什么不提及 Tiddlywinks ？足球，棒球等都很好，但没有Tiddlywinks（或Bocci Ball，就此而言）？！