Skip to main content

YesSQL! a celebration of SQL and PL/SQL: OOW14 event 29 September

First the key details:

When: 6:30 - 8:00 PM on Monday, 29 September

Where: Moscone South - 103

To register: Session CON9027. This event will be offered as a "regular" OOW session, which means you register to attend through Schedule Builder.

Why: Because SQL and PL/SQL are amazing technologies, and the people who them to deliver applications are amazing technologists

For many, many years - since 1979, in fact - Oracle Database software and other relational solutions have been at the core of just about every significant human development, whether it be based in private enterprise, government, or the world of NGOs.

SQL, relational technology, Oracle Database: they have been incredibly, outrageously successful. And SQL in particular is a critical layer within the technology stack that runs the systems that run the world. SQL is a powerful yet relatively accessible interface between algorithmic processing and data. 

Rather than write a program to extract, manipulate and save your data, you describe the set of data that you want (or want to change) and leave it to the underlying database engine to figure out how to get the job done.

 It's an incredibly liberating approach and I have no doubt that SQL and Oracle Database are two of the defining technologies that made possible the Information Era and the Internet/Mobile Era. Sure, you could argue that if Oracle hadn't come along, some other company would have taken its place. But Oracle did come along, and from 1979 through 2014, it has continually improved the performance and capabilities of Oracle SQL, providing innovation after innovation.

Let me repeat that, because I think that so many of us have lost perspective on the impact Oracle technology – and we Oracle Database developers* – have had on the world:

SQL and Oracle Database are two of the most important software technologies of the last forty years. And all of you, all of us, played a key role in applying that technology to implement user requirements: literally, to build the applications upon which modern human civilization functions. Us. We did that, and we do it every day. 

How cool is that?

Very cool....and deserving of special note. So we are going to note that and much more at the first-ever YesSQL! A celebration of SQL and PL/SQL.

Co-hosted by Tom Kyte and Steven Feuerstein, YesSQL! celebrates SQL, PL/SQL, and the people who both make the technology and use it.

No feature Powerpoints. No demos. Instead special guests Andy Mendelsohn, Maria Colgan, Andrew Holdsworth, Graham Wood and others will share our stories with you, and invite you to share yours with us, because....

YesSQL! is an open mic night. Tell us how SQL and PL/SQL - and the Oracle experts who circle the globe sharing their expertise - have affected your life!

Bottom line: If developing applications against Oracle Database is a big a part of your life, join us for a fun and uplifting evening.

Share Your Stories!

I hope you can join us at the event (you'll be able to sign up for YesSQL! just like for a regular OOW session). But if you can't (or even if you can), you can share your story with us, right here (and on the PL/SQL Challenge, in our latest Roundtable discussion).

How has SQL and/or PL/SQL and/or Oracle Database changed your life, personally, professionally or otherwise? We will select some of your stories to read at the YesSQL! event and if you are attending, you can tell the story yourself.

I also encourage you to record a short video telling your story. That's so much more entertaining! Just record and upload to a location of your choice, and I will grab it or link to it (YouTube, for example).

* I used to talk about PL/SQL developers and APEX developers and ADF developers and Javascript developer and so on, but I have recently come to realize that very, very few Oracle technologists can be “pigeon-holed” that way. Sure, I know and use only PL/SQL (and SQL), but just about everyone else on the planet relies on a whole smorgasbord of tools to build applications against Oracle Database. So I’m going to start referring to all of us simply as Oracle Database Developers.

Comments

  1. I thought I would get things started.

    I'm not going to talk about how I have benefited from Oracle PL/SQL. That should be pretty darned obvious. I do consider myself lucky to have "fallen into" PL/SQL - it is such an accessible, well-scoped language (it's not intended to do everything for everyone), and it is relatively simple. Since I am not a computer scientist, I like the simpler languages. :-)

    But that same accessibility and readability of PL/SQL has also meant that many other PL/SQL developers are similarly not computer scientists. I have met countless developers who started off as data analysts or users, who worked with SQL Forms developers - and then realized "Hey, I can do that myself." and off they went on a path that led to a full time programming job in PL/SQL.

    One of my favorite stories along those lines happened at a Chicago OUG meeting, in which I did a presentation on, well yes you guessed it, PL/SQL. Afterwards, a fellow came up to shake my hand and thank me. He said:

    "I used to be a union electrician in a steel mill down in Gary. When that whole chunk of the economy collapsed, I went back to school. I came across your book, decided to focus on Oracle, and now I have a great job, which allows my wife to stay home with the kids. Your book changed my life!"

    Of course, I feel great when people tell me that, but what really changed their lives were some really great technology and their own discipline and desire.

    So share a little of your life with us: how has the technology (or, sure, why not, my books) impacted your life?

    ReplyDelete
  2. Hello Steven,

    As you are already speaking about the "Umbrella" name of Oracle Database Developers for covering all of us, then, if the discussion will however arrive to the point of separating those domains, then I would just like to ask you not to forget the good, old Oracle Forms from the tools list :) :)

    If we already speak about how Oracle changed our lives, then I can only say that
    digging deeply into Oracle Forms and accompishing really nice things with relatively few out-of-the-box features did and still does represent an important part of my Oracle life ... it that life is important at all to anyone ...

    I know that APEX and ADF are much more modern, but for an "old-comer" like me,
    they still look and probably are indeed much more complicated than the good old
    Oracle Forms, which is, by the way, still widely used in the Oracle development world :) :) and I know this by the so many users to whom I often use to offer help on various web forums.

    Therefore, I really feel an "internal demand" to make justice to this still very nice
    and useful tool :):)

    Front-end development tools do have their own "witchery and wizardry" that could be mastered at various levels of art, just like SQL and PL/SQL ....
    And, as I always like to say and believe, anything that one is able to master at a high level, will always become a nice and important part of his/her professional life .

    Thanks a lot & Best Regards,
    Iudith Mentzel

    ReplyDelete
  3. Well, let me share my story – to be fair, I started to work with databases already in college, but more from the data modelling/business analysis angle. When I moved to the USA in 2000 (just after graduation) I quickly recognized that my language skills are too limited to work as BA, so I went to evening Oracle courses in Philadelphia to deepen by technical skills – SQL, PL/SQL, SQL*Plus, into to administration etc.

    And suddenly I realized that I like it even more than playing with ERDs! Also, a bit of a lucky break – one of my teachers recommended me to his former boss. To be fair, I have no idea how I survived that interview – somewhere in the middle of it I realized that this boss is no less than Dr. Paul Dorsey, whose book I was recently quoting in my Master Degree Thesis… Anyways, on February 26th, 2001 Dulcian Inc got a brand new 21-year-old employee with the focus on database development.
    And couple of months later I’ve got a task that really shaped my specialization: I needed to write a module that would check for invalid objects in the schema and compile them in the appropriate order of dependencies. So, the set of tools is obvious (now), but at that time I had to discover: data dictionary views, object collections, recursion, and, finally, Dynamic SQL. For my reader/listeners – that list sounds really familiar, isn’t? :-) Looks like Oracle versions change, but favorite toys stay the same!

    After that module started to work (I think, even Dr. Paul got surprised!) my field was settled: solving strange/unsolvable database problems using SQL and PL/SQL. That’s pretty much what I still do now – even 14 years later. Bad news – there are lots of such problems. Good news – it’s fun to solve them (and that’s the way I get new stories for books/presentations!)

    Good enough? I will think for more PL/SQL-related stories to share!

    ReplyDelete
  4. Well ... I liked the story of Misha ...
    it just proves once again that not just history matters, but geography as well.

    It just happens that I know Dr.Paul Dorsey from the web, I found his web site some years ago when he was (still) dealing a lot with Oracle Forms features and had some great material there.

    One more similarity between Misha and me ... I am also somehow dealing with "solving strange database problems", yes ... this is my task in our DBA team ...
    there are some strange bugs or maintenance issues that I am always the address for solving them, in ways that I would not disclose to Oracle support ...
    But, our team is a small anonymous one, and so am I ...
    And ... yes ... I even have in one of my applications a routine for compiling dependent objects in the right order ... so, looking back, I think that I have done not a few things
    over these so many years ...

    I just wonder sometimes how my life could have been different had I chosen the other geographic coordinates ... never thought of it at the proper time and age ...
    and then it became too late ...

    I also use to think many times how much I would have probably enjoyed Oracle and software programming in general, if I had the chance of meeting with them at early childhood,
    as is possible today.
    Maybe in my next reincarnation ... in another place ...

    But, then I also think of those who lived in the stone age, and of those who, unfortunately, these very days "endeavor" so much for getting there again ... and I say to myself that everyone has his fate, his age and his place in this Universe ...
    sometimes even decided by others and much less by fate itself ...

    Best Regards,
    Iudith Mentzel

    ReplyDelete
  5. YesSQL! You are beautiful!

    This would be my hymn at the celebration of SQL and PL/SQL.

    In my 16 years' with SQL, I have never stopped being amazed by the simplicity, elegance and power of this beautiful language. I have had a great amount of fun working with SQL: I have enjoyed implementing very complex logic in single queries; I have amazed developers by tuning up query performance as they watch. My SQL skill has earned me visibility and reputation on almost every project that I have worked.

    Now I am using SQL for something new. I want to return JSON objects from SQL. To showcase the wonder the SQL can do, I am obligated to provide an example for you to see:

    Here is the SQL:

    select l.location_id As "locId",
    l.country_id As "country",
    l.state_province As "state",
    l.city As "city",
    d.department_id As "departments[.deptId",
    d.department_name As "departments[.deptName",
    m.employee_id As "departments[.manager.empId",
    m.first_name As "departments[.manager.firstName",
    m.last_name As "departments[.manager.lastName",
    m.email As "departments[.manager.email",
    m.phone_number As "departments[.manager.phone",
    mj.job_title As "departments[.manager.title",
    e.employee_id As "departments[.employees[.empId",
    e.first_name As "departments[.employees[.firstName",
    e.last_name As "departments[.employees[.lastName",
    e.email As "departments[.employees[.email",
    e.phone_number As "departments[.employees[.phone",
    ej.job_title As "departments[.employees[.title",
    h.start_date As "departments[.employees[.jobHistory[.startDate",
    h.end_date As "departments[.employees[.jobHistory[.endDate",
    hj.job_title As "departments[.employees[.jobHistory[.title"
    from hr.locations l,
    hr.departments d,
    hr.employees m,
    hr.jobs mj,
    hr.employees e,
    hr.jobs ej,
    hr.job_history h,
    hr.jobs hj
    where d.location_id(+) = l.location_id
    and m.employee_id(+) = d.manager_id
    and mj.job_id(+) = m.job_id
    and e.department_id(+) = d.department_id
    and ej.job_id(+) = e.job_id
    and h.employee_id(+) = e.employee_id
    and hj.job_id(+) = h.job_id

    (I assume that we all familiar with the HR tables in Oracle database.)

    Here is JSON array returned by the SQL:
    [
    {
    "locId": 1700,
    "city": "Seattle",
    "state": "Washington",
    "country": "US",
    "departments": [
    {
    "deptId": 90,
    "deptName": "Executive",
    "employees": [
    {
    "email": "NKOCHHAR",
    "empId": 101,
    "firstName": "Neena",
    "lastName": "Kochhar",
    "phone": "515.123.4568",
    "title": "Administration Vice President"
    "jobHistory": [
    {
    "endDate": "2005-03-15T00:00:00Z",
    "startDate": "2001-10-28T00:00:00Z",
    "title": "Accounting Manager"
    }
    ]
    }
    ],
    "manager": {
    "email": "SKING",
    "empId": 100,
    "firstName": "Steven",
    "lastName": "King",
    "phone": "515.123.4567",
    "title": "President"
    }
    }
    ]
    },
    ...
    ]
    ( to be continued)

    ReplyDelete

Post a Comment

Popular posts from this blog

Running out of PGA memory with MULTISET ops? Watch out for DISTINCT!

A PL/SQL team inside Oracle made excellent use of nested tables and MULTISET operators in SQL, blending data in tables with procedurally-generated datasets (nested tables).  All was going well when they hit the dreaded: ORA-04030: out of process memory when trying to allocate 2032 bytes  They asked for my help.  The error occurred on this SELECT: SELECT  *    FROM header_tab trx    WHERE (generated_ntab1 SUBMULTISET OF trx.column_ntab)       AND ((trx.column_ntab MULTISET             EXCEPT DISTINCT generated_ntab2) IS EMPTY) The problem is clearly related to the use of those nested tables. Now, there was clearly sufficient PGA for the nested tables themselves. So the problem was in executing the MULTISET-related functionality. We talked for a bit about dropping the use of nested tables and instead doing everything in SQL, to avoid the PGA error. That would, however require lots of wo...

How to Pick the Limit for BULK COLLECT

This question rolled into my In Box today: In the case of using the LIMIT clause of BULK COLLECT, how do we decide what value to use for the limit? First I give the quick answer, then I provide support for that answer Quick Answer Start with 100. That's the default (and only) setting for cursor FOR loop optimizations. It offers a sweet spot of improved performance over row-by-row and not-too-much PGA memory consumption. Test to see if that's fast enough (likely will be for many cases). If not, try higher values until you reach the performance level you need - and you are not consuming too much PGA memory.  Don't hard-code the limit value: make it a parameter to your subprogram or a constant in a package specification. Don't put anything in the collection you don't need. [from Giulio Dottorini] Remember: each session that runs this code will use that amount of memory. Background When you use BULK COLLECT, you retrieve more than row with each fetch, ...

PL/SQL 101: Three ways to get error message/stack in PL/SQL

The PL/SQL Challenge quiz for 10 September - 16 September 2016 explored the different ways you can obtain the error message / stack in PL/SQL. Note: an error stack is a sequence of multiple error messages that can occur when an exception is propagated and re-raised through several layers of nested blocks. The three ways are: SQLERRM - The original, traditional and (oddly enough) not currently recommended function to get the current error message. Not recommended because the next two options avoid a problem which you are unlikely  to run into: the error stack will be truncated at 512 bytes, and you might lose some error information. DBMS_UTILITY.FORMAT_ERROR_STACK - Returns the error message / stack, and will not truncate your string like SQLERRM will. UTL_CALL_STACK API - Added in Oracle Database 12c, the UTL_CALL_STACK package offers a comprehensive API into the execution call stack, the error stack and the error backtrace.  Note: check out this LiveSQL script if...