Re: What does everyone else do for graphically displaying data?
- From: Silvio Bierman <sbierman@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 24 Dec 2007 12:23:55 +0100
Lew wrote:
mdR wrote:anyway, one good example i've traced worked with only one table and
even that got kind of complicated managing one key id between db
objects and various gui objects. i guess there was ~a lot~ happening
behind the curtain that i've got to learn ;) iyo-does it ever get
easy?
Easier, yes, easy, no.
The matter of keys is complicated by a tendency for some to overuse integer surrogate keys, without identifying the so-called "natural" key that at least ideally identifies the row based on the attributes represented by the columns.
The "key id" I take you to mean is an integer SEQUENCE surrogate key maintained by the database to help determine row uniqueness, yes?
This surrogate key should be managed by the database - your object should use it, if at all, only as a very low-level handle for a database row, not for the object' own purposes. Sequenced surrogate keys exist only to make the database simpler, and are not (typically) part of the data model. (We'll ignore certain exceptions.) One should instead understand a row in the database to be determined by a "natural" column or set of columns, and usually there should be a UNIQUE constraint on that set of columns. [1]
Think of the object model - these attributes would be the ones that determine equals() in your object model.
The integer surrogate key should be determined, if you even need it at all, which you really don't, actually, except sometimes to underpin DAO layer machinery, by looking it up from the database, and in no wise should the middleware attempt to set or change it.
So you shouldn't any more have trouble "managing" (translation: "mucking with") the key ids.
[1]
"But so-called 'natural' keys can change in real life! People change SSNs all the time!" No, they don't do it all the time. They do it rarely. And when they do, it'll screw up your database schema. Then you'll fix it, manually. At which point their new SSN will uniquely identify them, so the key will still work as a key.
Don't get me started on data warehouse schemas. They're part of what make me so cynical about transaction db schemas.
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.
Regards,
Silvio Bierman
.
- Follow-Ups:
- References:
- What does everyone else do for graphically displaying data?
- From: mdR
- Re: What does everyone else do for graphically displaying data?
- From: RedGrittyBrick
- Re: What does everyone else do for graphically displaying data?
- From: mdR
- Re: What does everyone else do for graphically displaying data?
- From: Lew
- Re: What does everyone else do for graphically displaying data?
- From: mdR
- Re: What does everyone else do for graphically displaying data?
- From: Lew
- What does everyone else do for graphically displaying data?
- Prev by Date: Re: sqlserver JDBC driver problem.
- Next by Date: Re: What does everyone else do for graphically displaying data?
- Previous by thread: Re: What does everyone else do for graphically displaying data?
- Next by thread: Re: What does everyone else do for graphically displaying data?
- Index(es):
Relevant Pages
|
|
