[OSM-dev] smart db table scheme? (was: tiles cut corners)

Immanuel Scholz immanuel.scholz at gmx.de
Mon Feb 27 09:25:49 GMT 2006


Hi,

>> No, you need the subselect (or its equialent) to get the newest elements
>> in the bounding box. (It's a wiki, right?)
>
> yes.. to expand: you get the nodes in a bounding box, then you get the
> latest versions of those nodes, then you have to retest that the latest
> version is still within the bounding box.

I already criticize this table scheme some month ago.. Stored in this way,
you can do very efficient changes to the data - just add an entry - but
slow read only access of the latest version.

Wouldn't it be smarter to optimize the scheme so that common access (read
of the latest version) is fast and uncommon access (read of non-latest,
changes) are slow?


Someone suggested introducing a "latest" flag that is set for the data
entry which is currently the latest version.

I would rather suggest having two tables per object type - one for the
always latest version (with unique-constraint on "id") and one for the
history stuff. I think this would be the fastest in just reading the
latest version of an area (especally since history would not affect the
speed of reading-the-latest-version anymore).

With the use of some db features as triggers and stored procedures,
changing the data could be almost as fast as now.


Ciao, Imi.






More information about the dev mailing list