I’m trying to understand why I wouldn’t use Row ID for all unique identifiers
The answer is probably nuanced, but hearing people’s personal examples/use cases will help me understand pros/cons of using Row ID as unique identifiers.
The benefit I see of Row ID is they are …
easier to implement
more secure (or reliable) since it can’t be modified
I use (and would advise) using RowID for probably 95% of use cases.
The only time I’ll use a Unique Identifier is in a situation where a RowID can’t be used, or isn’t appropriate.
An example of this is when I’m creating a parent record and want to create one or more multiple related child records at the same time. In this situation, the ParentID (RowID) won’t be available to use with the child records, so I’ll use a Unique Identifier instead.
I ran into an issue using user rowID instead of emails when applying row owners. I have a few tables that are interconnected: installations, inventory, removals, add ons.
I used user rowid in the “roles” section to be able to connect these tables but this means every user is considered private and I’m limited to 100 or so users.
But the problem with using emails is that users can’t change their emails, as it will disconnect any data that uses their previous email (those email fields in other tables are static)
“Roles” are really just a way to group users into an ownership group. Using RowID as the data source for roles guarantees that you will create groups of one, exactly like using an email address. So you might as well apply row ownership to the email column rather than roles to the RowID column.
It’s clear what you are trying to do: associate the app account to a UserID instead of the user’s email address so your users can change their email address and still have access to their account. As far as I know, this is not possible: for now, access to an app is tied to a unique email address and cannot be tied to another piece of data such as a UserID, phone number or other email address.