Prev: JApplet + JNI working only in Safari
Next: drools+rational 7
From: tomo on 22 Dec 2009 02:35
public class Car{

long carId;
short carType;

}

This class is mapped to table Car. So my question is is it better to have
one more table names let's say CAR_TYPE which will have have columns like
(NUMBER(15) type Id, VARCHAR2(200) typeName) and than a FK from
table CAR or an ENUM names CAR_TYPE ?



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4640 (20091126) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




From: Martin Gregorie on 22 Dec 2009 08:44
On Tue, 22 Dec 2009 08:35:42 +0100, tomo wrote:

> public class Car{
>
> long carId;
> short carType;
>
> }
>
> This class is mapped to table Car. So my question is is it better to
> have one more table names let's say CAR_TYPE which will have have
> columns like (NUMBER(15) type Id, VARCHAR2(200) typeName) and than a FK
> from table CAR or an ENUM names CAR_TYPE ?
>
Depends what you're trying to represent in the database. A full solution
would probably rename your Car to, say, vehicle and use it as a many:many
link between an Owner table and a Car table:

Owner Car
name PK-+ Vehicle +-- make PK,FK <--- Manufacturer (not shown)
age | plate |+- model PK
.... +---->name FK || ....
make FK <--+|
model FK <---+
colour
date_bought
date_sold
registered?
....

IOW, start by setting up an ERD, list each entity's attributes and key
attributes, normalise it, denormalise as needed. When you've got to this
point you'll understand the problem you're trying to solve. Thetre's no
point in considering Java representations before you have a first cut,
normalised data model.

If you don't understand the above, you need to start by doing Data
Modeling 101 and after that take another stab at the problem..


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
From: Lew on 22 Dec 2009 09:58
Martin Gregorie wrote:
> On Tue, 22 Dec 2009 08:35:42 +0100, tomo wrote:
>
>> public class Car{
>>
>> long carId;
>> short carType;
>>
>> }
>>
>> This class is mapped to table Car. So my question is is it better to
>> have one more table names let's say CAR_TYPE which will have have
>> columns like (NUMBER(15) type Id, VARCHAR2(200) typeName) and than a FK
>> from table CAR or an ENUM names CAR_TYPE ?
>>
> Depends what you're trying to represent in the database. A full solution
> would probably rename your Car to, say, vehicle and use it as a many:many
> link between an Owner table and a Car table:
>
> Owner Car
> name PK-+ Vehicle +-- make PK,FK <--- Manufacturer (not shown)
> age | plate |+- model PK
> .... +---->name FK || ....
> make FK <--+|
> model FK <---+
> colour
> date_bought
> date_sold
> registered?
> ....
>
> IOW, start by setting up an ERD, list each entity's attributes and key
> attributes, normalise it, denormalise as needed. When you've got to this
> point you'll understand the problem you're trying to solve. Thetre's no
> point in considering Java representations before you have a first cut,
> normalised data model.
>
> If you don't understand the above, you need to start by doing Data
> Modeling 101 and after that take another stab at the problem..

I would not use an integral type to model "car type" in the first place.
Also, working with object-relational mapping (ORM), remember that data
modeling and object modeling differ. Do the data modeling separately.

Integers as keys (data modeling perspective) are *surrogates* for the natural
keys. Sometimes (frequently, even) it's far better to use the natural keys.

In JPA you wouldn't express relationships through the keys

public class Car{
long carId;
short carType;
}

but through the objects

public class Car{
@Id
long carId;

@ManyToOne
CarType carType;
}

--
Lew
 | 
Pages: 1
Prev: JApplet + JNI working only in Safari
Next: drools+rational 7