Re: MySQL versus PostgreSQL for GPS Data
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
Re: MySQL versus PostgreSQL for GPS Data
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
MySQL versus PostgreSQL for GPS Data
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? Thanks in advance Juan Karlos.
Re: MySQL versus PostgreSQL for GPS Data
Juan I don't think it really matters, doesn't look like you'll need any features which are only available in one or the other! The main issue you will have is supporting the application and the RDBMS so go for the one you are most comfortable with and can support/configure best. Regards John 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? Thanks in advance Juan Karlos. __ This email has been scanned by Netintelligence http://www.netintelligence.com/email -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: MySQL versus PostgreSQL for GPS Data
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=arch...@jab.org
Re: MySQL versus PostgreSQL for GPS Data
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
