Am 06.06.12 13:24, schrieb Paul Poulain:
Le 25/05/2012 18:23, Marc Balmer a écrit :
I contradict. This results neither in complexity nor in mistakes. Imagine two tables, A and B, which both have an id column, then a select would probably look like the following:
select A.id as aid, B.id as bid from A, B, where ...
So it's not a problem.
I contradict your contradiction. If you have branches.id as identifier, then, the FK in borrowers table (the branch of the patron) can't be id, as, in your proposition, the identifier of the borrower will be borrower.id
It means instead of : borrowers(borrower_id,surname,firstname,branch_id) / branches(branch_id,name) / SELECT * FROM borrowers LEFT JOIN branches USING(branch_id) and use all field in a hash, your option would result in:
borrowers(id,surname,firstname,branch_fk_id) / branches(id,name) / SELECT borrowers.*,branches.id as bid,branches.name LEFT JOIN branches ON (borrowers.branch_fk_id,branches.id), and deal with bid as a hash entry.
So, depending on the part of Koha you'll refer to $borrowers->{bid} or $branch->{id}
I can't imagine a second that would be easier to read. No gain, big loss, this option must be forgotten according to me.
From a technical point of view, there is no need (and no benefit) for
column names to be unique accross a database. The only requirement is that column names be unique within the same table. Other than that, the name is totally irrelevant and can be aliased to anything in a query.
That said, while I still disagree with your reasoning (and you probably with mine), this does not mean that I am opposing to your proposal. I am just saying, that it is not needed, strictly speaking. And I am kind of a database / SQL purist ;)