Form saving, db question ?
in [Java Programming]
|
Prev: PDF Screen Shots
Next: open all sites free now
From: vlado on 9 Jul 2010 08:10 Here is a concrete example in attachemt how the form looks like. Input forms are prices and name of the car garage. So can you now suggest me how would the database table(s) look like, and how will the entites look like ?
From: vlado on 9 Jul 2010 08:13
From: vlado on 9 Jul 2010 08:28 CAR GARAGE NAME: CITY GARAGE (inputText) ------------------------------------------------------ | 2005 | 2006 | 2007 | 2008 | ------------------------------------------------------- AMG | 200.000 | | | | --------------------------------- ---------------------- OPEL | 15.000 | 20.000 | | | ------------------------------------------------------- AND SO ON..... Where Car garage name is inputText, and so are prices that are enetered beneth years. So can you please give me suggestion how the datatable(s) should look like to save this form, and how should entites look like ? Thanks is advance.
From: Lew on 9 Jul 2010 10:24 vlado wrote: >>> I'm using a relation database, and ID in these tables is used >>> as a primary key. What do you mean by you will have a lookup table >>> with car types to keep them consistent ? Is't lookup table bes used >>> when let's say I hava a drop down list in >>> my form with data that which will be rearly changed or updated ? > Arved Sandstrom wrote: >> My question would still be, in *your* problem is the car type >> (something like FORD_MUSTANG) part of the identity? Lew was trying to >> get at this, because it's important. > 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. >> If it's not part of the identity then that field is more of a >> free-form descriptive string; if you wish to pre-define the available >> values that then is still more of a user-input presentation-layer >> constraint, and you could use an enum mapping to a varchar field to >> store the actual values. In this case your ID primary key is a >> surrogate key and you may have no natural key at all. > >> If OTOH the car type is part of the identity (it's all or some of >> a/the natural key) then you may very well still be using the ID column >> as a surrogate and primary key, but it's now also in your interests to >> ensure that the car type column is constrained (a unique index) on the >> data/RDBMS side. In which case the table that enforces this constraint >> isn't going to be the table that stores user input; hence foreign >> keys. In this case, as Lew said, the actual param value is in the user >> input table, that uses a foreign key relationship to point back at the >> table containing the car type natural keys. > vlado - that point is the key. >> "Rarely changed or updated" isn't typically your driver in deciding >> data relationships, what the natural keys are, or how you'll enforce >> data integrity in your tables. It's definitely a factor - for example, >> I'd take it into account when fine-tuning entity caching in JPA - but >> not at this stage. > > 1.What do you mean by "part of identity" ? > Once again, read about third normal form (3NF). I didn't mention it for its irrelevance, but its relevance. You are going to have extremely poor results if you don't familiarize yourself with the basics of database design. "Identity" is the attribute or collection of attributes that uniquely identifies an entity. Think of it as the object attributes that contribute to 'equals()' evaluation, if you like. Answer the question I asked above, which you have for some reason so far refused to do: What is the *meaning* of ID in the problem domain? It isn't that "it's the primary key". That's backwards thinking. What does it represent in terms of the entities that make it the primary key. Again, I'm willing to gamble that it means nothing. Please answer this question. > 2.Other thing is that on every project we have practise to have lookup > tables , like country that have for example ID, NAME columns, so I can't > use table without primary key (ID). > ID and "primary key" are not synonyms. What is the *real* key? -- Lew
From: Lew on 9 Jul 2010 10:28
On Jul 9, 8:28 am, vlado <vl...(a)miha.net> wrote: > CAR GARAGE NAME: CITY GARAGE (inputText) > > ------------------------------------------------------ > | 2005 | 2006 | 2007 | 2008 | > ------------------------------------------------------- > AMG | 200.000 | | | | > --------------------------------- ---------------------- > OPEL | 15.000 | 20.000 | | | > ------------------------------------------------------- > > AND SO ON..... > > Where Car garage name is inputText, and so are prices that are enetered > beneth years. > So can you please give me suggestion how the datatable(s) should look > like to save this form, and how > should entites look like ? > I already gave one answer to that question, but you didn't answer mine. -- 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, info TEXT ); -- no surrogate key ID needed or wanted -- Lew |