手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表Tag:数据库

对于n个条件中有大于等于或小于m个条件成立时符合要求的sql 条件语句的写法

假设的应用场景 

我假定博客园要在首页为群组开辟一块空间,推广小组,小组能在首页显示的条件有四个:

1.       页面点击量大于10w

2.       小组人数大于1000

3.       小组帖子数大于10000

4.       小组在2007年之前创建

现在假定4个条件都满足的小组只有两个,太少了,推广位可以推广10个小组;这时候运营人员要求这4个条件中满足3个但是第4个条件不满足的小组算符合条件的小组,如果4个条件都满足就认为这个小组太火了,不需要在首页推广它了。业务逻辑想清楚了,下一步就该写代码了,数据逻辑层的代码的任务假定交给我了,我要考虑满足4个条件中3个成立的sql怎么写。

为了叙事方便,我们假如小组表的名字为Group,相关的条件字段是Pv,UserCount,PostCount,CreateTime:分别表示小组的点击量,人数,帖子数,创建时间

我来写sql语句,上面的四个条件满足至少3个,有多少种情况呢?这是一个组合问题,一共有多少种的公式我已经忘记了,我要根据感觉写写看:

SELECT * FROM Group
WHERE  (Pv>100000 AND UserCount>1000 AND PostCount>10000 AND CreateTime > 20070101
OR (Pv>100000 AND UserCount>1000 AND PostCount<10000 AND CreateTime < 20070101)
OR (Pv>100000 AND UserCount<1000 AND PostCount>10000 AND CreateTime < 20070101)

这个Sql语句条件还行,但是我们的题目是n个条件m个条件成立,如果多了还这么写,恐怕就很累了,能不能改进呢?答案是肯定的,要不我就不写这篇随笔了,呵呵

SELECT * FROM Group
WHERE 
(
CASE Pv WHEN Pv>100000 THEN 1 ELSE 0 END--这是PV的条件成立则为1,否则为0
+(CASE UserCount WHEN UserCount > 1000 THEN 1 ELSE 0 END--用户数条件
+(CASE PostCount WHEN PostCount > 10000 THEN 1 ELSE 0 END--帖子数条件
+(CASE CreateTime WHEN CreateTime < 20070101 THEN 1 ELSE 0 END--时间条件
= 3

如果上面的三个表达式加起来值是3就说明恰好满足三个条件,如果是两个条件就是等于2,如果扩展为n个条件m个条件成立也很容易写,很容易维护、修改。 

这是一个sql条件语句的技巧,希望对你有用。

本文假设的场景纯属虚设,请勿遐想。J

 

原文地址:http://www.cnblogs.com/yukaizhao/archive/2008/11/14/sql_condition_m_n.html

PS:

顺便说明一下,在mysql中也支持这样的用法(4我没有试过,但是5是支持这样的用法的。)虽然这样的用法比较容易写和维护及修改,但看上去还是有点妖。而且,效率不一定能保证。

Tags: 数据库, 条件查询, where

天天加班,更新会延迟了

由于最近天天加班,连载可能会延迟了,希望大家莫要见怪,不过我仍然是会抽空看书并添加的。

努力努力

为了那句:今天不努力工作,明天努力找工作

Tags: 更新, 连载, 数据库

SQL语句导入导出大全(转)

备份资料:Copy from ---> http://php.mydict.com/ziliao/7/2006_05/SQLYuJuDaoRuDaoChuDaQuan3016_1.html



/******* 导出到excel
EXEC master..xp_cmdshell 'bcp SettleDB.dbo.shanghu out c:\temp1.xls -c -q -S"GNETDATA/GNETDATA" -U"sa" -P""'

/*********** 导入Excel
SELECT *
FROM OpenDataSource( 'Microsoft.Jet.OLEDB.4.0',
'Data Source="c:\test.xls";User ID=Admin;Password=;Extended properties=Excel 5.0')...xactions

更多看详细。。。

» 阅读全文

Tags: sql, 导入, 导出, 详解, 数据库

精通MYSQL数据库——连载十二

三大范式:第一范式,第二范式,第三范式,听着名字就很恐怖。但其实现在的人都被这个所谓的第三范式折腾死了,有事没事就拿出来涮涮,究竟怎么理解这些呢?一个一个慢慢的介绍。

数据库理论家们为数据库的设计1对N,N对N这种问题总结出了一个通用的解决方案,只需一步一步地三个范式(Normal Form)的规则应用到自己的数据库上就可以了。

第一范式的规则:

1、内容相似的数据必须“消除”(所谓消除,即再创建一个表来存储他们)

2、必须为每一组相关数组分别创建一个数据表

3、每条数据记录必须用一个主键来标识

第一条规则,看上去就比较适用于1对多的情况

第二条规则就不太好控制了,很多人认为第二条规则很难理解,数据的相关度,很难简单的描述清楚

第三条规则其实是一个实践经验,它的意思是数据表里的第一个数据行都应该包括一个独一无二的标识符作为索引。在使用MYSQL的时候,我们大多采用了自增字段来作为主键,但并非只有整数的自增字段才能作为索引,只要是独一无二的数据列,都可以用来做索引,之所以采用自增列,那是因为:1、不需要主动插入值2、整数列的时间和空间效率相对比其他类型的要高。

第二范式的规则:

1、只要数据列里的内容出现重复,就意味着应该把数据表拆分为多个子表

2、拆分形成的数据表必须用外键关联起来

第二范式,其实是在第一范式的基础上再进行一个拆分。指的就是第一范式规则的第二条内容。

外键关系在第二范式里显得特别重要,是因为第二范式时,数据会拆得更细,如果没有外键关联,恐怕数据就找不回来了。外键相当于我们日常所说的:交叉引用,对开发人员来说相当于指针。

第三范式的规则

第三范式只有一条规则:与主键没有直接关系的数据列必须“消除”

其实也就是把第二范式再分解,再建表。

可想而知,等到真正把一堆数据完全按照第三范式来进行设计的时候,恐怕在数据库里也就只能看到一堆ID了,数据呢?数据在哪里?通过外键,外键的外键,外键的外键的外键来慢慢的一个一个搜索吧。

对于MYSQL 4.1以下的版本,第三范式是会要了他们的命的,foreign key功能的不完善,让MYSQL 4.1以下版本,基本不适合第三范式,能用到第二范式设计时,数据表的效率已经几乎不能保证了。

这三个范式是著名学者E.F.Codd最先提出来的,后人在此基础 上对大到数学集合理论、小到关系数据库设计细节等诸多方面进行了研究和探索。如果对这方面有兴趣的朋友,还是多找找相关的书籍看看为好。

如果你的性子比较急,那么你可以尝试按照下面的方法来进行:

1、设计数据库的时候,一定要给自己充足的时间,如果等到数据库充满了数据,而程序也几乎开发完毕时,才发现数据库设计有缺陷,那么花费的代价就太大了

2、如果发现自己创建的表的数据列有序号,如name1,name2等,那一般就意味着还有更好的解决方案没有采用。可以考虑多创建一个表,而把这些分拆开。

3、第一时间往数据库里多插点测试数据,如果发现冗余量很大,往往就是表需要分拆的信号

4、设计时应该注意数据与数据之间的关联及引用关系

5、对于设计完的数据库,应该自己尝试写SQL语句,看看能否达到你预想的目标,如果达不到,那就要考虑是否设计的有问题。

6、如果你还是等不急,根据你的需要,到网上找找有没有类似的示例数据库,可以考虑拿来作借鉴。

说了这么多时间的范式,最后再说说他们的优缺点吧

缺点:数据表的个数越多,也就相对证明了从表单里获取数据并往表里插的时候,复杂性非常大,给开发人员会带来很大的困扰。同样,表多了,查询结果时,从中提取相关数据生成查询结果的复杂性也就越大;数据库的容量随着表的拆分量的增大而增大(不过现在也不是什么矛盾了,硬盘的价格几乎也快到了白菜价了,这点可以被忽略)

优点:严格按照范式设计出来的数据库,能够提供最丰富、最灵活的查询选项,人们往往都是在等到必须使用一种新的查询或者必须对数据进行一种新的分类时才会真正意识到这一点,但可惜的是,这些新需求往往都是出现在数据库已投入运行数月之后,到时候再改数据库,代价非常大。


现在工作有点忙,连载不会忘记,但更新频率会放慢,毕竟全部都是手工打出来的字。

不会象写小说那样太监掉的,毕竟这个东西对我自己来说,也是一种学习

给自己加油,为自己打气。也谢谢大家的支持

Tags: mysql, 精通, 数据库, 连载

精通MYSQL数据库——连载十一

一个好的数据库设计应该符合以下几点要求:
1、数据表里没有重复冗余的数据(如果总是往里面插入同样的数据,那应该是设计上有问题,当然现在在利用空间换时间的时候,多数人还是保留了这样的想法)
2、数据表里没有column1,column2,column3……这类没有明确意义的字段,因为这样会让后来人摸不清头脑
3、数据表占用的空间越小越好
4、使用频率高的数据表的查询,应该都能以简单高效的方式执行(表内数据少的时候,你就是10几个left join,你可能都感觉不出什么,但数据量一大,你一个left join都会让你感觉到速度慢下来,如果最初设计时没有满足这个要求,那么,以后想改可能也没有机会了)
这些也只是一些总的原则,也只是简单的介绍,以后会详细说明,当然上面这几点并非完全正确,就象第三范式,这是一个标准,但这个标准真的就是最好的吗?并非如此,但我们现在是在讲设计数据库,它好不好,目前不讲。以后一起讨论

为MYSQL的数据库和数据表甚至字段起名字还是有讲究的,最重要的是,千万不要使用保留关键字,而且有一些单词很奇怪,在4.0里面并不是关键字,但升级后,却变成了关键字。
详细的关键字列表请看:MYSQL手册中保留字部分
对于一个完整的设计应该注意以下几项:
1、由于MYSQL对数据列的命名不区分大小写,而对库名和表名区分大小写,因此为了规范和统一,请使用同样的规则,不要象程序代码那样来个骆驼命名啥的,这样只会给开发带来困难,建议是全部采用小写,移植、升级都方便
2、不要采用特殊字符或者中文,MYSQL对于多字节的处理并不十分完美,虽然支持中文建库、建表等,但实在不建议使用,如果你的服务器对中文支持不好,可能建库的时候就会是乱码,字段里,明明看到有值就是查不出,所以,为了规范,还是采用英文,26个字母的排列组合,没有那么复杂的。
3、数据库、表、字段的长度请不要超过64个字符,
4、表名和数据列名,请尽量采用有意义的名称,不要出现上文提到的那种column1,colnmn2之类的,时间长了,你自己都可能不知道是什么意思
5、给字段命名,需要有规范,因为这样会减少粗心带来的错误,比如username,user_name,如果分在各个表里,恐怕你每次写程序的时候,都得再检查一遍吧?对于由多个单词组成的字段,要么全部加下划线,要么全部不加,这样也比较有利于开发和维护
6、数据列的单复数,原因和5一样,要么全部单数,要么全部复数,一会单数一会复数的,开发和维护的时候,你就得盯着数据表来进行了。

数据库的设计是一件很复杂的事情,要在短时间内把一批数据分割开,并存储到数据库中,还得为开发人员提供足够的优化空间,不是一天两天就能完成的,当然现在有很多这样的工具,比如powerdesign(PD),在设计完后,还能导出数据库,确实是挺方便,但这样的软件,价格就太高了,不是我们所买得起的。
平时,我们还是使用WPS的电子表格,或者openoffice的电子表格功能,设计好数据表(电子表格最大的好处就是有几乎无穷的sheet,可以让你把一个很大的库放在这些sheet里),而且,几乎每台电脑上都会有这样的工具,便于交流。这样可以在最初的阶段对于一些数据列进行安排(没办法建立索引的,只是简单的用来布局,检查设计上是否有缺陷)

对于管理MYSQL,也有很多工具,比较常见的,就是:phpMyadmin;MYSQL自已也提供过,好象是mysqlFront?记不太清,现在我自己用的是navicat for mysql lite ,不用钱的东西都是好的。虽然在国内,大家都了解软件业的行情。自己也处于软件业的下游,能够使用正版,还是使用一下正版吧。不能使用正版的,找找免费版。
在我看的书上,它介绍说openoffice里其实还隐藏着连接数据库这个功能的,而且可以能够象创建视图一样来创建SQL,这个功能不错,我以后要好好看看,如果确实有用,那我WPS也不装了,直接使用openoffice。
不过,最常用的,最方便的,还是使用phpmyadmin,它实在是居家旅行、杀人灭口之大杀器。

Tags: mysql, 精通, 数据库, 连载

Records:14123