实现功能:
1.用户管理
(1).管理员
添加:
更改:
删除: 逻辑是删除,不让登录,为得是不破坏账目记录
(2).普通用户
更改: 登录名,姓名,密码等等
2.类别管理
(1).大类管理
添加:
更改:
删除: 有帐目记录的不能删除,只能修改
排序: 为了输入的方便,地时要适当的人性化
(2).小类管理: 附属于大类
添加:
更改:
删除: 有帐目记录的不能删除,只能修改
3.帐目管理
(1).收入
添加: ①没有日账,要先添加日账;②有日账,在其下添加明细帐.最好有备注或是日记
更改:
删除: 删除前要确认
(2).支出
添加: ①没有日账,要先添加日账;②有日账,在其下添加明细帐.最好有备注或是日记
更改:
删除: 删除前要确认
4.节日管理
添加:
更改:
删除: 有帐目记录的不能删除,只能修改
5.分析统计
查看: 根据不同的要求,出现不同统计表,可以以文档的形式保存
6.系统管理
备份: 数据库的备份
其它: 隐喻
关系数据库 :
先简要地设计了七张表,先暂不考虑权限,多语言,
[USER用户] 登录后方可以记录
[TOTAL总帐] 总的已收帐 已负账 资产 现金 银行款 基金
[BIGCLASS大类] 衣食住行消费类和收入分类
[SMALLCLASS小类]大类下的小类
[GALA特殊节日] 周末 法定假日 特殊节日等 (用于分析,更高地说就是加了一个时间维度)
[LIST日账] 每日收支
[ITEM日账明细] 每日收支明细
本设计的主键只用来表示关系,不含有现实意义,所有主键全是bigint 绝对够用了吧 人能活100岁 每天买1000件东西,一年365天
1000*100*365=? 当然这是简要的设计,其实我要做的并不是记录工作,记录是为了更好地分析,然后怎样去收支。
存在问题:
(1)收入和支出是不是要再关联到个人
(2)总帐是不是又要分出个人
关系图 :
图有点错误:
(1)USER表里少一个字段USER_LEVEL
(2)ITEM里少了一个LIST_NO
(3)应该是LIST_NO和LIST里的LIST_NO对应)
1.用户管理
(1).管理员
添加:
更改:
删除: 逻辑是删除,不让登录,为得是不破坏账目记录
(2).普通用户
更改: 登录名,姓名,密码等等
2.类别管理
(1).大类管理
添加:
更改:
删除: 有帐目记录的不能删除,只能修改
排序: 为了输入的方便,地时要适当的人性化
(2).小类管理: 附属于大类
添加:
更改:
删除: 有帐目记录的不能删除,只能修改
3.帐目管理
(1).收入
添加: ①没有日账,要先添加日账;②有日账,在其下添加明细帐.最好有备注或是日记
更改:
删除: 删除前要确认
(2).支出
添加: ①没有日账,要先添加日账;②有日账,在其下添加明细帐.最好有备注或是日记
更改:
删除: 删除前要确认
4.节日管理
添加:
更改:
删除: 有帐目记录的不能删除,只能修改
5.分析统计
查看: 根据不同的要求,出现不同统计表,可以以文档的形式保存
6.系统管理
备份: 数据库的备份
其它: 隐喻
关系数据库 :
先简要地设计了七张表,先暂不考虑权限,多语言,
[USER用户] 登录后方可以记录
[TOTAL总帐] 总的已收帐 已负账 资产 现金 银行款 基金
[BIGCLASS大类] 衣食住行消费类和收入分类
[SMALLCLASS小类]大类下的小类
[GALA特殊节日] 周末 法定假日 特殊节日等 (用于分析,更高地说就是加了一个时间维度)
[LIST日账] 每日收支
[ITEM日账明细] 每日收支明细
本设计的主键只用来表示关系,不含有现实意义,所有主键全是bigint 绝对够用了吧 人能活100岁 每天买1000件东西,一年365天
1000*100*365=? 当然这是简要的设计,其实我要做的并不是记录工作,记录是为了更好地分析,然后怎样去收支。
存在问题:
(1)收入和支出是不是要再关联到个人
(2)总帐是不是又要分出个人
关系图 :
图有点错误:
(1)USER表里少一个字段USER_LEVEL
(2)ITEM里少了一个LIST_NO
(3)应该是LIST_NO和LIST里的LIST_NO对应)
![](https://i-blog.csdnimg.cn/blog_migrate/5588623f24119678b7872a9950265668.jpeg)