

Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters - senthadev
http://pipesql.com/

======
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.

------
dvcc
Seriously this is going to be charged by usage? A query builder? I am really
starting to hate these new pricing models.

~~~
hendzen
When your SaasS startup's product can be implemented as a clojure macro, you
probably need to expand your goals a bit.

------
akavi
Most of your favorite languages have sql composition libraries that'll get you
90% of this (Arel for Ruby, SqlAlchemy for Python, etc, etc).

The remainder, the "piping" syntax, is pretty easy to implement (Takes about
30-40 lines of ruby on top of Arel, speaking from experience).

So then, is this just a matter of wrapping a library in a web page and calling
it SAAS? Or am I just totally missing the point?

~~~
senthadev
Piping is used to merge the tables rows. Tables can be merged in multiple
ways, for example by join, left join, exists, not exists, union, minus etc..
And you can have the pipe chain up to 255 levels.

------
vkb
This might be good for developers, but I'm not sure how it's helpful for
either heavy users or beginners. For business analysts, it's just another
layer on top of SQL, which slows down processing time, and for beginners, it's
now two types of syntax and order they have to learn instead of one.

~~~
rnovak
I don't even think it should be used with Devs. For one, a good dev _should_
know how to build queries, otherwise he/she is missing a good foundation, in
which case shouldn't be working with the db. Just my personal take though

~~~
icebraining
I know how to write assembly, but I still develop most of my software in
Python. If this makes hairy queries more readable, I can see the use case,
even if it doesn't replace SQL itself or the need to know it.

------
garAvRovro
[http://nareshv.github.io/atomsql/](http://nareshv.github.io/atomsql/) \-- for
simple sql operations, inspired by unix shell operators

------
tucif
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...](http://docs.oracle.com/cd/E11882_01/server.112/e10592/statements_10002.htm#i2129904)

on SQL Server: [http://msdn.microsoft.com/en-
us/library/ms175972.aspx](http://msdn.microsoft.com/en-
us/library/ms175972.aspx)

~~~
radiowave
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 towards a query
language that keeps the nice declarative dataflow property that complex SQL
queries can have, but provides better means of abstraction, and the
possibility to write more intention-revealing code.

~~~
siddboots
Postgres implement WITH in a way that doesn't lend itself to modularity. When
you declare a subquery in a WITH block, the query optimiser won't attempt to
integrate your query over that boundary. In other words, your entire subquery
will be materialised before the lower query is run.

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!

------
yorp
Why not use (virtual) views?

[http://en.wikipedia.org/wiki/View_(SQL)](http://en.wikipedia.org/wiki/View_\(SQL\))

------
scribu
IMO, this would be more interesting as an alternative way to write complex
queries in an ORM.

Currently, all ORMs that I've seen try to mimic the declarative SQL syntax,
which doesn't always look pretty.

------
alex_duf
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.

~~~
2muchcoffeeman
I've been wondering the same thing.

But I don't have any real world experience writing software that actually ends
up being used with different databases.

I may use all these abstractions, but really we just use Postgres or MySQL in
the end.

