On Wed, Jul 24, 2013 at 11:47 AM, Bèrto ëd Sèra <berto.d.s...@gmail.com> 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 crossing the two defining tables. Unless you take your PK down there is > no way that can happen, and even if it does, a cartesian product defining > how many languages a user speaks does not look like needing more than > killing doubles. So what would be the rationale for investing process into > this?
You are probably right: you are like to never refactor this kind of design, and this situation using a surrogate key is useless. But what happens if your language is no more uniquely identified by lpp_language_id? Suppose you need to track also the language version and therefore a language is identified by the couple (id, version). In this case you have to refactor two tables: the language one and the person-language join table. Having a surrogate key on both sides allows you to smoothly add such constraint without having to refactor the latter table and ensuring all previous joins still work. Ok, not a really smart example, but the only one that comes into my mind at the moment. Luca -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
