How would I move a structure like this over to sup...
# help
s
How would I move a structure like this over to supabase?
n
Hello @Sasial! This thread has been automatically created from your message in #843999948717555735 a ``few seconds ago``. Pinging @User so that they see this as well! Want to unsubscribe from this thread? Right-click the thread in Discord (or use the ... menu) and select Leave Thread to unsubscribe from future updates. Want to change the title? Use the
/title
command! We have solved your problem? Click the button below to archive it.
g
It looks like will probably have at least a categories table, a questions table possible with foreign key to category, and a currentTickets table. But other than that, not really enough info to understand your relationships, what guild, channel and messages are, why some tickets have guild and others have message, where 0's are does that mean there will be more than 1 (assumed), etc.
n
Sasial (2022-04-30)
s
so i can't have nested structures, I have to use more tables?
this is FB's stupid UI, 0's are the first item in an array
so yes
message is a temp field, which'll change to guild
g
You can do json columns as deep as you want or array columns of json objects, but it gets harder to search and maintain. Relational data bases are designed for lots of smaller tables all interconnected by keys, references or just how you set up you queries.
s
are there any docs for migrating from firestore?
g
I've not seen any, but I'm sure you could google. Remember you are not just looking for firestore to supabase, but to Postgres which should get more hits. I like this reference in PostgREST (which Supabase uses for its API) as it relates fairly clearly ways you can relate tables. You are not at the point though you need to really worry about relations between tables versus how to breakdown your structure into tables. Normally you look at structures that are common, like messages, users, tickets, categories, etc.
I moved from firebase, mainly because I was spending all my time fighting query cost and organizing data to minimize that, versus just organize the data so it makes sense then just worry about minimizing how much you download, versus how many calls you make to do it.
s
Yeah for sure!
JSON colums wouldn't be typed though, right?
g
technical for json and jsonb in postgres https://www.postgresql.org/docs/current/datatype-json.html
If by typed you mean numeric/boolean/string then yes that is supported
s
ohhh, okay
g
I'm not suggesting you use json columns for what you have, just saying if you need very flexible data formats json is supported reasonable well. That is usually the big issue if someone took full advantage of a no sql database without any fixed structure on their objects. I have a note taking app where each note type can have different information and some of the information may or may not be filled in so use a json column for that. I then pull out a few key items into separate columns for searching faster and displaying in lists. But I can also do a full search on the json, just slower.