到底有多大?SQL Server應該可以處理的,或者你另建個數據庫

解决方案 »

  1.   

    完全同样楼上的做法。^_^
    http://www.lebo.cn
      

  2.   

    情况是这样的,公司前几年买了一套文档管理软件,这套软件是把图形等(包括OFFICE文档)直接存入数据库.公司已经输入大量的目录信息(约150万条),如果把这么多文件都放在数据库里,那就太庞大了!
    按照各位的想法,我们只有换软件了,但以前做的大量的工作也就没有用了!!!能不能用SQL SERVER的集群技术把数据库放在不同的服务器上(不知道是否可行?)
      

  3.   

    那还不如用notes了~~~Sql本来就适合处理记录~不是文件服务器~
      

  4.   

    居然有这样的软件开发公司!我试过JPG文件放到数据库内,其所占磁盘空间几乎与这一JPG文件未转格式前的BMP文件一样。我开发过VOD、电台播出系统(音频文件有数十万条记录),都是记录路径的。你把旧的系统废了(不过要写一个导出模块),重新写一个软件,比你加硬盘、改集群要合算。而且数据备份更方便灵活。
      

  5.   

    巨难的问题并不难呀!解决方案如下:
    1。一个表中的内容再多也不多?MSSQL支持1000G级别的数据库。不是问题。
    2。唯一可能是您的硬盘分区格式FAT32,数据库文件超过2GB,但分区不支持。
    3。解决方案一: 在建数据库的时候,指定多个硬盘数据库文件。(FAT32所迫)
    4。解决方案二: 在建数据库的时候,指定硬盘数据库文件放在NTFS格式的分区中。(强烈推荐)
    5。解决方案三: 使用群集服务器,OLEDB联合查询,将增加程序设计复杂度。(很累的)。
    6。若数据库>单个硬盘空间,联合方案二和方案一均可完美解决,不建议采用方案三)
    祝您好运。:)
      

  6.   

    150万条对MSSQL数据库来说算不了什么,您的数据应该不会超过一个机器能挂的硬盘容量吧?!不行有一二百GB的硬盘呢,数据库不是问题。:)
      

  7.   

    一二百GB的服务器硬盘很贵的啊!在说,200GB的一个数据库运行起来效率怎样?
      

  8.   

    用DTS,可以把磁盘文件写入到数据库的image类型的属性中,反过来,也行^_^
    Read File和Write File转换类型
      

  9.   

    1、这些数据完全可以放在同一个server下,通过增加存储空间存放。
    2、如果需要提高运行并行度,可以将数据表分成几个部分建立在不同的server上,然后通过视图合并成一个表进行处理。
      

  10.   

    说回楼主提到的那个档案软件,考虑到图片的安全性,图片是否存放到数据库比较合理?
    又或者在数据库中只保留图片的路径,在保存图片的文件夹中设置window访问权限?
      

  11.   

    数据表分成几个部分建立在不同的server上,然后通过视图合并成一个表进行处理,
    对于已经设计好的软件,不需要改动访问的方式就可以吗?还是要修改原来的软件?
      

  12.   

    数据表分成几个部分建立在不同的server上,然后通过视图合并成一个表进行处理,
    对于已经设计好的软件,不需要改动访问的方式就可以吗?还是要修改原来的软件?软件不需要改动。
      

  13.   

    那么,怎么把几个SERVER上的表合通过视图合并成一个表呢?
    学习!
      

  14.   

    两个步骤:
    1、为每个server建立链接服务器,具体可以查看联机帮助中sp_addlinkedserver的说明。
    2、创建可更新分区视图。
    首先水平分区表。
    原始表被分成若干个较小的成员表。每个成员表包含与原始表相同数量的列,并且每一列具有与原始表中的相应列同样的特性(如数据类型、大小、排序规则)。如果正在创建分布式分区视图,则每个成员表分别位于不同的成员服务器上。为了获得最大程度的位置透明度,各个成员服务器上的成员数据库的名称应当是相同的,但不要求非这样。例如:Server1.CustomerDB、Server2.CustomerDB、Server3.CustomerDB。成员表设计好后,每个表基于键值的范围存储原始表的一块水平区域。键值范围基于分区列中的数据值。每一成员表中的值范围通过分区列上的 CHECK 约束强制,并且范围之间不能重叠。例如,不能使一个表的值范围从 1 到 200000,而另一个表的值范围从 150000 到 300000,因为这样将不清楚哪个表包含 150000 与 200000 之间的值。例如,正在将一个 Customer 表分区成三个表。这些表的 CHECK 约束为:-- On Server1:
    CREATE TABLE Customer_33
      (CustomerID   INTEGER PRIMARY KEY
                    CHECK (CustomerID BETWEEN 1 AND 32999),
      ... -- Additional column definitions)-- On Server2:
    CREATE TABLE Customer_66
      (CustomerID   INTEGER PRIMARY KEY
                    CHECK (CustomerID BETWEEN 33000 AND 65999),
      ... -- Additional column definitions)-- On Server3:
    CREATE TABLE Customer_99
      (CustomerID   INTEGER PRIMARY KEY
                    CHECK (CustomerID BETWEEN 66000 AND 99999),
      ... -- Additional column definitions)在创建成员表后,在每个成员服务器上定义一个分布式分区视图,并且每个视图具有相同的名称。这样,引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样,但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。生成分布式分区视图的方式如下: 在每一个含有在其它成员服务器上执行分布式查询所需连接信息的成员服务器上添加链接服务器定义。这将使得分布式分区视图能够访问其它服务器上的数据。
    对于在分布式分区视图中使用的每个链接服务器定义,使用 sp_serveroption 设置 lazy schema validation 选项。这确保了只有在实际需要远程成员表的数据时,查询处理器才请求任何链接表的元数据,从而使性能得到优化。
    在每个成员服务器上创建分布式分区视图。这些视图使用分布式 SELECT 语句访问链接成员服务器上的数据,并将分布式行与本地成员表的行合并。 
    若要为上一个示例创建分布式分区视图,应当: 为 Server2 添加一个名为 Server2 的、带有连接信息的链接服务器定义,并添加一个名为 Server3 的链接服务器定义以访问 Server3。
    创建以下分布式分区视图: 
    CREATE VIEW Customers AS
       SELECT * FROM CompanyDatabase.TableOwner.Customers_33
    UNION ALL
       SELECT * FROM Server2.CompanyDatabase.TableOwner.Customers_66
    UNION ALL
       SELECT * FROM Server3.CompanyDatabase.TableOwner.Customers_99在 Server2 和 Server3 上执行相同的步骤。 可更新的分区视图
    如果本地或分布式分区视图为不可更新的,则它只能作为原始表的只读复本。可更新的分区视图可展示出原始表的所有功能。在下列情况中,视图被视为可更新的分区视图: 视图是一组 SELECT 语句,这些语句的结果集通过 UNION ALL 语句组合为一个结果集。每个 SELECT 语句引用一个 SQL Server 基表。该表可以是本地表,也可以是使用 4 部分名称、OPENROWSET 函数或 OPENDATASOURCE 函数引用的链接表(不能使用 OPENDATASOURCE 或 OPENROWSET 函数指定直接传递式查询)。 
    表规则
    成员表在视图定义中的每个 SELECT 语句的 FROM 子句中定义。每个成员表都必须遵守如下规则: 在视图中每个成员表只能引用一次。
    成员表不能有任何计算列上创建的索引。
    成员表在数目相同的列上应具有所有 PRIMARY KEY 约束。
    成员表必须有相同的 ANSI 填充设置。有关 ANSI 填充设置的更多信息,请参见 SET ANSI_PADDING。 
    列规则
    列在视图定义中的每个 SELECT 语句的选择列表中定义。列必须遵守如下规则。 每个成员表中的所有列必须包含在选择列表中。
    在选择列表中不能多次使用同一列。
    在选择列表中对列的引用不能多于一次。
    列必须位于选择列表中的相同序号位置处。
    每个 SELECT 语句的选择列表中的列必须是同一类型(包括数据类型、精度、小数位数和排序规则)。例如,以下视图定义失败,这是因为两个 SELECT 语句中首列的数据类型不同: 
    CREATE VIEW NonUpdatable
    AS
    SELECT IntPrimaryKey, IntPartNmbr
    FROM FirstTable
      UNION ALL
    SELECT NumericPrimaryKey, IntPartNmbr
    FROM SecondTable分区列规则
    分区列存在于每个成员表上,并且通过 CHECK 约束标识特定表中的可用数据。分区列必须遵守如下规则: 每个基表都拥有键值由 CHECK 约束所强制的分区列。每个表的 CHECK 约束的键范围与其它任何表互不重叠。任何分区列的给定值必须只能映射到一个表。CHECK 约束只能使用以下运算符:BETWEEN、AND、OR、<、<=、>、>=、=。
    在视图中,分区列必须位于每个 SELECT 语句的选择列表中相同的序号位置处。例如,分区列要么总是每个选择列表中的首列,要么总是每个选择列表中的第二列,依次类推。
    分区列不允许为空。
    分区列必须是表的主键的一部分。
    分区列不能是计算列。
    在分区列上必须仅有一个约束。如果有多于一个的约束,SQL Server 会忽略所有的约束并在确定视图是否为分区视图时不考虑这些约束。 
    满足所有上述规则的分区列将支持 SQL Server 2000 查询优化器支持的所有优化。有关更多信息,请参见解析分布式分区视图。数据修改规则
    除了为可更新的分区视图定义的规则外,引用该视图的数据修改语句还必须遵守为 INSERT、UPDATE 和 DELETE 语句定义的规则。说明  只有在安装了 Microsoft SQL Server 2000 企业版或 Microsoft SQL Server 2000 开发版时,才可通过分区视图修改数据。
    INSERT 语句
    INSERT 语句通过分区视图将数据添加到成员表中。INSERT 语句必须遵守下列规则: 所有列必须包含在 INSERT 语句中,即使基表中的列可能为 NULL 或在基表中定义了 DEFAULT 约束。
    不能在 INSERT 语句的 VALUES 子句中指定 DEFAULT 关键字。
    INSERT 语句提供的值必须符合在一个成员表的分区列上定义的 CHECK 约束逻辑。
    如果一个成员表包含具有标识属性的列,则不能使用 INSERT 语句。
    如果一个成员表包含 timestamp 列,则不能使用 INSERT 语句。
    如果存在具有同一视图或任一成员表的自联接,则不能使用 INSERT 语句。 
    UPDATE 语句
    UPDATE 语句通过分区视图在一个或多个成员表中修改数据。UPDATE 语句必须遵守下列规则: UPDATE 语句不能在 SET 子句中将 DEFAULT 关键字指定为值,即使列在相应的成员表中定义了 DEFAULT 值。
    不能更改具有标识属性的列的值;不过可以更新其它列。
    如果列中包含 text、image 或 ntext 数据,则不能更改 PRIMARY KEY 的值。
    如果基表中包含 timestamp 列,则不能进行更新。
    如果存在具有同一视图或成员表的自联接,则不能进行更新。
    不能在 UPDATE 语句的 SET 子句中指定 DEFAULT 关键字。 
    DELETE 语句
    DELETE 语句通过分区视图在一个或多个成员表中删除数据。DELETE 语句必须遵守如下规则: 如果存在具有同一视图或任一成员表的自联接,则不能使用 DELETE 语句。 
    分布式分区视图规则
    除了为分区视图定义的规则外,分布式(远程)分区视图还有下列附加条件: 将启动分布式事务以确保更新所影响的所有节点间的原子性。
    XACT_ABORT SET 选项必须设置为 ON。
    远程表中的 smallmoney 和 smalldatetime 列分别映射为 money 和 datetime。因此,本地表中的相应列也应为 money 和 datetime。
    任何链接服务器都不能是环回链接服务器,即指向同一 SQL Server 实例的链接服务器。 
    如果视图中含有 INSTEAD OF 触发器,则不遵循上述规则而引用分区表的视图可能仍然是可更新的。但是,查询优化器不能总能够为含有 INSTEAD OF 触发器的视图生成和遵循所有上述规则的分区视图一样有效的执行计划。