Well, my guess is that he's relating each place name record with a freeway distance record... that's where all of the selects and stuff come in.
Sounds like you need to figure out a normalization scheme, Jim. With a relational database, you shouldn't need to pre-parse things. Instead, see if you can't figure out how to do the freeways by exit number, which is usually the same as the mile number (at least in Oregon.) That way, if you're leaving eugene, OR and you're going to Portland, you know you're going to get on the freeway at exit 195 and exit it at exit 310... 115 miles.
I don't have a resource, but I ran across some GIS algorithms online somewhere that would make it possible to just store this data in a large relational table, and then draw a line "as the crow flies" from coordinate to coordinate (Eugene, OR and PDX, OR in this example)... and then snap it to the road system using a "best guess" method per mile.
You'd need a table of junctions, a MONSTOROUS table of freeway exits and their GPS coordinates (or your own coordinate system) (I might split this table by state), and a table of origins/destinations (possibly also split by state) and coordinates.
When someone puts in an origin and a destination, the GIS algorithm finds the closest destination and origin point in your dest-orig table. It then figures out the "as the crow flies" line, and does a select to figure out if it needs to use any junctions. Finally, it generates a long list of freeway exits, and you can use mysql's integrated math functions to sum the distances between the exits.
Does that sound like it would work? I probably didn't hit it anywhere near on the head, but my method should eliminate a lot of the processing, because I think you can easily get tables of freeway exits and GPS coordinates. After that, it procesess the GIS algorithm in php on the server (no preprocessing required) and then sends it all to the database in a tidy set of queries that can just return a sum of the distance.
