Juan: Still seems excessive but in that case, ignore inserts that have no change in lat / lon ...
Jim > 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 >> > >> > >> >> > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
