In the limit, fetching data from an in-process, close to native representation (e.g. SQLite) will significantly outperform an out-of-process (and possibly remote machine) based RDBMS, at the very least due to the latency and inter-process communication involved.
One could claim that the performance difference could be introduced by differences in the FDO translation layer (e.g. SQLite translation being hypothetically slower than other RDBMS), but this is not the case in FDO. The above assumes simple queries, as generally required by MapGuide rendering, given that the original question was about MapGuide. Traian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jackie Ng Sent: Wednesday, April 06, 2011 9:04 PM To: [email protected] Subject: [mapguide-users] RE: RDBMS connection performance in Mapguide Agreed. You shouldn't automatically dismiss SQL Server's performance (or any other RDBMS) just because MapGuide may give a very bad impression of it. There are entire books written and tons of Google results about this particular subject (DB design and optimisation). All MapGuide does is issue queries to your database, it doesn't know anything about indexes, execution plans, etc. - Jackie -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/RDBMS-connection-performance-in-Mapguide-tp6245821p6248246.html Sent from the MapGuide Users mailing list archive at Nabble.com. _______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users _______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users
