Double-checking database structure - object vs relation

NicelyPutEllie

I've been looking through the forum and I think I've understood what I should do from other posts, but before I start trying to build this, could someone check my logic?

I've started trying to map out the data structure I need for my Webflow/Wized/Xano based client app in this FigmaJam file.

When I started mapping it out, I thought that maybe fewer tables and more objects would be better. But I think the general gist from the forum answers here is that more tables and more references would be advantageous?

I've watched the early videos on Idea to App and the database, but while I broadly understand what an array, object and relation is, I don't really get the ramifications of certain choices when building the structure.

Happy to be pointed towards other learning resources if that's easier!

Ray Deck

A lot of data structure concerns can be handled in multiple ways. The choice is between a more complex document, and a composed set of simpler tables that relate to each other. The complexity of the latter comes in the connections, rather than the individual fields in the table.

When to use each is a balancing act. I try to think in terms of primary and subordinate entities.

For an example of primary entities, consider people vs books. A person might have read a bunch of books, but rather than keeping a list of book objects on the person, I would keep a table of books, and a table of people. Then the question of managing who read what book could be a list of person references in the book table (who read this book?) a list of book references in the person table (what has this person read?) or a relational table containing one record per book per person who read it (answering both questions equally). Which path to take depends on the nature of the application, and the questions that are likely to be asked.

For subordinate entities, consider chapters for books, or limbs for people. Books can have multiple chapters, but we are very unlikely to search for chapters - we search for books, and discover their chapters. That means its probably fine to have chapters as a list or object field in the book table.

Finally, these choices are reversible, and your first priority should be a data structure that makes sense to you. The wonderful thing about nocode is that it lets you protype quickly and find out where you are wrong. And we are always wrong somewhere. Making progress lets us discover that more quickly so we can move on to our version 2.

These questions elevate from being "about the tool" and to a mental model for thinking about your data and making progress. They are part of the 5% we focus on at State Change in the daily office hours and loom-based discussions we hold to help everyone make progress.

NicelyPutEllie

Thank you. That's really helpful on two levels.

Firstly, the book analogy is really useful, and I think that clears up a lot of my questions!

Secondly, it's helpful to consider a different way of thinking about it. I've got ADHD and my thinking was "try to get everything nailed before you implement, so it's not a hot mess". But if the reality is that there will always be trial and error, I just have to adjust my expectations.

State Change looks really interesting. What are the times/timezones of the office hours?

Ray Deck

This week office hours are/will be 1200 GMT, 1700 GMT, and 2300GMT.

Also available to our members are transcribed recordings the 180+ office hours and broken-out topical segments from them help people find info and make progress a lot faster.

We are also very loom-centric on our help forum - this lets people get out their questions in less time and dig deeper into the issues before we get to office hours. A significant majority of the time we crack the issue in the forum with looms so that the office hours are just the hardest 20% of the hardest 5%.