MSSQL网页设计STORED PROCEDURES: GOOD OR BAD(存储过...

InnoDB事务型数据库的首选引擎，支持ACID事务，支持行级锁定存储历程
Author

DateOfSubmission

UserLevel

SaikalyanPrasadRao

07/06/2004

Intermediate

作者

提交日期

用户级别

SaikalyanPrasadRao

07/06/2004

中级



Iamsurethisissuehasbeentakenupanddiscussedinlotsofarticlesonthenet.Thisarticleaimstolookatbothsidesofthecoin.FirstwewilldwellontheadvantagesofStoredProcedures.



我确信这个成绩在网上已被会商屡次了。这篇文章是从两方面会商。起首我们先具体叙述一下存储历程的长处。

StoredProceduresprovideperformancebenefitssuchaslocaltodatabase,pre-compilingandcaching,aprogrammingframeworkwithuseofinput/outputparameters,reuseofproceduresandsecurityfeaturesuchasencryptionandprivilegelimitstousers.Apartfromthatitoffersmodularizationofcodeandchangesareimmediatelyaffectedunlikebusinesscomponentswhichneedtoberecompiledanddeployed.Notforgettingthatwiththeadventof.Net,deploymentissueshavebeenreducedquitealot.Butneverthelesschangesmadetoanycomponentdoneedtoberebuilt.Theotherbenefitsincludesavingonroundtripstotheclientappsandreductionofnetworktraffic.



存储历程供应诸如数据当地化、预处置弛缓冲等特性，一个利用输出输入参数的架构，可反复利用存储历程和平安特征作为加密手腕和权限设定来限定用户。个中一部分来自它的代码模块化，数据变动的时分不用像贸易组件那样必要从头编译和部署。别忘了自.Net的呈现后，部署已被年夜年夜简化了，但对任何组件的变动仍需从头编译。另外一个优点就是节俭了与客户端使用程序的交互工夫和加速收集呼应。

ButontheflipsideStoredProceduresdocomewithitsownshareofproblems.DebuggingandmaintenancehasalwaysbeenaknownissueanditmakesiteventhemoredifficultwhendeveloperslikemegetusedtoVS.Netdebugger.Onasidenote,IdothinkMicrosofthasalwaysbuiltaverygooddebuggerinVS/VS.Net.



可是，存储历程的另外一个反作用则发生于它本身。调试与保护已成为一个尽人皆知的话题，关于像我如许已习气了VS.Net的调试器的开辟者来讲，这个大概更加坚苦。从某个角度来讲，我以为微软VS/VS.Net调试器其实不老是体现得很好。

Managingchangesinstoredproceduresandapplyingservicepackreleasescanbeabitteethingattimes.Apartfromthisthereareissuespertainingtomigration.WhatifyourapplicationwhichwasbuiltwithSQLServerneedstobeportedtoOracleoranyotherdatabase?Itwould/isanightmareconvertingallthosestoredproceduresandT-SQLspecificcodetoacompatible/ANSISQLcodeforthatdatabase.



偶然存储过程当中的变化和使用服务包使用大概有点方便。除这点以外，另有一个移植方面的成绩。假如你的使用程序是用SQLSever编写的，但如今要移植到Oracle或其他数据库你该怎样办？把一切的存储历程和T-SQL代码转向一个与方针数据库相兼容的SQL代码几乎就是个恶梦。

Personally,IwouldliketogoinforstoredproceduresandleveragemostofthedatabasecapabilitiesifIknewmyprojectwasgoingtouseaspecificdatabaseandwouldn’tchange.Iamsuremanymustbethinkingonthesamelines.AfteralloneofthecoolfeaturesthatIlikedaboutSQLServerwasitssupportforXML.YoushouldtrydoingbulkupdatesthroughXML,workslikeacharmandthattoowithlessamountofcode.Infactin.Net,datasetshavethecapabilitytooutputoutXMLrepresentationofdatawhichsavesyoutheeffortofwritingcodetoformulatetheXML.PumpinginofBusinessLogicinStoredProcedureshavebeendoneandmakesalotofsenseforsmallprojects.Butifyouwanttoscaleupyourapplicationitposesaproblemsinceyourdatabaseandbusinesslogicgettiedtoyourdatabasetier.Iamsureforsmallprojectsitwouldn’tmattermuchbutforalargescaleenterpriselevelsolutionthiswouldatsomepointintimeposeahugeproblem.



假如我晓得我的项目工程利用一个特定的数据库并且不会变动的话，我倡始利用存储历程。我信任良多人也有一样的设法。究竟SQLServer有着一个可以撑持XML的特征。你能够经由过程XML来举行大批的数据更新。现实上，在.NET里，数据集可以把已存储的数据以XML的数据体现情势输入XML文件。存储过程当中贸易逻辑的导进使得良多小项目变得十分简单。可是，假如你想扩大的你使用程序，就会发生一个成绩，由于你的数据库和贸易逻辑绑缚在你的数据库tier。关于小工程来讲这其实不主要，但关于年夜型企业级的办理计划来说，便可能是个浩劫题了。

Iamsuretherewillalwaysbetwodifferentschoolsofthoughtsonwhetherornottousestoredprocedures.Allsaidanddone,itdoesraiseaninterestingissue.Ifweweren’ttousestoredprocedures,whatcouldbeanalternative?DifferentsolutionscometomindsuchasagenericDBlayercomponentwhichwouldhaveallANSISQLstatementswhichwouldallowonetoconnecttovariousdatabasesorthead-hocSQLapproach.Butbothoftheseapproachesdocomewithitsshareofhurdlesandpitfalls.Weallknowhowbrittlead-hocscriptsaresinceanysmallchangetothedatabasecouldhaveseverimpactsonyoursystem.BuildingagenericDBcomponentneedstohaveaproperlydesigneddatabasewhichwouldgetaffectedeverytimeyourdatabasechanges.



我信任关于是不是利用存储历程一定有分歧的定见。这会引发一个很风趣的话题。假如我们不利用存储历程的话，会呈现甚么替换办法呢？分歧的办理计划会招致如许的一个数据库层组件的发生：它具有一切ANSISQL表达式来顺应多种分歧的数据库或是特定的SQL办法。但这两种办法都有配合的弱点。我们都晓得，特定的剧本是很懦弱的，对数据库中的任何一个很小的变更都大概影响到你的体系。创建一个通用的数据库组件必要一个计划优秀的的数据库来承受外界对数据库的修改。

Iguesswithbothsideshavingitsownshareofadvantagesanddisadvantages,Ifeelthebestapproachwouldbeistomakebestofboththeworlds.Allinsertions,updating,selectsetctobedoneinstoredprocedureswhichwouldenablemetoleveragesomeofthecoolfeaturesofSQLServerlikeXMLupdatesandputthebusinesslogicintocomponentswhichwouldallowmetoeasilydebugandscalethem.



我料想这两个方面都有它们的长处和弱点，我以为最好的办理办法就是一分为二的对待成绩。一切的Insert、Update、Select等都能够在能让我利用的SQLServer的XML更新功效的存储过程当中完成，而把贸易营业逻辑放到能让我轻松调试和扩大的组件中往。

TheupcomingreleaseofSQLServer“Yukon”andASP.Net“Whidbey”aimstoaddresstheseissues.YukoniscomingupwithinbuiltsupportforCLR.Thatmeanswecannowcodestoredproceduresinanyofthe.NetlanguageswhichiseasiertowritethanT-SQLandatthesametimeleveragethepowerfuldebuggingfeaturesofVS.Net.InASP.Net“Whidbey”thereareplansofintroducinganewextensibilitypointcalledProviders.ThisnewProviderModelwouldsupportmanynewfeatureslikesMembership,Personalization,RoleManager,SiteNavigation,BuildProviders,andHealthMonitoringetc.TheProviderModelinASP.NetWhidbeyenablesdeveloperstocompletelyun-plugthelogic/behavior/datainteractionofaparticularfeatureofASP.Netandreplacesitwithone’sownlogic/datalayer.InshorttheProvidermodelprovidesbothdataandbusinesslogicabstraction.



行将公布SQLServer“Yukon”与ASP.Net“Whidbey”都针对这个成绩作了会商。Yukon撑持CLR。这也就意味着我们能够在具有壮大的调试功效的VS.Net里，利用恣意的.NET言语来替换T-SQL来编写存储历程。在ASP.Net“Whidbey”中，有企图提出一种称为Provider的可扩大的办法。这类新的ProviderModel会撑持很多新的特征，比方Membership、Personalization、RoleManager、SiteNavigation、BuildProviders和HealthMonitoring等。ASP.NetWhidbey中的ProviderModel可以让开辟者完整往除ASP.NET中的逻辑/举动/数据交互，取而代之的是一个逻辑/数据层。简言之，ProviderModel把数据与贸易逻辑笼统化。

Boththeupcomingreleaseshavetriedtobridgethegaps.Iforoneameagerlywaitingfortheirrespectivereleasestohappen.Whethersuccessfulornot,onlytimewilltell.



我一向在守候它们各自的版本的公布。不管乐成与否，工夫会证实统统。
支持大型的数据库。可以处理拥有上千万条记录的大型数据库。

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

从项目平台的选择上讲，我们关心的，应该是一款产品能不能满足任务需求，而不是网上怎么说。

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

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

发几份SQL课件，以飨阅者

发几份SQL课件，以飨阅者

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

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