数组还是数据库表？
我真的可以使用一些关于最佳实践的良好反馈/关于将内容放入数据库或构建数组是否更好的见解。举个例子，你有纸牌的花色：
$suits = array('clubs', 'spades', 'hearts', 'diamonds');
数组将来可能会改变，但如果有的话，也不会很频繁。现在这些花色被应用到一副牌中的牌上。因此，如果我构建一个表，架构将类似于：
create table cards {
id INT(11)
card_value char(2),
suit varchar(8)
}
或者构建一个 suits 表并引用 cards 中的 ID 更好> 表：
create table suits {
id INT(11),
name varchar(8)
}
create table cards {
id INT(11),
suit_id int(11),
card_value char(2)
}
哪一个是更好的方法，为什么？
I could really use some good feedback on best practices / insight on whether it is better to put things in the database, or build an array. Take for example you have the suits of cards:
$suits = array('clubs', 'spades', 'hearts', 'diamonds');
The array could change in the future, but not very frequently if at all. Now these suits are applied to the cards in a deck. So if I build a table, the schema would look something like:
create table cards {
id INT(11)
card_value char(2),
suit varchar(8)
}
Or is it better to build a suits table and reference the ID in the cards table like:
create table suits {
id INT(11),
name varchar(8)
}
create table cards {
id INT(11),
suit_id int(11),
card_value char(2)
}
Which is the better way to go and why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常，我会说你最好将信息存储在数据库中，尽管在卡片示例中，我很想将信息存储在代码中并存储根据 (suit_idx * 13 + card_value) 计算得出的“卡号” ，或者使用您在第二个代码片段中提供的卡片表 - 因为卡片极不可能更改（特别是一旦您开始在代码中使用它们之后）。
归根结底，如果您要对数据库中的“手牌”或一副牌执行查询，那么您将需要使用任一 SQL 表示形式 - 以及前者只是更容易查询一点（尽管有一个连接卡以适应的视图，这两个选项都很容易查询 - 尽管我仍然想坚持使用第一个 SQL 版本）。
Typically I'd say you're best off storing the information in the database, although in the cards example I'd be tempted to either have the information in code and store a 'card number' calculated from (suit_idx * 13 + card_value), or use the cards table you gave in your second code fragment - as cards are highly unlikely to change (especially once you've started using them in code).
At the end of the day - if you're going to be performing queries against e.g. 'hands' of cards, or against a deck of cards in the database then you're going to want to use either of your SQL representations - with the former being just that little bit easier to query (although with a view that joins card to suit, either option is easy to query - although I'd still be tempted to stick with the first SQL version).
阅读了您对威尔的回复的评论后，我知道西装和纸牌不是您的首选示例，但无论如何我都会继续使用这个示例:)
我同意西装的价值不太可能改变，除非您想要一个系统足够灵活，可以处理塔罗牌（剑、法杖、圣杯和硬币）。尽管如此，将数据保存在表中还是有好处的。
首先是该套装在多个地方使用。像桥牌和惠斯特这样的纸牌游戏需要知道哪种花色是王牌。红心大战（Black Maria、Chase the Lady）是一款需要能够区分某些带有惩罚的花色的牌的游戏。因此，有几个地方引用 SUITS.ID 会很有用。
第二个好处是套装有更多属性而不仅仅是名称。有些游戏对花色进行排名，例如在桥牌中，三黑桃的出价胜过三红心的出价。如果我们正在构建纸牌游戏应用程序，我们可能会关联图像文件或翅膀角色来表示纸牌符号。
这两个考虑因素都指向你的第二个设计。它是唯一可以避免重复并允许我们强制执行完整性约束的方法。
Having read your comments to Will's response I know Suits and Cards wasn't your first choice of example, but I am going to pursue the example anyway :)
I agree it is unlikely the values of suits are going to change, unless you want a system that is flexible enough to handle Tarot cards (Swords, Staves, Cups and Coins). Nevertheless there are benefits to holding the data in a table.
The first is that the Suit is used in several places. Card games like Bridge and Whist need to know which Suit is trumps. Hearts (Black Maria, Chase the Lady) is a game which needs to be able to distinguish the cards of certain suits which carry penalties. So, there are several places where referencing SUITS.ID would be useful.
The second benefit is that Suits have more attributes than just name. Some games rank suits, for instance in Bridge a bid of Three Spades wins over a bid of Three Hearts. If we're building a card game application we might what to associate an image file or wingding character to represent the card symbol.
Both these considerations point towards your second design. It is the only one which avoids duplication and allows us to enforce integrity constraints.