Form saving, db question ?
in [Java Programming]
|
Prev: PDF Screen Shots
Next: open all sites free now
From: Lew on 9 Jul 2010 10:32 vlado wrote: >> So can you please give me suggestion how the datatable(s) should look >> like to save this form, and how >> should entites look like ? > Lew wrote: > I already gave one answer to that question, but you didn't answer > mine. > You need to answer the questions we ask, and research the things we suggest, else why do you bother to ask us for help? > -- PostgreSQL > CREATE TABLE garage > ( > garage VARCHAR(32) PRIMARY KEY, > address TEXT, > info TEXT > ); > > CREATE TABE make > ( > make VARCHAR(32) PRIMARY KEY > ); > > CREATE TABLE car > ( > car VARCHAR(32) PRIMARY KEY, > make VARCHAR(32) NOT NULL FOREIGN KEY REFERENCES make (make) > garage VARCHAR(32) FOREIGN KEY REFERENCES garage (garage), > whenin DATE, -- oops, I forgot price NUMERIC (10, 2), > info TEXT > ); > > -- no surrogate key ID needed or wanted > -- Lew
From: Arne Vajhøj on 9 Jul 2010 22:14 On 09-07-2010 10:24, Lew wrote: > Actually, I was trying to get at why he was using ID specifically. > The answer "it's the primary key" is flat-out silly - that's circular > reasoning. It's not the primary key because it's the primary key. > > WHY is it the primary key? What does it *mean*? > > If the answer is "nothing in terms of the problem domain" (vlado - you > need to know what "problem domain" means) then the logical analysis > should eliminate ID and look at the *real* primary key - the one that > identifies the thing described *in terms of the domain of discourse*. > > A database table is a representation of the problem domain - it > doesn't drive the definitions, it reflects them. That is what about half the DB people thinks. The other half thinks exactly the opposite. Arne
From: Lew on 9 Jul 2010 23:40 Lew wrote: >> Actually, I was trying to get at why he was using ID specifically. >> The answer "it's the primary key" is flat-out silly - that's circular >> reasoning. It's not the primary key because it's the primary key. >> >> WHY is it the primary key? What does it *mean*? >> >> If the answer is "nothing in terms of the problem domain" (vlado - you >> need to know what "problem domain" means) then the logical analysis >> should eliminate ID and look at the *real* primary key - the one that >> identifies the thing described *in terms of the domain of discourse*. >> >> A database table is a representation of the problem domain - it >> doesn't drive the definitions, it reflects them. Arne Vajhøj wrote: > That is what about half the DB people thinks. > > The other half thinks exactly the opposite. That's not at all accurate, though I'd be interested in the statistical basis for your observation. The only way I can take the meaning of "exactly the opposite" is that you are suggesting "half" of "database people" think that the problem domain should represent the database. I have never in my decades of reading about database design encountered anyone who suggested the opposite of having the database model the problem domain, or even deprecated the importance of the unique attribute collection that defines an entity in the business-domain model. I'm familiar with the controversy over sequenced surrogate keys vs. not using them, but no one I've read in that debate has ever suggested that the tail should wag the dog. /Au contraire/ the proponents of surrogate keys I've read suggested that surrogate keys help to model the problem domain, and protect against volatility in the "natural" key. (See the Developerworks article mentioned /infra/.) Furthermore, if one does not analyze the problem domain for natural keys, one cannot properly assign sequenced surrogate keys to the rows, and will risk update anomalies. <http://en.wikipedia.org/wiki/Third_normal_form manages to explain 3NF quite clearly without once resorting to sequenced surrogate keys. The ACM article at <http://www.bkent.net/Doc/simple5.htm> goes through five normal forms without once resorting to sequenced surrogate keys. Same with <http://support.microsoft.com/kb/283878> The Developerworks article at <http://www.ibm.com/developerworks/web/library/wa-dbdsgn1.html> discusses how to pick keys and the motivations to use surrogate keys responsibly. They provide a balanced viewpoint, but are careful to point out, "As part of the plumbing, the surrogate key has no need to ever be visible outside the DB. In particular, it should never be revealed to the user. ... If a business need arises for providing the user with a unique identifier to a particular dataset, this identifier should be considered real /business/ data and kept separate from the plumbing." [emph. original] -- Lew
From: Arne Vajhøj on 10 Jul 2010 10:53 On 09-07-2010 23:40, Lew wrote: > Lew wrote: >>> Actually, I was trying to get at why he was using ID specifically. >>> The answer "it's the primary key" is flat-out silly - that's circular >>> reasoning. It's not the primary key because it's the primary key. >>> >>> WHY is it the primary key? What does it *mean*? >>> >>> If the answer is "nothing in terms of the problem domain" (vlado - you >>> need to know what "problem domain" means) then the logical analysis >>> should eliminate ID and look at the *real* primary key - the one that >>> identifies the thing described *in terms of the domain of discourse*. >>> >>> A database table is a representation of the problem domain - it >>> doesn't drive the definitions, it reflects them. > > Arne Vajhøj wrote: >> That is what about half the DB people thinks. >> >> The other half thinks exactly the opposite. > > That's not at all accurate, though I'd be interested in the statistical > basis for your observation. That seems to be what is observed when DB people discuss. > The only way I can take the meaning of "exactly the opposite" is that > you are suggesting "half" of "database people" think that the problem > domain should represent the database. You usually have some terms to describe when someone post something that is not particular relevant. Is this a strawman or a non sequitur (or both)? > I'm familiar with the controversy over sequenced surrogate keys vs. not > using them, Then why do you then post: # If the answer is "nothing in terms of the problem domain" (vlado - you # need to know what "problem domain" means) then the logical analysis # should eliminate ID and look at the *real* primary key - the one that # identifies the thing described *in terms of the domain of discourse*. as if it is the one and only truth?? > Furthermore, if one does not analyze the problem domain for natural > keys, one cannot properly assign sequenced surrogate keys to the rows, > and will risk update anomalies. Any source for that? > <http://en.wikipedia.org/wiki/Third_normal_form > manages to explain 3NF quite clearly without once resorting to sequenced > surrogate keys. > > The ACM article at > <http://www.bkent.net/Doc/simple5.htm> > goes through five normal forms without once resorting to sequenced > surrogate keys. > > Same with > <http://support.microsoft.com/kb/283878> No one has claimed that it is not possible. > The Developerworks article at > <http://www.ibm.com/developerworks/web/library/wa-dbdsgn1.html> > discusses how to pick keys and the motivations to use surrogate keys > responsibly. They provide a balanced viewpoint, but are careful to point > out, "As part of the plumbing, the surrogate key has no need to ever be > visible outside the DB. In particular, it should never be revealed to > the user. ... If a business need arises for providing the user with a > unique identifier to a particular dataset, this identifier should be > considered real /business/ data and kept separate from the plumbing." > [emph. original] That is one of the main arguments for surrogate keys. The problem with real keys is if it need to change. Surrogate keys that are not exposed outside the database never change. Arne
From: Lew on 10 Jul 2010 11:31
Lew wrote: >> I'm familiar with the controversy over sequenced surrogate keys vs. not >> using them, Arne Vajhøj wrote: > Then why do you then post: > > # If the answer is "nothing in terms of the problem domain" (vlado - you > # need to know what "problem domain" means) then the logical analysis > # should eliminate ID and look at the *real* primary key - the one that > # identifies the thing described *in terms of the domain of discourse*. > > as if it is the one and only truth?? Because there I'm talking about the logical analysis, as I clearly stated, and not the physical implementation. You cannot appropriately choose a sequenced surrogate key unless you know what the natural key is, i.e., what the identity is that you're modeling. -- Lew |