ER_NON_UNIQ_ERROR以及如何正确设计表

Question

I have come across this problem and I've tried to solve it few days now.

Let's say I have following tables

properties

-----------------------------------------
|  id  |  address  |  building_material |
-----------------------------------------
|   1  |  Street 1 |         1          |
-----------------------------------------
|   2  |  Street 2 |         2          |
-----------------------------------------

building_materials

-----------------------------
|  id  |  building_material |
-----------------------------
|   1  |        Wood        |
-----------------------------
|   2  |       Stone        |
-----------------------------

Now. I would like to provide an API where you could send a request and ask for every property that has building material of wood. Like this:

myapi.com/properties?building_material=Wood

So I would like to query database like this (I want to return the string value of building_material not the numeric value):

SELECT p.id, p.address, bm.building_material 
FROM properties as p 
JOIN building_materials as bm ON (p.building_material = bm.id) 
WHERE building_material = "Wood"

But this will give me an error

Column 'building_material' in where clause is ambiguous

Also if I want to get property with id of 1.

SELECT p.id, p.address, bm.building_material 
FROM properties as p 
JOIN building_materials as bm ON (p.building_material = bm.id) 
WHERE id = 1

Column 'id' in where clause is ambiguous

I understand that the error means that I have same column name in two tables and I don't specify which id I want like p.id.

Problem is I don't know how many query parametes API user is going to send and I would like to avoid looping through them and changing id to p.id and building_material to bm.building_material . Also I don't want that user has to send request to the API like this

myapi.com/properties?bm.building_material=Wood

I've thought about changing the properties table building_material to fk_building_material and changing properties table id to property_id .

I just don't like the idea that on client side I would then have to refer property's building material as fk_building_material. Is this a valid method to solve this problem or what would be the correct way of designing these tables?

Answer 1

The query mentions two tables, so all the columns in both tables are "on the table" for use anywhere in the query.

In one table building_material is an "id" for linking to the other table; in the other table, it is a string. While this is possible, it is confusing to the reader. And to the parser. To resolve the confusion, you must qualify building_material with which one you want; that is done with a table alias (or table) in front (as you did in all other places).

There are two ids are all ambiguous. But this is the "convention" used by table designers. So, it is OK for an id in one table to be different than the id in the other table. ( p.id refers to one thing in one table; bm.id refers to another in another table.)

SELECT p.id, p.address, bm.building_material 
    FROM properties as p 
    JOIN building_materials as bm ON (p.building_material = bm.id)
    WHERE bm.building_material = "Wood"  -- Note "bm."