MayBe_you
- 浏览: 3565 次
- 性别:
- 来自: 上海
-
最新评论
文章列表
越简单，越清晰；
越执着，越恒久；
付出越多，得到越多？ 失去越少！
学会反省，学会自控，学会计划。
最近都干了什么？
1.有空没空玩手游，还花了30块钱，明知道没破解的游戏不花钱肯定玩不下去有必要还继续玩吗？
2.有事没事折腾一些毫无目的性的环境和工具，装好了干嘛了？
3.对于之前想改变的想法仍旧没有拿出具体的计划，还是靠头脑记忆，头脑能一直记住吗？
4.对于短期工作和生活的目标不清晰，最近要干嘛？学习啥？去哪儿玩？有计划吗
5.对于生活里的成分自己不敢承担责任，每天晚上不敢面对想玩游戏的内心。等着他们叫上我一起，他们睡了我就睡了，他们说完我就继续玩。玩了自己的计划是不是会被打乱？为什么下 ...
最近状态不是很好，本想在这里噼里啪啦一顿。
转念想了想，毕竟生活，为什么要跟工作一样想得那么因果必然？
在此只想简简单单的留下几个词语，他日看到后能延伸开来即可。
责任
信任
淡定
诚实
现实
恒心
。。。
po是持久化对象，对应数据库表；
vo是指值对象，在业务逻辑层之间可以独立出来的对象。
本文主要是基于跟DBA往来邮件中内容以及实际开发过程中的经历，用文字记录一下设计开发感悟。
1.设计数据库之前一定要对业务了如指掌，任何业务的边边角角都要读到，杜绝出现业务盲区；
2.需求本身的不确定不能影响数据库设计本身，即数据库设计必须最低满足3范式等一些数据库设计本身的一些基本约束；
3.字段类型长度选择定论应该以业务的可拓展为目标，例如数据字典树结构数据(000000,000100,010101)建议存成varchar类型，varchar类型数据无论在数据库还是在代码里都可以做截取操作；
4.数据库表除了物理主键外，最好设置一个业务主键，外键由业务主键充当，当然建议是主表才这么做；
5. ...
最近参与了公司一次的技术分享会（侧重开发经验和实战演示），在准备阶段个人觉得相对于前几期纯理论的分享，我这次分享应该会有不一样的效果。结果还是不尽人愿，。
事后分析了一下，归纳为以下几点感悟：
1、分享内容过多，篇幅较长。由于分享会是有时间限制的，以至到了会议后期为了完成分享目标而牺牲了分享质量。内容越多，对自身知识要求越高，暴漏问题的几率越大。
2、没有权衡好整体听众的技术水平，分享内容太专业也未必是好事。
3、准备时间太短，自信心不足，导致语气语调不响亮，无法满足分享的讲师要求。
4、缺乏培训分享经验，对话题切入时机和氛围营造手段经验不足。
幸运的是，公司高层和其他同事 ...
自己不算是一个合格数据库使用者，但是却参与了很重要的数据库设计过程，然而开发后期却一直在维护数据库，从而导致代码层面出现因数据库变更导致的系统问题。个人觉得后期我所做的数据库维护是必须的，因为从逻辑上讲之前的表设计不合理；但是我却忽略了变更会带来的风险，由此我一直在思考。开发到一定阶段，表该不该轻易变动？能否轻易改动表？代码层面和数据库设计层面有没有办法能屏蔽数据库变更造成的影响？
先说说开发后期表该不该改？
从重构思想的角度来讲，有错就得改，系统数据库就该不断重构优化，那么改和维护是可以的和必须的。
既然后期变更一定会存在，那如何降低数据库变更对代码层面造成的影响？如何降低表变更对系统带来 ...