建议：系统操作日志做到数据库中

日常使用操作日志，目前默认是另存到Excel中，随着使用量变大无分割文件和文件过大打开、筛选等不是很理想。特建议如下：1、操作日志可以做到数据库中，
2、导出日志，
   2.1 手动导出：（根据日志条数提示用户，管理员自行导出）。
   2.2 自动导出：按照管理员给定周期导出文件到Excel
3、开发人员可以根据日志进行过滤等具体报表操作，检索用户操作上的异常现象。
如：开发时未测试出来某些用户可以对数据库修改操作， 用户发现此问题未提交到开发。
4、可以在用活字格加工此数据，进行分析等等



以上建议希望可以采纳，为谢！

Simon.hu 发表于 2019-6-14 17:59
这个不是在纠结呢，因为一般日志最好不要跟业务数据的数据放到一起啊~

为啥不能放在业务数据库中？有用户登入退出，对数据表增删改记录就行了。

Simon.hu 发表于 2019-5-21 13:40
第2个应该可以，（2.报错事件）

后面的2个，我还是不同，跟踪啥意思，咋跟踪？

上面说的报错事件，应该是程序运行报错日志。比如，发布的程序，客户使用有时候出一些错误，能快速追踪到问题。
我目前主要是要那些用户登录了系统，都做了些什么操作。比如操作了那些表，对这些表做了那些增删改查，什么时间做的。起一个追溯作用。并且能够通过活字格在此加工得到自己想要的问题。

日志包括：
什么信息比较合适，目前只包含了数据库的增删改查，您还需要别的吗？

Simon.hu 发表于 2019-5-21 10:38
日志包括：
什么信息比较合适，目前只包含了数据库的增删改查，您还需要别的吗？

这些信息放至数据库方便查询与追溯点击事件
2.报错事件
3.查询与跟踪事件（追溯问题）
3.BUG记录事件

第2个应该可以，（2.报错事件）

后面的2个，我还是不同，跟踪啥意思，咋跟踪？
bug记录啥呢？

pathping 发表于 2019-5-22 19:52
上面说的报错事件，应该是程序运行报错日志。比如，发布的程序，客户使用有时候出一些错误，能快速追踪到 ...

这个想法我也是同意的 建议分离业务数据与事件业务的数据库  ！能支持设置一个远程日志数据库不要放到业务数据库里面！

mfkpie8 发表于 2019-5-26 15:14
这个想法我也是同意的 建议分离业务数据与事件业务的数据库  ！能支持设置一个远程日志数据库不要放到业 ...

目前这个是在服务器的一个日志文件中的

不过似乎一般而言，业务数据库和错误日志要不要放在一起，是仁者见仁智者见智。

做进数据库是一直以来的需求
：》

cg6207 发表于 2019-6-14 11:45
做进数据库是一直以来的需求
：》

这个不是在纠结呢，因为一般日志最好不要跟业务数据的数据放到一起啊~