Primary Keys, Alternate Keys Clarification

[bluesyBlues]

Hi:

I am creating new “things” in Bubble but I don’t see a way to specify a primary key or enforce alternate keys in the DATA TYPES tab. And no way to specify an autoincrementing field. So that tells me I’m missing something fundamental to how bubble handles data.

Is there a resource of some kind that I can read to understand how bubble handles the database in terms of these types of keys and how I can enforce alternate keys and such?

Or is there someone who might be able to help explain or point to an existing forum post?

Thanks in advance for any help.

[mikeloc]

Hi there, @bluesyBlues… a longtime Bubbler named Nigel has written some great posts on this topic. Maybe this particular post could be helpful…

Understanding Relational Database Nature of Bubble

Fundamentally, this is the bit that makes Bubble (and others) a bit different to a traditional relational DB. You don’t need to do it. Yes, you can set up something that looks like a foreign key, but it makes it much much more complex. The way you “tie” A Project to many Timeslips, and a Timeslip to One Project is by embedding a particular thing in the database record. So the TimeSlip has a field of Type ProjectData, that gets set to a particular Project. Not the key or an Id, the whole thing…

… and check out his responses in this thread, too…

How to learn about database models and database structure

I feel that a lot of new users struggle with bubble, not just because there is a learning curve to the bubble platform itself, but because most are non-coders and do not have a background in database design. Personally, once I began to understand database design a bit more, it had profound impacts on how I was able to build using bubble, especially when it came to ease of manipulating data. I also feel, that a lot of new users forget about Google…that powerful search engine that can point you …

Hope this helps.

Best…
Mike

[bluesyBlues]

Hey Mike - thanks for those references. I guess the takeaway from reading those posts is to use list fields when possible. Too bad no one has been able to really articulate the performance tradeoffs between using list fields vs classical relational database techniques.

[cmarchan]

@bluesyBlues Hello!

Actually, as you suggest this is a critical performance topic. Complementing @mikeloc great suggestions, please review an insightful discussion in this forum with awesome contributions by many folks including frequent contributors @lottemint.md and @nocodeventure

Alternative approach to the Bubble’s recent tutorials for list of things

Hello everybody, I’ve taken a look at some tutorials from the following topic: In short, I think that these tutorials contain some crucial mistakes. Regarding How To Build A Pinterest Clone Without Code Configure your database User [image] We’re facing this mistake on many apps. That’s a wrong approach since it negatively affects performance and speed. Let me explain why I do think that this is wrong. The Bubble’s unique id for each thing looks like the next one: 1583401182457x36677842…

In short, strong arguments made for building light objects indirectly related as much as possible. Here, another great resource (paid) by @petter. One of the best resources on building for performance in Bubble that I have come across:

The Ultimate Guide to Bubble Performance - how to build fast, scalable...

Hope this contributes to your research!

[bluesyBlues]

Thanks for the additional resources!