Jim Ginn wrote: >>Not sure why you you need the trucks location 'every second' ie: >>31,536,000 rows per year per truck ? >>doing every 30 seconds seems more manageable at 1,051,200 rows per year >>per truck? Maybe better at 60 seconds?
OpenGGD is also designed to deliver GPS data in real time; we have customers that sometimes want to track their trucks in real time, that's why we think the worst scenario could be one position per second. Juan Karlos 2009/3/18 Jim Ginn <j...@oats.com> > Juan: > > We've had success with spatial indexes and mysql on our sites however our > numbers are smaller: > > http://brokersnetwork.com (200,000+ records) > > http://yearlyrentals.com (200,000+ records) > > http://avalonrealestate.com/map.php (4,400+ records) > > ... > > Not sure why you you need the trucks location 'every second' ie: > > 31,536,000 rows per year per truck ? > > doing every 30 seconds seems more manageable at 1,051,200 rows per year > per truck? Maybe better at 60 seconds? > > Jim > > > > Juan, > > > > On Wed, Mar 18, 2009 at 11:14 AM, Juan Pereira > > <juankarlos.open...@gmail.com> wrote: > >> Hello, > >> > >> I'm currently developing a program for centralizing the vehicle fleet > >> GPS > >> information -http://openggd.sourceforge.net-, written in C++. > >> > >> The database should have these requirements: > >> > >> - The schema for this kind of data consists of several arguments > >> -latitude, > >> longitude, time, speed. etc-, none of them is a text field. > >> - The database also should create a table for every truck -around 100 > >> trucks-. > >> - There won't be more than 86400 * 365 rows per table -one GPS position > >> every second along one year-. > >> - There won't be more than 10 simultaneously read-only queries. > >> > >> The question is: Which DBMS do you think is the best for this kind of > >> application? PostgreSQL or MySQL? > > > > I think it depends on exactly what you want to do with the data. MySQL > > has fairly poor support for spatial types but you can achieve a lot > > just manipulating normal data types. Postgres (which i know nothing > > about) appears to have better spatial support via "postgis" > > > > http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html > > > > http://postgis.refractions.net/documentation/manual-1.3/ > > > > In terms of data size you should not have a problem, I think you need > > to look at how you are going to query the tables. > > > > Cheers, > > > > Ewen > >> > >> > >> Thanks in advance > >> > >> Juan Karlos. > >> > > > > -- > > MySQL General Mailing List > > For list archives: http://lists.mysql.com/mysql > > To unsubscribe: http://lists.mysql.com/mysql?unsub=...@oats.com > > > > > >
