使用 phpmyAdmin 的数据库关系(复合键)

发布于 2024-08-27 10:40:57 字数 381 浏览 3 评论 0原文

我对制作一个好的关系数据库有点困惑。我正在使用 phpmyAdmin 创建数据库。我有以下四张表。不用担心,事实上地点和价格是可选的,它们就是这样。

  1. 人员(必填)
  2. 项目(必填)
  3. 地点(可选)
  4. 价格(可选)

项目是主表。它总是与人联系在一起。 * 我知道你确实在 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.

  1. Person (Mandatory)
  2. Item (Mandatory)
  3. Place (Optional)
  4. 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

心欲静而疯不止 2024-09-03 10:40:57

NULL 值

这也意味着项目将有 5 个 ID,包括它自己的 ID。这一切都会导致空值(显然是一个很大的不,我可以理解),因为如果地点和价格是可选的并且没有在项目表的一个条目上使用,我将在那里有一个空值

我个人认为这是一种情况NULL 值是完美的,我当然不会怀疑将其放入我的数据库设计中。

我看到其他人在没有 NULL 值的情况下实现相同目标的一种方法是在可选表(示例中的地点和价格)中创建一条 ID 为 0 的记录,表示没有相关记录 -但这只会使应用程序开发人员过滤这些记录的工作量增加 10 倍 - 进行联接要容易得多,如果没有返回任何记录,则可选表中没有相关记录。

如果您想返回 Item,无论它们是否有 PlaceLEFTRIGHT OUTER 连接code> 或 Price 关联(对于没有关联记录的 Item,您将在可选表列中获得 NULL 值)以及如果您想要确实有关联可选记录的Item,则使用INNER连接。

复合键

复合键是表中由多个列组成的键。如果您的每个 PersonItemPlacePrice 都有一个 ID(即使它只是一个自动-递增数字)您不需要复合键 - 只需每个表中的主键列,以及每个相关表的 Item 表中的外键列 - 例如 item_id、<代码>person_idplace_idprice_id。您声明 Item 有自己的 ID,因此您不需要复合键 - 只需要 item_id 列上的主键即可。

NULL values

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

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 or RIGHT OUTER join if you want to return Items regardless of whether they have a Place or Price associated (you'll get NULL values in the optional table columns for Items that don't have associated records) and an INNER join if you only want the Items 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 and Price 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 the Item table for each related table - e.g. item_id, person_id, place_id, price_id. You state that Item has its own ID, so you shouldn't need a composite key - just a primary key on the item_id column.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文