w1100n
This site is best viewed in Google Chrome
wiloon, 7/13/2015 17:06 | Tag:

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。从2010年3月15日起,Redis的开发工作由VMware主持。从2013年5月开始,Redis的开发由Pivotal赞助。redis是一个key-value存储系统。和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash(哈希类型)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上,redis支持各种不同方式的排序。与memcached一样,为了保证效率,数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步。 Redis 是一个高性能的key-value数据库。 redis的出现,很大程度补偿了memcached这类key/value存储的不足,在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang等客户端,使用很方便。[1] Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步,从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制,使得从数据库在任何地方同步树时,可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。 redis的官网地址,非常好记,是redis.io。(特意查了一下,域名后缀io属于国家域名,是british Indian Ocean territory,即英属印度洋领地) 目前,Vmware在资助着redis项目的开发和维护。redis[2] 的作者,叫Salvatore Sanfilippo,来自意大利的西西里岛,现在居住在卡塔尼亚。目前供职于Pivotal公司。他使用的网名是antirez。

wiloon, 6/30/2015 9:38 | Tag:

http://www.2cto.com/database/201208/150620.html   呵呵,花了一个多小时,左右把11g安装折腾好了。其中折腾SQL Developer 花了好长时间,总算搞定了。好了,先总结下安装步骤,希望给后面的童鞋提高安装效率。呵呵。 一、Oracle 下载 注意Oracle分成两个文件,下载完后,将两个文件解压到同一目录下即可。 路径名称中,最好不要出现中文,也不要出现空格等不规则字符。 官方下地址: http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html以下两网址来源此官方下载页网。 win 32位操作系统 下载地址: http://download.oracle.com/otn/nt/oracle11g/112010/win32_11gR2_database_1of2.zip http://download.oracle.com/otn/nt/oracle11g/112010/win32_11gR2_database_2of2.zip win 64位操作系统 下载地址: http://download.oracle.com/otn/nt/oracle11g/112010/win64_11gR2_database_1of2.zip http://download.oracle.com/otn/nt/oracle11g/112010/win64_11gR2_database_2of2.zip 二、Oracle安装 1. 解压缩文件,将两个压缩包一起选择, 鼠标右击 -> 解压文件 如图 \ 2.两者解压到相同的路径中,如图: \ 3. 到相应的解压路径上面,找到可执行安装文件【 setup.exe 】双击安装。如图: \ 4. 安装第一步:配置安全更新,这步可将自己的电子邮件地址填写进去(也可以不填写,只是收到一些没什么用的邮件而已)。取消下面的“我希望通过My Oracle Support接受安全更新(W)”。 … Continue reading

wiloon, 6/28/2015 20:59 | Tag:

http://uule.iteye.com/blog/1109647   脏读、幻读和不可重复读 + 事务隔离级别 博客分类:数据库 需学习 ITeyeBlog.net 丢失更新:两个事务同时更新一行数据,最后一个事务的更新会覆盖掉第一个事务的更新,从而导致第一个事务更新的数据丢失,这是由于没有加锁造成的; 1. 脏读 :脏读就是指当一个事务正在访问数据,并且对数据进行了修改,而这种修改还没有提交到数据库中,这时,另外一个事务也访问这个数据,然后使用了这个数据。 e.g. 1.Mary的原工资为1000, 财务人员将Mary的工资改为了8000(但未提交事务) 2.Mary读取自己的工资 ,发现自己的工资变为了8000,欢天喜地! 3.而财务发现操作有误,回滚了事务,Mary的工资又变为了1000 像这样,Mary记取的工资数8000是一个脏数据。   2. 不可重复读 :是指在一个事务内,多次读同一数据。在这个事务还没有结束时,另外一个事务也访问该同一数据。那么,在第一个事务中的两次读数据之间,由于第二个事务的修改,那么第一个事务两次读到的的数据可能是不一样的。这样在一个事务内两次读到的数据是不一样的,因此称为是不可重复读。 e.g. 1.在事务1中,Mary 读取了自己的工资为1000,操作并没有完成 2.在事务2中,这时财务人员修改了Mary的工资为2000,并提交了事务. 3.在事务1中,Mary 再次读取自己的工资时,工资变为了2000 解决办法:如果只有在修改事务完全提交之后才可以读取数据,则可以避免该问题。   3. 幻读 : 是指当事务不是独立执行时发生的一种现象,例如第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好象发生了幻觉一样。 e.g. 目前工资为1000的员工有10人。 1.事务1,读取所有工资为1000的员工。 2.这时事务2向employee表插入了一条员工记录,工资也为1000 3.事务1再次读取所有工资为1000的员工 … Continue reading

wiloon, 5/14/2015 8:36 | Tag:

http://blog.sina.com.cn/s/blog_6caea8bf0100z9wz.html   通常情况下,建立索引是加快查询速度的有效手段。但索引不是万能的,靠索引并不能实现对所有数据的快速存取。事实上,如果索引策略和数据检索需求严重不符的话,建立索引反而会降低查询性能。因此在实际使用当中,应该充分考虑到索引的开销,包括磁盘空间的开销及处理开销(如资源竞争和加锁)。例如,如果数据频繁的更新或删加,就不宜建立索引。     本文简要讨论一下聚簇索引的特点及其与非聚簇索引的区别。 建立索引: 在SQL语言中,建立聚簇索引使用CREATE INDEX语句,格式为:CREATE CLUSTER INDEX index_name ON table_name(column_name1,column_name2,…); 存储特点: 聚集索引。表数据按照索引的顺序来存储的,也就是说索引项的顺序与表中记录的物理顺序一致。对于聚集索引,叶子结点即存储了真实的数据行,不再有另外单独的数据页。 在一张表上最多只能创建一个聚集索引,因为真实数据的物理顺序只能有一种。 非聚集索引。表数据存储顺序与索引顺序无关。对于非聚集索引,叶结点包含索引字段值及指向数据页数据行的逻辑指针,其行数量与数据表行数据量一致。     总结一下:聚集索引是一种稀疏索引,数据页上一级的索引页存储的是页指针,而不是行指针。而对于非聚集索引,则是密集索引,在数据页的上一级索引页它为每一个数据行存储一条索引记录。 更新表数据 1、向表中插入新数据行    如果一张表没有聚集索引,那么它被称为“堆集”(Heap)。这样的表中的数据行没有特定的顺序,所有的新行将被添加到表的末尾位置。而建立了聚簇索引的数据表则不同:最简单的情况下,插入操作根据索引找到对应的数据页,然后通过挪动已有的记录为新数据腾出空间,最后插入数据。如果数据页已满,则需要拆分数据页,调整索引指针(且如果表还有非聚集索引,还需要更新这些索引指向新的数据页)。而类似于自增列为聚集索引的,数据库系统可能并不拆分数据页,而只是简单的新添数据页。 2、从表中删除数据行     对删除数据行来说:删除行将导致其下方的数据行向上移动以填充删除记录造成的空白。如果删除的行是该数据页中的最后一行,那么该数据页将被回收,相应的索引页中的记录将被删除。对于数据的删除操作,可能导致索引页中仅有一条记录,这时,该记录可能会被移至邻近的索引页中,原索引页将被回收,即所谓的“索引合并”。     稀疏索引 稀疏索引只为数据文件的每个存储块设一个键-指针对,它比稠密索引节省了更多的存储空间,但查找给定值的记录需更多的时间。只有当数据文件是按照某个查找键排序时,在该查找键上建立的稀疏索引才能被使用,而稠密索引则可以应用在任何的查找键。如图3-3所示,稀疏索引只为每个存储块设一个键-指针对。键值是每个数据块中第一个记录的对应值。 例3.3同例3.2一样,我们假定数据文件已排序,且其键值为连续的10的倍数,直至某个较大的数。我们还继续假定每个存储块可存放四个键-指针对。这样,第一个索引存储块中为前四个数据存储块的第一个键值的索引项,它们分别是10、30、50和70。按照前面假定的键值模式,第二个索引存储块中为第五至第八个数据存储块的第一个键值的索引项,它们分别是90、110、130和150。图中我们还列出第三个索引存储块存放的键值,它们分别是假设的第九至第十二个数据存储块的第一个键值。 图3-3 顺序文件上的稀疏索引 在已有稀疏索引的情况下,要找出查找键值为K的记录,我们得在索引中查找到键值小于或等于K的最大键值。由于索引文件已按键排序,我们可以使用二分查找法来定位这个索引项,然后根据它的指针找到相应的数据块。现在我们必须搜索这个数据块以找到键值为K的记录。当然,数据块中必须有足够的格式化信息来标明其中的记录及记录内容,可以采用2.5节和2.7节中的任何技术。   http://book.51cto.com/art/201012/238283.htm

wiloon, 4/27/2015 1:27 | Tag:

database –>schema browse–>my schema –>Tables查看该用户所有的表

wiloon, 3/23/2015 1:37 | Tag:

在实体关系模型中,我们知道有三种关系:一对一、一对多、多http://www.cnblogs.com/studyzy/p/3309782.html 数据库模型设计——关系的实现对多。这只是概念上的关系,但是在真实的关系数据库中,我们只有外键,并没有这三种关系,那么我们就来说一说在关系数据库管理系统中,怎么实现这三种关系。 一对多 这里先讲解一对多,因为这个关系最简单。一对多和多对一是一回事,所以就不再提多对一这个词。一对多的概念是一个对象A会对应多个对象B,而从B的角度看,一个对象B只会对于一个对象A。比如说班级和学生就是一对多关系。一个班级对应多个学生,一个学生只会对于一个班级。 一对多的关系之所以说简单,是因为RDBMS的外键其实就是表示一对多关系。对于一对多关系,我们只需要在“多”的这个表中建立“一”的外键关联即可,而“一”这边的表不需要做任何修改。比如前面说到的班级学生关系。班级表不变,学生表增加班级Id作为外键。 多对多 多对多的关系在数据库设计时比一对一要常见,所以这里先说说多对多。多对多是一个对象A对应多个对象B,从B角度看,一个对象B也会对应多个对象A。比如说学生和课程的关系就是多对多关系。一个学生会学习多门课程,一门课程会有多个学生来选修。 在RDBMS中,必须使用中间表来表示多对多的关系。中间表我们可以分成两种,一种是纯粹表示关系的中间表,一种是表示中间实体的中间表。 纯粹表示关系的中间表很简单,只需要两列:AID和BID,AID以外键关联到A表的主键,BID以外键关联到B表的主键,然后这两个列组成联合主键。这个中间表纯粹是表示多对多关系而存在,在业务上不会有对应的实体与之对应。比如前面提到的学生和课程的关系,如果我们只需要知道哪些学生上哪些课,哪些课有哪些学生选,不需要有更多的信息的情况下,我们就可以建立“学生课程”中间表,里面只有学生ID和课程ID两个字段。 中间实体是在纯粹的中间关系表的基础上,加上了更多的属性,从而形成了一个新的实体。比如前面提到的学生和课程的关系,如果我们需要记录学生选课的时间、学生选择这门课程后的考试成绩,那么我们就像建立一个“选课”实体,该实体具有如下属性: 选课ID,主键 学生ID,与学生表做外键关联 课程ID,与课程表做外键关联 选课时间,DateTime类型 考试成绩,记录选修该课程后考试的最终成绩 这就是一个中间实体,已经完全脱离了普通的多对多关系中间表,而变成一个实体的形式的存在,所以按照前面博客中讲到的主键设计的原则,我们可以单独建立一个选课ID的列作为数据库的主键,该主键本身并没有业务含义。 一对一 一对一概念上是说一个对象A最多对应一个对象B,从B角度看,也是一个对象B最多对应一个对象A。比如说班主任(教师)和班级的关系,一个班主任最多管理一个班级,一个班级也最多只有一个班主任。 一对一的关系在数据库设计中,是使用的最少的关系,因为一般来说,如果两个实体是一对多关系,那么我们也可以把这两个实体合并成一个实体。但是在设计中,我们仍然会遇到两个完全不同的实体,之间存在一对一关系。 一对一的RDBMS实现是在其中的一个表上建立外键指向另一个表,同时在该外键列上建立唯一约束。比如前面说到的班主任和班级关系,我们可以在班级表建立班主任字段,然后再在该字段建立唯一约束。因为每个班都会有班主任,所以班主任字段是不允许为空的。一个教师可以当某个班的班主任,也可以不当任和班的班主任,同时也不可能在班级表的班主任字段上出现两次,所以最多就当一个班的班主任,所以该设计满足需求。 那么我们可不可以反过来,在教师表中建立所管理的班级Id字段,指向班级表,并建立唯一约束呢?除了不满足“每个班必然有一个班主任”这个业务约束外,其他都没有问题。所以如果对于一对一的情况,如果那边必须要求持有另一边,则就在哪边增加外键字段;如果没有要求必须持有一个另一类实体的话,就哪边添加外键列都行。 外键与索引 外键是一种约束,与索引的概念不一样,只是大多数情况下,我们建立外键时,都会在外键列上建立对应的索引。外键的存在会在每一次数据插入、修改时进行约束检查,如果不满足外键约束,则禁止数据的插入或修改,这必然带来一个问题,就是在数据量特别大的情况下,每一次约束检查必然导致性能的下降。索引其实也有类似的问题,索引如果建多了,那么在插入删除修改数据时也要去维护对应的索引,所以索引的存在也会导致数据操作变慢。 不过外键与索引的优点不同,外键只是保证数据的一致性,并不能给系统性能带来任何好处,所以由于外键导致的插入数据变慢会随着数据量的增长而越来越严重。而索引的目的是为了检索数据更快,维护数据时导致的索引数据的变更,对性能的影响不会像外键那样随着数据量增长而变得严重(当然大数量时的索引树维护会比小数据量的索引树维护更麻烦,但至少不是像外键那样)。 出于性能的考虑,如果我们的系统完全由我们开发的程序使用,而不需要提供数据库给其他应用系统写入数据,而且对性能要求较高,那么我们可以考虑在生产环境中不使用外键,只需要建立能够提高性能的索引。由于整个数据库的操作都是由我们开发的程序来完成的,所以我们程序可以在开发过程中做好各方面的一致性检查,保证操作的数据是满足外键约束的,而不需要真正的存在这样一个外键约束。怎么做到这一点呢,首先,我们在建立数据库时有多个脚本,包括创建表、创建初始化数据、创建索引、创建外键等,我们在开发和测试环境中,都把这些脚本运行了,以使开发测试环境中的数据库是完整的,经过大量测试保证应用程序能够维护数据之间的约束的情况下,那么我们在生产时,并不需要运行创建外键这个脚本文件,只需要创建表、初始化数据、创建索引等即可。 【出自博客园深蓝居,转载请注明作者出处】

wiloon, 3/23/2015 1:28 | Tag:

http://www.itokit.com/2012/0512/73913.html 关联映射:一对多/多对一存在最普遍的映射关系,简单来讲就如球员与球队的关系;一对多:从球队角度来说一个球队拥有多个球员 即为一对多多对一:从球员角度来说多个球员属于一个球队 即为多对一数据表间一对多关系如下图:       关联映射:一对一关系就如球队与球队所在地址之间的关系,一支球队仅有一个地址,而一个地址区也仅有一支球队。数据表间一对一关系的表现有两种,一种是外键关联,一种是主键关联。图示如下: 一对一外键关联:                     ———————————————————————————————————- 前言:多对多关系至少需要3个表,我们把一个表叫做主表,一个叫做关系表,另外一个叫做字典表或者副表(字典表是纪录比较少,而且基本稳定的,例如:版块名称;副表是内容比较多,内容变化的,例如)。 按照数据库的增删查改操作,多对多关系的查找都可以用inner join或者 select * from 主表 where id in (select 主表id from 关系表) 1,角色任命型 特点:关系表两外键组合无重复纪录,关系表一般不需要时间字段和主键,有一个表是字典类型的表。 界面特点:显示主表,用checkbox或多选select设置多选关系。 例如:任命版主(用户表-关系表-版块名称表),角色权限控制等,用户是5个版块版主,只要关系表5行纪录就可以确立,关系表的两个外键具有联合主键性质。 增加关系:如果没有组合纪录,insert之。 删除关系:如果有组合纪录,删除之。 … Continue reading

wiloon, 3/4/2015 8:17 | Tag:

http://www.cnblogs.com/tintown/archive/2005/03/02/111459.html 数据库主键设计之思考 在我们的数据库设计中,不可逃避的就是数据库表的主键,可能有很多朋友没有深入思考过,主键的设计对整个数据库的设计影响很大,因此我们不得不要重视起来。 主键的必要性: 有些朋友可能不提倡数据库表必须要主键,但在我的思考中,觉得每个表都应该具有主键,不管是单主键还是双主键,主键的存在就代表着表结构的完整性,表的记录必须得有唯一区分的字段,主键主要是用于其他表的外键关联,本记录的修改与删除,当我们没有主键时,这些操作会变的非常麻烦。 主键的无意义性: 我强调主键不应该具有实际的意义,这可能对于一些朋友来说不太认同,比如订单表吧,会有“订单编号”字段,而这个字段呢在业务实际中本身就是应该具有唯一性,具有唯一标识记录的功能,但我是不推荐采用订单编号字段作为主键的,因为具有实际意义的字段,具有“意义更改”的可能性,比如订单编号在刚开始的时候我们一切顺利,后来客户说“订单可以作废,并重新生成订单,而且订单号要保持原订单号一致”,这样原来的主键就面临危险了。因此,具有唯一性的实际字段也代表可以作为主键。因此,我推荐是新设一个字段专门用为主键,此主键本身在业务逻辑上不体现,不具有实际意义。而这种主键在一定程序增加了复杂度,所以要视实际系统的规模大小而定,对于小项目,以后扩展不会很大的话,也查允许用实际唯一的字段作主键的。 主键的选择 我们现在在思考一下,应该采用什么来作表的主键比较合理,申明一下,主键的设计没有一个定论,各人有各人的方法,哪怕同一个,在不同的项目中,也会采用不同的主键设计原则。 第一:编号作主键 此方法就是采用实际业务中的唯一字段的“编号”作为主键设计,这在小型的项目中是推荐这样做的,因为这可以使项目比较简单化,但在使用中却可能带来一些麻烦,比如要进行“编号修改”时,可能要涉及到很多相关联的其他表,就象黎叔说的“后果很严重”;还有就是上面提到的“业务要求允许编号重复时”,我们再那么先知,都无法知道业务将会修改成什么? 第二:自动编号主键 这种方法也是很多朋友在使用的,就是新建一个ID字段,自动增长,非常方便也满足主键的原则,优点是:数据库自动编号,速度快,而且是增量增长,聚集型主键按顺序存放,对于检索非常有利;数字型的,占用空间小,易排序,在程序中传递也方便;如果通过非系统增加记录(比如手动录入,或是用其他工具直接在表里插入新记录,或老系统数据导入)时,非常方便,不用担心主键重复问题。 缺点:其实缺点也就是来自其优点,就是因为自动增长,在手动要插入指定ID的记录时会显得麻烦,尤其是当系统与其他系统集成时,需要数据导入时,很难保证原系统的ID不发生主键冲突(前提是老系统也是数字型的);如果其他系统主键不是数字型那就麻烦更大了,会导致修改主键数据类型了,这也会导致其他相关表的修改,后果同样很严重;就算其他系统也是数字型的,在导入时,为了区分新老数据,可能想在老数据主键前统一加一个“o”(old)来表示这是老数据,那么自动增长的数字型又面临一个挑战。 第三:Max加一 由于自动编号存在那些问题,所以有些朋友就采用自己生成,同样是数字型的,只是把自动增长去掉了,采用在Insert时,读取Max值后加一,这种方法可以避免自动编号的问题,但也存在一个效率问题,如果记录非常大的话,那么Max()也会影响效率的;更严重的是并发性问题,如果同时有两人读到相同的Max后,加一后插入的ID值会重复,这已经是有经验教训的了。 第四:自制加一 考虑Max加一的效率后,有人采用自制加一,也就是建一个特别的表,字段为:表名,当前序列值。这样在往表中插入值时,先从此表中找到相应表的最大值后加一,进行插入,有人可能发现,也可能会存在并发处理,这个并发处理,我们可以采用lock线程的方式来避免,在生成此值的时,先Lock,取到值以后,再unLock出来,这样不会有两人同时生成了。这比Max加一的速度要快多了。但同样存在一个问题:在与其他系统集成时,脱离了系统中的生成方法后,很麻烦保证自制表中的最大值与导入后的保持一致,而且数字型都存在上面讲到的“o”老数据的导入问题。因此在“自制加一”中可以把主键设为字符型的。字符型的自制加一我倒是蛮推荐的,应该字符型主键可以应付很多我们意想不到的情况。 第五:GUID主键 目前一个比较好的主键是采用GUID,当然我是推荐主键还是字符型的,但值由GUID生成,GUID是可以自动生成,也可以程序生成,而且键值不可能重复,可以解决系统集成问题,几个系统的GUID值导到一起时,也不会发生重复,就算有“o”老数据也可以区分,而且效率很高,在.NET里可以直接使用System.Guid.NewGuid()进行生成,在SQL里也可以使用 NewID()生成。优点是: 同 IDENTITY 列相比,uniqueidentifier 列可以通过 NewID() 函数提前得知新增加的行 ID,为应用程序的后续处理提供了很大方便。 便于数据库移植,其它数据库中并不一定具有 IDENTITY 列,而 Guid 列可以作为字符型列转换到其它数据库中,同时将应用程序中产生的 GUID 值存入数据库,它不会对原有数据带来影响。 便于数据库初始化,如果应用程序要加载一些初始数据, IDENTITY 列的处理方式就比较麻烦,而 uniqueidentifier 列则无需任何处理,直接用 … Continue reading

wiloon, 5/28/2014 1:49 | Tag:

http://blog.sina.com.cn/s/blog_8020e4110101befz.html 表的主键应当不具有任何业务含义 (2012-12-17 15:10:36)转载▼ 标签: it 分类: DB/SQL 表的主键应当不具有任何业务含义 表通过主键来保证每条记录的唯一性,表的主键应当不具有任何业务含义,因为任何有业务含义的列都有改变的可能性。关系数据库学的最重要的一个理论就是:不要给关键字赋予任何业务意义。假如关键字具有了业务意义,当用户决定改变业务含义,也许他们想要为关键字增加几位数字或把数字改为字母,那么就必须修改相关的关键字。一个表中的主关键字有可能被其他表作为外键。就算是一个简单的改变,譬如在客户号码上增加一位数字,也可能会造成极大的维护上的开销。 为了使表的主键不具有任何业务含义,一种解决方法是使用代理主键,例如为表定义一个不具有任何业务含义的ID字段(也可以叫其他的名字),专门作为表的主键。 ——孙卫琴《精通Hibernate:Java对象持久化技术详解 本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/jackie_lee/archive/2006/08/01/1007948.aspx ======================================= 昨天令狐因为处理动网论坛的数据库时,发现它是用帖子号来作为主键,由于无意中对它作了一些修改,导致帖子的关联变得混乱了。于是我们讨论了一下数据库表中主键的选择问题。因为对动网论坛的程序不熟,所以我也不知道它是怎么设计实现的,今天令狐把JavaEye上的一个关于这个方面的话题拿来讨论就好办了。 我起初也觉得用一个无意义的逻辑主键是一个好办法,至少说用一个字段就可以唯确定一条记录,使用上会很方便,速度应该也会快些。但是看了JavaEye那个帖里的讨论,以及在QQ群里的讨论后,我发现不完全是这样的。 其实这是两种不同的设计思路,谈不上用逻辑主键一定比用业务主键好。 用业务主键是传统的C/S应用开发的思路,包括我现在用的SAP里,也大量使用业务主键。但如果用O/R Mapping,则可能用逻辑主键好一些。 因 为对于传统C/S应用来说,以典型的两层结构看,前端处理的是一个数据表示的工作,后端处理的是一个数据持久化的工作。业务逻辑分散在两端,特别是在后 端。因为需要在后端通过Stored Procedure和View等来实现业务逻辑,应用直接与关系数据库打交道,所以数据的记录不但要求便于程序访问,对开发者来说,还要易读。也就是说需 要数据库的关系逻辑能够清晰地表达出业务逻辑来。主键采用业务主键是自然甚至是必须的。 而ORM应用恰恰相反。它需要一个最简单的 办法来标记一条唯一记录,但不需要有具体的意义,就像在OOP中,我们访问一个Object总是通过指针(或相似的引用),但我们并不需要知道这个指针具 体的值是0x89ABCDEF还是0xFEDCBA98。逻辑主键就相当于一个指针,当别的关联表引用到这条记录时,用一个外键字段记录了这个逻辑主键, 就相当于那个Object中有一个属性记录了一个指向这个Object的指针。这时如果用业务主键–特别是复合业务主键–就是存心给自己打麻烦了。最 糟糕的情况就是当需要修改这个业务主键的值的时候,会导致所有的关联发生混乱–在传统C/S应用中,我们是用Trigger来解决这个问题,但是在 ORM中不可能这样做,否则那还要ORM干什么? 当然,对于开发者来说,在ORM这样的情况下,用逻辑主键存在一个至关重要的问题 就在于数据的可读性将要变差。也就是说,除非通过OO的视角来看数据才是易于理解的。但如果直接进入后端看关系数据库,将变得困难。因此,基本上,逻辑主 键与ORM是相辅相成的,缺一不可,并且采用ORM的开发者要尽可能避免与后端的关系数据打交道,否则就会非常的痛苦。 正如令狐所作的总结:一个是从OO角度看,一个是直接深入数据库内部看。 关于数据库表应该采用逻辑主键还是业务主键的讨论 ============================= 数据库主键不应该具有任何业务意义 关系数据库学的最重要的一个理论是:不要给关键字赋予任何业余意义。假如关键字具有了业务意义,当用户决定业务含义,也许他们想要为关键字增加几位数字或者把数字改为字母,那么就必须修改相关的关键字。一个表中的主关键字有可能被其他表做为外键。就算是一个简单的改变,也可能会造成极大的维护上的开销。 为了使表的主键不具有任何业务意义,一种解决办法是使用代理主键,例如为表定义一个不具有任何业务含义的ID字段(也可以叫其他名字),专门做为表的主键。 我回顾我以前设计的很多数据库,都在某些地方没有考虑周到,即使大部分的主键都没有业务意义,还是会有某些表的主键和业务联系起来。因为我一直认为,主键是用来保持唯一性的,之所以要有代理主键,是因为有一些记录的内容没办法保持唯一性。例如设计一个用户表,用户的名字有可能重复,这个人可能叫blue,那么人也可能叫blue。这样就需要一个ID来分清。 … Continue reading

wiloon, 5/21/2014 3:09 | Tag:

事务(Transaction): 是并发控制的单元,是用户定义的一个操作序列。这些操作要么都做,要么都不做,是一个不可分割的工作单位。通过事务,sql server 能将逻辑相关的一组操作绑定在一起,以便服务器 保持数据的完整性。事务通常是以begin transaction开始,以commit或rollback结束。Commint表示提交,即提交事务的所有操作。具体地说就是将事务中所有对数据的更新写回到磁盘上的物理数据库中去,事务正常结束。Rollback表示回滚,即在事务运行的过程中发生了某种故障,事务不能继续进行,系统将事务中对数据库的所有已完成的操作全部撤消,滚回到事务开始的状态。   1、事务的特性  (ACID): 原一隔持 1) 原子性(Atomic):即事务是不可分割的最小工作单元,事务内的操作,要么全部执行,要么全部不执行。 2) 一致性(Consistency):事务在完成时,必须是所有的数据都保持一致状态。 在事务执行前数据库的数据处于正确的状态,而事务执行完成后数据库的数据还是处于正确的状态,即数据完整性约束没有被破坏;如银行转帐,A转帐给B,必须保证A的钱一定转给B,一定不会出现A的钱转了但B没收到,否则数据库的数据就处于不一致(不正确)的状态。 3) 隔离性(Isolation):一个事务的执行不能被其他事务所影响。 并发事务执行之间无影响,在一个事务内部的操作对其他事务是不产生影响,这需要事务隔离级别来指定隔离性; 事务必须是互相隔离的,防止并发读写同一个数据的情况发生 。 4) 持久性(Durable):一个事务一旦提交,事物的操作便永久性的保存在DB中。即使此时再执行回滚操作也不能撤消所做的更改。   事务类型 数据库事务类型有本地事务和分布式事务: 本地事务:就是普通事务,能保证单台数据库上的操作的ACID,被限定在一台数据库上; 分布式事务:涉及两个或多个数据库源的事务,即跨越多台同类或异类数据库的事务(由每台数据库的本地事务组成的),分布式事务旨在保证这些本地事务的所有操作的ACID,使事务可以跨越多台数据库; Java事务类型有JDBC事务和JTA事务: JDBC事务:就是数据库事务类型中的本地事务,通过Connection对象的控制来管理事务; JTA事务:JTA指Java事务API(Java Transaction API),是Java EE数据库事务规范, JTA只提供了事务管理接口,由应用程序服务器厂商(如WebSphere Application Server)提供实现,JTA事务比JDBC更强大,支持分布式事务。 Java EE事务类型有本地事务和全局事务: 本地事务:使用JDBC编程实现事务; 全局事务:由应用程序服务器提供,使用JTA事务; 按是否通过编程实现事务有声明式事务和编程式事务; 声明式事务: 通过注解或XML配置文件指定事务信息; 编程式事务:通过编写代码实现事务。   … Continue reading

wiloon, 4/1/2014 10:21 | Tag:

delete flag created date created by update date update by

wiloon, 3/5/2014 5:25 | Tag:

MySQL MySQL Connector/J Driver 驱动程序包:http://mvnrepository.com/artifact/mysql/mysql-connector-java 驱动程序类名: com.mysql.jdbc.Driver JDBC URL Format The general format for a JDBC URL for connecting to a MySQL server is as follows, with items in square brackets ([ ]) being optional: jdbc:mysql://[host1][:port1][,[host2][:port2]]…[/[database]] » [?propertyName1=propertyValue1[&propertyName2=propertyValue2]…] Here is … Continue reading

wiloon, 2/21/2014 1:33 | Tag:,

  H2的简单使用 安装: H2不依赖与任何Jar包,使用H2时,只需要将H2的Jar包添加到classpath中即可。 Xml代码   <dependency>     <groupId>com.h2database</groupId>     <artifactId>h2</artifactId>     <version>1.3.171</version> </dependency> 配置数据源: 通过spring jdbc来访问H2,下面是spring的配置,在这里我使用的是H2的in-memery模式。 Xml代码   <bean id=”dataSource4H2″ class=”org.apache.commons.dbcp.BasicDataSource”         destroy-method=”close”>         <property name=”driverClassName” value=”org.h2.Driver” />         <property name=”url”             value=”jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;IGNORECASE=TRUE;MODE=MySQL” />         <property name=”username” value=”test” />         <property name=”password” value=”test” /> </bean> <bean id=”jdbcTemplate4H2″ class=”org.springframework.jdbc.core.JdbcTemplate”>         <property name=”dataSource”>             <ref bean=”dataSource4H2″ />         </property> </bean> H2的URL可以支持很多参数的设置,具体可以参看H2的官方网站http://www.h2database.com/html/features.html 我这里的参数配置说明如下: a) jdbc:h2:mem:test:代表用内存来存储数据。mem:后面的为数据库名称。 b) DB_CLOSE_DELAY=-1:代表当JVM停止时才关闭H2数据库。 c) IGNORECASE=TRUE:不区分大小写。 d) MODE=MySQL:H2本身支持的是标准的SQL,但实际上不同的数据库之间存在一些差别,H2为了适配不同的数据库,可以在URL中添加MODE这个参数,我们使用的是MySQL数据库,所以MODE=MySQL 使用: 通过spring jdbcTemplate来访问H2 … Continue reading

wiloon, 1/15/2014 5:46 | Tag:

一套适用于MySQL数据库系统地图形化数据库管理、报告以及监控的工具。新版本具有高性能的、具有商业智能的、强大的备份功能,此外还有许多的改进。含简体中文文件。 官方网站:www.navicat.com 官方下载地址:http://www.navicat.com/en/products/navicat_mysql/mysql_overview.html中文下载地址:http://down.chinaz.com/soft/22655.htm

lcf, 11/1/2012 15:15 | Tag:

http://www.cnblogs.com/Bob-FD/p/3352216.html 为什么需要锁(并发控制)? 在多用户环境中,在同一时间可能会有多个用户更新相同的记录,这会产生冲突。这就是著名的并发性问题。 典型的冲突有: l 丢失更新:一个事务的更新覆盖了其它事务的更新结果,就是所谓的更新丢失。例如:用户A把值从6改为2,用户B把值从2改为6,则用户A丢失了他的更新。 l 脏读:当一个事务读取其它完成一半事务的记录时,就会发生脏读取。例如:用户A,B看到的值都是6,用户B把值改为2,用户A读到的值仍为6。 为了解决这些并发带来的问题。 我们需要引入并发控制机制。 并发控制机制 最常用的处理多用户并发访问的方法是加锁。当一个用户锁住数据库中的某个对象时,其他用户就不能再访问该对象。加锁对并发访问的影响体现在锁的粒度上。比如,放在一个表上的锁限制对整个表的并发访问;放在数据页上的锁限制了对整个数据页的访问;放在行上的锁只限制对该行的并发访问。可见行锁粒度最小,并发访问最好,页锁粒度最大,表锁介于2者之间。 悲观锁:假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作。[1]      悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长,这样可能会长时间的限制其他用户的访问,也就是说悲观锁的并发访问性不好。 乐观锁:假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性。[1] 乐观锁不能解决脏读的问题。    乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的,因此乐观锁直到你准备提交所作的更改时才将对象锁住,当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短,乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象,那么当他完成了自己的更改进行提交时,数据库就会发现该对象已经变化了,这样,第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中,会增加并发用户读取对象的次数。   从数据库厂商的角度看,使用乐观的页锁是比较好的,尤其在影响很多行的批量操作中可以放比较少的锁,从而降低对资源的需求提高数据库的性能。再考虑聚集索引。在数据库中记录是按照聚集索引的物理顺序存放的。如果使用页锁,当两个用户同时访问更改位于同一数据页上的相邻两行时,其中一个用户必须等待另一个用户释放锁,这会明显地降低系统的性能。interbase和大多数关系数据库一样,采用的是乐观锁,而且读锁是共享的,写锁是排他的。可以在一个读锁上再放置读锁,但不能再放置写锁;你不能在写锁上再放置任何锁。锁是目前解决多用户并发访问的有效手段。 乐观锁应用 1.      使用自增长的整数表示数据版本号。更新时检查版本号是否一致,比如数据库中数据版本为6,更新提交时version=6+1,使用该version值(=7)与数据库version+1(=7)作比较,如果相等,则可以更新,如果不等则有可能其他程序已更新该记录,所以返回错误。 2.      使用时间戳来实现. 注:对于以上两种方式,Hibernate自带实现方式:在使用乐观锁的字段前加annotation: @Version, Hibernate在更新时自动校验该字段。 悲观锁应用 需要使用数据库的锁机制,比如SQL SERVER 的TABLOCKX(排它表锁) 此选项被选中时,SQL  Server  将在整个表上置排它锁直至该命令或事务结束。这将防止其他进程读取或修改表中的数据。 SqlServer中使用 Begin Tran select top 1 @TrainNo=T_NO … Continue reading

wiloon, 7/1/2012 17:20 | Tag:

  1.DDL(Data Definition Language)数据库定义语言statements are used to define the database structure or schema. DDL是SQL语言的四大功能之一。 用于定义数据库的三级结构,包括外模式、概念模式、内模式及其相互之间的映像,定义数据的完整性、安全控制等约束 DDL不需要commit. CREATE ALTER DROP TRUNCATE COMMENT RENAME 2.DML(Data Manipulation Language)数据操纵语言statements are used for managing data within schema objects. 由DBMS提供,用于让用户或程序员使用,实现对数据库中数据的操作。 DML分成交互型DML和嵌入型DML两类。 依据语言的级别,DML又可分成过程性DML和非过程性DML两种。 需要commit. SELECT INSERT UPDATE … Continue reading

wiloon, 3/27/2012 16:18 | Tag:,

什么是连接? 连接,是我们的编程语言与数据库交互的一种方式。我们经常会听到这么一句话“数据库连接很昂贵“。 有人接受这种说法,却不知道它的真正含义。因此,下面我将解释它究竟是什么。[如果你已经知道了,你可以跳到它的工作原理部分] 创建连接的代码片段: ? 1 2 3 String connUrl = “jdbc:mysql://your.database.domain/yourDBname”; Class.forName(“com.mysql.jdbc.Driver”); Connection con = DriverManager.getConnection (connUrl); 当我们创建了一个Connection对象,它在内部都执行了什么: 1.“DriverManager”检查并注册驱动程序, 2.“com.mysql.jdbc.Driver”就是我们注册了的驱动程序,它会在驱动程序类中调用“connect(url…)”方法。 3.com.mysql.jdbc.Driver的connect方法根据我们请求的“connUrl”,创建一个“Socket连接”,连接到IP为“your.database.domain”,默认端口3306的数据库。 4.创建的Socket连接将被用来查询我们指定的数据库,并最终让程序返回得到一个结果。 为什么昂贵? 现在让我们谈谈为什么说它“昂贵“。 如果创建Socket连接花费的时间比实际的执行查询的操作所花费的时间还要更长。 这就是我们所说的“数据库连接很昂贵”,因为连接资源数是1,它需要每次创建一个Socket连接来访问DB。 因此,我们将使用连接池。 连接池初始化时创建一定数量的连接,然后从连接池中重用连接,而不是每次创建一个新的。 怎样工作? 接下来我们来看看它是如何工作,以及如何管理或重用现有的连接。 我们使用的连接池供应者,它的内部有一个连接池管理器,当它被初始化: 1.它创建连接池的默认大小,比如指定创建5个连接对象,并把它存放在“可用”状态的任何集合或数组中。 例如,代码片段: ? 1 2 3 4 5 … Continue reading

wiloon, 3/27/2012 16:05 | Tag:,

jdbc(java database connection)就是java数据库链接的api,是java标准类库的扩展,用它可以应用sql访问数据库,完成对数据库的查找,更新。 与其它数据库编程环境相比,jdbc有java语言的特性,使用jdbc开发的程序可以跨平台运行,而且不受数据库供应商的限制。 为什么不受数据库供应商的限制呢? 就在于jdbc的设计。 一、sun公司为sql访问数据库提供一套“纯”java api; 二、同时提供一个驱动管理器,以允许第三方驱动程序可以链接到特定的数据库,这样数据库供应商就可以提供自己的驱动程序,并插入到驱动管理器中,关键是所有的驱动程序都必须满足驱动管理器api提出的要求。 三、需要一套简单的机制,以使得第三方驱动程序可以想驱动管理器注册。 jdbc的典型用法 在传统的客户服务器模式中, 通常在服务器端配置数据库,jdbc驱动程序部署在客户。发展到后来的三层 , 甚至更高层的应用模式时,客户端不直接调用数据库,而是调用服务器上的中间层,再由中间层完成数据库查询操作。这种三层模式的优点是:它将可视化表示(位于客户端)从业务逻辑(中间件层)和原始数据(位于数据库)中分离出来。因此,我们就可以从不同的客户端,如java应用,applet或web表单,访问相通的数据库和相通的业务规则。 客户端和中间层之间的通信可以通过http(web浏览器用作客户端时),rmi(当使用应用或applet)或其他机制来完成。jdbc负责在中间层和后台数据库之间金星通讯。   JDBC(Java Data Base Connectivity,java数据库连接)是一种用于执行SQL语句的Java API,可以为多种关系数据库提供统一访问,它由一组用Java语言编写的类和接口组成。JDBC为工具/数据库开发人员提供了一个标准的API,据此可以构建更高级的工具和接口,使数据库开发人员能够用纯 Java API 编写数据库应用程序,同时,JDBC也是个商标名。   有了JDBC,向各种关系数据发送SQL语句就是一件很容易的事。换言之,有了JDBC API,就不必为访问Sybase数据库专门写一个程序,为访问Oracle数据库又专门写一个程序,或为访问Informix数据库又编写另一个程序等等,程序员只需用JDBC API写一个程序就够了,它可向相应数据库发送SQL调用。同时,将Java语言和JDBC结合起来使程序员不必为不同的平台编写不同的应用程序,只须写一遍程序就可以让它在任何平台上运行,这也是Java语言“编写一次,处处运行”的优势。 Java数据库连接体系结构是用于Java应用程序连接数据库的标准方法。JDBC对Java程序员而言是API,对实现与数据库连接的服务提供商而言是接口模型。作为API,JDBC为程序开发提供标准的接口,并为数据库厂商及第三方中间件厂商实现与数据库的连接提供了标准方法。JDBC使用已有的SQL标准并支持与其它数据库连接标准,如ODBC之间的桥接。JDBC实现了所有这些面向标准的目标并且具有简单、严格类型定义且高性能实现的接口。 Java 具有坚固、安全、易于使用、易于理解和可从网络上自动下载等特性,是编写数据库应用程序的杰出语言。所需要的只是 Java应用程序与各种不同数据库之间进行对话的方法。而 JDBC 正是作为此种用途的机制。   JDBC 扩展了 Java 的功能。例如,用 Java 和 … Continue reading

wiloon, 9/22/2011 9:27 | Tag:, ,

Apache Derby, an Apache DB subproject, is an open source relational database implemented entirely in Java and available under the Apache License, Version 2.0. Some key advantages include: Derby has a small footprint — about 2.6 megabytes for the base … Continue reading

辽ICP备14012896