Clean coding in plsql and sql, v2

Clean Coding in PL/SQL and SQL Brendan Furey, April 2019 A Programmer Writes… (Brendan's Blog) Ireland Oracle User Group, April 4-5, 2019 Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 1

whoami Freelance Oracle developer and blogger Keen interest in programming concepts Started career as a Fortran programmer at British Gas Dublin-based Europhile 25 years Oracle experience, currently working in Finance Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 2

Agenda  General Programming Design Concepts (8 slides)  Outlining basic concepts behind programming design, and programming paradigms  Design Principles and Program Modules (6 slides)  Noting important design principles, and their application to package and subprogram structure  Object Types and Collections (6 slides)  Showing how object and record types and collections may be used to write cleaner code  API Design with Examples (6 slides)  Explaining how to design APIs for both usability and internal structure, with examples of external design and internal refactoring  Oracle and Other Languages (3 slides)  Concerning the integration of PL/SQL programs with other languages  Oracle's Object Orientation (5 slides)  Discussing appropriate use of Oracle’s object-oriented features  SQL and Modularity (4 slides)  Discussing application of modular design concepts in relation to SQL  Conclusion (2 slides)  Recommendations around Oracle program design Brendan Furey, 2019 3Clean Coding in PL/SQL and SQL

General Programming Design Concepts Brendan Furey, 2019 4 General Programming Design Concepts Outlining basic concepts behind programming design, and programming paradigms Clean Coding in PL/SQL and SQL

Modularity Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 5 Modularity “The concept of modularity is used primarily to reduce complexity by breaking a system into parts of varying degrees of interdependence and independence and "hide the complexity of each part behind an abstraction and interface.“  Many ways to decompose, but aim for:  High Cohesion within components  Low Coupling between components  Different programming paradigms decompose in different ways… OCR Computing A-Level Revision

Programming Paradigms: Diagram Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 6 Overview of programming paradigms

Imperative and Declarative Approaches Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 7 Two main approaches to programming  Imperative programming  Focuses on how to execute, defines control flow as statements that change a program state  Declarative programming  Focuses on what to execute, defines program logic, but not detailed control flow SQL and PL/SQL  SQL is a declarative programming language based on mathematical set theory  Database-centred, Structured Query Language  Not regarded as a functional programming language, but closer than to other paradigms  PL/SQL is an imperative, block-structured programming language based on ADA  Core language procedural, but…  Embedded SQL  Object-oriented features from v8 (1997); object types widely used, OO features such as inheritance and type bodies hardly ever used (why? to be discussed)  How do we most effectively use the two languages together?...

Prefer Declarative to Imperative Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 8  Declarative programming reduces the amount of code developer writes  Use of local variables, iteration etc. removed, detailed logic handled internally by language  Reduces scope for bugs, and enables faster development SQL Query  Returns data set from database tables based on declarative logic…  Specified table joins  Transformation rules, including aggregation, analytics etc.  …with some procedural features also possible, such as:  Subquery factor sequencing and recursion  Query projection originally flat, now may use object-relational mappings to return hierarchical data sets SQL and Modularity  Complex SQL may need to be designed with modularity in mind, to be discussed later

Thick Database Paradigm - Diagram Brendan Furey, 2018 Database API as Mathematical Function: Insights into Testing 9

SQL and PL/SQL Packages Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 10 Prefer SQL to PL/SQL  Database APIs form a layer between external or internal clients and the database  The API procedure is ideally just a simple wrapper around (for example):  An SQL query (‘getter’ method for report or web service)  SQL Inserts/Updates/Deletes (IUD) (‘setter’ method for batch program or web service) More Complex PL/SQL  Setter methods that involve multiple table IUDs  Unit test programs that require test data setup and teardown for repeatability  Instrumentation such as code timing and information and error logging PL/SQL and Modularity  Consider how best to write more complex PL/SQL in a clean, modular way  Take note of advantages various programming paradigms may have…

Programming Paradigms: Definitions Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 11 Main programming paradigms / Overview of the four main programming paradigms [Definitions below come from the two links above]  Procedural programming  Specifies the steps a program must take to reach a desired state  First do this and next do that  Object-oriented programming  Organizes programs as objects: data structures consisting of datafields and methods together with their interactions  Send messages between objects to simulate the temporal evolution of a set of real world phenomena  Functional programming  Treats programs as evaluating mathematical functions and avoids state and mutable data  Evaluate an expression and use the resulting value for something  Logic programming – from second link only  Answer a question via search for a solution  Seems less natural in the more general areas of computation

Design Principles and Program Modules Brendan Furey, 2019 12 Design Principles and Program Modules Noting important design principles, and their application to package and subprogram structure Clean Coding in PL/SQL and SQL

General Design Principles Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 13 DRY: Don't repeat yourself “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system“…They (Andy Hunt and Dave Thomas) apply it quite broadly to include "database schemas, test plans, the build system, even documentation“ WET = "write everything twice", "we enjoy typing"  Coupling versus cohesion “Coupling refers to the interdependencies between modules, while cohesion describes how related the functions within a single module are" Functional design “A functional design assures that each modular part of a device has only one responsibility and performs that responsibility with the minimum of side effects on other parts"  Aim for low coupling and high cohesion, which can be facilitated by…  Obvious case in re-usable functions in programming languages  Relational databases apply DRY to data by normalization  Use of object types and records can push DRY to field level (to be discussed)  How can we apply this in PL/SQL packages? (to be discussed)

Information Hiding and Subprogram Nesting Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 14 information hiding “In programming, the process of hiding details of an object or function. Information hiding is a powerful programming technique because it reduces complexity. ... In a sense, the entire hierarchy of programming languages, from machine languages to high-level languages, can be seen as a form of information hiding. Information hiding is also used to prevent programmers from intentionally or unintentionally changing parts of a program” - Vangie Beal in Webopeida Nesting in Ada Programs is for the Birds (Clarke, Wileden & Wolf, 1980) “…a tree structure is seldom a natural representation of a program… We have proposed a style for programming in Ada that precludes the use of nesting and thereby avoids nesting's negative impact on program organization and readability.“  PL/SQL based on Ada and has similar package structure, and nesting capabilities  Nesting blocks or subprograms makes information from higher levels accessible  Reduction in information hiding tends to increase complexity  Suggests that nesting subprograms and blocks should be exceptional…  Or, care must be taken to avoid negative impacts on information hiding

Inheritance Hierarchies Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 15 JavaScript Inheritance vs Composition (Tyler McGinnis, 2019) “If you look at the real world, you’ll see Containment (or Exclusive Ownership) Hierarchies everywhere. What you won’t find is Categorical Hierarchies" Oracle and object type inheritance  Oracle has had object type inheritance capabilities since around 1997  Very rarely used, and, perhaps, with good reason  We will look at appropriate use of OO concepts and/or syntax in Oracle later… On Inheritance (in Goodbye, Object Oriented Programming (Scalfani, 2016)  One of many articles arguing against use of inheritance in OO languages

Subprogram Design Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 16 Subprogram Design Guidelines  Separate out different subprogram types, maximize the use of pure functions  Avoid state accessors unless functionally required (eg code timing instrumentation)  Use input parameters and a maximum of one return value  Use record and object types to group inputs and outputs  Minimize shared access to variables

Package Design Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 17  API layer in PL/SQL consists of entry-point programs that interface between external clients and the database  Generally access no package state but global constants may be shared  Subprograms small, single purpose, and have 0 or 1 return value  Limit package sizes

Object and Record Types and Collections Brendan Furey, 2019 18 Object and Record Types and Collections Showing how object and record types and collections may be used to write cleaner code Clean Coding in PL/SQL and SQL

Record and Object Types Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 19 Suggested Usage of Records vs Objects  Objects necessary where type for database column, or casting in SQL  Lack of index-by array support is a serious limitation for programming  For purely PL/SQL use, record types more flexible, and can be of smaller scope  Allow grouping of fields and passing as one value: DRY at field level  Fields can be defined with defaults  Fields can be scalars, record/object types or collections Record Types  PL/SQL-only constructs, and may include PL/SQL associative (index-by) arrays  No default constructor function, but can write our own  No ‘rec IS NULL’ feature, but can add a flag null_yn and use "rec.null_yn = 'Y'" Object Types  Database level, may not include index-by arrays, can be used for table columns  Have default constructor, and IS NULL works

Oracle Collection Types Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 20 Collection Types (Oracle Database PL/SQL Language Reference, v12.1)

Arrays and Functional Programming Methods Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 21  FP features allow functions to be passed as parameters to other functions  Cleaner code can result, for example, by removing the need for explicit iteration Map, Filter, Reduce Methods  Map: Create a new collection by applying a function to each item of the source collection  Filter: Create a new collection by applying a Boolean function to each item of the source collection, returning True if item to be retained  Reduce: Aggregate a collection by applying a function to each item of the source collection, with an accumulator also passed Can we benefit from these ideas in Oracle?  These methods correspond roughly to SQL concepts (with Select as the iterator):  Map -> Projection (Select expressions based on the fields)  Filter -> Where clause  Reduce -> Aggregate functions with grouping 1. Use SQL where possible, and then… 2. Consider design patterns and generic array types to facilitate cleaner PL/SQL code…

Decomposition by Arrays Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 22 Processing arrays of independent elements  PL/SQL does not have an FP-style generic map function  However, we may want to apply the same processing to each element in an array  Example 1: A logging method needs to log a list of string values  Example 2: A unit test program needs to test a set of independent scenarios Design pattern  Encapsulate record processing in a subprogram with a parameter of element type  Call the subprogram within a loop  Subprogram is simpler for processing scalar rather than list (or array of 1-smaller dimension) PROCEDURE Put_List( p_line_lis L1_chr_arr, p_log_id PLS_INTEGER := NULL, p_line_rec line_rec := LINE_DEF) IS … BEGIN … FOR i IN 1..p_line_lis.COUNT LOOP Put_Line(p_line_text => p_line_lis(i), p_log_id => l_log_id, p_line_rec => l_line_rec); END LOOP; … PROCEDURE Put_Line( p_line_text VARCHAR2, p_log_id PLS_INTEGER := NULL, p_line_rec line_rec := LINE_DEF) IS … Log_Set (My Oracle logging framework on GitHub)  Array type L1_chr_arr in caller  Scalar VARCHAR2 in called subprogram

Generic Array Types and Methods Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 23 String methods: Join and Split  Most languages have string methods for conversion between list of strings and delimited string  These often simplify programming tasks SELECT Utils.List_Delim(col_1, col_2) BULK COLLECT INTO l_lis FROM some_table; CREATE TYPE L1_chr_arr IS VARRAY(32767) OF VARCHAR2(4000); CREATE TYPE L2_chr_arr IS VARRAY(32767) OF L1_chr_arr; CREATE TYPE L3_chr_arr IS VARRAY(32767) OF L2_chr_arr; PL/SQL Equivalents  Generic list types of string and integer type can be defined at schema level for general use  Higher dimension lists can be defined on top of these, and may be useful, eg in unit testing FUNCTION List_Delim (p_field_lis L1_chr_arr, p_delim VARCHAR2 DEFAULT g_list_delimiter) RETURN VARCHAR2; FUNCTION Csv_To_Lis(p_csv VARCHAR2 RETURN L1_chr_arr;  Return a delimited string for input list of strings  Return a list of strings for input delimited string  Can select record set with any column list (of char, number, date type) into a generic array  Generic type declarations

API Design with Examples Brendan Furey, 2019 24 API Design with Examples Explaining how to design APIs for both usability and internal structure, with examples of external design and internal refactoring Clean Coding in PL/SQL and SQL

Clean API Design: Overloading, Record Types, Defaults Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 25 Design Considerations  Aim to make API usage as simple as possible, at least where multiple clients involved  Prefer complexity in centralized APIs to complexity in multiple clients Subprogram Overloading  Create multiple versions where different types of call required, rather than bundle all options into one  Overloaded subprograms, or just different versions, as applicable  Core logic centralized, called by external subprograms Defaults  Use defaults wherever possible to allow omission of parameters  Declare default record for record types for use in parameters  Default record has its own field level defaults Record Types  Use to simplify parameters and centralize defaulting  Use to group parameters logically

API Design: Log_Set Example Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 26 TYPE construct_rec IS RECORD( null_yn VARCHAR2(1) := 'N', config_key VARCHAR2(30), header log_headers%ROWTYPE, do_close BOOLEAN := FALSE); CONSTRUCT_DEF construct_rec; FUNCTION Con_Construct_Rec( p_config_key VARCHAR2 := NULL, p_description VARCHAR2 := NULL, p_put_lev_min PLS_INTEGER := NULL, p_do_close BOOLEAN := NULL) RETURN construct_rec; FUNCTION Construct( p_construct_rec construct_rec := CONSTRUCT_DEF) RETURN PLS_INTEGER; FUNCTION Construct( p_line_text VARCHAR2, p_construct_rec construct_rec := CONSTRUCT_DEF, p_line_rec line_rec := LINE_DEF) RETURN PLS_INTEGER; FUNCTION Construct( p_line_lis L1_chr_arr, p_construct_rec construct_rec := CONSTRUCT_DEF, p_line_rec line_rec := LINE_DEF) RETURN PLS_INTEGER; l_rec := Log_Set.Construct; l_rec := Log_Set.Construct( p_construct_rec => p_con_rec); Three overloaded functions Record defined with null flag default ‘N’  2 other scalar fields  Nested record type based on table  Record variable CONSTRUCT_DEF Constructor function for record  All parameters optional Multiple call structures  First form has 2 calls, with/without parameter  Others have 1 mandatory parameter, with 4 (= 2x2) options for other 2  Client caller can choose best for it…

Refactoring Example - Purely_Wrap_API - Before Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 27  Unit test subprogram to test a single scenario  Input is test data for the scenario  Formatted as a generic 3-level array, plus 2 offsets  Output is the set of outputs generated from unit under test (uut)  Formatted as a generic 2-level array  Nested block loops over a sequence of events involving calls to logging methods from uut  It has an exception handler, which gets exception details as an output group  Rest of main block gets the other output groups from functions that read the database  Also rolls back and deletes committed data  Split Purely_Wrap_API in two, separating out the nested block  Make call to new function Do_Event_List

Refactoring Example - Purely_Wrap_API - After Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 28  Subprogram is split into two units each about half size of original  Do_Event_Lis takes all inputs as parameters and direct outputs as a return value  Also writes to database by nature of unit under test  These writes are read from caller, turned into direct output elements in the return array  Writes are then reverted to make Purely_Wrap_API ‘externally pure’ Unit Test Automation  This refactoring from idea to publishing to GitHub took 1 hour:  Last Fri, 0630-0730  Possible because…  Unit Testing (see over)

Clean Code, Refactoring and Unit Test Automation Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 29  Refactoring essential to writing clean code  Automated unit testing allows repeating tests in seconds, so can easily refactor many times  Tests must be at right level - behavioural/transactional - not Junit-style small code units

Oracle and Other Languages Brendan Furey, 2019 30 Oracle and Other Languages Concerning the integration of PL/SQL programs with other languages Clean Coding in PL/SQL and SQL

Integration of PL/SQL with Other Languages: MLE and JSON Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 31  We have emphasized use of good design principles for clean coding in PL/SQL, inspired by:  Programming design concepts in general  Functional Programming, in particular  Some functionality may just be better done in other languages though…  For example, the HTML Unit Test summary links page on last slide was created in Javascript  Oracle Database Multilingual Engine may offer a future solution for direct integration… “MLE is an experimental feature for the Oracle Database 12c. MLE enables developers to work efficiently with DB-resident data in modern programming languages and development environments of their choice." Integration via JSON file exchange (see JSON Developer's Guide)  From Oracle 12.2 we can easily use JSON features to write output files in JSON format…  …then process the files in another language such as Javascript  This is how the unit testing of the Log Set package works  Next slide shows the structure of the input and output from Purely_Wrap_API  This is converted to a JSON file with expected and actuals included on the output side

Integration of PL/SQL with Other Languages: Example JSON Diagram Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 32

Oracle's Object Orientation Brendan Furey, 2019 33 Oracle's Object Orientation Discussing appropriate use of Oracle’s object-oriented features Clean Coding in PL/SQL and SQL

Objects in Tables Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 34 Columns Based on non-Collection Object Types  Object (or record) types may be used for grouping fields in PL/SQL, as mentioned earlier  On the database, however, the table would be the natural way to group fields Columns Based on Collection Types  Generally master-detail relationships represented by two tables with foreign key link  This allows full use of database features such as field indexing, and simple delete and update of detail records  In exceptional cases, it may be considered acceptable to use a collection type column instead  Where the detail entity is considered to be contained within the master entity and…  …the detail collection is always accessed as a whole  Nested array could then be considered natural physical model from logical  For example, the Log Set logging framework treats system contexts in this way as detail collections within header and line tables  Log lines though are modelled as a conventional table linked to headers

Log Set Data Model with Nested Object Types Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 35  Two collection types defined on database  Used as column types in tables as shown

Oracle's Object Orientation - Programming Issues Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 36  Oracle has had object oriented programming capabilities since around 1997  Very rarely used, while some PL/SQL new techniques become widespread quickly. Eg…  Analytic functions introduced same time, now widespread  Subquery factors introduced in v9, now widespread  Why is this? I suggest three main reasons: 1. PL/SQL as a Persistence Layer for the Database  Recall one definition of OO paradigm:  Send messages between objects to simulate the temporal evolution of a set of real world phenomena  Getting and setting data from/to the database is different from writing computer games 2. Deficiencies in Oracle’s OO Implementation  Oracle’s types for use in PL/SQL are defined at schema level and lack…  Private instance attributes (bad from Information Hiding perspective)  Instance level Index By arrays (important programming construct in any language) 3. Packages are Good Enough  Type inheritance, as we noted, not recommended, and other features available in packages …

Programming Object Instance in PL/SQL Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 37  Sometimes we need to model objects having state, eg in instrumentation code such as Log Set  Suggestion: Do not use object type bodies, but packages, records and arrays instead TYPE log_inp_rec IS RECORD( header log_headers%ROWTYPE, config_rec log_configs%ROWTYPE ); TYPE log_out_arr IS VARRAY(32767) OF log_lines%ROWTYPE; TYPE log_rec IS RECORD( inps log_inp_rec, ctx_out_lis ctx_out_arr, out_lis log_out_arr, lines_buf PLS_INTEGER, lines_tab PLS_INTEGER, log_id PLS_INTEGER ); TYPE log_arr IS TABLE OF log_rec INDEX BY BINARY_INTEGER; g_log_lis log_arr; 1. Define record with the structure required for the state 2. Define an array of records to maintain the states independently 3. Use the array index as the object handle, passing it as a parameter to methods 4. Place code in a single package to represent the object, with object array at package body level

SQL and Modularity Brendan Furey, 2019 38 SQL and Modularity Discussing application of modular design concepts in relation to SQL Clean Coding in PL/SQL and SQL

Centralizing SQL in Views and Functions Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 39  Views and database functions can be used to centralize SQL  Can then use them in multiple places  However, using them as building blocks in larger queries can lead to problems…  …coupling between the calling programs and complex underlying SQL  DRY can conflict with other design principles, and sometimes…  …repeating simple declarative code such as SQL joins may be preferable SQL and Modularity: Patterns, Anti-Patterns and the Kitchen Sink

Modular SQL via Subquery Factors Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 40  Use subquery factors to modularize, diagrams can help…  Query Structure Diagramming

Extracting Pure Functionality from SQL Queries Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 41  We can use the idea of separating out pure functionality into modules in SQL also  Here is an example where the WITH FUNCTION clause is used to do that…  Extracting Pure Functionality from SQL Queries WITH FUNCTION calc_bonus(p_jhs_emp_id NUMBER, p_job_id VARCHAR2, p_salary NUMBER, p_avgsal NUMBER) RETURN NUMBER IS BEGIN RETURN Round(0.1 * Nvl(p_avgsal, p_salary) * CASE WHEN p_jhs_emp_id IS NULL THEN 1 ELSE 1.1 END * CASE p_job_id WHEN 'IT_PROG' THEN 1.5 ELSE 1 END); END; depsals AS ( SELECT dep.department_id, dep.manager_id, Avg(emp.salary) avgsal FROM departments dep JOIN employees emp ON emp.department_id = dep.department_id GROUP BY Dep.department_id, dep.manager_id ) SELECT emp.employee_id, emp.salary, dsl.avgsal, calc_bonus(jhs.employee_id, job.job_id, emp.salary, dsl.avgsal) bonus FROM employees emp JOIN jobs job ON emp.job_id = job.job_id LEFT JOIN depsals dsl ON dsl.manager_id = emp.employee_id LEFT JOIN (SELECT employee_id FROM job_history GROUP BY employee_id) jhs ON jhs.employee_id = emp.employee_id ORDER BY 1

Conclusion Brendan Furey, 2019 42 Conclusion Recommendations around Oracle program design Clean Coding in PL/SQL and SQL

Conclusion Brendan Furey, 2019 Clean Coding in PL/SQL and SQL 43  Create small, cohesive subprograms, separating pure functionality from database accessors  Subprograms should return 0 or 1 (possibly complex) values  Avoid package state, except where necessary  Use nesting of blocks with care, avoiding unnecessary sharing of variable access  Group simple, uncoupled subprograms into moderately sized packages of related types  Use a single package each for complex code serving a single purpose  Provide clean API interfaces using record types, defaults and overloading  Use generic types and collections where this reduces duplication  Facilitate refactoring with automated unit tests at a transactional level  Consider integrating other languages for complex non-database processing, possibly via JSON  Use Oracle's object types freely, but avoid inheritance and type bodies  Follow a simple array-based design pattern, where object state instances are required  Use subquery factors extensively to modularize SQL queries  Use views where appropriate, but try to avoid coupling problems from joining complex views  Use functions in the WITH clause to separate out pure functionality where possible

References 1. Modularity 2. OCR Computing A-Level Revision 3. Overview of programming paradigms 4. Two main approaches to programming 5. Main programming paradigms 6. Overview of the four main programming paradigms 7. DRY: Don't repeat yourself 8. Coupling versus cohesion 9. Functional design 10. information hiding (Vangie Beal in Webopeida) 11. Nesting in Ada Programs is for the Birds (Clarke, Wileden & Wolf, 1980) 12. On Inheritance (in Goodbye, Object Oriented Programming (Scalfani, 2016) 13. JavaScript Inheritance vs Composition (Tyler McGinnis, 2019) 14. Collection Types (Oracle Database PL/SQL Language Reference, v12.1) 15. Log_Set (My Oracle logging framework on GitHub) 16. Oracle Database Multilingual Engine 17. JSON Developer's Guide 18. SQL and Modularity: Patterns, Anti-Patterns and the Kitchen Sink 19. Query Structure Diagramming 20. Extracting Pure Functionality from SQL Queries Brendan Furey, 2018 44Database API as Mathematical Function: Insights into Testing

Clean coding in plsql and sql, v2

More Related Content

What's hot

Similar to Clean coding in plsql and sql, v2

Recently uploaded

Clean coding in plsql and sql, v2

Editor's Notes