Primary keys / foreign keys don’t exist in Bubble really. Well, behind the scenes they obviously do, but Bubble treats it differently (and I think they do it quite well).
You rarely need to use ‘ids’ in Bubble. The primary key of a Thing is it’s unique ID. But you don’t save that unique ID to a different thing to connect it, you just save the actual Thing. Yes, it sounds weird if you’re familiar with other DB structures.
Let’s suppose you have data as follows:
Product
Variant
On the Product data type, you’d have a field called Variant. The ‘type’ of this field should be Variant. So this essentially says, hey, this field contains a specific variant. On the Bubble side, that’s essentially storing the unique ID of the specific variant.
To reference that data, you’d just use Product’s Variant’s name/description/whatever field you want etc.
Also I’ll just throw in my preferred naming convention because bad naming can confuse people and I’ve seen a few examples these last few days…
-
Data types should be singular and capitalised (Post, Entry, Order rather than posts, Entries, or All Orders for example)
-
Where a field references another data type or option set (e.g Variant has a field of type Product), name that field the name of the type exactly. So in this case the name should be Product and type also Product. This helps you easily identify what a field refers to and the type of that field.
-
In relation to the above, don’t save foreign types as fields like ‘ProductID’. ‘ProductID’ just implies it’s a string (a text field) when actually it’s a Product.
-
Where a field is basic data (i.e text, yes/no, number etc where it doesn’t reference a type/option), name it lowercase with extra words capitalised. e.g dateOfBirth, or fullName. This helps you know that a certain field is just a basic field rather than referencing other data in the DB.
Other people will have slightly different methods but you get the gist 