Magic:The Gathering数据库设计

前端之家收集整理的这篇文章主要介绍了Magic:The Gathering数据库设计前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我想为我拥有的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,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卡有很多细节(有人提到的彩色文字),但这些对这种模型来说可能并不重要,因为这是为了收集和销售而追踪实际卡片.但如果有任何其他属性的需求,比如卡稀有,那么“卡片”表就是放置它们的地方.

设置表用于集合.我不知道一个集合是什么,只有这里假设的东西(还有一个系列的偶然参考,我不知道它们是否相关).集具有名称,用于分组卡.所以,我们有一个’set’表.

卡组表是多对多连接表.由于一个集合可以有多张卡片,并且一张卡片可以属于多个集合,因此该模型需要一些东西来表示这种关系.这是关系数据库中非常常见的模式,但对初学者来说也是不明显的.

有两个简单的查找表,条件和saletype表.这两个表用于标准化目的,让用户标准化这两类数据的术语.它们每个都有一个’别名’和’描述’.别名是简短的英文版本:’好’,’差’,’拍卖’,’现在购买’,而描述是较长的英文文本’差卡显示磨损,弯曲和擦痕的迹象’.显然,为了自己的目的而这样做的人可能不需要描述,但这是一种习惯.

最后,系统的肉是单一的表.单张表代表一张实际的,在您的手牌中.它模拟了使每张实际卡彼此不同的所有特征.个人卡不是一个集合的成员(至少不是来自描述),而是一个更高级别的概念(例如它是如何发布的 – 所有“Hero:Bartek the Axe Wielder”卡片是“黑暗”的一部分神秘“和”死亡小丑“集,或其他什么).因此,单卡只需要参考其父卡表,具有实际的通用卡特征.

这张单卡可以参考卡的状况以及如何通过外键将其销售到相应的表格中.它还有其他数据,例如必要的日期和价格.

根据所给出的,这应该满足基本需求.

自己重塑这个是一个很好的练习.从您最基本的需求开始,以及您理解的最佳模型.然后将它与我在这里所写的内容进行对比,然后使用该书或许试着理解你的简单设计如何成为这个设计.

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

原文链接:https://www.f2er.com/mssql/76325.html

猜你在找的MsSQL相关文章