Documents

0072230657_ch01.pdf

Description
Color profile: Generic CMYK printer profile Composite Default screen ORACLE Series TIGHT / Effective Oracle by Design / Kyte / 223065-7 / Chapter 1 Blind Folio 1:1 CHAPTER 1 The Right Approach to Building Applications P:\010Comp\Oracle8\065-7\ch01.vp Wednesday, July 30, 2003 12:56:14 PM Color profile: Generic CMYK printer profile Composite Default screen 2 ORACLE Series TIGHT / Effective Oracle by Design / Kyte / 223065-7 / Chapter 1 Blind Folio 1:2 Effective Oracle by Design n this ch
Categories
Published
of 74
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  CHAPTER  1 The Right Approach toBuilding Applications  2 Effective Oracle by Design I nthischapter,wewilllookatsomeofthe“softer”issuesregardingOraclebestpractices. These issues pertain to system design, development, testing, deployment,and maintenance. They are not really Oracle-specific, but they are approached fromanOracleperspective.Eachoftheseitemswouldberelevantinvirtuallyeverysystem, regardless of the software or even the goal (what you were trying to build).This will be the least technical of all of the chapters in this book. Nevertheless, it may be themost important one. Time after time, the mistakes I see being made are more procedural thantechnical in nature. Here are a few examples: ■ The tendency to put up walls between developers and database administrators (DBAs).I’ll examine the potential consequences of this and offer advice to help make therelationship more productive for everyone involved. ■ The decision that a testing environment is too costly. On the contrary, not having oneis far more expensive in the long run. ■ The failure to fully exploit what the database has to offer. This can be due to ignorance;or it can stem from a desire to remain database-independent; or it can be related to fear,uncertainty, and doubt what I call FUD. In any case, it often leads to applications thattake longer than necessary to develop and that don’t perform up to the developer’sexpectations.These and related topics are the focus of this chapter. It’s a Team Effort Teameffortreallyhasnothingtodowithtechnologyorsoftware.Thisisallabouthumaninteraction.Let’s face it: Many of the issues we encounter during software development have more to dowith politics than they have to do with technology. I cannot tell you how many times I’ve seendevelopment efforts thwarted by policy, procedure, and politics, rather than stymied by sometechnical challenge.Too often, the relationship between database development team members and the DBA staff members that support them is characterized by a heavy-duty “us versus them” mentality. In suchan atmosphere, DBAs often feel a need to protect the database from the developer. On the otherhand, developers feel that they must thwart the DBA in order to implement features in the waytheydesire.Attimes,tryingtogetthesetwogroupstoworktogether,I’vefeltmorelikeamarriagecounselor than an onsite database expert!What we really must remember is that teamwork is a two-way street. Developers often feelthat DBAs impose too much of a burden on them to prove why they need a certain privilege orwhy they need a certain feature enabled. In fact, this is often a reasonable request. The grantingof database privileges should be done with care and thought. There is nothing wrong with a DBArequesting that a developer document why he needs, for example, the CREATE VIEW privilegegranted directly to his development account (we’ll take a deeper look at this in a moment). Onthe other hand, it is unreasonable for a DBA to assume carte blanche  authority to outlaw certaindatabase features, such as database views, stored procedures, or triggers.  Chapter1:The Right Approach to Building Applications 3 Here is just one example of such attitudes in action (taken from my AskTom web site):“Stored procedures—are they evil?Whatarethedrawbacksofusingstoredprocedures?Isthereanyoverhead?IamanoviceOracleDBA.IhavebeenaskedbyoneoftheSQLprogrammerstoauthorizehimwiththeCREATE PROCEDURE system privilege on an ORACLE user…”Inmyanswer,Iexplainedtheoverwhelmingbenefitsofstoredprocedures.IpointedouthowtheycanhelptheDBAtunetheapplications(withouthavingtodiveintotheapplication).Iemphasizedthatstoredproceduresareagreatsecuritymechanism,aperformanceenhancementtool,andanawesomeprogrammingdevice.IadvisedtheDBAtopermittheuseof storedprocedures.Isuggestedthatdeveloperscoulddoasmuch,ifnotmore,damagebyputtingbadSQLintheirclientapplications.Furthermore,IpointedoutthatiftheSQLwereinstoredprocedures,atleasttheDBAcouldreasonablyinspectitandhelptotuneitandmanageit.Thefollow-upresponseswereextremelypolarized,demonstratingtheexistenceofachasmbetweenthedevelopmentandDBAcamps.TheattitudeoftheDBAswas,“It’smyjobtoprotectthedatabase.”Theattitudeofthedeveloperswas,“It’smyjobtocode,andit’stheirjobtoletmedothat.”Onedeveloperexpressedtheopinionthatit’stheDBA’sjobtorevieweverylineofcodethatgoesintothedatabase.ADBArejectedthis,sayingthatitwas,infact,the developer’s job to do that. And so the argument went on.Inreality,itwouldbeimpossiblefortheDBAtoinspectandrevieweachlineofcodegoingintothedatabase,forgettingforthemomentthataDBAisn’tadeveloperingeneralandwouldn’tnecessarilyunderstandwhattheywereevenlookingatiftheydidreviewthesourcecode.Clearly, the DBA staff and the development staff often feel that they have totally differentobjectives, but this is not the case. The DBA doesn’t work just to protect the database, but neitherdoes the DBA work solely to serve the developer.Much like an overprotective parent, a DBA who takes the “protect the database from thedevelopers” mindset will not be productive. On the other hand, the developer isn’t programmedtothwarttheDBA(contrarytopopularDBAlore).Developershaveajobtodoandarejusttryingtodoit.Theirsharedobjectiveistobuildafunctionaldatabaseapplicationthatmeetstheendusers’requirements, performs well, scales as required, is maintainable, and was developed in as cost-effective a manner as possible. Unless the two teams work together toward this common goal,the chances for success are severely curtailed. If there is a virtual wall, or even worse, a physicalwall between the two teams, many of these goals cannot be realized. DBA and Developer Roles Typically, the DBA knows more than the developer about the database and how it works, and thedeveloper knows more than the DBA about software development. This is a natural outcome of their job descriptions.  DBAs are generally responsible for understanding the database architecture, how to patch thedatabase, and how it works. They would not be able to craft a successful backup and recoveryprocedure (for example, if they did not have this knowledge) as an intimate understanding of theOraclearchitectureisneededtoaccomplishthatparticulartask.IftheDBAdidn’tunderstandthe architectural relationship between database control files, datafiles, and redo logs, they wouldinvariably make mistakes during the backup and recovery process. The DBA lives to work withthe database.Developers are generally programmers/analysts who see the database as just another tool—something that must be used to achieve an end. In many cases, they spend much of their timedoing “nondatabase” work, such as interface design.Whatweneedhereissomecross-pollination.Ifthetwoteamscanworktogether,thengradually,thedeveloperswillknowmoreabouthowthedatabaseworks,andtheDBAswillbeinamuchbetterpositiontohelpfacilitatetheirdevelopmentprocesses.I’ve drawn up two lists of do and don’t advice—one list for DBAs and one for developers—that will be helpful in closing out this section. This advice addresses some of the more damagingattitudes that exist. DBA Dos and Don’ts DBAs, do not consider that your primary job is to protect the database from the evil developers.The database is their tool, and you can and should counsel them on how best to use it, ratherthan attempt to protect it from them. Do not consider the developer your enemy.Also,donotoutlawafeatureorfunctionwithoutproperjustification.Toooften,thesedecisionsarebasedonfearanduncertainty,oronthatonebadexperience.Thefollowingaresomecommonrestrictions: ■ No views allowed. The reasoning behind this is usually that a DBA once experiencedbad performance with a view and, therefore, views must be evil. If you applied suchreasoningconsistently,youwouldendupoutlawingSQLwhenyoucameacrossapoorly performing query. ■ Nostoredproceduresallowed.Thisonereallyconfusesme,sinceaDBAshouldoptimallywant everything in a stored procedure. If this were the case, they would know exactlywhat module depended on what database object. They would be able to easily tune apoorly performing module if the problem was SQL-based (just read the code from thedatadictionaryandplaywiththeSQL).TryhavingaDBAtuneaJava2EnterpriseEdition(J2EE) application some day, since they are not  developers, they do not program using J2EE, they would not know where to begin. If the database portion of the application isin the database, tuning the database access becomes easy. ■ No features added after version 6 allowed. This is common among old-time DBAs, whoare leery of anything new—PL/SQL, triggers, application contexts, fine-grained auditing,fine-grained access control, and so on. All they want is keyed reads into the database(if they could only outlaw joins!). My suspicion here is this is a DBA who wants as littleresponsibility for anything at all. If all the developers do are simple Data ManipulationLanguage (DML) statements, the DBA’s job is trivial. But the company as a whole loses,since it paid a lot of money for this database stuff but cannot use it. 4 Effective Oracle by Design
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks