It is my understanding that to fetch a thing by a unique id requires:
- do a search for [thing type]
- with a constraint of [unique id = ‘…’]
- get a first item of a [resulting list of “things” …of one]
Coming from a relational db world, I don’t know if bubble uses this structure to fetch a thing directly from an index of unique id.
Say, I defined a regular bubble type property local id which I made sure contained some unique id. Then, if I used the above method to fetch the thing by local id, would the performance of “fetch by local id” be the same as "fetch by unique id?
Need this for the data base of 500K+ of things.
Unique ID is an in-built attribute of a given entity. Everytime you “create a thing”, a unique ID is generated in a unique ID built in bubble field. You do not need to create another UID field.
You can definitely do a search constraint using that built in UID as discriminant.
In terms of query performance, searching by the built in ID versus a custom UID field should not present a performance delta.
However, as far as my understanding goes of your use case, creating a custom UID would be redundant and therefore an extra datapoint that generally speaking would negatively impact performance while serving a purpose already solutionned by another field(the built in UID).
2 Likes
Synthia, thank you kindly for your advice. The key takeaway for me is “searching by the built in ID versus a custom UID field should not present a performance delta”.
In our case, at least one more unique id is required due to use of “thing” data by other,/external entities and a need to protect privacy, integrity, etc. Business use case.
Absolutely. If indeed you have a need for another UID obviously that last paragraph does not apply. Everything else held constant neither query is more performant than the other. Good luck with your app 
