Timeline for SQL query for finding a set of columns that create a unique key for a table
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 31, 2016 at 5:49 | comment | added | Andrew Wolfe | I'd probably start with comparing row count against count of distinct rows, just to see if there are dupes. If so, you may already be out of luck. | |
| Jul 30, 2016 at 12:27 | comment | added | Lennart - Slava Ukraini | @Juan Carlos Coto, while I agree that the domain should be analysed (as noted first in my answer), I also assume that the whole purpose is to add a unique constraint. Any row that violates this constraint will be rejected. | |
| Jul 30, 2016 at 11:33 | comment | added | Juan Carlos Coto | While this might work it doesn't (and can't) take future records into consideration. Even if you do find a unique combination of columns now, how can you tell if it will apply later? That's why I would (very strongly) suggest you look at the way the data should be identified in the problem domain, first. Figure out the data model based on the reality of the problem, don't try to shoehorn it the other way around. | |
| Jul 30, 2016 at 7:03 | history | edited | Lennart - Slava Ukraini | CC BY-SA 3.0 |
deleted 8 characters in body
|
| Jul 29, 2016 at 18:29 | comment | added | Lennart - Slava Ukraini | Yes, the number of combinations grows exponentially, so it is beneficial if you can remove as many columns as possible from the set of suspects. | |
| Jul 29, 2016 at 18:25 | comment | added | YonkeyDonk64 | The group by is definitely what I was looking for, thanks. The good news is that I have a hunch on which columns look unique, so I will start my search there. | |
| Jul 29, 2016 at 18:24 | vote | accept | YonkeyDonk64 | ||
| Jul 29, 2016 at 16:56 | history | answered | Lennart - Slava Ukraini | CC BY-SA 3.0 |