Re: [SQL] Advice on key design

Hi, yeah, I am okay with design prudence, just used to be so paranoid about performance that just any possible "one more thing to do" gets me nervous :) Language versions do exist, say Dutch has different orthography depending on what convention is used, so you may well need to suddenly add a furt

Re: [SQL] Advice on key design

On Wed, Jul 24, 2013 at 11:47 AM, Bèrto ëd Sèra wrote: > Hi, > > It looks heavy, performance-wise. If this is not OLTP intensive you can > probably survive, but I'd still really be interested to know ow you can end > up having non unique records on a Cartesian product, where the PK is defined > by

Re: [SQL] Advice on key design

Hi, It looks heavy, performance-wise. If this is not OLTP intensive you can probably survive, but I'd still really be interested to know ow you can end up having non unique records on a Cartesian product, where the PK is defined by crossing the two defining tables. Unless you take your PK down the

Re: [SQL] Advice on key design

On Wed, Jul 24, 2013 at 10:38 AM, Bèrto ëd Sèra wrote: > What would be the rationale behind the serial number? > The serial key, also named "surrogate key" is there for management purposes. Imagine one day you find out your database design is wrong and what was unique the day before is no more s

Re: [SQL] Advice on key design

Hi, > I also need the field "lpp_id" as a unique key which is a field that contains a consecutive number of type serial. Are you sure you REALLY need this? It looks like a lot of trouble for nothing, as you now have one thing warranting the unicity of the record (your serial) plus a unique key wa

Re: [SQL] Advice on key design

Agreed with Anton, as PK, lpp_id is easier to be managed than (lpp_person_id + lpp_language_id) One more suggestion, foreign key constraints could be setup on lpp_person_id and lpp_language_id to link with target tables. Thanks, Stan 2013/7/24 Anton Gavazuk > The reason is simple - as you nee

Re: [SQL] Advice on key design

The reason is simple - as you need the artificial PK lpp_id, then everything else becomes an constraint Thanks, Anton On Jul 24, 2013, at 0:28, JORGE MALDONADO wrote: >> In your case it would be lpp_id as PK, and >> lpp_person_id,lpp_language_id as unique constraint >> >> Thanks, >> Anton Is

Re: [SQL] Advice on key design

>> In your case it would be lpp_id as PK, and >> lpp_person_id,lpp_language_id as unique constraint >> >> Thanks, >> Anton Is there a reason to do it the way you suggest? Regards, Jorge Maldonado On Tue, Jul 23, 2013 at 5:02 PM, Anton Gavazuk wrote: > Hi Jorge, > > In your case it would be lpp

Re: [SQL] Advice on key design

Hi Jorge, In your case it would be lpp_id as PK, and lpp_person_id,lpp_language_id as unique constraint Thanks, Anton On Jul 23, 2013, at 23:45, JORGE MALDONADO wrote: > I have 2 tables, a parent (tbl_persons) and a child > (tbl_languages_per_person) as follows (a language table is also invol

[SQL] Advice on key design

I have 2 tables, a parent (tbl_persons) and a child (tbl_languages_per_person) as follows (a language table is also involved): -- tbl_persons -- * per_id * per_name * per_address -- tbl_languages_per_person --