追寻真理之美

关系型数据库中，有一个经常出现的模式，就是集合A和集合B，通过一个关系集R，组成多对多的关系。举个例子，我们有学生表create table student( id serial primary key, name text)课程表create table course( id serial primary key, name text);可以建立一个选课表create table take_course ( id serial p

基于三元语义的关系数据库动态建模工具SocratesSocrates, Relational Database Dynamic Models Make Tools摘要 SummarySocrates是一个基于关系型数据库和ORM的通用数据库工具。它通过三元语义表达了对动态数据结构的存储和管理功能。使得开发人员可以在关系数据库中管理结构可变的数据。三元语义可以方便的表达单一信息之

自挖坑，存档 岗位职能区分数据库技术在现代软件技术领域有广泛的应用，与数据相关的技术岗位和职能，也可以区分为若干个不同的类别。根据在一个理想的开发团队中不同的分工和知识掌握的不同，可以区分为：程序员分析师设计师 架构师管理员对于数据库领域，分析与设计岗位、架构与运维岗位（管理员）的重叠较高。特别是分析与设计岗位通常在团队中由同一（组）人承担。在更多的团队

前几天有个朋友提了一个问题:应用平台需要统计最近访问的20个用户的信息。我第一个想到的是用memcache之类的专用的缓冲，以用户名为键，以最后访问时间为值，如果用户访问比较均匀，限定一个合适的 超时值，查询的时候遍历过滤就好了，虽然不是很精确，但是实现起来够简单。答：不可以，领导要求只在数据库端解决。环境准备提问的朋友使用的是 MySQL ，这里我用一个 Postgr

今天要在Firebird中使用分页查询功能，就开始犯愁，这个东西没有Oracle的rownum，也没有SQL Server的Top n，会是通过什么方式分页的呢？非常让人无奈的是Firebird的网站上找不到新版的查询语言文档。而我手头的Interbase 6.0 Language Refrence中对分页查询只字未提。在我心里，准备好了两个方案：1、用Generator生成一个rownum，显然

前面的文章中，我们初步见识了NULL这个不可思议的小东西。今天，我尽可能详细的介绍一下它。依照惯例，这是一次尽量浅显但并不严谨的讨论，甚至可能内容也不那么严肃。我的目的在于帮助读者更轻松地工作，并且有兴趣对数据库进一步的学习。从另一方面讲，我相信自己论点中的错误，肯定会有其他人也在犯，所以请发现不妥的朋友一定要公开指出。这样，才有助于我和我的读者朋友们进步。衷心感谢每一个提出批评和指正的朋友，特别

 初学SQL的日子，感觉就像是刚学走路，步态可掬，跌跌撞撞。摔了不少可笑的跟头。拿出来大家娱乐一下，也互相提个醒，这样的错我们可以尽量避免的嘛。 先看这个：例1 不合理的逗号：Select Field1, Field2, Field3, From MyTable一执行就是个语法错误，什么意思嘛，这可是从书上抄的哎，你不能这么对我……呵呵呵，其实嘛，错误在于我在最后一个字段名后面加了

面向集合的结构化设计。这一点很多人都知道，可真正能够活用的就太少了。举一个简单的例子：例1-3：有一个简单的数据表Orders，存储某商店的订单信息：CREATE TABLE [dbo].[ORDERS] ([ID] [int] IDENTITY (1, 1) NOT NULL ,[CustomerID] [int] NOT NULL ,[OrderDate] [datetime] NOT NUL

在优快云上回贴时，我总是苦口婆心地劝告楼上楼下的朋友们多用联接。可响应甚微。往往一个简单的功能，也一定要写成子查询或游标，弄得非常复杂冗长。的确，这样写对于初学者来说，费力不费脑，思路比较好理解。所以往往得分的也是这些回贴。可事实上，如果你真正熟悉了SQL的编程风格，你会明白，联接查询才是最直接、最清晰、最有力的方法，而更好的办法就是无招胜有招，一条简单查询结束战斗。下面我举几个例子来证明一下这

  不等联接通常来说，SQL语言进行的都是无序操作。想要进行有序的处理，比如比较一个序列的前后项，必须要使用游标。但是，在有些场合下，可采用另一种方法，不用游标，一样能处理有序的信息，这就是不等联接。先看下面一个例子前一阵， 优快云网友BuildIt来信，和我讨论了这样的问题：以下表HISTORYCREATE TABLE [HISTORY] ([TheDate] [datet

  关系的真相长期以来，我们习惯了称关系型数据库中的表为二维表。因为它有行和列，很容易我们就可以把它同一个二维平面联系起来，但事实上，这并非关系型数据库的初衷，也并非符合关系模型的设计。其实长久以来，我对此也只有一个很模糊的概念，对平面表的观点虽有怀疑，却一直无从验证。直到有一天，翻出一本老书——《关系数据库》（石树刚、郑振楣编著，清华大学出版社，1993年），这本老书没有什么流行的新噱头

例1-2、键值重复的信息现在看一下压缩掉重复信息的PRODUCT表ID PNAME PRICE NUMBER PDESCRIPTION 1Apple 123000NULL2Banana 16.997600NULL3Olive 25.224500NULL4Coco Nut 40.992000NULL4Orange 15.995500NULL5Pineapple 302500NULL6Olive 25

树状结构的存储与管理，是每一个在关系型数据库平台上工作的程序员早晚都要遇到的问题。说大不大，怎么都能解决，说小不小，处理不好，有的是麻烦等着你。仁者见仁，智者见智，公说公有理，婆说婆有理（谁用机箱砸我？机箱是个好东西，乱丢会摔坏硬盘的，你看我话没说完你又把显示器丢了……），咳咳，好吧，闲话少说，我们从最大路的处理风格谈一谈吧。这里面的大部分内容并非我的独创，从很久很久以前，数据库程序员们就这样做啦

  游标概观相信很多Delphi程序员都写过这样的代码：...beginMyDataSet.Open;MyDataSet.Frist;while not ( MyDataSet.BOF or MyDataSet.EOF) dobegin...end;MyDataSet.Close;end;...很久以来，我们习惯了用这样的代码对数据库返回的数

数据抽取理论上的关系型数据库，数据是以关系的形式存在。通常我们都可以把它们视为一种集合。这样，数据一般是以无序的形式存在的。这种做法的好处自不用多加讨论了，不过我们也得承认，有时这样也会带给我们一些麻烦。我最近就遇到这么一件。我在网上遇上我的一个老同学，他提出了这样一个问题。有一个表（假设就叫myTable），表中有三个整型字段（假设就叫A11，A12，A13），其上有一个唯一键约束。现在

?写这本书的最初想法，来自于在第一个公司工作时，与同事的交流和学习。不过发布这本书的导火索，却在于一次在优快云上读到一篇关于最新信息的报表问题的贴子。贴子中的问题可以用子查询和联接两种方式完成。由于条件所限，我不能详细解答，由此发贴的朋友不能理解我的本意，让我心生遗憾。所以决定将写书的想法付诸行动，并将这本书贴在优快云上，与大家一起交流，共同进步。今天正好又见到类似于当日的问题，心生感触，决定