Mysql - 一个简单的数据库设计问题

发布于 2024-09-25 23:45:49 字数 1410 浏览 2 评论 0原文

假设我有导师,他们学习在线网络课程并创建学习包在线网络课程学习包都可以由学生进行评分,最后导师的评分是所有评分的简单平均值他的课程的评级。

这是我们当前 Ratings 表的表架构 -

CREATE TABLE IF NOT EXISTS `Ratings` (
  `id_rating` int(10) unsigned NOT NULL auto_increment,
  `id_teacher` int(10) unsigned default NULL COMMENT 'the teacher who created the class/pack',
  `id_lp` int(10) unsigned default NULL  COMMENT 'the id of the learning pack',
  `id_wc` int(10) NOT NULL default '0' COMMENT 'the id of the webclass',
  `id_user` int(10) unsigned NOT NULL default '0' COMMENT 'the user who has rated',
  `rate` int(10) unsigned NOT NULL default '0',
  `cdate` timestamp NOT NULL default CURRENT_TIMESTAMP,
  `udate` timestamp NULL default NULL,
  PRIMARY KEY  (`id_rating`),
  KEY `Ratings_FKIndex1` (`id_user`),
  KEY `id_lp` (`id_lp`),
  KEY `id_wc` (`id_wc`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

目前,等级和包等级都输入到同一个表中(id_wcid_lp 分别是相应地输入 - 对于每个评级记录,输入一个,另一个为 NULL)。

所以,我的问题是 -
这种架构是否正确,或者将 classpack 评级分开更好?为什么或为什么不呢?对于 classpack 评级,我需要完全相同数量的 Rating 表字段。

我想,如果要单独查找类别和包评级,那么单独的表将减少要查找的记录数量。但是,由于在我们的例子中只需要导师评级(涉及班级和包),这就是为什么所有评级都放在一起的原因。

Suppose I have Tutors who take online webclasses and create learning packs. Both online webclasses and learning packscan be rated by students and finally a tutor's rating is the simple average of all the ratings on his classes and packs.

This is the table architecture of our current Ratings table -

CREATE TABLE IF NOT EXISTS `Ratings` (
  `id_rating` int(10) unsigned NOT NULL auto_increment,
  `id_teacher` int(10) unsigned default NULL COMMENT 'the teacher who created the class/pack',
  `id_lp` int(10) unsigned default NULL  COMMENT 'the id of the learning pack',
  `id_wc` int(10) NOT NULL default '0' COMMENT 'the id of the webclass',
  `id_user` int(10) unsigned NOT NULL default '0' COMMENT 'the user who has rated',
  `rate` int(10) unsigned NOT NULL default '0',
  `cdate` timestamp NOT NULL default CURRENT_TIMESTAMP,
  `udate` timestamp NULL default NULL,
  PRIMARY KEY  (`id_rating`),
  KEY `Ratings_FKIndex1` (`id_user`),
  KEY `id_lp` (`id_lp`),
  KEY `id_wc` (`id_wc`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

Currently, both class and pack ratings are entered into the same table (id_wc and id_lp are entered accordingly - one is entered and the other is NULL for every rating record).

So, my question is -
Is this architecture correct or is it better to keep class and pack ratings separate? Why or why not? I need exactly the same number of Rating table fields for both class and pack rating.

I guess, If class and pack ratings were to be separately found, then separate tables would reduce the number of records to be looked up. But, since in our case only tutor ratings are needed (involves both class and packs), that's why all the ratings are put together.

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

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

发布评论

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

评论(3

德意的啸 2024-10-02 23:45:49

更详细的模型。

  • 大学的老师也可以上课。
  • 一个班级可能有不止一位老师。
  • 同一主题可能有多个课程,由不同的老师教授。
  • 只有参加课程的学生才能对课程进行投票(评分)。
  • 学习包针对一个主题(数学、生物)。
  • 一个学习包可以有多个作者。
  • 从技术上讲,学生也可以编写学习包。
  • 只有使用学习包的会员才能对学习包进行评分。
  • 尽管作者可以为包投票,教师也可以为他们的班级投票,但这些投票会被忽略。

alt text

如果只对评级表感兴趣,您可以使用:

alt text

或者,将两个模型组合成如下形式:

替代文本

A bit more detailed model.

  • A teacher at a university can take classes too.
  • One class may have more than one teacher.
  • There may be several classes on the same subject, taught by different teachers.
  • Only students who participate in classes get to vote (rate) the class.
  • Learning packs are on a subject (math, biology).
  • One learning pack can have several authors.
  • Technically, a student can author a learning pack too.
  • Only members who use a learning pack get to rate a pack.
  • Although authors can vote for packs and teachers can vote for their classes, those votes are ignored.

alt text

If only interested in the ratings table, you could use:

alt text

Or, combine both models into something like:

alt text

冷情妓 2024-10-02 23:45:49

如果您认为最终会得到更多需要评级的实体,那么您需要创建一些更通用的东西(并且不太适合数据库哲学)。

ratings
-------
id
voterClass
voterId
subjectClass
subjectId
vote
date(s)

通过使用这种设计,您会忘记 FK 和引用完整性。但它非常灵活,并且使用正确的索引它具有很强的可扩展性。此外,当实体(主题)被删除时,投票仍然存在。这种设计使您免于重复字段和表格。

If you think that you'll end up with more entities which will require rating then you need to create something more generic (and not very db-philosophy-friendly).

ratings
-------
id
voterClass
voterId
subjectClass
subjectId
vote
date(s)

By using this design you forget about FKs and referential integrity. But it's very flexible, and using the right indexes it's very scalable. Also, when entities (subjects) are deleted the votes remain. This design saves you from duplicating fields and tables.

吾性傲以野 2024-10-02 23:45:49

使用 mySQL 工作台。它是跨平台的并且运行良好。

MySQL 工作台直观地查看您正在对数据库执行的操作。 http://diariolinux.com/wp-content/uploads/2008/08/wb51linuxpreview2a.png

MySQL Workbench 也满足您的所有标准 通用远程数据备份和下载包括-innodb-support stackoverflow 上的问题

顺便说一句:使用 + 对数据库进行正向工程。

Use mySQL workbench. Its cross-platform and works great.

MySQL workbench visurally see what you are doing with your database. http://diariolinux.com/wp-content/uploads/2008/08/wb51linuxpreview2a.png

MySQL workbench Also meets all of your criteria for general-purpose-remote-data-backup-and-download-including-innodb-support question on stackoverflow

BTW: Use <ctrl>+<G> to forward engineer a database.

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