On Wed, 9 Jun 2010, Oliver Peters wrote: > So I assume that it is not(!) a mistake not(!) to use a composite PK in my > table "customer" (customernumber,customerorigin) and to refer to it from > the table "order" where I had to use these fields as a composite FK?
Oliver, Too many negatives there for me to really follow what you're asking. Whenever possible, the primary key for a table should be a 'natural' value that uniquely describes that entity. For example, a vehicle identification number, license registration number, or a person's passport number. For a customer table there is no natural identifier so you make one up: the ID column. This could be a sequential number or a compisite based on the customer's name. The customer table stands alone and can be used in various applications so you want only the single ID attribute as the primary key. If it is possible for a specific named customer to have several origins, then you would want a composite primary key. But, if each customer has only a single origin then you should have a simple primary key, the customer ID. The order table should have its own ID column as a primary key. This way you assign each new order a different primary key even if the same customer places two or more orders on the same date. For example: order_number customer_id date 1 1 9 June 2010 2 3 9 June 2010 3 1 9 June 2010 This makes each order unique regardless of customer, date, or items ordered. HTH, Rich _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
