On Tue, Apr 1, 2014 at 8:07 PM, Michael Bayer <mike...@zzzcomputing.com> wrote:
> Think about it. You have 2000 individual Python classes all called
> TimeSeries, all referring to a different table. This is the question you
> have to answer (and which I think is going to wind you up back at one
> table):
>
> 1. which one of those 2000 TimeSeries classes do I refer to when I say
> "Location.timeseries" ?
>
> 2. what SQL would a query like query(Location).join("timeseries") produce?
> Are you looking for an enormous UNION of 2000 tables? that's not going to
> work.
>
> Think about this in terms of SQL. If you want to query across *all*
> timeseries at once, having them all in 2000 tables is not going to be
> possible. If you did have that setup, the approach would be to write a
> map/reduce query that hits each TimeSeries table separately and figures it
> out at that level, just like if you were running a noSQL database like
> CouchDB or something like that.
Thing is, this is not relational data.
I believe you need a columnar data store.
Which, I guess it's up to you to choose - I don't know many opensource ones.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
