4 ms·

> Writing a SQL equivalent example of that query is, at this point, beyond my SQL capabilities. Let me get this straight, someone who doesn't know SQL is going

by meritt 8y ago

> Writing a SQL equivalent example of that query is, at this point, beyond my SQL capabilities. Let me get this straight, someone who doesn't know SQL is going to solve all of the deficiencies of SQL by inventing something new? InfluxDB is awesome and the syntax looks great, but please spare me the "problems" you're solving when you can't write a simple moving-average query.

tanilama 8y ago
They are just building a subset of semantics which SQL supports, and no join. Nothing to see here.
- rbetts 8y ago
  I'm the dir. of eng. for the team building flux. Before that, I built a transactional SQL system (during peak NoSQL hype). I like SQL. After a year+ of watching people use InfluxQL and thinking about the types of user experiences that timeseries specific platforms can offer - I'm eager to see flux enter the world. People like exploratory and notebook like environments. Building a language that integrates with those workflows and even supports a REPL for writing queries is a nice fit to this space. InfluxDB chooses a non-relational data model. Timeseries queries almost all filter on terms, partition, window, group - and then apply a sequence of functions to those groups. Most queries end up using SQL analytic functions that many users aren't experienced using... while mapping a only vaguely-relational (and very non-normalized) data model to boot. The timeseries space is visual - visual tooling really matters. SQL isn't an easy fit there, either. It is hard to write SQL incrementally or to interpret just part of a SQL query to show intermediate results. Additionally, users expect a large set of non-standard SQL functions to be builtin. There are competing systems betting explicitly on SQL and others choosing a functional approach, a strong competition of ideas and practices which should be a win for end-users. (And to correct the above comment, flux expresses select, project, and join operators.)
  - nwmcsween 8y ago
    when making a new project I honestly believe the best way of doing it is documenting other projects, in this case SQL, datalog, etc and why the choices they made were not what you wanted and the alternatives and why $x was chosen, this way if people disagree with your design you can refer to the research you did.

by meritt 8y ago

tanilama 8y ago

They are just building a subset of semantics which SQL supports, and no join. Nothing to see here.

rbetts 8y ago
I'm the dir. of eng. for the team building flux. Before that, I built a transactional SQL system (during peak NoSQL hype). I like SQL. After a year+ of watching people use InfluxQL and thinking about the types of user experiences that timeseries specific platforms can offer - I'm eager to see flux enter the world. People like exploratory and notebook like environments. Building a language that integrates with those workflows and even supports a REPL for writing queries is a nice fit to this space. InfluxDB chooses a non-relational data model. Timeseries queries almost all filter on terms, partition, window, group - and then apply a sequence of functions to those groups. Most queries end up using SQL analytic functions that many users aren't experienced using... while mapping a only vaguely-relational (and very non-normalized) data model to boot. The timeseries space is visual - visual tooling really matters. SQL isn't an easy fit there, either. It is hard to write SQL incrementally or to interpret just part of a SQL query to show intermediate results. Additionally, users expect a large set of non-standard SQL functions to be builtin. There are competing systems betting explicitly on SQL and others choosing a functional approach, a strong competition of ideas and practices which should be a win for end-users. (And to correct the above comment, flux expresses select, project, and join operators.)
- nwmcsween 8y ago
  when making a new project I honestly believe the best way of doing it is documenting other projects, in this case SQL, datalog, etc and why the choices they made were not what you wanted and the alternatives and why $x was chosen, this way if people disagree with your design you can refer to the research you did.