Re: What does everyone else do for graphically displaying data?

Silvio Bierman wrote:
I disagree with your view on natural keys versus what you call surrogate keys. The equals definition for a Point class would compare (x,y) tuples where a Polyline class could contain a Collection of Points and have an equals definition that compares the contained Points.
To represent a number of Polylines in a database you would have to give the Polyline some form of key, comparable with the objects identity it has in the Java program. Primary keys are more comparable with == than with equals.

Good work. You found an important use case for integer keys, albeit not auto-sequenced ones, in a scenario different from the one I described but related. The differences are important, and explain why this scenario is not the one to which I alluded upthread.

To represent the polylines in the database I'd have an integer column representing the order of the points in the Polyline, combined with a foreign key reference to the Polyline. There'd be no sequenced integer key at all in the polyline table, just ( polyline_id, point_seq ) as the PK. I would never compare polyline rows in the database to each other point by point; the concept of value equality is not relevant to it.

Since the point order is significant, it cannot be auto-sequenced by the database. It's part of the data model, and therefore part of the natural key.

To represent multiple polylines one must have a similar key, ( vertex_id, polyline_id). This is one of the exceptions to which I alluded in my post. Again, I'd probably not use an auto-sequenced key, since I want to keep the sequence local to the vertex_id. Furthermore, the object model needs to be able to tell the polylines apart; however, the object has itself as a natural key, which the db row does not. The polyline_id, sequence or not, stands in for the object reference. Again, the concept of value equality is not relevant - I doubt very much that you'd compare polylines point by point in your object model either. You'd use ==.

In this case the numeric ID, for which I would not use an auto-sequence, actually is part of the data model. (That's why I wouldn't use an auto-sequence.) Therefore it actually is part of the "natural" key, along with the vertex_id. You use an integer column to model the object identity reference.

My earlier comments were about a different scenario from this, where the integer is a synonym for a natural key, not actually part of the natural key. I specifically spoke of auto-sequenced integer surrogate keys; this scenario has an integer natural key column that should not be auto-sequenced.

--
Lew
.