MYSQL教程之为下拉式数据窗口创建缓冲区

MySQL的支持者们却认为，MySQL所保留的功能都是精华，并且是你部署、MySQL学习教程配置和维护这个数据库所必不可少的一些功能。数据|下拉为下拉式数据窗口创建缓冲区
张健姿01-6-22下战书04:47:33

同其他4GL工具如Delphi，VisualBasic的早期版本一样，PowerBuilder4.0以前所天生的可执行文件使用是伪代码，也称P-Code（pseudo-code）。P-Code在运行时是被解释执行的，更准确地说，P-Code使用的是虚拟机指令，为不同的宿主机提供共享的操作命令。在运行时，操作系统根据不同平台解释实现P-Code指令。一条P-Code指令可以替代几条机器代码指令，如许就减少了执行代码的年夜小，不过却以应用的执行效力为代价。一般的，P-Code的执行速度要慢于编译代码，但文件的年夜小却小于编译代码。PowerBuilder5.0引进了生成全编译的可执行代码的功能，以提高运行效力，但同时它也保留了使用P-Code为可执行文件的功效。使用P-Code的应用程序包括执行文件.EXE和PowerBuilder的动态连接库.PBD，而编译代码所产生的执行文件为.EXE文件和动态连接库DLL。什么是编译代码编译代码起首以P-Code为基础，PowerBuilder首先根据P-Code创建C代码，然后将C代码编译成为机器代码的执行文件。编译后的实行程序中，所有指令都是实际的机器代码。这就意味着这样的执行文件的年夜小将远年夜于P-Code。使用编译代码仍需要PowerBuilder的运行库，PowerBuilder在执行机器代码时，仍使用共享的函数库，这样做的目的主要是为了节省内存。使用动态连接库可以避免将所有的功能函数都写在一个可执行文件中，以减小可执行文件的体积。而在Windows环境中，内存中留有一份DLL的拷贝可觉得多个应用程序使用。此外PowerBuilder5.0还压缩了一些DLL中函数的年夜小，现在32位平台上运行时只需7个动态毗连库，解压缩后为4.5M。应用所需要的其它DLL如用于数据库访问、分布式PowerBuilder，及RTF编辑器等可在用到时动态地装进。编译代码创建编译代码的创建有以下几个步骤：在开发的过程中，PowerScript首先被翻译成了P-Code，当您在Script编辑器中编写完一个事件或函数的代码返回窗口时，系统就会自动地翻译这一段Script代码。当您在工程画笔中创建P-Code可执行文件时，PowerBuilder将为不同的PBL中不同对象之间的引用建立起连接，并将这些对象拷贝到指定的EXE或PBD文件中。这是一个绝对较快的过程。接下来P-Code将被翻译成为C语言的语句。在这一过程中，工程画笔窗口下面的微帮助中将显示"compiling..."的字样，这一过程约占全部编译时间的10％。然后是将C代码编译和链接成为机器代码，形成可执行文件和动态连接库，在这一步骤中，微帮助显示的是"generating..."，这一编译过程最费时间，将占约90％的编译时间。通过上面的介绍，我们看到创建机器代码所用的时间比产生P-Code的用时要多得多，因为后者只是一个二进制代码搬运的过程。因此在开发过程中，我们一般使用的主要是P-Code，只是在最终交付用户使用时，才根据实际情况选择是不是创建机器代码。编译代码的优势：在以下这几个方面，将PowerScript代码编译成为机器代码将得到较快的运行速度：・循环结构・浮点运算・整数运算・函数调用但是在另外的一些方面，编译成为机器代码并不能使运行速度分明加快，如涉及图形用户界面，数据库访问，小数运算，字符串操作等。在有些情况下，两种代码的速度是相同的，如对资源的调用和对数据窗口的执行。在这些情况下，您就无法通过使用编译代码来提高运行的速度了。如果您的使用是以执行自身的代码为主，例如应用中较多的是统一条代码被反复执行（如循环）或是编写的代码主要用来进行数学运算，这样的应用应当使用编译代码。在函数调用方面，使用机器码也要比P-Code快得多。因而如果您的Script年夜量的调用函数或是采用新的语法情势调用事件，使用机器码也将是个好的选择。不过您应当记住，编译代码的执行文件年夜小要比P-Code年夜很多，因为一条PowerScript代码将有可能编译成为5条甚至10条C代码。当这些C代码被编译后，可执行的代码将远远年夜于相应的P-Code，因此如果您的应用程序的文件巨细是您应用的首要考虑因素，或者您的应用较多的是数据库访问，那您应当选择使用P-Code。提高应用的性能事实上，一个好的数据库的物理设计和应用程序的模块设计能够年夜年夜地提高应用的性能。如果应用设计不好，即使使用了编译代码，也不会得到很好的系统性能。此外调整系统参数设置和合理的物理带宽，可以使PowerBuilder5.0的应用运行得十分快捷。在PowerBuilder5.0中，系统内部已经在一些功能上进行了增强，对这些功能加以利用，本身就可以实现性能的优化。・使用PowerBuilder5.0的Tab控件时，如果在TabPage的属性中选中"createondemand"这个复选框，在运行时，只有当用户选择这个TabPage，PowerBuilder才往初始化该TabPage对象的实例。・使用DataStore而不要使用不可视的DataWindow作为数据的缓冲区。・传递string、datetime等数据类型的参数尽可能使用read-only方式，因为同采用reference方式相比，PowerBuilder无需为这些参数再于内存中复制一份拷贝。同理，reference方式要比value法传参更快一些。・使用局部变量要比全局和共享变量要快一些，因为局部变量存在栈中，而全局变量则存储于远堆。这个速度的差异在使用机器代码时比P-Code更为明显。・使用数组对DataWindow的数据进行赋值，而不要使用SetItem()和GetItem()系列的函数，因为前者只使用了一次函数，就调用了所有的行和列。・为加快编译速度，不要在一个事件或函数中编写过长的代码，将它们分成几个函数或其他可重用的代码对象。・调整您的数据库。一般来说，数据库访问在客户/服务器结构的应用中要占用年夜量的工夫，尽可能利用PowerBuilder的特性来减少数据库访问的工夫，包括：1.在5.0中DBParm缺省设置StaticBind=1，也就是说在检索数据之前，PowerBuilder并不首先获取查询数据结果集结构的描述，这样作可以提高数据的检索速率，但是如果数据窗口同数据库的结果集不匹配时，将发生错误。因此如果您需要动态改变数据窗口所查询的表，而且这些表结构不同时，您应当将StaticBind的值设置为0。2.DBParm缺省设置允许DataWindow放置BLOB字段，使用DataPipeline可以对数据库插进BLOB字段的数据。3.通过DBParm的设置可以使数据库支持游标。设置DBParmSQLCache=n将告诉PowerBuilder将为多少个使用不同SELECT语句的游标建立缓冲。如果您多次重复使用同一个SELECT语句，当缓冲区内有数据时，检索的速度将年夜年夜加快。SQLCache的缺省值为0。4.PowerBuilder5.0中对数据窗口有了这样的一个选项，可以将数据窗口的结果集保存在本地磁盘上。这样作可以减少内存的使用，使您创建更年夜的报表，不过存取速度比将结果集放在内存中要慢很多。如果您的数据窗口将显示的不是一个很年夜的报表，一般还是将结果集放在内存中为佳。其它的注意事项对于用户利用PowerBuilder编译代码，还有以下几点值得说明：・PowerBuilder产生编译代码的速度很慢，应尽可能使用主频较快的计算机，最多至64M内存，不外在5.0的版本中，多CPU对提高编译速度没有任何匡助。・PowerBuilder所使用的Watcom的技术主要是32位的技术，尽管在32位平台上有生成16位代码的选项，但是速度却并不见佳。另外在16位平台上，我们不能产生32位的应用程序。・编译16位应用程序有一个限制就是代码和数据都不能超过64K，如果函数或事件中的代码过长，PowerBuilder在创建EXE时将产生错误。我们推荐的办理办法就是将长代码分解成多个小函数，这样做也能够提高运行效率并有利于您对应用代码的维护。・如果您在WindowsNT或Windows95上运行16位应用程序，您所使用的运行库也应当是16位的。・在一个PowerBuilder应用中我们只能使用P-Code的PBD或编译代码DLL中的一种，而不能将其混合使用，不过唯一的例外是使用PowerBuilder创建OLE服务器。・如果您只是想改变一个DLL，而并不想重新编译全部的应用，您可以在Library画笔中选择Library|BuildRuntimeLibrary...的菜单项。・在编译时，系统将首先剔除注释语句，所以Script中注释语句的多少对编译速度没有影响。・在您使用PowerBuilder的Plug-In技术时，您不能使用编译代码。客户还是可以使用DBaaS系统所能提供的所有能力。数据库云服务消除了组织对专职人员、本地数据库存储设备的需要。他们不必安装、配置和维护任何软硬件。

groupby子句可以将查询结果分组，并返回行的汇总信息Oracle按照groupby子句中指定的表达式的值分组查询结果。

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

同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中，就能感觉到目前架构的尴尬。

但换公司用MSSQL2K感觉自己好像根本就不了解MSSQL。什么DTS触发器以前根本没用过。

可以动态传入参数，省却了动态SQL的拼写。

数据库物理框架没有变动undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免I/O效率问题。

而写到本地,我又考虑到效率问题.大家来讨论讨论吧,分数不打紧,就给10分,十全十美,没啥对错,各抒己见,但是要有说服力的哦~

其实可以做一下类比，Oracle等数据库产品老早就支持了java编程，而且提供了java池参数作为用户配置接口。但是现在有哪些系统大批使用了java存储过程？！连Oracle自己的应用都不用为什么？！