189 8069 5689
谈一点个人的看法：
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名注册、网络空间、营销软件、网站建设、贵德网站维护、网站推广。
从库结构设计来看，通常来说，两个库相关联的字段是以唯一值为基础的，可能是一对多的关系，但通常是用的 ID 来做。比如：news 的 newstype 用 newstype_ID 与 newstype 库的 ID 相关联。
建议可以参考一下其他数据库的设计，比如：Discuz 论坛中的库结构。
SELECT aid,a1,a3,B.*,C.* FROM A LEFT JOIN B ON aid=b_aid INNER JOIN C ON aid=c_aid
你也可以 create view xx as SELECT aid,a1,a3,B.*,C.* FROM A LEFT JOIN B ON aid=b_aid INNER JOIN C ON aid=c_aid
也许是我孤陋寡闻了，似乎没有办法跨库关联查询吧。如果非要跨库关联，我能想到的办法就是把两边的数据查询出来并存入一个临时表，再查询临时表。不过这种方法只是用于不同库中相同或相似的表，比如有的数据量较大的分库项目。
在回过头来看你的项目需求，其实根本不需要跨库的。首先在任意一个库里创建一个表，在发送会议信息给会员的时候，除了这个表的主键之外，只需要记录会员的id和会议的id，这两个id分别从两个库里获取。
你如果要查看某条会议信息发送的详情，就通过这两个id分别从两个库里获取会员信息和会议信息。
你如果要查询出列表，用笨办法，因为你这个表肯定和会员或会议其中一个在一个库了，可以关联，然后在列表循环中逐条查询另一个数据，虽然这样有些影响性能，但是也比“跨库关联查询”好点，况且如果数据多的话，一般都是分页操作的话，一个列表最多二三十条记录，一次查询二三十也不会有太大影响。
另一个笨办法，就是把发送记录列表中所有需要列出的字段都记录在发送会议信息的记录表里，这样就不需要在循环查询另一个表了。但缺点就是这里面的数据就不能和会员以及会议信息的数据同步，除非你在更新会员以和会议信息的数据的同时更新这个表的数据。
但不管用哪种方式，我觉得都比“跨库关联查询”要好，即使真的有“跨库关联查询”的方法。