31–38 of 38 posts
The more I look at programs that generate SQL, the more I think we should just learn how to write proper SQL. Layers are just hiding things, and when you hide it, bad things happen.
In 99% of cases you don't need to write SQL in order to deliver business functionality. Just like we don't need to write low level machine code in 99% of cases.
You can already have a very similar query writing process using the sql WITH clause. on Oracle: http://docs.oracle.com/cd/E11882_01/server.112/e10592/statem... on SQL Server: http://msdn.microsoft.com/en-us/library/ms175972.aspx
And also in Postgres. But once you've got queries that run to about 10 WITH clauses chained one after the other, just because you can't calculate a value in the SELECT clause and then refer to it from within the same statement, you tend to start wishing there was a better way to do it. As useful as SQL is in so many ways, as a piece of language design it's a total bloody travesty. I'm delighted to see any movement to…
In Oracle's implementation WITH is more like a VIEW.
Edit: BTW, this is not an accident or oversight on the part of Postgres. This is in the spec!
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?
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.
Earlier quoted context omitted.
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).
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?
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.
Earlier quoted context omitted.
Yes, but what are the advantages over SQL? I did quite a bit of SQL in my last job, and I can't think of a single case where I wish I had a pipeline operator. If I wanted to do something similar to the example on your homepage the simplest way is just to use subqueries. Here's a rewrite of your query in T-SQL... ------------------------------------------------------ SELECT EMP.Country, EMP.LastName, EMP.FirstName, OD…
This is an example where SQL can be written in multiple ways to get the same result. It doesn't matter how many lines SQL contains since its all depends on how the database engine going to execute it. Therefore, pipeSQL's main aim is to make it easier to read and understand the query after couple of days/weeks :) .
Earlier quoted context omitted.
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).
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?
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.