MYSQL编程：平安的ACCESS加密办法

表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。access|平安|加密
平安的ACCESS加密办法

徐长友


Microsoft的ACCESS数据库，是我们经常使用的桌面数据之一，年夜多中小企业的数据库办理体系都能够接纳它，但其平安性一向使人担犹，试想，一套财政办理体系，用户间接翻开数据库往变动数据，成果会怎样？有些体系对ACCESS数据库大概只是变动扩大名，或加个暗码，尽人皆知，破解ACCESS暗码的办法和工具网上多的是！以是如许的加密一样使人担犹，上面先容一个复杂的办法，完成ACCESS数据的加密，供人人参考。

用UltraEdit翻开MDB文件能够看到，文件前16个字节的内容：
000100005374616E64617264204A6574
如今任意变动几个，再用ACCESS翻开，发明呈现分歧辨认的文件格局毛病，由于ACCESS后面保留的信息都是一些MDB文件的界说和口令，假如变动这些内容，他人就很丢脸出这个数据库的格局，没法翻开它了，并且如许不会对数据库的内容作变动，不会损坏原本的数据。

上面就用Delphi作个复杂的加密解程序：

用到的加密解函数以下：

const
titlestr:array[0..15]ofbyte=
($00,$01,$00,$00,$53,$74,$61,$6E,$64,$61,$72,$64,$20,$4A,$65,$74);//对应MDB文件的前16个字节
titlestr2:array[0..15]ofbyte=
($48,$4A,$00,$58,$55,$43,$48,$41,$4E,$47,$59,$4F,$55,$00,$20,$20);//变动后的MDB文件的前16个字节，本人任意写吧，好比写上本人公司的简称或自已的名
produceEncrypMDB(filename:string);//用titlestr2内容交换MDB前16个字节，以便完成加密的感化
varF:TFileStream;
begin
ifnotfileExists(filename)thenexit;
F:=TFileStream.create(filename,fmopenwrite);
try
F.seek($00,soFromBeginning);
F.Write(titlestr2,16);
finally
F.free;
end;
end;
produceuncrypMDB(filename:string);//复原MDB前16个字节
varF:TFileStream;
begin
ifnotfileExists(filename)thenexit;
F:=TFileStream.create(filename,fmopenwrite);
try
F.seek($00,soFromBeginning);
F.Write(titlestr,16);
finally
F.free;
end;
end;

我们晓得翻开ACCESS数据库后会呈现一个锁定文件(.ldb文件),由于我们本人也要利用数据库，以是必需在利用时复原数据库。
假如复原后没有举行加密的话，用户一样能够复制MDB文件，然后用ACCESS或别的工具翻开它，以是应当在数据翻开前后都处于加密形态才干包管数据的平安。
用Delphi接纳ADO毗连数据库用以下办法能够完成：

//复原数据，以便自已利用数据库
copyfile(pchar(APP_path+dataaccount.db),pchar(app_path+data        emp.db),false);//app_path暗示程序确当前目次，account.db是个变动了扩大名的MDB文件
uncrypMDB(App_path+data        emp.db);
copyfile(pchar(App_path+data        emp.db),pchar(APP_path+dataaccount.db),false);
adoconn.connectionstring:=provider=Microsoft.Jet.OLEDB.4.0;DataSource=+App_path+dataaccount.db;PersistSecurityInfo=false;//adocon是个TADOConnection组件
try
adoconn.connected:=true;
except
MessageBox(handle,翻开数据库呈现致命的毛病！！！,毛病,MB_OK+MB_ICONERROR);
end;
//翻开后即刻对其加密
copyfile(pchar(APP_path+dataaccount.db),pchar(app_path+data        emp.db),false);//app_path暗示程序确当前目次，account.db是个变动了扩大名的MDB文件
EncrypMDB(App_path+data        emp.db);
copyfile(pchar(App_path+data        emp.db),pchar(APP_path+dataaccount.db),false);
deletefile(App_path+data        emp.db);
下面利用了两次一时文件，是由于数据库翻开后再对MDB举行间接的写进会呈现成绩，并且你没法往断定几个用户翻开了程序。
全部程序共用一个TADOConnection，只在翻开数据库毗连的时分复原MDB文件，别的工夫MDB文件一向都处于加密形态！用户复制了MDB文件一样平常很难晓得它是甚么！

翻开数据库后会有一个.ldb文件，范例会呈现ACCESS等字样，假如你不想让人看出是甚么的话就修正注册表吧,如:
reg:=TRegistry.Create;
try
reg.RootKey:=HKEY_CLASSES_ROOT;
reg.OpenKey(.ldb);
reg.WriteString(,tempfile);
finally
reg.closekey;
reg.free;
end;
如许用户看到的文件范例是tempfile

注：以上所用数据库都是指ACCESS2000，别的版本的我想应当迥然不同，本人下手尝尝吧。人人若有甚么更好的办法或倡议，接待来信交换：yousoft@chinaren.com
下面我将描述五个不使用MySQL的响亮理由。

SQL语言是学习所有数据库产品的基础，无论你是做数据库管理还是做数据库开发都是这样。不过具体学习的侧重点要看你将来做哪一块，如果是做数据库管理（DBA），侧重点应该放在SQLServer的系统管理上.

分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。

对于数据库来说，查询是数据库的灵魂，那么SQL查询效率究竟效率如何呢？下文将带对SQL查询的相关问题进行讨论，供您参考。

是否碎片会引发效率问题？这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。

但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）

这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高，但是相对映射到数据表中效率还是提高了很多。我做过试验，在我的实验环境中会比映射到表中提高30%左右的效率。

个人感觉没有case直观。而且默认的第三字段（还可能更多）作为groupby字段很容易造成新手的错误。

我个人认为就是孜孜不懈的学习

很多书籍啊，不过个人认为看书太慢，还不如自己学。多做实际的东西，就会遇到很多问题，网上搜下解决问题。不断重复这个过程，在配合sql的F1功能。