过度的开发导致没必要的复杂。非常复杂的业务和功能在工作中，开发中都会遇到。抓住本质，了解核心需求，消减不必要的功能，才能事半功倍。
需求分析
博客本质就是一个放了很多文章的网页，点击文章链接能看文章，仅此而已。
1、博客最重要的功能是阅读，能让用户以最不费力最方便的阅读，集中注意力于内容上。除此以外所有的花哨功能都不重要。
2、其次重要的功能是交互，通过博文抛砖引玉，让所有网友一起畅所欲言，自由探讨。思维碰撞，可以冒出各种新点子和启发。
3、再然后是博客的文章编辑器，或者后台管理功能。这都是可有可无的东西，但是一个好的编辑器和管理界面确实可以提高写作效率。
4、最后才是无关紧要的插件，小玩具，其他无关阅读体验的小功能。
做加法，从零开始，从最核心的需求开始。因为本来需要迁移现在Wordpress博客的内容，所以直接对多余的Table和Conlunm去除就好了。
数据库设计
E-R图、数据库模型就不搞了，博客全部功能四张表就能覆盖。因为只有我自己用，所以用户表也没建。
article表，对应的实体是博客的文章
属性字段有：文章ID、文章标题、文章html内容、创建日期、修改日期、发布状态、点赞数、评论数、浏览量。
这个简单易懂，字段名即是用途
comment表，对应的实体是用户的评论
属性字段有：评论ID、评论内容、发表用户、发布日期、匿名状态、父评论ID、文章ID。
父评论ID是用于实现嵌套的层级查询的
archive表，对应的文章的标签和分类等归档信息
属性字段有：归档ID、归档名、 分类方法、文章ID。
我把文章的标签和分类放到了一个表中，两个东西实际上是一样的，都是为了显示该分类体系下的文章。只是分类和文章是一对多关系，分类是1端，文章是多端；文章和标签是一对多关系，文章是1端，标签是多端。分类方法的字段'tag'表示是标签，'category'是分类。archive表的每一条信息的归档名，根据分类方法字段的不同，有可能是文章的分类，也有可能是文章的一个标签。
建表语句
CREATE TABLE article (
article_ID int UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '文章ID',
article_title varchar(200) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '文章标题',
article_content longtext COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '文章内容',
post_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '发布时间',
update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
post_status varchar(20) NOT NULL DEFAULT 'publish' COMMENT '发布状态',
likes_count int UNSIGNED DEFAULT 0 COMMENT '点赞数',
comments_count int UNSIGNED DEFAULT 0 COMMENT '评论数',
views_count int UNSIGNED DEFAULT 0 COMMENT '浏览量',
PRIMARY KEY (article_ID)
) DEFAULT CHARSET=utf8mb4 COMMENT = '文章';
CREATE TABLE comment (
comment_ID int UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '评论ID',
content text NOT NULL COMMENT '评论内容',
author varchar(50) NOT NULL COMMENT '用户呢称',
publish_date datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '发布日期',
anonymous_status tinyint(1) NOT NULL DEFAULT 0 COMMENT '匿名状态（0=否，1=是）',
parent_ID smallint NOT NULL DEFAULT 0 COMMENT '父评论ID，嵌套实现层级评论',
article_ID int UNSIGNED NOT NULL COMMENT '文章ID',
PRIMARY KEY (comment_ID)
) DEFAULT CHARSET=utf8mb4 COMMENT = '评论';
CREATE TABLE archive (
archive_ID int UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '归档ID',
archive_name varchar(20) NOT NULL COMMENT '归档名',
taxonomy varchar(20) NOT NULL COMMENT '分类方法(文章分类、文章标签等)',
article_ID int UNSIGNED NOT NULL COMMENT '文章ID',
PRIMARY KEY (archive_ID)
) DEFAULT CHARSET=utf8mb4 COMMENT = '归档';
小记:和ChatGPT的斗智斗勇
为了重新设计博客的数据库，也在网上查一些类似的实现参考参考。问一下Chatgpt还更快，设计完还给他检查一下。看看语法对不对，有没有字段设计的不合理。
虽然效率挺高的，但是AI还是没办法理解代码的含意，话不能全听。“ChatGPT可能会犯错，请核查重要信息”所言不虚。
首先如果不写注释的话，我感觉他可能会曲解我的代码的意思。好吧，其实注释没说清楚的时候，它都想给我出馊主意了。本来上网article表做的差不多了，然后修改时间字段，它非要加一个ON UPDATE CURRENT_TIMESTAMP ，让数据库每次更新记录时，update_time 字段自动更新为当前时间。我说我这个在业务里实现就行。
还好这次是我有主意了，才让他提出些建议。如果让他直接生成一段建表语句，我不知道它要在网上找哪一段臃肿的建表语句给我。
和Chatgpt在第一张表上斗智斗勇了一会儿，我把第二张Comment表第一次给它看时。就对我的表设计给出了很高的评价：“很好”、“清晰且功能完整”、“合理”。
没挑刺和给奇怪的优化方案。最后我又问了他否是懂这段代码的含意，它说照着我的注释又复述了一遍。但他肯定没懂。
还有一个风险是，必须要完全懂这个问题，你才能得到一个正确的答案。
我问它这两张表的字段连起来没问题吧，它撺掇我非要用外键连接。我问它“不用外键也可以通过两个字段连接两个表对吧”，然后他说可以用使用 JOIN 连接两个表。然后我问它“使用外键连接的好处是什么呢”，干吗这么做，他说一堆数据完整性，一致性巴拉巴拉的。
最后我问它“事实上我好像看到过，MySQL应该尽量不使用外键而是用Join连接，这是什么原因”，然后它才告诉我一推外键的缺点：“外键约束会增加额外的开销；没有外键约束的，设计更灵活，方便快速迭代和开发；在数据迁移或复制时，外键约束可能导致问题； Join连接业务逻辑在应用层实现，可以根据业务需要灵活处理数据”。
看过《魔法少女小圆》吗，这TM的就是QB啊。相当于你不问，他不答。这太坏了，说真话说不全，有时比说假话还严重！！因为真的，不像假的信息一眼就能看出问题。你问它两个数据表能连吧，它就说外键能连，外键有多好。你不问他外键的缺点和其他的方法，它就只告诉你外键可以连。没经验的初学者要是这样问它，这不就误人子弟了吗。因为本质上ChatGPT没有理解话的含意，不会真正的思考。最蠢的程序员都不会犯这种错误！
文章评论