Arne Georg Gleditsch wrote:
>* Malcolm Box
>
>>indexes.type is still indexes.type, but it now references
>>declarations.declid. indexes.langid references declarations.langid.
>>Non-normalised I know - see the bug report ;-)
>>
>
>Ah, like so. But if langid is a functional dependency of declid,
>couldn't you just make declid the primary key of declarations and be
>done with it? You could even remove langid from the indexes table,
>possibly with a significant size gain.
>
Yes, you could. The current code is stuck in a half-way house between
my original idea (declid is the one and only key) and a proposal from
Robin that a (langid, declid) tuple would be better.
What we've ended up with is that the indexes table assumes that the
(langid, declid) tuple is the foreign key, while because of how the
declarations table is generated is actually just using declid as the
primary key.
I'm tempted to more to the tuple as the key, since this makes it easier
to filter indexes by language without joining onto declarations. It
seems to me that langid could become a reasonably useful thing to have
in the indexes table, rather than hanging out in the declarations table
where it doesn't really fit as dependant info.
>Anyway, I still think I'm right. d.declid in Kristoffer's Postgres.pm
>patch (in the setting of $indexes_select) should be d.declaration as
>far as I'm able to see. That's the way it looks in Mysql.pm, at least.
>
Yes, in indexes_select the value that is to be returned from the select
should be d.declaration, as that is the string that gets displayed.
Malcolm
|
