多数据库的关联查询:
1.指定数据库如[db1].[own].[table],只能存在于一个服务器上
2.链接服务器方式,链接服务器,比较耗性能,工分拆业务,分拆数据库,确实比较传统,给程序员及数据库管理人员都带来比较大的麻烦,实现起来也不透明。
3.程序端处理。
4.第三方分库、分表的透明代理。
比喻说,一个大的系统,分为四个数据库
1.产品
2.订单
3.日志
4.其它,如帐号,基础省市等等
petshop也是如此
全部使用存触过程或视图
======================
1.指定数据库如[db1].[own].[table],只能存在于一个服务器上
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER VIEW [dbo].[VBaseCity]
AS
SELECT *
FROM [YCV2.0].dbo.BaseCity
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
====================
2.新建链接服务器,推荐使用复制分发
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER VIEW [dbo].[VBaseCity]
AS
SELECT *
FROM [10.10.11.105].[YCV2.0].[dbo].[BaseCity]
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
以后全部使用视图来调用处理,在数据库端直接处理跨数据库访问。
这样则相对于程序是透明的。
查询一般建议建立存储过程或视图。
视图可以建立索引和统计数据。
==========================
1.数据库负载均衡,读写分离,有分发布和订阅方式,仅解决读问题。
2.人工分拆业务,分拆数据库。解决读写问题,可以与1结合使用。
3.拆分得太细了并不是非常好。
===================================
我以前是这样处理的:
1。建立链接服务器
1.建立视图
SELECT *
FROM [10.10.11.105].[YCV2.0].[dbo].[BaseCity]
3.程序端调用视图或存触过程,相对于程序端是透明的,无需关心数据库的分离。
============================
分库分表总结
基本思路如下:首先sql解析路由,再根据路由确定分片,然后结果集合并。
1.分布式事务解决方案。
2.关联查询。
3.尽量少的客户端的架构。
4.分库适合于业务的完全独立或相对独立,不独立的采用视图方式。
5.读写分离,发布或订阅方式,频率问题。数据库的复制能解决访问问题,并不能解决大规模的并发写入问题。
6.分表:2005提供了表分区的功能,可以将一个逻辑表分别存储到不同的文件组中.
7.跨库联合查询采用并不是很推荐。缓存解决、分发冗余解决,复制分发视图
8.使用第三方数据库分库分表透明代理。在应用程序端做了太多改变,并不是很好,最好对应用层透明。在数据库端解决,或第三方代理才好。
9.分表根据时间段或业务特征。可考虑采用sql2005分区功能,如online、offline、vip用户、一般用户。
10.业务特征,事务性强不强,电子商务与社区、新闻系统是不一样的。
11.数据库负载均衡:发布订阅。发布方设定频率主动推送给订阅者,会出现数据不一致问题。
12.主从数据库,一般是一个写,多个读。Master,Slave
13.数据库间,使用应用进行部门字段落地处理,方便查询。
http://aronlulu.iteye.com/blog/791294
http://www.blogjava.net/happyenjoylife/archive/2011/05/13/350177.html
http://rdc.taobao.com/team/jm/archives/590
http://lzkooo.iteye.com/blog/905917