On Tue, Mar 17, 2009 at 7:47 AM, Craig Ringer <cr...@postnewspapers.com.au> wrote: > Juan Pereira wrote: > > >> - The database also should create a table for every truck -around 100 >> trucks-. > > Why? > > That's a rather clumsy design that makes it really hard to get aggregate > data across the fleet or do many interesting queries. > > You're almost always better off using a single table with a composite > primary key like (truckid, datapointid) or whatever. If you'll be doing > lots of queries that focus on individual vehicles and expect performance > issues then you could partition the table by truckid, so you actually do > land up with one table per truck, but transparently accessible via table > inheritance so you can still query them all together. > > Read up on PostgreSQL's table partitioning features.
If there is little/no reason to span queries over various trucks, then the OP's approach is ok, better than standard TP even. I agree though that a single table approach is best unless 1) the table has to scale to really, really large sizes or 2) there is a lot of churn on the data (lots of bulk inserts and deletes). merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
