有关子表联合查询

Question

查看了一番，似乎事情在Access等“关系数据库”中很简单，建立一对多关系就OK了。
可是偶需要的是SQL语言参考，而不是“打开鼠标指向点击”之类莫名其妙的东西。没有人拉一把？ 这么说吧，有没有示例程序看的？偶在翻MSDN，在access/DAO/ADO/SQL参考之间翻来复去地正逛荡呢。谁给个明确的提示？？？这么翻很累的啵 :-((((

Answer 1

在没有找到直接的操作指令之前，笨办法有两个。
一个是自己写关联操作，放到应用程序中解决。
二个是调用Access，用Access的指令完成。可是偶觉得Access这玩意太巨大了，没必要启动它，用ADO就调它个驱动就可以了。——偶花了不少工夫，已经实现了不用配置ODBC，用ADO直接操作*.mdb文件。

Answer 2

第一个问题的回答：这不是效率问题，而是根本不允许这样冗余地设计字段。否则你把所有记录放在一张表里更有效率。有趣的是所谓的效率会因为逻辑的冗余和混乱而变得毫无使用效率。第二个问题的回答：你不了解SQL，否则就不会觉得很麻烦。看看这个论坛中各种SQL查询的例子，包括一些有一句话的大型应用的报表的例子。你的问题牵涉到数据库的三个基本理论：SQL、结构化设计和索引优化。你需要从基本知识入手，而不要仅仅使用一些数据库“语言”。

Answer 3

似乎也不是“使用”，好象是“阅读、理解、使用、在使用中再理解”吧？另外，我觉得以下问题的回答也不一定准确：
http://expert.csdn.net/Expert/topic/1201/1201349.xml?temp=.7659876关联/关系表和子表嵌套至少在Access中不是一回事。

Answer 4

再有，偶的问题已经基本解决了，拿掉了那个所谓的中间表，直接用一张主表和十多张主表分别建立一对多关系，OK.最初提出这个问题的时候，初衷由于：
1。主表中某条“优秀学生”记录不一定在每个子表中都有数据，可能只在少数的几张子表里有对应数据。我想，打开一个子表肯定不如在内存里进行一点计算快，如果能在这之前判断需要打开哪几张表可能会快一些。所以有了“中间表”的想法。2。尽管会对GUID做索引，但是很遗憾，这个GUID字段是CHAR类型的。无论如何，它搜索它的速度肯定没有搜索子表中自增长整数类型的ID字段（也带索引）快。如果数据规模很大的话，例如总共十几万条记录，每个子表也有那么几万条记录？

Answer 5

我觉得用3个表比较好。
表一：学生基本情况表。有1个字段标识是否为优秀学生。
表二：优秀学生项目类型表。可以维护项目的类型。如除了“学科竞赛获奖”、“三好学生评选”、“组织生活”外还想添加“科技发明”、“好人好事”等
表三：优秀学生记录表。有3个字段，“学生基本情况表ID”、“优秀学生项目类型表ID”、“相应类容描叙”。
不知道我说得对否，很想听大家讨论。