I am building a mvp for an application and I was wondering how quick can a poor database design be fixed when using bubble? It might not be necessary to try to have the best suited db from start if it can easily be updated. In my case I have two table users and seekers (type of user) with a 1-1 relationship. To get the user information from a seeker, I will rely on the creator field. So I have no reference to the seekers in my users table. I want to get the seekers who have skills is in X and city = A where skill is a seeker’s attribute whereas city is a user’s attribute. I split in these tables as i feel its better regarding the duplication on other types of users, privacy etc. I think that one simple way could be to simply put all fields that are used to look for seekers in the seekers table. I could then perform a search for seekers and add the necessary constraints on seekers attributes.
what do you advice?
Some of my experience…
- you can be really flexible with the database, quickly refine the design during development … until you have live data in the system and have a schema migration problem
- I find more and more often using “flat” table designs works better with Bubble limitations around how you can query the data, and with how plugins work (usually unable to access the attributes of linked things). “Normalisation” (non duplication) of the DB design is often unhelpful.
- Privacy rules - you can’t have a rule of a “things thing” - eg role.company.type - so again normalisation isn’t helpful
- You probably won’t get it right first time …
… so the quicker you can prototype the app and test the DB design the better.
Good luck!
About Me
I’m a Bubble Freelancer. I like Bubble coaching and making plugins for tricky API’s.
My Bubble plugins Pleased to say all 5* reviews.
1 to 1 coaching with nocodeguides.io DM me for a free voucher code if you want a quick chat.
My Youtube Channel Mostly about my plugins.
My Freelancing Website
Thks Lindsay. Regarding the second point, this is where I am curious. Building the queries in bubble will be faster, more intuitive for US using “flat” tables but in terms of performance, will it really be better for BUBBLE? I mean, if we don’t really know how bubble make these queries run under the hood, we do not really know what is the best structure and type of queries to provide the tool with don’t you think?
[In my experience] Sometimes that “flat” table design is the only feasible way to query and use the Bubble database. You can’t (without very messy subqueries) do the typical SQL approach of x.y.z property. So your traditional normalised relational database design simply doesn’t work.
Around performance under the hood - everything I know I learnt from this The Ultimate Guide to Bubble Performance - the new edition is out (now 210 pages!)
FWIW what I’ve found is however Bubble does it’s indexing - it seems to work. (probably because you cant access 2nd order properties like x.y.z I guess) so if you table has 10 rows or 20k (thats the biggest table I’ve dealt with) performance seems unaffected.
I’d be interested to hear anyone else’s experience. Beyond 20K + rows I suspect I will be looking to (optionally) use an external database like Firebase - search for @jared.gibb if you want to know about using external databases.
In my experience you can fix most/many things via Bubble’s ability to run recursive workflows to modify or create entries in bulk. How easy or hard that is depends on the specifics of what you’re fixing.
100% read the book @lindsay_knowcode references. It explains what’s happening behind the scenes with Bubble, which then will help you clarify the right approach.
And if this is your first time building on Bubble, expect that you’ll do some things that you’ll want to go back and re-do.
With my app (heavily data driven) I was able to get it mostly right first go around. The one (and only) thing I’m still trying to optimize is a “list to list” search in a many-to-many relationship (Filter list from a list - #2 by ed727).