While I like the concept…it’s extremely frustrating how little valuable documentation is on how this thing really works.
We live in a relational world - I (me, a person) am not the car I buy, the store I shop at, or the banking account I have, on and on and on and on.
SooOOOooo… how do I set up relationships in this [so called] database behind the scenes.
If I have a transaction table for a financial transaction, and I want to know
Who the user is that paid the transaction (from - a user id)
What is the users account the money is coming from (an account id)
Who the company (not a person, a company or organization) he pays the money to (to - an company id)
What the product/service the money is for (a product id)
I want FIVE relationships from the transaction to DIFFERENT entities or objects.
How do I set it up in the database?
How do I display that on the screen - so that it shows the involved parties and products?
I mean, the 3 minute tutorials are cute…but building a REAL APPLICATION with a REAL relational database takes more and BETTER tutorials than what I see.
The tutorials on dropdowns are NON-EXISTANT
And is this it, release confusing software and rely on forum for help?
H E L P!!!
Show me how to make a REAL application in a database with relationshipos, why and why not to do certain things, and how connect the data to the UI.
I don’t agree. What you are discussing here is actually covered in the tutorials and through some forum searching. Take a dive and start building something simple. Things should come together pretty quickly.
HellooOOOOOooo… I’ve build TONS of applications, in a number of languages. The tutorials on the home page of the software do not cover setting up relationships between entities and objects, and how to interact with that data on the UI. Go here, type this here, click this here…doesn’t show you what’s happening in the database at all.
Funny you can’t send me a link to a video?
Who really wants to search through THOUSANDS of forums posts to learn something? Honestly, who?
Who wants to bang their head against the wall and have to post a question on a forum every hour to (supposedly) use a product?
I want tutorials that use standard language like Parent-Child relationships or Many-to-Many relationships and show how interact with data in relationship both to VIEW and EDIT. Calling something a “thing” or a “type” gets you in trouble when you have to use those words.
I certainly appreciate the attempt to make things easy and not have to write code, but everyday business applications live and exist on relationships in data, and it’s not clear how to manage those relationships and how to interact with those data relationships through the UI.
Look at the shopping list tutorial. They NEVER showed the DB, but here it is. So they are placing foreign keys from a child table into the parent table. REALLY?
If you’re interested, I’d love to teach you Bubble’s core database concepts so that you can move forward. I teach Bubble every day, so I promise the hour we spend together will be worth it. I hate to see such frustration hold you back from building awesome things on Bubble - and not just cute things- but real powerful apps.
Check out coachingbubble.com if you’re interested. I have a ton of free resources on there too.
I think you have hit the nail on the head with this, as Bubble does not refer to “many-to-many” because that is coding “language”.
it can be difficult to get your head round Bubble’s database concepts if you are used to “SQL” style databases ( which are not as common as they once were, plenty of noSQL, Columnar and the like are widely used now) and how relationships work.
Essentially Bubble is an “simplified Object Relational” database, and is built on top of Postgres (itself an ORDMS but more complex). Although it was like that when Bubble was on Elastic.
So what you are seeing in your example above is not, in fact, a list of Foreign Keys, but a list of Object identifiers. In the absence of you telling Bubble any different, it identifies the objects in the list by id. But you can change that in “Primary Fields” so it will be more human readable. So email address, or part name.
I have done an SQL to Bubble comparison here…
But an hour with Gabby would be well worth it, and will cut through some of the language and concepts.