Question

After reading around, I’ve realized that SQL (MySQL in my case) does not support column exclusion.

SELECT *, NOT excluded_column FROM table; /* shame it doesn't work */

Anyways, while I’ve come to accept that, I’m wondering if there’s any decent workarounds to achieve this sort of behavior. Reason being, I’m creating a view to consolidate information across a few tables.

I’ve normalized some user data to tables user and user_profile among others; purpose being that user stores data critical to user operations, and user_profile stores non-critical data. Application requirements are still being realized, so columns are being added/removed from user_profile as necessary, and further tables may be supported down the line which would be included in the view.

Problem is, when I create the view, I get Error 1060: Duplicate Column Name because user_id is present in both tables.

Now, the solution I’ve come up with so far, is basically:

/* exclude user_id from user */
SELECT user.critical_field, user.other_critical_field,
       user_profile.*
FROM user
LEFT JOIN user_profile
ON user.user_id = user_profile.user_id;

Since the user table is going to remain unchanged throughout the application lifecycle (hopefully) this could suffice, but I was just curious if a more dynamic approach exists.

(Table names were not copypasta’d, I know user is often a poor choice of naming convention on it’s own, I use prefixes.)

Answer 1

Typically, I’ll define which fields I want to be in my view

Using your example:

SELECT user.critical_field, user.other_critical_field,
       user_profile.User_Id, user_profile.MyOtherOfield
FROM user
LEFT JOIN user_profile
ON user.user_id = user_profile.user_id;

Now, additionally, I’ll make sure that I alias things properly:

SELECT u.critical_field, u.other_critical_field,
           up.User_Id, up.MyOtherOfield, u.KeyField AS userKey, up.KeyField as ProfileKey
    FROM user as u
    LEFT JOIN user_profile as up
    ON u.user_id = up.user_id;

This allows me to ensure I know what’s in my view, and that the columns are named intelligently, but it does mean that I’ll need to touch that view when I make changes to the underlying table structures.