如何为具有多种内容类型的类别设计数据库架构?

发布于 2024-10-20 08:37:28 字数 379 浏览 2 评论 0原文

示例:

4 个类别:
- 汽车
- 自行车
- 船
- 飞机

和几个带有内容文章的表格

(id、标题、正文)
照片画廊(id、照片文件名...)
video_galleres (id, video_title, video_url)

现在我很好奇如何设计数据库模式以将这些表中的内容划分为类别......

我想到了某事。像这样:

categories_content
- 类别_id
- 文章_id
- photo_gallery_id
- video_gallery_id

但对于 NULL 来说似乎浪费了很多空间......:/

Example:

4 categories:
- cars
- bikes
- boats
- planes

and several tables with content

articles (id, title, body)
photo_galleries (id, photo_filename...)
video_galleres (id, video_title, video_url)

and now i'm curious how to design database schema to divide content from those tables in to categories...

i thought about sth. like this:

categories_content
- category_id
- article_id
- photo_gallery_id
- video_gallery_id

but it seems like a lot waste of space for NULL's... :/

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

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

发布评论

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

评论(2

公布 2024-10-27 08:37:28

要考虑的另一种设计是为每种内容类型创建单独的关系表:

article_category   (article_id NOT NULL, category_id NOT NULL)
photo_g_category   (photo_g_id NOT NULL, category_id NOT NULL) 
video_g_category   (video_g_id NOT NULL, category_id NOT NULL)

此设计消除了设计中所需的存储 NULL 值的需要。所有这些列都将被定义为相应表的外键。

浪费空间对于您的设计来说并不是真正的问题。 (在大多数数据库引擎中,没有空间用于存储 NULL 值。)

设计的更大问题是确保至少填充一个内容 FK 列,并允许其他列为空。此外,如果您允许在一行上填充多个内容 FK 列,您的设计会使添加和删除关系的过程变得更加复杂。

您计划如何表示与类别相关的内容,例如 1 ?

文章:a、b、c
照片_g:p,q
video_g: v, w, x, y, z

1 a p v
1 b q w
1 c - x
1 - - y
1 - - z

或者

1 a - -
1 b - -
1 c - -
1 - p -
1 - q -
1 - - v
1 - - w
1 - - x
1 - - y
1 - - z

删除类别 1 和 photo_g p 之间的关系会有所不同,在一种情况下需要更新一行,另一种情况是删除一行(保留一行是没有意义的)其中未填充任何内容 FK 值)。

我建议使用三个单独的表来保存这些关系:

article_category:
a 1
b 1
c 1

photo_g_category:
p 1
q 1

video_g_category:
v 1
w 1
x 1
y 1
z 1

Another design to consider would be to create separate relationship tables for each content type:

article_category   (article_id NOT NULL, category_id NOT NULL)
photo_g_category   (photo_g_id NOT NULL, category_id NOT NULL) 
video_g_category   (video_g_id NOT NULL, category_id NOT NULL)

This design eliminates the need to store NULL values, as would be required in your design. All of these columns would be defined as foreign keys to the appropriate tables.

Wasted space is not really an issue with your design. (In most database engines, no space is used to store a NULL value.)

The bigger issue with your design is making sure that at least one of the content FK columns is populated, and allowing the others to be null. Also, your design makes the process of adding and removing relationships more complicated, if you allow more than one content FK column to be populated on a row.

How would you plan represent content related to category, e.g. 1 ?

article: a, b, c
photo_g: p, q
video_g: v, w, x, y, z

1 a p v
1 b q w
1 c - x
1 - - y
1 - - z

OR

1 a - -
1 b - -
1 c - -
1 - p -
1 - q -
1 - - v
1 - - w
1 - - x
1 - - y
1 - - z

The removal a relationship between category 1 and photo_g p would be different, in one case requiring an update to a row, the other, deleting a row (there's no point in keeping a row where none of the content FK values is populated).

I suggest three separate tables to hold these relationships:

article_category:
a 1
b 1
c 1

photo_g_category:
p 1
q 1

video_g_category:
v 1
w 1
x 1
y 1
z 1
情魔剑神 2024-10-27 08:37:28

您可以有一个关系表,例如:

category_id、type_of_item、item_id

其中 type_of_item 是文章、照片、视频等,item_id 是类别中项目的 ID。

You could have a table for the relationship like:

category_id, type_of_item, item_id

where type_of_item would be article, photo, video etc. and item_id is the id of the item which is in the cateogry.

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