About Oracle's readiness

Steven Feuerstein Four simple guidelines for improving the number and quality of PL/SQL code I've been writing PL/SQL code since 1990.     This means that I have written tens of thousands of lines of software code, but I am sure that most of the code is very poor and difficult to maintain. Fortunately, I find it's not too late to find and follow a new approach to writing better code.     It was in the last year that my code quality improved significantly, mainly because of the simple rules that were introduced and adhered to as discipline. This article has made four suggestions for both PL/SQL novice and experienced developers, and if you follow any of them, your code quality will improve.     These four suggestions are taken, and you may be surprised to discover that you are a very good programmer, far beyond your imagination. All the work is done alone. Few of us are isolated, and most of the PL/SQL development work is done in relatively large institutions. But basically we're working alone in our cubicle with our own equipment.     There are few PL/SQL development teams that perform formal code review or system testing. I cannot change the basic state of your development team through this article. Therefore, I carefully selected the following suggestions. The implementation of any of these does not require the consent of the management. Whether your group is big or small, you don't have to let everyone agree with the coding rules.  You only need to follow the following suggestions to change your own encoding method: 1.    Follow the naming conventions Strictly, as if they were the pillars of your life.    2. Kick the habit of writing sql: the less SQL you write, the better.    3. Make the execution part short: Say Goodbye to "spaghetti code".     4. Find a partner: very much agree to find someone to supervise your work.     1. Follow the naming convention if you build and follow a set of naming conventions, especially for application components, you can save a lot of time. Of course, the idea of following a naming convention is nothing new, and you may be tired of hearing it.     So I'm not proposing grandiose naming schemes, but rather giving some very specific and definite engagements and proving how useful these conventions are. I've been designing and building a new tool for PL/SQL developers for the last few months. It is named SWYG, which can be found in, to help programmers do the work of building, testing, and reusing code. It has several unique components.  I have specified a two-letter abbreviated name for each component, as follows: Sf-swyg the sm-swyg of the metadata sg-swyg of the base part of the SL-SWYG code base ST-SWYG Unit tests   I then followed the naming convention in table 1 and used the abbreviations. What are the benefits of following these conventions?     In general, if I ask for consistent naming rules, I can write code more smoothly and efficiently. Specifically, these conventions are predictable, meaning that the SQL program I write can generate useful scripts. For example, by using the Conventions in table 1, you can generate installation scripts for all the underlying packages in SWYG. The Sql*plus script that performs these tasks is shown in Listing 1. This kind of script is very useful because it means that I don't have to manually maintain the installation scripts.     When I add another table to the SWYG scenario and generate a set of related packages, I just run my script and the updated installation script jumps out. 2. The less SQL you write about the habit of writing SQL, the better it seems to be inconsistent with our intuition. This is a peculiar suggestion for PL/SQL developers, because one of the main advantages of PL/SQL is that it is easy to write the statement in code.     However, this simplicity is also a deadly weakness of the language. Pure SQL statements can be placed directly in PL/SQL code without the need for a middle tier such as JDBC or ODBC. Therefore, whenever and wherever, a PL/SQL developer will typically embed an SQL statement into their application code whenever they need the statement.     So what's the problem with that?    The use of SQL statements everywhere in PL/SQL code inevitably leads to the following consequences: Although the actual performance is different, the same logical statement can still be duplicated, resulting in excessive parsing and difficulty in optimizing the performance of the application. Expose business rules and programs. This includes the logic to execute business rules directly in the SQL statement.     These rules are always changing, so the maintenance costs of the application will increase dramatically. Of course, almost every PL/SQL application you write is based on the underlying tables and views. You need to execute the SQL statement.     The problem is not whether it executes, but when it executes and how it executes.     If you encapsulate the data structure, or hide them behind a PL/SQL code layer (usually a code package), your application will be more robust and you will find that creation and maintenance are much easier.  Let's look at a simple example. Suppose I need to write a program that handles the work of an employee. The first thing is to get the full name of the employee, defined as "name comma (,) last name"; then I can do a detailed analysis.     Listing 2 shows an example of this type of code that I would most likely want to write in this case. Everything seems to be so simple and straightforward; what could be wrong with the code? Actually, it was really bad. The main thing is I exposed a business rule: the structure of the full name. I may have to spend hours on this code and on theApplication for testing.     But just as it was in use, I realized that the customer would constantly call and tell me that, in fact, their full name should be represented as "first name space name." Now what?     Search for all single commas in quotation marks? A realistic solution is to use a package that hides all the details, provides only a set of predefined, predictive, and pre-optimized and can complete all tasks. Listing 3 is a process_employee process rewritten based on the encapsulated code.     The HR_EMPLOYEE_TP package provides the types of local variables that define the names that are saved; Hr_employee_rp contains functions that return full names based on a business rule. It's easy to pour the SQL code into the display of the PL + statements, and it's not too hard to talk about how important it is to encapsulate these statements. On the other hand, writing code that performs encapsulation tasks is challenging, even unrealistic.     It might make more sense to build these packages. A few years ago, I helped build such a build program. The program segment is Pl/generator and is now owned by Quest Software, and the PL/SQL Development Community is free to use.     You can get from my web site when you no longer write too much SQL, but instead call a program that executes SQL, your application will benefit from whether you are building or writing your own custom package. 3. Make the executive part of the short-faced reality: always against our judgments and the latest series of New Year resolutions, we must stop writing spaghetti-style code: Huge and lengthy, people can't actually understand them, let alone maintenance or upgrades.     How can we avoid "spaghetti"? In fact, the answer is simple: never allow more than 50 or 60 rows to be executed.     This size allows you to view the entire logical structure of the block on a single page of paper or on a screen, which means that you can really comprehend the program's intentions and understand it completely intuitively. You may agree very much, but at the same time laugh at my suggestion that the program code never exceeds 50 lines. Yes, you should laugh at it, because of course it is impossible.     There is no doubt that you need more than 50 lines of executable code; The question is where you put the code and how you organize it.    If you do the following, you can really deal with complex requirements and limit your code to 50 lines: Place all business rules and discrete logic blocks in their own programs (usually functions), so you can reuse the code carefully whenever possible.    Try to use local modules, procedures, and functions defined in the Declaration section of the program. Suppose I was compiling a call center application. I need to write a program that meets the following requirements: "For each employee in a specific department, the amount of work (the number of calls assigned to that employee)Compare the average workload with that department's staff. If an employee's workload is lower than the average workload, the next pending call is dispatched to the person, and the contract is scheduled based on that situation. "I learned from my previous work: My friend Claudia has written an analysis package that returns information on workload.     However, assigning pending calls and scheduling conventions are all new work, as detailed in the remainder of the requirements documentation. I wanted to read all the 15 pages at first, but I didn't do that.     I used a technique called "stepwise refinement" or "top-down design", and first wrote the code in Listing 4 to implement the program. The following is an explanation of the most critical line of code in Listing 4, which starts with the last step of the program (the Compact execution part).     This may seem counterintuitive, but it is really the best way to read through the process of writing with the step-up refinement method. Line 22nd to 30th. Iterates over all employees in the specified department with a cursor for loop (cursors for loop). In line 24th to 25th, use the program in the analysis package to determine whether the current employee is under-workload. In line 27th to 28th, call three programs: Assign_next_open_case, Schedule_case, and Next_appointment.     I don't know how to implement these programs yet, but I know that they express the work that needs to be done in advance by their name and parameter table. Line 10th to 19th. Create a stub for the three programs in line 27th to 28th, which is the placeholder program.     Note that they are local modules that are defined in assign_workload and cannot be called from any other program. Line 5th to 8th. Defines a cursor for all employees in the specified department.     You can now try to compile this code. Successful compilation of such a small program seems like a small victory, and it does.     Doing the right compile, then the simple test, then adding a little bit of code, then compiling it correctly, and so on, and so on, the small victories created a well-constructed program, and would be very satisfied. I can also verify that the parser is valid and that the appropriate employee is identified for the task to assign. When all this work is done, I'll pick one out of three programs, such as Assign_next_open_case, for the next or next level of fine design.     I want to read the documentation for this task and write a short execution section in Assign_next_open_case that will reflect the overview of the task.     Soon, my local process has its own local processes and functions, but at every step of the process, my code is short, readable, easy to test, and can be adjusted as needed. 4. Find a good partner computer does not program, talent will。 How many times have you been sitting in front of a computer with a bent waist and a camel on your back, frustrated by the inability to find errors in your code? First a few minutes passed, and then a few hours later.     Finally, tired of yourself, feel very defeated, you put your head out of your cubicle and ask a friend to help you see.    Typically, one of the following three scenarios occurs: when your friend gets up from her chair, everything becomes very clear in an instant.    Your friend glanced at the screen and immediately pointed out the problem. Your friend is not responsible for the part of the system that you are doing, so you have to explain what your program is doing.    As you step through the logic, the problem that causes the error is suddenly exposed to you.  The truth is that it's hard for you to debug your code, because you're too engaged and focused on it yourself.     Next read more about Oracle Database 10g

Preparing for Oracle