MYSQL编程：ACCESS存储数据极限

据我的观察，现在有一个趋势，那些经过正式培训的数据库管理员DBA更倾向于选择一个专有关系数据库，例如Oracle。对于一些具有专门数据库管理员的比较大的环境来说，MySQL很难得到宠爱，这时候，关于MySQL是否真的具有良好的可扩展性的争论已经没有意义。access|数据Access数据库的存储下限
Access规格
MicrosoftAccess数据库规格
Access数据库



属性最年夜值
MicrosoftAccess数据库(.mdb)文件巨细2G字减削往体系工具所需的空间。
数据库中的工具个数32,768
模块（包含“内含模块”属性为“是”的窗体和报表）1,000
工具称号中的字符数64
暗码的字符个数14
用户名或组名的字符个数20
并发用户的个数255



表



属性最年夜值
表名的字符个数64
字段名的字符个数64
表中字段的个数255
翻开表的个数2048；实践可翻开的表的数量大概会少一些，由于MicrosoftAccess还要翻开一些外部的表。
表的巨细2G字减削往体系工具所需的空间
“文本”字段的字符个数255
“备注”字段的字符个数经由过程用户界面输出为65,535；以编程体例输出时为1G字节的字符存储。
“OLE工具”字段的巨细1G字节
表中的索引个数32
索引中的字段个数10
无效性动静的字符个数255
无效性划定规矩的字符个数2,048
表或字段申明的字符个数255
纪录的字符个数（除“备注”字段和“OLE工具”字段外）2,000
字段属性设置的字符个数255



查询



属性最年夜值
实行干系的个数每一个表为32减往表中不包括在干系中的字段或字段组合的索引个数
查询中的表的个数32
纪录会合的字段个数255
纪录集巨细1G字节
排序限定255个字符（一个或一个以上字段）
嵌套查询的条理数50
查询计划网格一个单位格中的字符个数1,024
参数查询的参数字符个数255
WHERE或HAVING子句中AND的个数99
SQL语句中的字符个数约为64,000



窗体和报表



属性最年夜值
标签中的字符个数2,048
文本框中的字符个数65,535
窗体或报表宽度22英寸（55.87厘米）
节高度22英寸（55.87厘米）
一切节加上节页眉的高度（在“计划”视图中）200英寸（508厘米）
窗体或报表的最年夜嵌套层数7
报表中可作为排序或分组根据的字段或表达式个数10
报表中页眉和页脚的个数1对报表页眉/报表页脚，1对页面页眉/页面页脚，10对组页眉/组页脚
报表的打印页数65,536
可增加到窗体或报表的控件和节的个数754
SQL语句中作为窗体、报表或控件的“纪录源”或“行来历”属性的字符个数（合用于.mdb和.adp）32,750



宏



属性最年夜值
宏中的操纵个数999
前提中的字符个数255
备注中的字符个数255
操纵参数中的字符个数255




MicrosoftAccess项目规格
Access项目



属性最年夜值
MicrosoftAccess项目(.adp)中的工具数量32,768
模块（包含“内含模块”属性为“是”的窗体和报表）1,000
工具称号中的字符数64
表中的索引个数250(MicrosoftSQLServer6.5)
1024（MicrosoftSQLServer7.0和2000）




MicrosoftSQLServer数据库



SQLServer文档中形貌了MicrosoftSQLServer最年夜容量规格。有关SQLServer联机丛书的具体信息，请拜见MicrosoftDevelopersNetworkWeb站点。



注重利用该主题中的超链接会跳转到Web上，但随时能够切换回“匡助”。



窗体和报表



属性最年夜值
标签中的字符个数2,048
文本框中的字符个数65,535
窗体或报表宽度22英寸（55.87厘米）
节高度22英寸（55.87厘米）
一切节加上节页眉的高度（在“计划”视图中）200英寸（508厘米）
窗体或报表的最年夜嵌套层数7
报表中可作为排序或分组根据的字段或表达式个数10
报表中页眉和页脚的个数1对报表页眉/报表页脚，1对页面页眉/页面页脚，10对组页眉/组页脚
报表的打印页数65,536
可增加到窗体或报表的控件和节的个数754
SQL语句中作为窗体、报表或控件的“纪录源”或“行来历”属性的字符个数（合用于.mdb和.adp）32,750



宏



属性最年夜值
宏中的操纵个数999
前提中的字符个数255
备注中的字符个数255
操纵参数中的字符个数255
需要处理因此带来的更多的支持工作，这有可能会带来成本上的提高。在这种情况下，一些MySQL学习教程发行商可能倾向于选择别的开源数据库，例如遵循BSD授权的PostgreSQL。

还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。

多走走一此相关论坛，多看一些实例开发，多交流0经验，没什么的，我也是刚学没多久!加油

对于微软系列的东西除了一遍遍尝试还真没有太好的办法

语句级快照和事务级快照终于为SQLServer的并发性能带来了突破。个人感觉语句级快照大家应该应用。事务级快照，如果是高并发系统还要慎用。如果一个用户总是被提示修改不成功要求重试时，会杀人的！

大侠们有推荐的书籍和学习方法写下吧。

XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应该是相当的熟了！）

所以你总能得到相应的升级版本，来满足你的需求。

一个是把SQL语句写到客户端,可以使用DataSet进行加工;