The document discusses the 'guilty pleasures' of PL/SQL programming, highlighting common practices that may compromise code quality, such as using overly large data types or mixing SQL and PL/SQL operations. It emphasizes the importance of simplicity, readability, and proper API usage in PL/SQL development. Furthermore, it encourages leveraging PL/SQL's unique features like package specifications and authid for enhanced data security and organization.

1. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
asktom.oracle.com
PL/SQL Guilty Pleasures
1
Steven Feuerstein
Oracle Developer Advocate for PL/SQL
Oracle Corporation
Email: steven.feuerstein@oracle.com
Twitter: @sfonplsql
Blog: stevenfeuersteinonplsql.blogspot.com
YouTube: Practically Perfect PL/SQL

2. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
2
Because programming….
• should feel good.

3. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
3
Guilty Pleasure (from Denis)
• Implement functions and procedures which expect all values
for their parameters (which are translated to attributes),
which leads to the fact that consumer should think about the
`lost update` problem. But consumers are so lazy that it
would be a much better idea to implement routines in a way
that they expect only the changed attributes, in this case the
`lost update` problem would not exist for the consumers, but
the routines would be a bit more complex.

4. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
4
Guilty Pleasure (from Denis)
• Not think a lot about how big my string variables are, just go
for varchar2(32767), when in fact it is a much better to
specify the needed length, or even use an anchoring data
type.
• Not think a lot about how small my string variables are, just
go for varchar2(32767), when in fact it is better to consider
using CLOBs in these particular case, but, c'mon, varchars are
easier.

5. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
5
Guilty Pleasure (from Denis)
• Not think a lot and just go for dates, because they are easier
that timestamps. In fact, it is always not enough and
timezones management hell appears in the end (at least this
is true for my country).

6. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
6
Guilty Pleasure (from Denis)
• Use magical ad-hoc literals instead of constants.
• "I will need it only this time, and will always remember what
47 means!"
• "What do you mean will I remember it a year later?"

7. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
7
Guilty Pleasure (from Denis)
• And my favourite, because it is quite difficult to catch it - do
SQL stuff in PL/SQL and PL/SQL stuff in SQL. It is really good
to use a tool for the stuff it was made for, SQL and PL/SQL
are very close, but still, in many cases a task could be solved
in a much more efficient way in particularly SQL (or PL/SQL).

8. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
8
My (sort of) Guilty Pleasures
• A database programming language to work with data
– Making SQL easy, making dynamic SQL easy and fast
• Simplicity and readability
• Packages, a.k.a., APIs
• No need to make
• The power of AUTHID

9. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
9
Data API Language for Data
• Data is different from algorithms.
– And humans naturally process data as sets and patterns.
• That's why SQL has such enduring power and popularity.
• It also argues for an intermediary programming language
that is data/SQL-aware.
• Thank you, PL/SQL.

10. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
10
Simplicity and Readability
• It's true that PL/SQL can't compete with all the new
approaches and capabilities of a language like Python or
JavaScript.
• Whew. I am so glad.
• PL/SQL keeps things simple, allows you to write code that is
easy to read and maintain.
• And keeps you focused on the data.

11. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
11
Packages, a.k.a., APIs
• APIs are all the rage – and they should be.
• But there's nothing new about APIs.
• Package specifications have offered clean, powerful APIs to
data and business rules for decades.
• Don't write apps without them!

12. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
12
No need to make
• An "automatic and completely reliable" (Bryn) equivalent to
make utilities.
• The database performs dependency analysis and unit
invalidation.
• Fine-grained dependency reduces the need for invalidation.
• Another reason to use %ROWTYPE and %TYPE!

13. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
13
The Power of AUTHID
• Easy SQL construction and execution can lead to easier
insecure code.
• AUTHID offers a simple mechanism to provide tight control
over data, while providing access to data APIs.
• Get in the habit of including AUTHID DEFINER to your
program unit headers.
– It'll remind you of the feature – and its other form: CURRENT_USER

14. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
14
Question on AUTHID
• "If I use all_OBJECTS instead of DBA_objects, I get
ORA-00942 with or without AUTHID CURRENT_USER,
what gives?"
• Remember: when you compile a stored program unit, you need
directly granted privileges to resolve references to objects.
• But….clearly something is wrong with your set up. Everyone has
access to ALL_OBJECTS.

15. Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
asktom.oracle.com
More Questions?
Share your thoughts!
1