文章类型的网站用什么数据库

看规模大小，及 *** 作系统而定。在win视窗平台上，数据量不大、每日增量不多且经常维护的，可以用MS Access,这个最好打理了。

数据量大的、增量大，且有存储图形需求的，就用MSSQL。

在UINX和Linux平台上，只能选mysql了。当然也可以选DB2和Oracle,可没这个选项。呵呵。

MSSQL 界面相对友好，但维护起来很麻烦。MySql界面不好，但维护起来相对容易些，前提是会用SQL语句。

动态的结构：

{

user_id:13,

action: 行为,

object_id: 对象ID,

object_type: 对象类型,

object_user_id: 对象用户ID,

parent_object_id: 对象父级ID,

parent_object_type: 对象父级类型,

parent_object_user_id: 对象父级用户ID,

reply_id: 回复ID, // action为回复时有用

parent_reply_id: 回复的父级回复ID, // action为回复时有用，回复了别人对评论的回复

text: '转发或者分享时附加文字',

view_count: 0,

created_at: 创建时间,

deleted_at: 删除时间,

}

说明： 1object_只存储主要模块内容信息，不含评论； 2parent_object_存储有嵌套关系的对象，比如当object_为答案时，parent_object_为问题； 3reply_id用于直接回复评论时用到； 4parent_reply_id父回复ID; 5 两个回复ID，使用情况是：当回复了别人的回复时，根据comment_id拉取评论与全部回复，在模板显示时只显示对话的两个回复。

场景列表：

一级结构：

安正超发布了文章

'action' => NEW,

'user_id' => 安正超ID,

'object_id' => 文章ID,

'object_user_id' => 安正超ID,

'object_type' => ARTICLE,

安正超上传 了 N张

'action' => NEW,

'user_id' => 安正超ID,

'object_id' => ID（数组，以逗号隔开）,

'object_user_id' => 安正超ID,

'object_type' => PICTURE,

安正超提了问题xxxx

'action' => NEW,

'user_id' => 安正超ID,

'object_id' => 问题ID,

'object_user_id' => 安正超ID,

'object_type' => QUESTION

二级结构：

安正超评论了文章xxxx（回答了通用）

展示：

文章： xxxxx

评论：xxxxx (李林评论的)

'action' => COMMENT,

'user_id' => 安正超ID,

'object_id' => 评论ID,

'object_type' => COMMENT,

'object_user_id' => 安正超ID

'parent_object_id' => 文章ID,

'parent_object_user_id' => 作者ID

'parent_object_type' => ARTICLE,

三级结构：

安正超在文章中回复了李林的评论

展示：

文章： xxxxx

评论：xxxxx (李林评论的)

回复:xxxx (安正超)

'action' => REPLY,

'user_id' => 安正超ID,

'object_id' => 评论ID,

'object_type' => COMMENT,

'object_user_id' => 李林ID

'parent_object_id' => 文章ID,

'parent_object_user_id' => 作者ID

'parent_object_type' => ARTICLE,

'reply_id' => 安正超的回复ID

四级结构：

安正超回复了李文凯在问题 “xxxx” 中 李林的答案下的评论

说明：问题信息从答案接口取回

展示：

问题： xxxxx

答案1

答案2

答案3(李林回答的)

评论：xxxxx (李文凯评论的)

回复:xxxx (安正超)

'action' => RESPOND,

'user_id' => 安正超ID,

'object_id' => 评论ID,

'object_type' => COMMENT,

'object_user_id' => 李文凯的ID

'parent_object_id' => 答案ID,

'parent_object_type' => ANSWER,

'parent_object_user_id' => 李林ID

'reply_id' => 安正超的回复ID

1、开发数据库首先选一种数据库，譬如SQL SERVER\x0d\2、开发数据库其次选一种架构：即网站形式的B/S架构，或窗体程序的C/S架构\x0d\3、根据架构，和用户需求，选一种语言，B/S一般采用：JAVAEE,ASPNET,PHP；C/S架构一般选\x0d\NET,DELPHI,VC++等\x0d\4、用编程语言，并采用一种数据接口：诸如ODBC,ADO,ADONET,JDBC，较容易开发有界面的数据库程序\x0d\5、更多交流参考我空间主页有关文章

楼主您好，文章发布系统数据库的创建，首先考虑系统框架（也就是文章中是否含有不同的类别）表1：ID主键自增长（便于统计和计数），文章类别ID（分辨文章所属类别），文章类别名称（前一字段中文名称）（此表可当主表进行后表的延续）表2：ID自增长（计数），文章类别ID，文章类别名称，文章标题，文章内容，发布时间，发布人，是否转载，转载来源，是否显示表3：ID自增长（计数），文章ID，文章标题，评论人名称，评论人ID（根据系统是否含有用户名来判断如果该字段可以为空，如果为空显示为匿名评论），评论时间，评论人IP（可根据个人需要取决是否需要该字段），评论支持数（用于其他用户对此评论的支持数，根据个人需要取决是否需要）大概就是这几张表，如果需要更详细的可与QQ和我联系

前边介绍了负载均衡，mysql同步，接下来介绍tp6分布式部署多个数据库，实现读写分离。

tp6的分布式部署读和写仍然是一个系统，这里我们分开 *** 作，给用户展示的就是从数据库，后端添加文章就是主库，然后同步到从库。

1、配置数据库链接参数

目标：实现随机使用数据库展示信息，只是读 *** 作。

测试：前台可以读取表中内容（存放的不一致），查看是否是随机显示的。

打开env文件进行编辑

说明：

2、编辑databasephp

找到deploy设置为1分布式部署，下边不要改，都是读，写入的也就是后端的我们单独建站连接主库。

配置完成，tp6使用的是mt_rand取随机数判断使用哪个数据库。

3、数据库交互写 *** 作

比如浏览量没必要每次都去更新数据库，可以先使用redis缓存，存够1000的整数倍，再去更新数据库。

4、后台独立，也就是写

可以前后端分离，单独做一个网站（没有前端）使用ip访问或者独立的域名连接后台。

5、上传附件（jquery ajax跨域上传）

使用了nginx负载均衡，肯定是多个一样的网站，如果存放到一个站，别的就不能访问了，可以单独设置一个附件（压缩包，等）服务器，可以使用二级域名连接，这就要求我们上传附件的时候，是上传到附件服务器。

jqueryURL

API控制器apdpic方法

说明：

也可以先传到后台服务器然后使用（php）ftp上传，或者是通过curl上传到附件服务器，感觉那样毕竟麻烦，直接设置跨域会比较简单。

也测试了使用jsonp跨域，但是不能上传附件。

6、thinkphp6实现读写分离（在一个站点）

我个人是不喜欢这样的，负载均衡应该是均衡地读，也就是前台单独一个站点，后端的写是另一个独立的站点，看个人喜好吧。

独立后台的优点：可以提升安全性，因为我们的后台网址是不公开的，避免用户猜测一些后台的信息。

env配置按照1所述编辑，默认第一个是主库。

databasephp

愿大家在新的一年心想事成，万事如意！！！

当代网站的内容生成都是依赖数据库技术的，后台信息流经过审核以含媒体文本的方式进入数据库，前台页面对数据库的更新内容进行提取生成自动排版页面，再经过人工调整（可选）确定最后排版结果，再经过关键字热度调整在网站主页面上的排序和标题。

以上就是关于文章类型的网站用什么数据库全部的内容，包括:文章类型的网站用什么数据库、类似QQ空间的社交网站的用户动态的数据库应该怎么设计、怎样设计数据库前台等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！