使用 phpmyAdmin 的数据库关系(复合键)
我对制作一个好的关系数据库有点困惑。我正在使用 phpmyAdmin 创建数据库。我有以下四张表。不用担心,事实上地点和价格是可选的,它们就是这样。
- 人员(必填)
- 项目(必填)
- 地点(可选)
- 价格(可选)
项目是主表。它总是与人联系在一起。 * 我知道你确实在 mysql 中连接了表。 如果我想将表链接在一起,我可以使用复合键(使用每个表中的 id),但是这是链接表的最正确方法吗?这也意味着项目将有 5 个 id,包括它自己的 id。这一切都会导致空值(显然是一个很大的不,我可以理解),因为如果地点和价格是可选的并且没有在项目表的一个条目上使用,那么我在那里将有一个空值。请帮忙!
提前致谢。我希望这是有道理的。
I am bit confused on making a good relational database. I am using phpmyAdmin to create a database. I have the following four tables. Don't worry about that fact place and price are optional they just are.
- Person (Mandatory)
- Item (Mandatory)
- Place (Optional)
- Price (Optional)
Item is the main table. It will always have person linked.
* I know you do joins in mysql for the tables.
If I want to link the tables together I could use composite keys (using the ids from each table), however is this the most correct way to link the tables? It also means item will have 5 ids including its own. This all cause null values (apparently a big no no, which I can understand) because if place and price are optional and are not used on one entry to the items table I will have a null value there. Please help!
Thanks in advance. I hope this makes sense.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
NULL 值
我个人认为这是一种情况
NULL
值是完美的,我当然不会怀疑将其放入我的数据库设计中。我看到其他人在没有
NULL
值的情况下实现相同目标的一种方法是在可选表(示例中的地点和价格)中创建一条 ID 为 0 的记录,表示没有相关记录 -但这只会使应用程序开发人员过滤这些记录的工作量增加 10 倍 - 进行联接要容易得多,如果没有返回任何记录,则可选表中没有相关记录。如果您想返回
Item
,无论它们是否有PlaceLEFT
或RIGHT OUTER
连接code> 或Price
关联(对于没有关联记录的Item
,您将在可选表列中获得NULL
值)以及如果您仅想要确实有关联可选记录的Item
,则使用INNER
连接。复合键
复合键是表中由多个列组成的键。如果您的每个
Person
、Item
、Place
和Price
都有一个 ID(即使它只是一个自动-递增数字)您不需要复合键 - 只需每个表中的主键列,以及每个相关表的Item
表中的外键列 - 例如item_id、<代码>person_id
、place_id
、price_id
。您声明Item
有自己的 ID,因此您不需要复合键 - 只需要item_id
列上的主键即可。NULL values
Personally I think this is one situation where
NULL
values are perfect, and I certainly wouldn't have any doubts about putting this into my database design.One way I've seen others achieve the same thing without
NULL
values is to create a record in the optional tables (place and price in your example) with an ID of 0 that signifies there's no related record - but this just makes 10 times more work for the developer of the application to filter these records out - it's FAR easier to do a join and if you don't get any records back, there are no related records in the optional table.Just remember to do a
LEFT
orRIGHT OUTER
join if you want to returnItem
s regardless of whether they have aPlace
orPrice
associated (you'll getNULL
values in the optional table columns forItem
s that don't have associated records) and anINNER
join if you only want theItem
s that do have an associated optional record.Composite Keys
A composite key is a key in a table that's made up of more than one column. If each of your
Person
,Item
,Place
andPrice
all have an ID (even if it's just an auto-incrementing number) you won't need a composite key - just a primary key column in each table, and a foreign key column in theItem
table for each related table - e.g.item_id
,person_id
,place_id
,price_id
. You state thatItem
has its own ID, so you shouldn't need a composite key - just a primary key on theitem_id
column.