sql - 这就是现代新闻网站处理它的 sql/业务逻辑的方式吗？

Question

基本上，下图表示我正在处理的站点主页上的组件，其中到处都有新闻组件。 sql 片段设想了我认为它们应该如何工作，但我非常感谢以前使用过新闻站点的人提供的一些业务逻辑建议。以下是我的设想:

问题 #1:sql 逻辑是否有意义？您是否可以看到任何注意事项/缺陷？

我的模式是这样的:

articles:

article_id int unsigned not null primary key,
article_permalink varchar(100),
article_name varchar(100),
article_snippet text,
article_full text
article_type tinyint(3) default 1

我会将所有文章(主要特色、次要特色、其余)存储在一个表中，我会按 type 列对它们进行分类，这将对应于我的 中的数字news_types 表(例如，我使用文字文本，因为它更容易理解)。

问题 #1.1:不同类型的文章可以依赖一张表吗？

一篇新闻文章可以有 3 种图像类型:

• 原始图片大小的 1 倍，只会显示在文章的永久链接页面上
• 1x 主要特色图片，将显示在首页第 1 部分
• 1x 子特色图片，将显示在首页第 2 部分

现在我希望每篇文章对应一张图片而不是多张图片。不过，用户可以在 article_full TEXT 列中发布文章图片。

问题 #1.2:我不确定我应该如何将文章图片合并到我的模式中，对于像这样依赖 2 个表的模式来说是否常见？

文章图片链接:

article_id article_image_id
1          1

文章图片:

article_image_id article_image_url
1                media.site.com/articles/blah.jpg

数据要求:

从我的 sql 逻辑来看，必须有一些数据才能显示内容..

• 必须至少有一篇主要类型的文章
• 必须至少有四篇 featured 类型的文章位于主要文章的下方

问题 #1.3:如果数据丢失，我是否应该费心创建特殊情况？例如，如果没有主要特色文章，我应该选择最新的特色文章，还是应该要求有人总是指定主要文章？

问题 #1.4:在管理员中，当用户发帖时，默认情况下我会有一个下拉列表来指定文章类型，normal 将是 pre -选中，它将有 main 和 featured 选项。因此，如果某个用户决定更改文章类型，他/她可以这样做。

问题 #1.5:我的特色文章和主要文章的工作方式仅适用于最新日期。例如，如果用户出于某种原因想要指定一篇较旧的文章作为主要文章，我应该创建自定义逻辑，还是只告诉他们更新文章日期以使其晚于最新文章？

Answer 1

关于标题中的问题，给猫剥皮的方法肯定不止一种。适合一个站点的内容可能不适合另一个站点。一些可能影响您决定的因素是网站需要扩展到多大(例如，将有数十篇文章或数百万篇文章？)以及谁将输入数据(例如，您需要建立多少防白痴功能？在)。我会根据您提供的信息尽力回答问题。

问题#1:是的，我觉得不错。请务必设置索引(我将索引放在 [type,date] 和 [category,type,date] 上)。

问题 #1.1: 是的，我会说没问题，事实上，我会说这是首选。如果我正确地理解了这个问题(这与每个“类型”的表格相对)，那么如果您愿意的话，这会让您在将来更好地添加新类型。

问题 #1.2:如果您只希望每个故事有一个图像，每个图像有一个故事，我看不出将其拆分到一个额外的表格中有什么好处。它似乎只是更多的开销。但我可能在这里遗漏了一些东西。

问题 #1.3:这是您的设计决定，这里没有“正确”答案。这完全取决于您对系统的预期用途。