SQL

There has always been a special place in heart for the Fibonacci sequence. Decades ago in high school when comparing the ratio of successive items, as any naive student would, I thought I had stumbled upon some wonderful discovery that would assure my place in the pantheon of mathematical greats. Of course, it was somewhat disheartening to have my teacher subsequently crush that illusion when he threw me a reference book demonstrating my discovery had been well established just a mere 400 years earlier

In today’s video we’ll discuss Scalable Sequences, which were documented for the first time in Oracle 18c.

The video is based on this article.

• Scalable Sequences in Oracle Database 18c

The star of today’s video is David Peak, who is now working on the Oracle Pandemic Response Systems. This video is a throwback to a hotel we stayed in at São Paulo a few years back.

Cheers

Tim…

In today’s video we discuss how Temporal Validity can make querying of effective date ranges simpler in Oracle 12c and beyond.

The video is based on this article.

• Temporal Validity in Oracle Database 12c Release 1 (12.1)

The syntax looks similar to Flashback Query and Flashback Version Query.

One of the very cool features we’ve been talking about for 20c is SQL Macros. But you no longer need to wait for a future release of the database to get access to all the goodness of SQL Macros.

Why? Because much of the functionality has now been backported to 19c, and is also now officially in the documentation so there’s no ambiguity as to whether you are supported to use them or not. They’ll be coming soon to an RU near you

• 19c
• Autonomous
• livesql
• Macros
• SQL
• Uncategorized

Any database application that stores information about people will very likely store a person’s date of birth as part of that data. Whether it be for marketing purposes, or part of the security checks for a password reset, or part of the authentication when the inevitable call centre calls you with their “latest, greatest offer”, the date of birth is common.

But when it comes to reporting, typically it is not the date of birth that we present on our screen or hard-copy, but the person’s age. Clearly we cannot store a persons age in the database because it changes every day, month or year depending on the granularity with which you present it. Which leads to the ponderance – Surely it cannot be that hard to calculate someone’s age from their date of birth?

The Developer Live event for database has concluded. Thank you to the (almost) 2000 people that attended my talk across the USA, Europe and APAC timezones! I very much appreciate you giving up your time to attend the session.

Whilst we were doing some Q&A I tried to add as many useful links into the chat line as I could, to help people with onward learning on SQL performance and database performance in general. A few of you then asked if I could publish that chat as to not lose that information, so here it is below

From Me to Everyone:  04:06 PM
Hi everyone,

Its Connor here. Chris Saxon and I are monitoring the Q&A channel, so fire off your questions and we’ll answer them right here.  Anything we can’t answer, we’ll tackle at a later date.

If I gave you a telephone book and asked you to tell me how many distinct street names are present in the book, then the most likely thing you would do is …Wave your mobile phone at me and ask what a “telephone book” is . But assuming you’re old enough to remember telephone books, you’ll probably tackle the task by sorting the entire set in street name order and then work your way down the list and incrementing your count of distinct street names every time it changed. 

In database terms, a little demo of that approach is as below

By Franck Pachot

.
In The myth of NoSQL (vs. RDBMS) “joins dont scale” I explained that joins actually scale very well with an O(logN) on the input tables size, thanks to B*Tree index access, and can even be bounded by hash partitioning with local index, like in DynamoDB single-table design. Jonathan Lewis added a comment that, given the name of the tables (USERS and ORDERS). we should expect an increasing number of rows returned by the join.

In this post I’ll focus on this: how does it scale when index lookup has to read more and more rows. I’ll still use DynamoDB for the NoSQL example, and this time I’ll do the same in Oracle for the RDBMS example.

By Franck Pachot

.
I have written a few blog posts about some NoSQL (vs. RDBMS) myths (“joins dont scale”, “agility: adding attributes” and “simpler API to bound resources”). And I’ll continue on other points that are claimed by some NoSQL vendors and are, in my opinion, misleading by lack of knowledge and facts about RDBMS databases. But here I’m sharing an opposite opinion: SQL being user-friendly is now a myth.

What better way to start a new week than with a cheesy title to my blog post!

But there is method to my unstructured madness today as we talk about the TREAT function, available from 18C for JSON data. As many of us will already know it is possible to dive into JSON data and extract information from its components as if they were relational columns using the very cool dot notation

In order to do so, we need to be a little generous to the database by letting it know that the contents of a unstructured column such as a CLOB is truly correct JSON data.

I will start with a table with a simple CLOB which does indeed contain valid JSON but I have not let the database know about that fact: