Thanks for that response Frank. I find this very interesting. It seems that you could model just about any data stored in a RDBMS as an object in an object-oriented programming language.
For example: If you were writing a database program for used car lots you could represent cars as objects instead of data in individual table cells. But at some point you have to ask, is this worth the effort? I think that is one advantage of the RDBMS model, you can represent all types of data without custom programming. Still, I wonder if the overhead of an additional engine on top of the database makes the speed gap small. Have there been any documented benchmarks that compare this model to others? I think I'll see if my friend is interested in running some tests. I appreciate the input. SLB -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Warmerdam Sent: Friday, November 30, 2007 11:37 AM To: [email protected] Cc: Mark Dennehy Subject: Re: [Geowanking] Storing Simple Geometries in a RDBMS Model Landon Blake wrote: > What are the limitations or technical challenges that come from a > different approach, that of storing feature geometries in a database > using the traditional relational database model? > > For example: > > A database has a Coordinates table which stores a unique id for each > coordinate, with a northing, easting, and elevation. The database has > another Line table which stores a unique id and perhaps the length of > the line. A third PointsToLines table stores entries that link > Coordinates to Lines using the unique ids in both tables. Queries could > then be executed to obtain all the coordinates that make up a line, for > example. > > Is there a reason why this technique is not used more frequently? Is > there popular software that does use this technique to store spatial data? Landon, This was the "base model" for the original OGC simple features specification for SQL and has been used from time to time. But I believe it is not widely used because it is deathly slow. It is expensive to fetch a feature with it's geometry, and it's expensive to find out what feature(s) match a particular spatial criteria. Best regards, -- ---------------------------------------+-------------------------------- ------ I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | President OSGeo, http://osgeo.org _______________________________________________ Geowanking mailing list [email protected] http://lists.burri.to/mailman/listinfo/geowanking Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. _______________________________________________ Geowanking mailing list [email protected] http://lists.burri.to/mailman/listinfo/geowanking
