精华内容
下载资源
问答
  • 服务端 数据库设计mysql 数据库设计用户信息表格设计用户信息表格,保存用户的 账号 id,用户名,密码,邮箱等重要信息以及辅助信息用途:根据指定用户 id 获取信息,并展示重要属性:邮箱,邮箱是用户的安全保证,...

    服务端 数据库设计

    mysql 数据库设计

    用户信息表格设计

    用户信息表格,保存用户的 账号 id,用户名,密码,邮箱等重要信息

    以及辅助信息

    用途:根据指定用户 id 获取信息,并展示

    重要属性:邮箱,邮箱是用户的安全保证,通过邮箱可以注册,重置密码,进行重要操作

    字段名

    字段类型

    键属性

    说明

    uid

    int

    primary key auto_increment

    用户 id

    uname

    varchar

    not null

    用户名

    password

    varchar

    not null

    密码

    email

    varchar

    not null & unique key

    用户认证凭证

    sex

    tinyint

    default null

    性别

    age

    tinyint

    defalut null

    年龄

    create_time

    int

    not null

    注册时间 unix 时间戳

    more_info

    text

    default null

    额外信息 json

    建表语句

    create table `user` (

    `uid` int primary key auto_increment COMMENT '用户 id 唯一 自增',

    `uname` varchar(64) not null COMMENT '用户名',

    `password` varchar(32) not null COMMENT '密码',

    `email` varchar(32) not null COMMENT '绑定邮箱',

    `sex` tinyint default null COMMENT '性别',

    `age` tinyint default null COMMENT '年龄',

    `create_time` int not null COMMENT '注册时间',

    `more_info` text COMMENT '额外信息 json 格式保存',

    unique key (`email`) COMMENT '邮箱 唯一'

    ) COMMENT = '用户表';

    用户注册表格设计 效验作用

    注册信息表:用于用户注册验证真实性,是成为真正用户的过渡信息

    这里使用 邮箱服务对用户进行验证

    字段名

    字段类型

    键属性

    说明

    email

    varchar

    primary

    注册邮箱

    auth

    varchar

    not null

    验证码

    expire_time

    int

    not null

    失效时间

    验证码设计 6位

    失效时间用途:定时任务清除失效的验证码,确保数据表不会有过多垃圾数据

    建表语句

    create table `register` (

    `email` varchar(32) primary key COMMENT '验证邮箱',

    `auth` varchar(10) not null COMMENT '验证码',

    `expire_time` int not null COMMENT '失效时间'

    ) COMMENT = '用户注册验证表';

    重置密码信息表格(用于忘记密码情景)

    数据表同上面的注册过渡表

    表设计相同,是可以合并使用一个表格,但是分开设计的原因在于:

    考虑一种不太合理的情形,假如 A 如果使用 a 邮箱注册账号,服务端已发送验证码,这样在表格 register中会有一个注册记录,其中一个字段保存着验证码。

    假设在 用户 A 在使用 验证码进行认证之前,B用户在请求找回密码的服务,B 理应输入自己的邮箱,但是错误的输成了 A 的邮箱 a(这种情形下对 B 是没有副作用的,对 A 的影响就是 A 会再次接收到一个 包含用于重置密码的验证码的邮件), 如果将注册和重置密码使用的是同一个表格,会导致注册验证码被 重置验证码覆盖。

    分开设计可以避免验证码被覆盖,两个表格为不同的 api 提供服务(但是不足的是 A 用户依旧会收到重置密码的邮件)

    在重置密码时主要用到邮箱验证,我们无法确认用户输入的邮箱就是其本人的邮箱,即使要求用户重置密码时输入 自己的账号 id 与 邮箱 ,然后在服务端进行验证后决定是否发送消息。但是依旧避免不了利用服务端进行恶意操作的行为。这里我们不考虑这种恶意行为。

    好友关系表

    表格设计:

    由于关系是相互的,这样设计可以减少数据冗余,每一对关系在数据表中只会存在一份.

    字段名

    字段类型

    键属性

    说明

    uid_1

    int

    not null

    用户 1

    uid_2

    int

    not null

    用户 2

    remark_1_2

    varchar

    default null

    1 对 2 的备注

    remark_2_1

    varchar

    default null

    2 对 1 的备注

    group_1_2

    varchar

    default null

    1 对 2 的分组

    group_2_1

    varchar

    default null

    2 对 1 的分组

    暂不考虑 黑名单,单向删除就会删除好友关系

    uid_1 和 uid_2 组合作为主键

    建表语句

    create table `friend` (

    `uid_1` int not null COMMENT '用户 1',

    `uid_2` int not null COMMENT '用户 2',

    `remark_1_2` varchar(64) COMMENT '用户1 对 用户2 的备注',

    `remark_2_1` varchar(64) COMMENT '用户2 对 用户1 的备注',

    `group_1_2` varchar(64) COMMENT '用户1 对 用户2 的分组',

    `group_2_1` varchar(64) COMMENT '用户2 对 用户1 的分组',

    primary key(`uid_1`, `uid_2`) COMMENT '好友关系 唯一性'

    ) COMMENT = '好友关系表';

    好友离线消息表

    字段名

    字段类型

    键属性

    说明

    to_uid

    int

    index & not null

    接收者 id 索引

    from_uid

    int

    not null

    发送者 id

    msg

    text

    not null

    消息 json 格式

    好友离线表格只有在 接收方离线时才会使用。接收方在线时 不经过 mysql ,会直接推送给目标用户

    离线消息表 以 接收方为主体,设计索引,当用户上线时直接拉取所有 to_uid 等于 用户 id的消息即可

    离线消息不仅仅保存聊天的 消息,同时包含 好友申请消息,群聊邀请消息

    建表语句

    create table `pri_msg` (

    `to_uid` int not null COMMENT '接受者 id',

    `from_uid` int not null COMMENT '发送者 id',

    `msg` text not null COMMENT '消息 json 格式',

    index (`to_uid`) COMMENT '建立索引'

    ) COMMENT '私聊离线消息表';

    群聊信息表

    群聊信息表:

    主要保存群聊的一些基本信息,便于用户查看群聊时显示

    字段名

    字段类型

    键属性

    说明

    gid

    int

    primary key & auto_increment

    群聊 id 主键 自增

    owner

    int

    not null

    群主 id

    gname

    varchar

    not null

    群聊名称

    create_time

    int

    not null

    群聊建立时间

    person_number

    int

    not null

    群人数

    建表语句

    create table `group_info` (

    `gid` int primary key auto_increment COMMENT '群聊 id 自增',

    `owner` int not null COMMENT '群主',

    `gname` varchar(64) not null COMMENT '群名称',

    `create_time` int not null COMMENT '建群时间',

    `person_number` int not null COMMENT '群人数'

    ) COMMENT = '群聊信息表';

    /* index (`owner`) */ /* 暂不考虑为 owner 建立 索引 */

    群聊用户关系表

    字段名

    字段类型

    键属性

    说明

    gid

    int

    not null

    群聊 id

    uid

    int

    not null

    用户 id

    join_time

    int

    not null

    入群时间

    remark

    varchar

    not null

    群呢称

    last_msg_id

    int

    no null

    已读群聊消息的最大 id

    群聊用户关系表 主键设计为 (gid, uid), last_msg_id 的作用在于标记用户已读的消息,在用户上线时推送未读消息(配合下面的群聊消息储存表使用)

    建表语句

    create table `group_person` (

    `gid` int not null COMMENT '群聊 id',

    `uid` int not null COMMENT '用户 id',

    `join_time` int not null COMMENT '加群时间',

    `remark` varchar(64) COMMENT '群聊备注',

    `last_msg_id` int not null COMMENT '已读的当前群聊最后一条消息 id',

    primary key(`gid`, `uid`)

    ) COMMENT = '群聊 用户关系表';

    群聊离线消息表

    针对不同的群聊,每个群聊设计一个表格。便于消息 id 的自增

    群聊表名设计为 group:$gid $gid 表示群号

    字段名

    字段类型

    键属性

    说明

    mid

    int

    primary key auto_increment

    消息 id

    from_uid

    int

    not null

    发送者 id

    msg

    text

    not null

    消息

    说明:群聊消息表格 消息 id 设置为自增,进行群聊离线消息推送时,只需要记录发送者 id 与发送的消息。

    建表语句

    create table `group:gid` (

    `mid` int primary key auto_increment COMMENT '消息 id, 自增',

    `from_uid` int not null COMMENT '发送者 id',

    `msg` text not null COMMENT '群聊消息'

    ) COMMENT = '群聊离线消息列表';

    展开全文
  • 数据库设计感悟

    2018-11-19 09:20:00
    关于数据库设计,首先需要明确的就是整个项目的设计是围绕数据库结构来实现的,也就是说数据库一旦设计好就不能随意改动,因为一旦改动对数据库的访问代码就很容易出现问题,相当于对整个项目需要改动,这也就意味着...

     关于数据库设计,首先需要明确的就是整个项目的设计是围绕数据库结构来实现的,也就是说数据库一旦设计好就不能随意改动,因为一旦改动对数据库的访问代码就很容易出现问题,相当于对整个项目需要改动,这也就意味着设计数据库需要从拓展的角度来实现, 比如说一个用户表,一个最简单的用户登陆只需要用户与密码,倘若当前阶段我只考虑用户的账号与密码两个字段,那么我只需要子啊用户表中设定两个字段即可,但如果有一条我需要增加功能,比如加一个个人设置功能,用户能添加图像,有个性签名等,那么该表就不能实现该拓展,也就意味着原来的数据库不能用了,需要重新定义数据库并且改动整个项目中用到该表的代码,其过程是十分复杂且不必要的。

      另外需要注意的就是在建多少表的问题。我可以设置一个字段很长的表,或者很多字段很少的表,两者的首先考虑基于面向对象的思想,把一个类的属性设为一个表,按照层次来建表,这样表与表之间的联系关系比较清晰,比如我们项目中的门店,类别,商品三个类,三者之间是商品->类别->门店,我们可以建一个表按照门店属性-类别属性-商品属性的格式,也可以建三个表设置主外键连接。但是前者存在两个问题:当我修改门店属性时要修改很多行,操作繁琐,另外当我只想得到门店属性时会得到类别与商品的属性,安全隐患很大。但也不是表越多越好,还是要从综合角度去考虑,最为合理。

      另外就是建表时记得加注释

    转载于:https://www.cnblogs.com/GongZhiMao/p/9981391.html

    展开全文
  • PAGE 1 图书管理系统数据库设计 一系统概述 1系统简介 图书管理是每个图书馆都需要进行的工作一个设计良好的图书管理系统数据库能够给图书管理带来很大的便利 2需求分析 图书管理系统的需求定义为 1.学生可以直接...
  • 第三方账号登录的设计数据库表的设计 **文章选自微信公众号,特意保存学习** 用户名密码注册登陆 流程图: 流程说明: 1 前端将用户名、密码发送到服务器,服务器进行常规的判断,判断用户名、密码长度是否满足...

    第三方账号登录的设计与数据库表的设计

    			**文章选自微信公众号,特意保存学习**
    

    用户名密码注册登陆

    流程图:
    流程图
    流程说明:

    1 前端将用户名、密码发送到服务器,服务器进行常规的判断,判断用户名、密码长度是否满足,用户名是否重复等条件,条件不通过直接返回对应错误码给到前端,这里密码字段,为了防止传输过程中被截胡,建议加密再上传,我们的传输密码默认都是会进行一个md5加密,然后记录到数据库再进行一层加密,就算是脱库也没事,密码不要明文存储。
    2 校验通过后,就将用户名密码写入数据库,并进行后面积分发放等操作,这里不展开。
    3 现在进行登录,前端将用户名,密码发送给到服务端,服务端首先会校验登录次数是否超过设置的阈值,如果超过只能继续等待被关小黑屋。
    4 如果未超过继续登录逻辑,判断用户名、密码是否正确,不正确密码则进行阈值的判断,如果超过则关小黑屋,记住小黑屋必须设置过期时间,要不然就会永久关上了,这个可以用redis的过期来做。
    5 登录成功后进行后续的一切后置逻辑,比如加积分。。。等操作。

    手机号注册登陆

    流程图:
    在这里插入图片描述
    流程说明:

    1 首先输入手机号,然后发送到服务端,服务端将手机号记录在我们数据库中,然后生成随机验证码,并将手机号和验证码绑定到一个redis里面,然后记录过期时间,这个过期时间一般是10分钟左右,这就是我们一般手机验证码的有效期。
    2 手机接收到手机短信后,那么就在界面填写验证码发送服务端,服务端收到验证码后就会在redis里面查询到这个手机号对应的验证码,失败就返回错误码。
    3 成功后就进行登录操作。

    这里看起来没有明确的注册登录操作,其实在发送手机号码就可以认为是一个常规的注册,然后后面的验证码输入就是一个登陆操作,

    在后续产品里面增加一个 手机号码密码补录的功能 即可,这也是现在很常规的手法,但是现在移动互联网大爆炸时代,密码已经显得不是那么重要了,反正我从来记不住密码,如果手机号码能操作的app,绝对不用密码来操作。

    数据库设计
    表结构 :

    自增id 用户名 密码 手机号 错误次数
    1 user1 7fef6171469e80d32c0559f88b377245 13456789012 1
    2 user2 7fef6171469e80d32c0559f88b377245 13456789012 10
    3 user3 7fef6171469e80d32c0559f88b377245 13456789012 1

    说明 :

    这里只是单纯说明需要用到的数据,没有扩展具体场景,这个表结构能够满足上面两个方案的设计。

    引入第三方账户方案

    这里是以QQ-SDK的登录逻辑, 我们先来一波时序图
    在这里插入图片描述
    说明:

    1 客户端自己调起登录的界面,进行输入用户名、密码,这里的是第三方的用户名,密码,登录成功后,会返回access_token openid expire_in,这过程会使用到oauth2.0,不过在sdk里面进行内置回调获取了,后面我们会说明我们自身实现的oauth2.0
    2 客户端拿到access_token、openid、login_type(qq、wechat…)请求应用服务器,应用服务器拿到这些数据后就会根据对应的login_type去对应的用户中心进行access_token和openid进行校验。校验不通过则返回对应错误码
    3 校验通过后就会判断本地是否有这个login_type和openid是否存在,不存在则进行获取远程的用户名、头像等基础信息来作为本地基础数据,并且返回code值
    4 如果已经存在,那就是进行登录操作,返回code值。
    5 客户端拿到code值后进行token值的换取,这个完全遵照oauth2.0的协议来走的,后续每次请求必须带上token,token值在服务端的时间比较久,因为我们想要做的是那种永不下线的操作,所以每次请求我们都将token过期时间进行累加。

    数据库设计
    用户基础表(users):

    字段 备注
    user_id 用户id
    token 用户登陆的token
    expire_in token过期时间
    try_times 登录失败次数

    用户验证关联表(user_auth_rel)

    字段 备注
    id 自增id
    user_id 用户id
    token 用户登陆的token
    auth_id 验证表id
    auth_type 验证类型(local、third)

    本地用户表(user_local_auth)

    字段 备注
    auth_id 认证id,自增id
    user_name 用户唯一标识
    password 密码
    mobile 用户手机
    user_name 用户唯一标识

    第三方用户表(user_third_auth)

    字段 备注
    auth_id
    openid 第三方用户唯一标识
    login_type 第三方平台标识(qq、wechat…)
    access_token 第三方获取的access_token,校验使用

    说明
    users表只是单纯针对我们业务侧的登录,主要是做自身业务的oauth2.0业务,
    user_local_auth是做自己用户名、密码登录,手机号码登录信息记录,
    user_third_auth是我们第三方用户体系的数据记录,
    user_auth_rel是用来关联我们users表与user_local_auth、user_third_auth。
    整个设计理念就是将自建用户与第三方在存储上区分,这在架构演进上也是合乎情理的,开始用户体系大多自建,而后才是对外接入。

    总结

    总的来讲,第三方用户的接入技术上来讲是比较简单的,这里设计多一个user_thirds是可以支持足够多的第三方接入,当然一般我们也就两三个登录就好,太多登录方不仅自身维护成本,界面摆盘也不好看不是。
    希望大家能够通过以上学习,能够对于我们多账户登录有一个比较好的认知,这里设计方案不包含分表分库、没有服务化,就是简单直接的设计,当然用户量和需要的不一样,在这个基础上还要加很多东西!!!

    展开全文
  • 设计数据库

    2019-10-12 16:56:58
    什么是数据库设计:设计出具有关系的数据,然后把这些数据通过数据库的表来存储它。 怎么去设计数据库,我们首先要学习E-R模型 数据库的三种关系 一对一(eg:用户与指纹) 一对多、多对一 多对多(eg:运动员和...

    设计数据库

    • 什么是数据库设计:设计出具有关系的数据,然后把这些数据通过数据库的表来存储它。
    • 怎么去设计数据库,我们首先要学习E-R模型

    数据库的三种关系

    • 一对一(eg:用户与指纹)
    • 一对多、多对一
    • 多对多(eg:运动员和比赛项目)

    例如:现在存储用户信息,然后此用户信息下面有很多游戏账号

    1.     先要找出有哪些数据对象(就是有哪些数据需要让数据库来存储)
    2.     然后再去判断这些数据对象之间的关系
    3.     用户与游戏账号,体现一对多的关系
    4.      创建用户表和游戏账号表
    

    设计数据库的步骤

    • 软件项目开发的需求分析

    • 学会判断有哪些数据对象,他们之间关系是什么

    • 创建E-R模型

    • 将E-R模型转换成物理模型

    • 将物理模型转换为数据库

      E-R模型

    • 体现设计数据库的思路
      
    • E-R模型,数据库的建模,是一种抽象的 思维方式去想数据库怎么设计
      
    • E-R模型有几个组成部分

    • 实体:数据对象

    • 属性:一个实体应该包含哪些属性

    • 关系:实体与实体之间的关系,体现出要么一对一,要么一对多,要么多对多

    例如:现在存储用户数据,然后此用户信息下面有很多游戏账号

    在这里插入图片描述

    任务:设计一个奥运会的数据库

    • 对象:国家、运动员、比赛项目、裁判
    • 关系:国家 vs 运动员(1 :n)、运动员 vs 比赛项目(n :m)、裁判 vs 比赛项目(n :m)

    在这里插入图片描述

    数据库工具

    • PowerDesigner工具
    • 就可以将E-R模型在工具中进行描述
    • 此工具可以生成数据库的脚本(SQL语句)

    如何使用PowerDesigner

    • 创建模型(物理模型,不要去创建概念模型)
    • 设计表的同时要学会建立关系
    • 完成数据库脚本的生成

    在这里插入图片描述

    在这里插入图片描述

    • 设计表的同时学会建立关系

    在这里插入图片描述
    在这里插入图片描述在这里插入图片描述

    在这里插入图片描述
    从子表往父表拉

    • 完成数据库脚本的生成

    在这里插入图片描述在这里插入图片描述在这里插入图片描述

    注意事项

    • 使用PowerDesigner工具建表的时候,一定要给创建的表加入一个主键(某一列存储的值是位移且不能为空的)
    • 如果没有给创建的表添加主键,则PowerDesigner生成脚本时会报错
    • 如果你要给表建立关系一定要创建一个主键
    展开全文
  • 专题图编号:ylbtechASPNET 1,功能描述 ver1.0 QQ多账号登录。两种账号形式,1,数字;...3,数据库设计 3.1 /App_Data/basic-sql.sql -- ============================================= -- 多账号登录 -- au...
  • 图书管理系统数据库设计 一系统概述 1系统介绍 图书管理是每个图书馆全部需要进行工作一个设计良好图书管理系统数据库能够给图书管理带来很大便利 2需求分析 图书管理系统需求定义为 1.学生能够直接经过借阅终端来...
  • Mysql数据库设计规范

    2018-09-26 15:24:00
    mysql数据库设计规范 命令规范 所有数据库对象的名称必须使用小写字母并用下划线分割 所有 数据对象的名称禁止使用mysql保留的关键字 关键字: https://dev.mysql.com/doc/refman/5.7/en/keywords.html 数据酷对象的...
  • 客户管理系统之数据库设计

    千次阅读 2015-05-20 19:33:44
    客户管理系统的数据库设计使用SQL Server 2008数据库开发,客户管理系统(Customermanagement)一共包含七个表,下面一一介绍:  一,存储管理员账号和密码的manager表    存储管理员账号和密码的manager表...
  • 点餐系统——数据库设计

    万次阅读 2017-12-08 14:04:28
    一、 数据库设计 1.用户表         字段 字段类型 字段描述 备注 U_ID Int   主键、自增 U_LoginID Varchar(20) ...
  • 关于MySQL私有云平台的方案设计,最从开始要基于RDS的设计方式到现在的迭代,其实还是走过了一段旅程,也算是比较坎坷,我来总结一些思路。1.首先是实例的概念解释:通常和业务所说的实例和数据库的实例有一些差别,...
  • 数据库拼接设计

    2014-07-26 22:17:05
    在现有数据库设计上,多人协作,不同账号
  • 数据库设计规范 逻辑设计 ->物理设计 实际工作中: 逻辑设计+物理设计 物理设计 表名 字段名 字段类型 数据库命名规范 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库...
  • 数据库操作行为规范 1.超100万行的批量写操作,要分批多次进行操作 2.对大表数据结构的修改一定要谨慎 3.禁止为程序使用的账号赋予super权限 ... 4对于程序连接数据库账号,遵循权限最小原则
  • 数据库课程设计

    千次阅读 2018-09-23 09:38:02
    假期刚回来就迎来一份数据库设计,好不容易花两个星期写完了,老师竟然说一个题目不能超过三个人,逼着我把需求给改了,难受的一匹 下面粘一下课设 资源下载地址 不知道为啥下载要一个积分,将就着看吧,没积分注册...
  • 在社交类系统中,用户与用户的好友关系的设计必不可少,那么如何设计好友的数据库至关重要,本篇文章带大家学习一下相关的设计方案。 基础分析 第一步,有一张用户表,表内包含用户的基本信息,比如账号、姓名...
  • 目录 ​​​​​​​​​​​账号 数值函数 字符函数 ...这里用户sys的权限是非常高的,可以打开关闭oracle数据库,它的权限是高于其他用户的(其他用户信息肯定保存在oracle数据库中) 数值函数 每...
  • 一、数据库设计仿QQ数据库一共包括5张数据表,每张数据表结构如下:1、 tb_User(用户信息表)这张表主要用来存储用户的好友关系与信息字段名数据类型是否Null值默认值绑定描述IDint否用户账号PwdVarchar(50)否用户...
  • 多账户的统一登录名称解释内容架构演进创业初期用户名密码注册登陆手机号注册登陆数据库设计引入第三方账户方案数据库设计总结 多账户的统一登录 名称解释 这里的多账户区别于系统级别的,我们讲的多账户系统是指,...
  • 图书管理系统数据库设计 一系统概述 1系统介绍 图书管理是每个图书馆全部需要进行工作一个设计良好图书管理系统数据库能够给图书管理带来很大便利 2需求分析 图书管理系统需求定义为 1.学生能够直接经过借阅终端来...
  • 图书管理系统数据库设计 一系统概述 1系统简介 图书管理是每个图书馆都需要进行的工作 一个设计良好的图书管理系统数据库能够给图书管理带来很大的便利 2需求分析 图书管理系统的需求定义为 学生可以直接通过借阅...
  • 1.一个学校每个年级都有一个课外的活动(是学生去获取年级的徽章的活动) 2.一个年级有很多自己的徽章,然后学生进入系统注册账号,找到自己所在年级进去查看该年级可以获得的...******请问这个数据库怎么设计比较好
  • 图书管理系统数据库设计 一系统概述 1系统简介 图书管理是每个图书馆都需要进行的工作 一个设计良好的图书管理系统数据库能够给图书 管理带来很大的便利 2需求分析 图书管理系统的需求定义为 1.学生可以直接通过借阅...
  • 图书管理系统数据库设计 一系统概述 1系统简介 图书管理是每个图书馆都需要进行的工作 一个设计良好的图书管理系统数据库能够给图书 管理带来很大的便利 2需求分析 图书管理系统的需求定义为 1.学生可以直接通过借阅...
  • 言简意赅远见卓识望君采纳谢谢删除水印可编辑页眉选中水印点击删除 图书管理系统数据库设计 一系统概述 1系统简介 图书管理是每个图书馆都需要进行的工作 一个设计良好的图书管理系统数据库能够给图书管理带来很大的...
  • 本文档旨在详细描述学生就业管理信息系统中的数据库结构与设计。本文的读者可为学生就业管理信息系统的开发者,也可以是学生就业管理信息系统的维护都。 (二)项目背景: 当前网站信息建设进程中,各种各样的应用...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,427
精华内容 570
关键字:

数据库设计账号