Create the Oracle database objects

This post is part of a series of posts: From idea to app or how I do an Oracle APEX project anno 2017

In a previous post we defined the ERD of the multiplication table application we're going to build. Now I want to go into detail how I create the Oracle database objects like tables, foreign keys, sequences, triggers, etc.

Before I tell you what I do today, let me first walk you through my history so you understand why I'm using it.

Data Modeling Tools

Data Modeling Tools allow you to visually create your tables, relationships, etc. If you work with Oracle for 10 or more years, you probably know Oracle Designer. This tool has been really popular, but today it's legacy and not maintained anymore by Oracle. Oracle moved forward with SQL Developer Data Modeler. Although I've been using those tools in the beginning, today I typically don't use them anymore, except for generating a visual diagram (ERD) of my tables, but that is now part of SQL Developer, so I don't have a data modeling tool installed anymore. The main reason for me was, it took me so much time to add the entities, that it was too slow for my process. As written earlier, I typically draw my entities on a whiteboard or piece of paper, after that I want to get going with real tables and data as fast as I can to verify the model.

If you have a big team and somebody is solely responsibility for modeling, I see a benefit of using a modeling tool or if you like the process of visually creating a model. There're probably more advantages using a modeling tool, so if you use it and like it, don't change because of this blog post, I just share how I typically do a project.

Manual

So if I didn't use a modeling tool, what did I do? I created the tables manually. I hear you think, yeah right, and that is faster? It was for me, because I had a certain workflow. I used strict naming conventions: 3 letters for the project, singular table names, meaningless id column in every table etc. Here's an overview screen:

You find the complete guide of my naming conventions here.
Those naming conventions were the base, but per project or customer we could adapt to their standards. The principle was that I created tables with only the relevant columns, a meaningful unique key and a comment.

Next I used a script that would generate all the primary keys and foreign key relationships, sequences, triggers, audit columns and everything else that I could automate for the particular project. You find the base of the script I used till two years ago here and a screenshot of a part of the script:

The only reason I could do this, was because I used strict naming conventions e.g. table_id column (fk) would be a reference to the id column of a table (pk). By doing this, I could really iterate fast on creating and adapting tables, it worked great for me.
The final step was to create a visual ERD of it in SQL Developer (or other tool) as it was easier to communicate with the team and we always include it as part of the documentation.

As I'm writing in the past, you probably figured that I stopped using this method. The reason is simple, because there came something I like even more :)

But before we move on, a final word on naming conventions; it's not which naming conventions you use that is important, it's more about being consistent within your project and make it easier for you to understand your model and have faster knowledge transfer. So whatever naming conventions you use is fine, there's not something like "this is the best" in my view.

Quick SQL

So now we come to today... this little tool is what I use to create a script for my database objects.

I can't explain Quick SQL better than what you find on the site:

Quick SQL enables you to rapidly design and prototype data models using a markdown-like shorthand syntax that expands to standards-based Oracle SQL. You can easily create master detail relationships, check constraints, and even generate sample data.

Quick SQL is a packaged app which comes with Oracle APEX, so you have it, without knowing :)

So back to our multiplication project; the first thing I did was installing the packaged app in our APEX workspace. Go to App Builder > Create > Packaged App > Quick SQL. Next run the app and this is the screen you will see:

Next you start typing your tables and columns and some additional syntax to specify constraints etc. The power of Quick SQL is that it not only generates the tables, but it has built-in naming conventions, generates indexes, constraints, triggers, views and even sample data.

Here's a video of me creating the script for our multiplication table project:



The next thing I do is generate with SQL Developer the ERD, so I visually see it. Just follow the wizard in SQL Developer you find in File - Data Modeler - Import - Data Dictionary:

While reviewing the visual ERD, I saw I made a small mistake in Quick SQL. I didn't specify timezone with local timestamp (tswltz), but just timezone with timestamp (tstz). In the application for my son I used a date for that column, that is why I called that column start_date and end_date, but the more logical name is start_time and end_time, so I changed that too. I want to use timestamp with local timezone as this app is probably going to be used around the world, so it would be nice if you could see the time you actually played in your own timezone.

Here's the final version of the script in Quick SQL:

It's very easy to make changes in Quick SQL, and in settings I just included the drop statements and re-ran the entire script in SQL Dev and I was done :)

I really like Quick SQL and I hope it gets even more improved in the future. It would be really nice to version control the scripts and be able to generate the differences for the tables (alter statements instead of create statements) or do reverse engineering of a specific schema. Another improvement I hope to see in the future, is the ability to define unique constraints on multiple columns (or it might be already there, but that I don't know how to use it?).

The visual ERD is below:

In this post we went from the paper ERD to real Oracle objects. Now we are ready to build our app.