Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters

pipesql.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters

#21

Post by eschutte2 »

trimtab wrote: post #2

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?

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

Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters

#22

Post by ZenoArrow »

senthadev wrote: post #16
tucif wrote: post #8

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

This is not a replacement for SQL. Its a tool to create SQL in a different angle. An angle which is similar to UNIX pipeline concept.

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.OrderID, ORD.ShippedDate, OD.SaleAmount

FROM (SELECT TOP 10 T1.OrderID, T1.ORDSUM FROM (SELECT OrderID, SUM(UnitPrice * Quantity * (1 - Discount)) AS SaleAmount FROM "Order Details" GROUP BY OrderID) AS T1 ORDER BY T1.ORDSUM DESC) AS OD

LEFT JOIN Orders AS ORD ON OD.OrderID = ORD.OrderID

LEFT JOIN Employees AS EMP ON ORD.EmployeeID = EMP.EmployeeID

------------------------------------------------------

That's fairly concise, and was quick to bash out. I'd wager it could be made even smaller if I used LINQ instead of SQL. Perhaps your method has some advantages in other types of query? How do you see it?

Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters

#23

Post by 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?

Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters

#24

Post by senthadev »

ZenoArrow wrote: post #22
senthadev wrote: post #16

Earlier quoted context omitted.

This is not a replacement for SQL. Its a tool to create SQL in a different angle. An angle which is similar to UNIX pipeline concept.

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 :) .

Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters

#26

Post by senthadev »

akavi wrote: post #23

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?

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.

Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters

#27

Post by clubhi »

alex_duf wrote: post #25

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.

You should look at proper SQL. It looks horrible.

One benefit a layer can add is the ability to optimize post compilation. Most of the fancy pants Hadoop libraries are doing this one way or another.

Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters

#28

Post by 2muchcoffeeman »

alex_duf wrote: post #25

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.

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.

Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters

#29

Post by [deleted] »

senthadev wrote: post #14
trimtab wrote: post #2

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.

[deleted]

Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters

#30

Post by tieTYT »

eschutte2 wrote: post #21
trimtab wrote: post #2

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?

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?
Post reply on HN