[trimtab]

So using this tool and building scripts in it just ties users to yet another vendor, right?

In that case, if you are already tied to Oracle why not just use their tools rather than something like this? Oracle's tools will hopefully work in lock-step with their releases and there should be no support lag.

This looks neat, but why add another layer of lock-in to yet another vendor with the uncertainty that entails?

[senthadev]

Main aim of this tool is to create complex queries in a bottom-up approach. Say you want to create a query by joining 5 tables. Even though we declare 5 tables in the FROM clause, database will join 2 at a time. And then join another table with the previous result set. So this tool helps to build query similar to execution plan tree structure.

[ldng]

Isn't that kind of doing the job of the query planner ? Do you always come up with something better by yourself ? Genuinely asking here.

[eschutte2]

Purchasing an add-on product from a third-party vendor is basically the exact opposite of vendor lock-in. Vendor lock-in is when you do what you advocate, which is only buy from your existing vendor (for whatever reason).

[tieTYT]

I'd like some clarification. If you purchase a closed source add-on from a third-party, aren't you now locked in to 2 vendors instead of 1?

[eschutte2]

No, "using a product" from a vendor is not vendor lock-in. Especially in the case of a product like this, which turns your employees' work product (queries) from "something that works only with Oracle" (as would be the case if you used Oracle's tooling) into "queries that work with potentially any database."

So when your Oracle rep calls and says "bad news, your license costs went up by 150% this year. What are you going to do, switch databases? Hahahaha!" you can reply "well you know, we can actually flip a switch and run on Postgres now. We'll get back to you."

Yeah, it never quite works out that easily in practice. But by using products from a selection of vendors that support other ecosystems than just one, you're reducing your vendor lock-in.

[trimtab]

Yes.

And your risk of finding that all the code you've created using a proprietary tool that runs on top of a proprietary platform owned by another entity is greater than just using the tools provided by the platform vendor who controls "the stack" of software below any other vendor providing an add-on.

Basically, (in this case) Oracle can break 3rd party add-on tools and programs anytime they want or make them operate in a suboptimal way by changing their product below. Oracle, Microsoft and other platform vendors have repeated done this in the past.

So buying cloud based or closed source tools that run on top of other closed source products controlled by another entity is a poor bet.

[michaelmior]

I'm not sure I understand your point about being tied to a vendor. This isn't tied to Oracle and it's mentioned at the bottom that you can also generate SQL for MySQL, MSSQL, and others.

[JustSomeNobody]

One would have to purchase this, yes? One would use this tool to build one's queries, yes? So what's not to understand about being tied to yet another vendor?

I thought that was a clear and honest question.

[michaelmior]

Ah, sorry. I was being naive and assuming this was open source.