Comments on: Finding queries with duplicate columns

By: Shlomi Noach

Shlomi Noach — Sat, 08 Aug 2009 18:08:39 +0000

But in many cases I don’t fetch results automatically into some hash or dictionary, but rather do rs.getString(“Country.Name”); or rs.getString(“City.Name”); (e.g. in Java).
ORM Frameworks also solve this problem.

Therefore, while I’m using fully qualified column names, there are no duplicates. The relational model stays sane.

What I’m saying is that it’s a very common case. How many tables just have “id” for AUTO_INCREMENT? It’s so common and I’m not sure it doesn’t make sense.

By: Xaprb

Xaprb — Sat, 08 Aug 2009 17:44:29 +0000

I said it makes no sense because you can’t tell one from the other. What happens if you fetch a row from the result into a Perl hash or a Python dictionary…? What if you wanted to get at the data in one of the Name columns but not the other (assuming their contents differ)?

The relational model is saner here IMO: everything is sets, and sets don’t allow duplicates. “If something is true, saying it twice doesn’t make it more true.”

By: Shlomi Noach

Shlomi Noach — Sat, 08 Aug 2009 13:02:40 +0000

Baron,

The problem you describe can also rise from normal SQL queries, for example (using ‘world’ database):

mysql> select * from (select * from Country join City on (Country.code = City.CountryCode)) as sel1;
ERROR 1060 (42S21): Duplicate column name ‘Name’

It just happens that both tables have a ‘Name’ column. This is still fine, since with SQL I can always say ‘SELECT City.Name’ explicitly.

So I’m not sure this necessarily falls under “things that make no sense”. Rather, perhaps the “SELECT * FROM (…inner query…) is the problematic part, whereas it cannot be guaranteed to succeed.

It is questionable if every single column should be aliased; but even then collisions may occur.

Regards,
Shlomi