数据库的层次结构


1、树状结构
在历史上，层次数据库最早出现，将数据库保存为文件中的记录，各种逻辑被嵌套到一起，而没有将同样的记录按照线性排列。层次数据库对某些查询非常适合，但是过强的结构限制了人们对数据的自由操控，后来出现的网络（CODASYL）数据库，虽然灵活了很多，但数据操控仍然很困难，知道关系型理论的出现，才证明的了数据库设计是科学而不是工艺，然而，因为层次模型很有弹性，所以层次结构依然极为常见（至少层次描述非常常见），例如XML和LDAP等层次技术非常活跃，严格的说HTML也算是一种层次存取数据的方式。
层次式数据不太容易理解，比如ERP系统中最基本的物料单，层次结构之所以复杂，主要原因不是因为组件之间的关系表达，而是访问树的方式，我们访问树的部分或全部节点，通常按照顺序返回这些节点，访问树通常由DBMS引擎以过程性方式实现，而过程性操作正是违背关系理论的主要表现之一。
2、树状结构和主从结构
很多人认为“父子关系”和“主从关系”没有什么不同，实际上这两种关系有着很多的不同。
1） 树状结构保存只需要一个表。代表层次结构的树，其所有节点完全相同，叶子节点的类型有时可能不同，例如文件系统中的文件夹和文件节点，如果撇去这点，所有的节点类型完全相同，我们可以用相同的方法描述，而且同一个表来代表节点，换句话说，表与它本身之间有种主从关系，而不是两个类型不同的表关系。
2）深度。层次结构中，与根节点的距离本身是重要的信息，而在主从关系中，不是主表就是明细表。
3）所有权。主从关系中，可以明确的外键完整性约束，例如，每个表中订单必须与另外一张表的已存在的ID对应，但层次结构，比如，虽然比如经理的工号虽然是参照已经存在的员工的工号规则来的，但是经理向老板报告，不跟员工报告，这会导致NULL值问题。
4）多重父节点。以父节点似乎别数据结合子节点，是假设一个子节点只有一个父节点，实际上生活中，很多情况下都不是这样，比如机械零件和螺丝钉，那就不是树了，父子关系就无能为力了。
其实某位大牛曾经说过：从关系理论角度去理解树的结构，树有两种实体类型，一个是节点，另一个是节点之间的连接。这样的设计世界上是解决了完整性约束的的问题，因为只有实际存在连结的节点才能被描述。这种描述实际上最后能描出一个图来，也就是能解决一个子节点对应多个父节点的问题。
DBMS厂商常常实现了空间数据处理或全文索引等特殊功能，但对层次结构的支持很薄弱或者根本没有。
处理层次结构的主要困难在于树的访问，当然仅仅为了在图形用户界面中显示树状结构，每次用户点击将树展开并没有什么问题

mysql root帐号丢失解决办法


一.windows系统的解决方法
1.首先以系统管理员身份登陆系统。
2.停止MySQL的服务。
3.进入命令窗口，然后进入MySQL的安装目录，比如我的安装目录是c:\mysql,进入C:\mysql\bin
4.跳过权限检查启动MySQL，c:\mysql\bin>;mysqld-nt –skip-grant-tables
(或者将–skip-grant-tables写入my.ini中，重新启动Mysql，即可设置新密码)。
5.重新打开一个窗口，进入c:\mysql\bin目录，设置root的新密码
c:\mysql\bin>mysqladmin -u root flush-privileges password “newpassword”
c:\mysql\bin>mysqladmin -u root -p shutdown
将newpassword替换为你要用的root的密码，第二个命令会提示你输入新密码，重复第一个命令输入的密码。
6.停止MySQL Server，用正常模式启动Mysql
7．你可以用新的密码链接到Mysql了。
二.Unix/Linux的解决方法
1.用root或者运行mysqld的用户登录系统；
2．利用kill命令结束掉mysqld的进程；
3．使用–skip-grant-tables参数启动MySQL Server
shell>mysqld_safe –skip-grant-tables &
4.为root@localhost设置新密码
shell>mysqladmin -u root flush-privileges password “newpassword”
5．重启MySQL Server

MySQL视图介绍


一． 视图概述
视图是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。
对其中所引用的基础表来说，视图的作用类似于筛选。定义视图的筛选可以来自当前或其它数据库的一个或多个表，或者其它视图。通过视图进行查询没有任何限制，通过它们进行数据修改时的限制也很少。
视图是存储在数据库中的查询的SQL 语句，它主要出于两种原因：安全原因， 视图可以隐藏一些数据，如：社会保险基金表，可以用视图只显示姓名，地址，而不显示社会保险号和工资数等，另一原因是可使复杂的查询易于理解和使用。
　　视图：查看图形或文档的方式。
　　视图是从一个或多个表或视图中导出的表，其结构和数据是建立在对表的查询基础上的。和表一样，视图也是包括几个被定义的数据列和多个数据行，但就本质而言这些数据列和数据行来源于其所引用的表。
　　所以视图不是真实存在的基础表而是一张虚表，视图所对应的数据并不实际地以视图结构存储在数据库中，而是存储在视图所引用的表中。
　　视图一经定义便存储在数据库中，与其相对应的数据并没有像表那样又在数据库中再存储一份，通过视图看到的数据只是存放在基本表中的数据。对视图的操作与对表的操作一样，可以对其进行查询、修改(有一定的限制)、删除。
　　当对通过视图看到的数据进行修改时，相应的基本表的数据也要发生变化，同时，若基本表的数据发生变化，则这种变化也可以自动地反映到视图中。
　　视图有很多优点，主要表现在：
　　•视点集中
　　•简化操作
　　•定制数据
　　•合并分割数据
　　•安全性
当然视图也存在一些缺点，最大的缺点就是视图带来的更新负担，比如源数据改了，那么视图中要做相应更新，视图中数据改了源数据也要做同步，这和MySQL的Cache差不多。
二． 创建视图——CREATE VIEW
1. 语法
CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] VIEW [db_name.]view_name [(column_list)] AS select_statement [WITH [CASCADED | LOCAL] CHECK OPTION]通过该语句可以创建视图，若给定了[OR REPLACE]，则表示当已具有同名的视图时，将覆盖原视图。select_statement是一个查询语句，这个查询语句可从表或其它的视图中查询。视图属于数据库，因此需要指定数据库的名称，若未指定时，表示在当前的数据库创建新视图。
表和数据库共享数据库中相同的名称空间，因此，数据库不能包含相同名称的表和视图，并且，视图的列名也不能重复。
2. 使用举例
Eg. 本例创建一个产品表（product）和一个购买记录表（purchase），再通过视图purchase_detail查询出购买的详细信息。
CREATE TABLE product
(
product_id INT NOT NULL,
name VARCHAR(50) NOT [...]

论坛程序设计的思考


新入公司，项目被老同志分的七七八八，系统还没有足够的熟悉，暂时清闲了几天，看了几天的代码，有面向对象的，更多的是面向过程的，这篇博文的title值得商榷的，反正我不知道该取什么名字，姑且唬人一下。
1）设计目标，任何软件都需要一个设计目标，比如目标用户，并发数等等，论坛这个东西实时性很强，同时在线人数一般不高，如果很高的话一般会自己做，或者请公司定制开发或优化。撑死了几千人同时在线，很多论坛的设计目标就是没有目标，看到好的功能和界面，拿过来，改改，堆上去，完事
2）模块划分，市面上的几个论坛软件大多还是沿用了N多年前的架构，面向过程，而且过程不清晰，虽然在用户后台看上去好像各个功能挺独立的，看看代码就知道，里面定义了一堆全局变量，更奇怪的是没有注释，还有好几个是没用的，代码重复率非常高，require来include去，绕啊，绕啊，我就晕了~~，功能模块都没能独立，更没法谈耦合和内聚了~
3）数据库设计，这个挺有意思的，曾经“有幸”阅读过discuz不知道几点几版本的代码，里面的SQL写得令人毛骨悚然，不得不佩服写这个SQL语句程序员的数据库造诣之深，反正我是没写过，也写不出来，我的原则是，能一次查询的不做两次查，能不用jion的就坚决不用，discuz的表有上百个之多，phpwind更是超过150个，且有不断增加之趋势，清一色使用mysql，而且还是用的MYISAM引擎，好吧，1000个并发的时候，discuz 7是挂掉了，phpwind没测试过，暂时不评论。数据表设计时冗余是必要的，不一定非要遵循范式规则，过度随意就成了灾难，我看到数据库中居然有q1,q2,q3一直到q21这样的字段，通通都是int型的，而且绝大部分都是空的，浪费空间之严重令人非常惊讶，且不说这个命名十分之不友好，这个东西能这样做的么，假如真的需要21个同样类型的q这种东西，为啥不再分一张表，然后给个ID连接一下不就好了么，这仅仅是一个例子，N张表都能找到这样的例子。用户表是论坛的核心表之一，论坛有积分啊，签名啊，生日啊，等级啊，权限啊之类之类的，用户属性自然是多之又多，可是再多也不能全放一个表里，一个表里有六七十个属性，这像话么！！绝大部分属性普通用户都是空的，又是一个“占着茅坑不拉屎”的表设计，大部分用户注册时能不填的肯定不会填，就那么昵称啊，email啊，密码啊几个字段需要insert，至于牵动六七十个属性同时更改一遍么，myisam引擎insert是加的是表级锁的啊，郁闷，纵向拆分这张表！
4）错误处理，出错了，前面加个@好了，让别人都看不到就不会有什么问题了，嗯，这个似乎是可以防止因为出错信息而泄漏一些东西，可是总得让自己知道怎么回事啊，不然怎么解决呢，还好都有官方论坛可以去问，大多数时候管理员也不知道用户出了什么问题，只能靠猜，为什么不记录一个log呢？！
5）不想说了~~先把前面的改了再说……

MySQL中索引限制


1) MyISAM存储引擎的索引键长度的总和不能超过1000个字节
2）BLOB 和TEXT类型的列只能创建前缀索引
3）MySQL目前不支持函数索引
4）使用不等于（！=或<>）的时候MySQL无法使用索引
5）过滤字段使用了函数运算（如abs(column)）后，MySQL无法使用索引
6）Join语句中Join条件字段类型不一致的时候，MySQL无法使用索引
7）使用LIKE操作的时候如果条件是以通配符开始（如%ABC）时，MySQL无法使用索引
8）使用非等值查询时候，MySQL无法使用HASH索引