3.3. UDP hole punching UDP打洞技术 The third technique, and the one of primary interest in this document, is widely known as “UDP Hole Punching.” UDP hole punching relies on the properties of common firewalls and cone NATs to allow appropriately designed peer-to-peer applications to “punch holes” through the middlebox and establish direct connectivity with each other, [...]
数据库的层次结构
1、树状结构 在历史上,层次数据库最早出现,将数据库保存为文件中的记录,各种逻辑被嵌套到一起,而没有将同样的记录按照线性排列。层次数据库对某些查询非常适合,但是过强的结构限制了人们对数据的自由操控,后来出现的网络(CODASYL)数据库,虽然灵活了很多,但数据操控仍然很困难,知道关系型理论的出现,才证明的了数据库设计是科学而不是工艺,然而,因为层次模型很有弹性,所以层次结构依然极为常见(至少层次描述非常常见),例如XML和LDAP等层次技术非常活跃,严格的说HTML也算是一种层次存取数据的方式。 层次式数据不太容易理解,比如ERP系统中最基本的物料单,层次结构之所以复杂,主要原因不是因为组件之间的关系表达,而是访问树的方式,我们访问树的部分或全部节点,通常按照顺序返回这些节点,访问树通常由DBMS引擎以过程性方式实现,而过程性操作正是违背关系理论的主要表现之一。 2、树状结构和主从结构 很多人认为“父子关系”和“主从关系”没有什么不同,实际上这两种关系有着很多的不同。 1) 树状结构保存只需要一个表。代表层次结构的树,其所有节点完全相同,叶子节点的类型有时可能不同,例如文件系统中的文件夹和文件节点,如果撇去这点,所有的节点类型完全相同,我们可以用相同的方法描述,而且同一个表来代表节点,换句话说,表与它本身之间有种主从关系,而不是两个类型不同的表关系。 2)深度。层次结构中,与根节点的距离本身是重要的信息,而在主从关系中,不是主表就是明细表。 3)所有权。主从关系中,可以明确的外键完整性约束,例如,每个表中订单必须与另外一张表的已存在的ID对应,但层次结构,比如,虽然比如经理的工号虽然是参照已经存在的员工的工号规则来的,但是经理向老板报告,不跟员工报告,这会导致NULL值问题。 4)多重父节点。以父节点似乎别数据结合子节点,是假设一个子节点只有一个父节点,实际上生活中,很多情况下都不是这样,比如机械零件和螺丝钉,那就不是树了,父子关系就无能为力了。 其实某位大牛曾经说过:从关系理论角度去理解树的结构,树有两种实体类型,一个是节点,另一个是节点之间的连接。这样的设计世界上是解决了完整性约束的的问题,因为只有实际存在连结的节点才能被描述。这种描述实际上最后能描出一个图来,也就是能解决一个子节点对应多个父节点的问题。 DBMS厂商常常实现了空间数据处理或全文索引等特殊功能,但对层次结构的支持很薄弱或者根本没有。 处理层次结构的主要困难在于树的访问,当然仅仅为了在图形用户界面中显示树状结构,每次用户点击将树展开并没有什么问题
代码格式规范的List
《代码大全》是本好书啊,推荐所有有志于改善自己的程序,或者在编码上寻找进一步提高的人应该仔细研究研究。以下是摘抄自《代码大全》第二版中谈到关于怎样的代码格式更适合人类阅读,更能令人愉悦的Check List。对照List进行自检和反省,令人欣慰的是List中80%以上我都做到了,在我的上一个项目中做得比较失败,由于时间的原因,很多注释没有加上,逻辑也不够清晰。在重构中解决,借此反省。 一般问题: 格式化主要是为了展现代码的逻辑结构吗? 2、你的布局方案能统一运行吗? 3、 你的布局方案能让代码易于维护吗? 4、你的布局方案是否有利于代码的可读性? 控制结构的布局 1、你的代码中避免begin-end 或对{}的双重缩进了吗? 2、相邻的块之间用空行分割了吗? 3、对复杂表达式格式化时考虑到可读性吗? 4、对只有一条语句的块布局始终如一吗? 5、case语句与其他控制结构的格式化保持一致了吗? 6、对goto语句格式化是否让其显眼了呢? 还好目前PHP只有5.3以上版本才会有goto 单条语句的布局: 1、为逻辑表达式、数组下标和子程序参数的可读性使用了空格了吗? 2、不完整的语句在行末似乎以明显又错的方式结束吗? 3、后续行按照标准数码缩进了吗? 4、每行顶多只有一条语句吗? 这一点是团队中比较头痛的问题,很多人不按照这个规则来做,结果它成了一种风气 5、所写的每个语句都没有副作用吗? 6、每行顶多只声明一个数据吗? 注释布局: 1、注释与其所注释的代码所尽量相同吗? 2、注释风格便于维护吗? 子程序的布局: 1、你对每个子程序的参数格式化方式便于看懂、修改、注释吗? 2、采用空行分割子程序各部分了吗? 4、文件中子程序用空行清楚分开了吗? 5、在没有更好的组织形式的场合,所有子程序都按字母排列了吗? 这一点我没有做到,没有做到是没有想到这一点,以后编码注意了……