DB 设计帮助:文章和文章评论网站

发布于 2024-10-02 19:00:14 字数 1279 浏览 3 评论 0原文

我正在开发一个包含文章和评论的基本博客风格网站。我知道类似的软件已经存在(drupal、joomla),但在这种情况下我更喜欢自己开发,此外,这就是我学习的方式。 :-)

以下是基本表详细信息:

表名称:users
用途:有关有权访问系统的人员的信息。
列名称
编号
姓名
散列密码
电子邮件
网站
上次登录日期
最后登录 IP
权限

表名称:文章
用途:用户表中人员发布的文章。
列名称
编号
标题
用户 ID
日期
内容

表名称:评论
目的:对公众和用户发表的文章进行评论。
列名称
编号
文章_id
comments_authors_id
日期
评论

表名称:comments_authors
目的:有关文章评论者的信息。
列名称
编号
姓名
电子邮件
网站

工作流程
1.) 用户表中的用户发布了一篇文章。
2.) 文章被写入文章表。
3.) John Doe(不是用户)对文章发表了评论。
4.) John 的个人信息被写入 comments_authors。
5.) John 的评论被写入评论表。

到目前为止听起来不错。现在考虑这个......

1.) 用户表中的用户对文章发表评论。
2.) 用户的个人信息写入comments_authors。
3.) 用户的评论被写入评论表。

问题
现在我们有关于用户的重复信息。 :-(
用户的姓名、电子邮件地址和网站网址存储在 users 表 comments_authors 表中。

这是一个错误的设计吗?有正确的方法吗?
一个只有几个用户的系统,也许不用担心。
一个拥有数百个用户的系统,嗯,有很多重复的数据。

我非常感谢您的帮助。谢谢!

I am working on a basic blog-style website with articles and comments. I'm aware that similar software already exists (drupal, joomla) but I prefer to roll my own in this case, and besides, it's how I learn. :-)

Here are the basic table details:

Table Name: users
Purpose: Information about people with access to the system.
Column Names:
id
name
hashed_password
email
website
last_login_date
last_login_ip
permissions

Table Name: articles
Purpose: Articles published by people in users table.
Column Names:
id
title
users_id
date
content

Table Name: comments
Purpose: Comments on an article published by the public and users.
Column Names:
id
articles_id
comments_authors_id
date
comment

Table Name: comments_authors
Purpose: Information about people who commented on an article.
Column Names:
id
name
email
website

Work flow:
1.) A user, from the users table, publishes an article.
2.) The article is written to the articles table.
3.) John Doe, not a user, comments on the article.
4.) John's personal info is written to comments_authors.
5.) John's comment is written to the comments table.

Sounds good so far. Now consider this…

1.) A user, from the users table, comments on an article.
2.) The user's personal info is written to comments_authors.
3.) The user's comment is written to the comments table.

The Problem:
Now we have duplicate information about the user. :-(
The user's name, email address, and website url are stored in the users table and the comments_authors table.

Is this such an incorrect design? Is there a correct way instead?
A system with only a few users, maybe not worrying about.
A system with hundreds of users, well, that's a lot of duplicate data.

I really appreciate your help. Thanks!

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

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

发布评论

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

评论(4

ˉ厌 2024-10-09 19:00:15

人们对重复的数据喋喋不休……这可能是……可能是一个问题。如果您正在构建订单输入系统、会计、交易系统……这将是一件大事。

这是博客评论...可能发生的最坏的情况是什么?

最坏的情况是你只有两份副本和两份海报……每个只发表评论的笨蛋都只存在一次。因此,如果您有 1000 张海报,就会有 1000 行额外的大约 100 字节的行...哇,您正在消耗一整兆字节的数据库空间。

我是否推荐此数据模型作为模拟模式,不。我的设计会有很大不同。但我是为超大型企业应用程序设计的,而这些设计不一定是最容易编程的东西。他们只是表现出色。但就你的情况而言,开始编码,不要担心那些多余的东西。

People harp on duplicate data... and it can be .. CAN BE a problem. If you were building order-entry systems, accounting, trading, system... it makes a big deal.

This is for BLOG COMMENTS... what's the worst that can happen?

at worst you've got two copies and only two copies of posters... every schmuck who only comments is there just once. So if you had 1000 posters, you'd have 1000 extra rows of about 100 bytes rows... whoa, you're chewing up an entire MEGAbyte of database space.

Am I recommending this datamodel as a pattern for emulation, no. I'd design this a lot differently. But I design for very large scale enterprise applications and those designs aren't necessarily the easiest thing to program against. They just perform great. But in your case, start coding and don't sweat that little redundancy.

城歌 2024-10-09 19:00:15

对于每条新评论,您都可以创建一个具有公共权限且没有密码的新“用户”。将电子邮件地址设置为唯一的用户名,这样您就不会出现重复的数据。在评论中,您可以改为comments_authors_id user_id。

For every new comment, you could create a new 'user' with public privs and no password. Make the email address the unique username and you won't have duplicate data. On comments, you could then make comments_authors_id user_id instead.

阳光的暖冬 2024-10-09 19:00:15

也许我不太理解您的设计,但是删除 comments_authors 表并使用 users 表中的 permissions 字段来判断是否允许用户发布文章或仅添加评论。

Maybe I'm not understanding your design very well, but wouldn't it be better to remove the comments_authors table and use the permissions field in your users table to tell whether the user is allowed to publish articles or just add comments.

岁吢 2024-10-09 19:00:15

我很欣赏反馈和不同的观点。我仍在争论采用哪种方法,因此我列出了每种方法的一些优点和缺点。有人说服我吗! :-)

用户和评论者都在用户表中
- Pro:少一张表(comments_authors 表已删除)
- 缺点:hashed_pa​​ssword、last_login_date 和权限列不适用于评论者
- 缺点:随着表的增长,当用户想要登录时查询时间会增加

使用comments_authors表的当前设计
- 优点:任何表中都没有未使用的列
- Pro:当用户想要登录时查询时间更快
- 缺点:comments_authors 表中存在重复的用户数据(用户表中的 # 个用户 = comments_authors 表中的 # 个附加行)

I appreciate the feedback and different points of view. I'm still debating which approach to take so I listed some pro's and con's of each approach. Someone convince me! :-)

Users and commenters all in the users table
- Pro: one less table (comments_authors table removed)
- Con: hashed_password, last_login_date, and permissions columns don't apply to commenters
- Con: as table grows, query time increases when users want to log in

Current design using comments_authors table
- Pro: no unused columns in any table
- Pro: quicker query time when users want to log in
- Con: duplicate user data in comments_authors table (# users in users table = # additional rows in comments_authors table)

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