Posts
I tried adding a new entry to my blog a few times since my last entry. My plan is to highlight a few key areas in DBClarity Developer so that you can learn a little more about what the product does. I have a list of around 10 topics, which morphs and expands as my ideas change. Having shown you how to “Get Started” in my first video, the next step is to write about the SQL Editor, as described in the presentation, Tutorial 1 - Introducing the SQL Editor , which is on the DBClarity website. There’s the rub..., for those of you who know me and my back ground, I can almost hear you say, “SQL Developer does this and more” or even “TOAD has a richer editor than this”, and so what am I up to? Well, that’s the point, this is a different product.
I have created a new video, Microgen DBClarity Developer: SQL Editor, which instead of focusing on the SQL Editor, shows you where it fits in, and then goes on to show you how you can start creating the visual queries, what we call SQL Rules. Take a look.
In the next video I’ll take a look at how to deploy your project.
Migrating Subversion to Git with LFS
6 years ago
2 comments:
Interesting product. How does it fit with the whole Aptitude/OST-BR ethos that "the diagram is the code"? It appears that DB Clarity may be used to produce stored procs. What happens when those stored procs are changed (as they inevitably will be)?
The “diagram is the code” ethos still stands true with the core Microgen Aptitude platform as we use our own execution engine, and therefore have full control of how this is managed and updated. When we are branching out to in-database processing, the database is the engine, and as such we have to generate code that will run within the database. In essence, it is still true that the diagram is the code, because any changes you want to make, you need to make in the diagram. With DBClarity you can see the SQL code and when you deploy the project, it executes a script to create or update the stored procedures in your database. Once in the database, you can edit these and update them without using DBClarity, but the idea is that you’d return to the product, update the diagram and redeploy from, thus ensuring that the point of truth is maintained in DBClarity. This becomes a matter of process and governance over your environments, and certainly when it comes to production systems, it would be normal to create deployment packages which are run through a controlled and audited process.
Post a Comment