Seriously this is going to be charged by usage? A query builder? I am really starting to hate these new pricing models.
When your SaasS startup's product can be implemented as a clojure macro, you probably need to expand your goals a bit.
Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters
11–20 of 38 posts
Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters
#12This 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.
I don't think it is another layer, and I don't think it ties you to a vendor. This is a query builder tool that produces SQL code. You then take that SQL and run it against the DB. Once you've generated the SQL, you can modify it, you're not tied to the original pipesql.
Exactly, its a tool to generate SQL in a elegant manner. Once the SQL is generated, we can uses the generated SQL in the app. There is no need of a new additional layer between apps and database.
Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters
#13This 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.
This is a tool to generate complex queries in a bottom-up approach. Once the SQL is generated, then we can use the SQL in the application for future use. It's not another layer between apps and database.
Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters
#14So 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.
Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters
#15Seriously this is going to be charged by usage? A query builder? I am really starting to hate these new pricing models.
API would be charge by usage. But the desktop APP will be one time payment(per year) since it will include the parser to translate the pipeSQL to database dialect. Still not finalised, but happy to hear your thoughts on the pricing model.
Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters
#16You 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.
Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters
#17IMO, 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.
Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters
#18Earlier quoted context omitted.
I don't think it is another layer, and I don't think it ties you to a vendor. This is a query builder tool that produces SQL code. You then take that SQL and run it against the DB. Once you've generated the SQL, you can modify it, you're not tied to the original pipesql.
Exactly, its a tool to generate SQL in a elegant manner. Once the SQL is generated, we can uses the generated SQL in the app. There is no need of a new additional layer between apps and database.
That doesn't make any sense. What happens when you need to change the SQL?
To an application developer, this looks like nothing more than a code generator. Generated code is not source code and it should not be edited directly. Rather, you should change the generated code's source code and then re-generate it. While it may not be a layer between the app and the database, it's definitely an extra step in your build chain.
You'd be foolish to tie your application's build process to a cloud service that may disappear without warning. No sane developer would do such a thing. I don't see how this is any use to developers in any form other than a standalone compiler.
Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters
#19You 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 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.
Re: Show HN: PipeSQL – Building SQL queries bottom-up using pipes and filters
#20This 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.
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
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.