You are right in that the primarykey is not needed by the database, but it is needed by OJB for materializing instances of this class. However using the implicit unique constraint of primarykeys to ensure that there is only at most one relationship between two instances of the other classes is not really a good database design IMO (especially not if you let the database or OJB create the primarykeys rather than doing it manually). Regard your case as an indirection table between Profile and Category (no primarykey needed, only one unique constraint on the two foreignkey fields) with the additional fact that there is a class representing the indirection table, which means an additional primarykey is needed for OJB.
Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
