这种数据库设计可以接受吗，或者有更好的方法吗？

发布于 2024-12-13 22:41:54 字数 501 浏览 0 评论 0原文

这正常化了吗？有没有更有效的方法来设计这个数据库？

个人资料可以有无限的相册，任何用户都可以从任何人的视频创建相册。一个相册可以包含多个视频，一个视频可以属于多个相册。我就是这样做的。。。

[Table] Profile
   [pk] Id
        (first, Last, Email. . . ect)

[Table] Album
   [pk] Id
        Title
   [fk] Owner (Profile.Id)
        Created


[Table] AlbumContent
   [pk] Id
   [fk] Album (Album.Id)
   [fk] Video (Video.Id)

[Table] Video
   [pk] Id
   [fk] Owner (Profile.Id)

有没有更好/更有效的方法。。。（我应该将Album 和AlbumContent '合并' 到一个表中...还是这是一个禁忌？？）

原文

Is this normalized properly ?? is there a more efficient way to design this DB ?

A Profile can have unlimited albums, any user can create an album from anyone's videos.
An album may contain many videos, and a video can belong to multiple albums.
This is the way I've done it. . .

[Table] Profile
   [pk] Id
        (first, Last, Email. . . ect)

[Table] Album
   [pk] Id
        Title
   [fk] Owner (Profile.Id)
        Created


[Table] AlbumContent
   [pk] Id
   [fk] Album (Album.Id)
   [fk] Video (Video.Id)

[Table] Video
   [pk] Id
   [fk] Owner (Profile.Id)

Is there a better / more efficient way. . . (should I 'merge' Album and AlbumContent into one table... or is that a no-no ?? )

分享到QQ

分享到微博

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

发布评论

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

挽清梦 2024-12-20 22:41:54

[Table] Album
   [pk] Id
        Title
   [fk] Owner (Profile.Id)
        Created


[Table] AlbumContent
   [fk][pk] Album (Album.Id)
   [fk][pk] Video (Video.Id)

我会在相册内容上使用复合主键
专辑内容其实并不需要代言PK
除非您想在相册中多次播放同一个视频

[Table] Album
   [pk] Id
        Title
   [fk] Owner (Profile.Id)
        Created


[Table] AlbumContent
   [fk][pk] Album (Album.Id)
   [fk][pk] Video (Video.Id)

i would use composite primary key on Album content
Album content doesnt realy need surrogate pk
unless youe want one video multiple times in your album

回复收藏 0 原文