数据库思考和推测

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据库思考和推测相关的知识,希望对你有一定的参考价值。

  软件还真不是一条好走的路,具体到细节各部分好让人头大。前端稍微清晰一点以后,想到数据库的使用让人不好理清。

  按道理说,数据库就是一种比较容易存储和读取的文件格式,就像txt格式一样,再加上一些加密处理。具体到内部的划分。一个数据库的可伸缩性,还有一个数据库所代表的模块、所表现的内部堆栈处理逻辑。自己没有见到过,于是也不容易设想,大体的倒是知道。

  如果可以的话,给每个用户建立一个数据库,这样每次登陆相应的数据库查找东西就可以了,不用那么都都挤在一个表中。挤在一个表中的好处是方便使用,就像不管什么东西都放在这个架子上,用起来就比较方便,也必然会影响速度。如果按照逻辑来分数据库和表还有表内的字段的话,就有些费事了。

  分表,分字段,分数据库连接。每当连接的时候各种网站都基本上、自己看到的一些小型网站基本上就用一个数据库了,直接一个登录名、密码登录到一个数据库上,所有的东西都在里边操作。也不知道这种登录的时间规划怎样,可是既然是个库级别,自然比表级别或者字段级别涉及到的东西多了一些。库一个连接单位,一般和一个库建立连接之后,再进行创建对话,用“对话”这个模式访问数据库里的内容。如果把用户分到库级别,那么每个用户在使用数据库的时候都要各自建立一个连线。库是默认连线吧,或者有别的自己没有使用过。

  以前看到的那个网站内部都是写在同一张表中,很多字段都写在上边。是个小网站,这样写其实是可以的,比较方便提取数据。当时郁闷了很久,本来想看一下数据库分级逻辑的,结果每一个应用快都直接放到一个表格里去了。

  关联查询是一种总比较费事的查询吧,查到字段了之后还要通过关联键匹配到另一个表再另一个表等,这样遍历是很多的。如果是短数据,也就是字段数量、字段内容比较少的话,就比较容易遍历吧。这样就考虑到了一些“高效建库”。

  分级是好的处理方式,比如用户名、密码。用户名在一个表,用户名、密码一个表,再一个表放用户的一些字段信息。三张表的第一ID序列都用同一个。突然想起oracle可以建立检索key并且给多个表使用,这样就像连接起来多个表一样了,就像把多个表用统一ID序列写进一个表里一样,区分大概是,明确出来确定的高频查询区域。不对,那个是自动增长序列的应用,应该没有把ID序列共用的,共用了也没什么功能,毕竟,已经排序好了的ID,从一个表到另一个表最大的方便从有序ID中就可以直接得到。倒是自动增长字段的独自建立也是好奇怪。

  表面审核用户是否存在,拿着存在的序列ID去直接照到用户名、密码再次匹配,匹配完后拿着序列ID2去取数据。为了确保这两次操作有意义,之后不再重复验证操作,那么在第二次操作之后应该给予用户一个可以去数据的权限。也就是ID2和权限同时存在才可以取到数据。那么如果用另一个用户得到权限,随机编一个ID2可能就得到别的用户的权限了。

  到具体问题的时候,站在问题角度去分析问题有时候不好弄。站在需求角度分析问题会比较好一点。安全级别一直是向上提的,以往或者生活中的,安全不是绝对的,是在一定范围内安全。数字角度和需求角度像是两种不同极端,数字角度展开问题要很大力气,的出来的不一定用得到;需求角度分析出来的不容易用代码实现出来同样的功能,毕竟代码和现实的“建墙”逻辑是不一样的,纯按需求写会有很多逻辑漏洞可以钻。

  在算法的时候总觉得可以有一种能脚踏地的算法。就像冒泡排序或者二分法有序查找,是可以提高效率的。忽然想起来二分法好像在数据库中用不到,如果是无序就需要全部遍历,如果是有序就直接能找到。如果是有序的无序倒是可以,比如说一排用户名,每当用户存进用户名之后,都对用户名进行排序,当来检索用户名的时候....好像还是用不到二分法,直接用过滤法要比二分还要快吧,特别是后期数据比较大,来回跳也比较累。所以我没找到二分的用处。

  提到脚踏地的算法,就是算法比较直接,能让人觉得比较踏实。另外一种,像MD5这种加密算法,随机函数,这些都是比较飘的内容,实现了一些人为的判断逻辑,那些逻辑本身就不严谨,所以写出来也比较飘,成了一种数学问题。

  加密算法,算是生活中不经常见到的东西,一些内容存储到数据库用这个的话还是有点用处。加密算法意思就是一端进入,另一端出来后这个过程不可逆,而且要少占系统运算之类。随机算法就是根据时间来,毫秒数之类,不然计算机里也没有别的变动数可以取。所以在方法实现本身上就存在数学逻辑上的漏洞,让人用起来不舒服,底层不透彻的感觉。

  加密的目的是在不知道密码的情况下,连写代码的人都不知道密码是什么,加密生成的字段想要翻译回去就要找到加密过程,所以每个加密算法应该算是个黑盒子吧。不是破解不了,是破解起来太费事,一般人懒得去破解。只要足够麻烦、可以阻碍别人去做就可以了。太简单了像新浪那样用户名、密码被偷了之后直接能看到,也不是很好的事。如果加密了之后,或许还被解密了出来,可是那时候。。。

  想起之前那个小网站,两次MD5进行加密,中间还有一个密匙 MD5(MD5(密码)*密匙),所以配个密匙,然后加密算法自己弄也是可以的。一般对密码有严格的要求,是因为加密过程只能用那些字母、下划线、数字吧。密匙作为用户数据保存在数据库中。

  也就是增加了攻门的手续,如果对方猜不出来这边的处理方式,就攻不进去了。想要进去,多做一些尝试还是可以预想出来的。

  忽然想起来,以前觉得计算做东西的就可以让逻辑分离,防止人和人之间互通,就像高考改试卷,要把名字部分遮住一样,这样保证每个部门能凭”真本事“进行评价和处理。后来想想这种需求并不是计算机做事的优越性,在生活中也有这种处理,计算机只是把它数字化并没有进一步增强,计算机的用处还是在于计算的高效、保存方便、传输方便之类。

  重要的数据还是要有档案备案的,毕竟对档案的保存已经有很成熟的解决方式,计算机才多少年,硬盘的熟悉度有多少。

  现在的存储设备就是磁盘,旋转存储,向外分布。对于固态硬盘的理解还是有限的,现在固态硬盘比较快一些,也比较贵一些。

  去查一下比较好。

  底层存储,加密算法,查询方式,分字段分表分数据库...

以上是关于数据库思考和推测的主要内容,如果未能解决你的问题,请参考以下文章

Thinkphp 生成订单号小案例

项目笔记之订单号生成规则以及方法,第一篇!

关于样本方差以及样本协方差的一点思考

错误推测法

Hadoop推测任务执行

Hadoop学习19--推测式执行