Re: PostgreSQL versus MySQL for GPS Data
От | Merlin Moncure |
---|---|
Тема | Re: PostgreSQL versus MySQL for GPS Data |
Дата | |
Msg-id | b42b73150903170618n1a97ba6hdfe5adb594f83183@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL versus MySQL for GPS Data (Craig Ringer <craig@postnewspapers.com.au>) |
Ответы |
Re: PostgreSQL versus MySQL for GPS Data
|
Список | pgsql-general |
On Tue, Mar 17, 2009 at 7:47 AM, Craig Ringer <craig@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
В списке pgsql-general по дате отправления: