New to this sweet bubble thing and trying to get my head around the database structure and how the different levels talk to each other. I could use a sanity check on my understanding so far.
Mocked up a quick example to illustrate.
I have a number of different account types. Each account type have, let’s say 6 different account names and amounts. The user can input name and amount and save it to the database.
The next time they log in, the input fields will show the users name and amount. If I understand it correctly, anything tied to a specific user must be mirrored in the User data type as a field?
Does this look like a reasonable database structure for such a scenario?
Each time the user updates a name or amount it gets saved and the latest entry
in the database is shown as initial content in the text input form.
I tried to make the account name and amount a list, but a) I can’t tell which amount belongs to which account then. b) I need to be able to update a specific entry, which I don’t think is possible in a list? So my conclusion was, each account name and amount needs to be stored as a field under the
data type? and the Asset datatype in itself then needs to be stored as a field under the User data type?
As a side note, calling something “a thing” doesn’t make for very intelligible learning material.
“a thing is a thing within a thing that is a thing” haha. The user manual could also benefit from
some proofreading, the grammatical errors and spelling mistake makes it extremely difficult to read and understand in some parts.
No, I don’t think that is going to be a viable way to structure the data.
The concept you need to understand is that of a list of another datatype (instead of text, number etc).
As an example, An AUTHOR writes many BOOKs.
So we have a BOOK datatype (with name, publisher etc).
And we have an AUTHOR datatype, which has a field which is a LIST of BOOKS. That is what keeps all the related information about a particular book in the same place (rather than book title 1, book title 2, Publisher 1, Publisher 2 like you have).
So you would have a new datatype called ACCOUNT.
The ACCOUNT has fields - name and amount and type.
The USER then has a list of ACCOUNTs. So when you “Save” your ACCOUNT you also add that account to USER’s list of Accounts.
This also means you have no limit (unless you want to) on the number of accounts.
The UI will be a little different, so instead of a list of 6 blank accounts you would have 1, and then “save” would save and create another blank one.
You get used to it, it really just means row or object or entry … but is trying to be non-technical. And also to stop technical people thinking that if it was a row then there would be a table. Which there probably isn’t. If that makes sense !
I had that structure initially, and it worked great for the type of UI you’re
describing. e.g. a to do list where you’re just creating a list of entries.
What I was trying to achieve here is not entirely the same, I think at least.
It might be that the database will be the same, and where I get confused is
on the display of data/front end side of things.
I need each account to be displayed and be editable separately, like an in-line editing function, if that makes sense? And I can’t figure out how to do that with a list of accounts.
When the user writes a name in the account name input, I need that name to stay
there. for example by using auto-binding, so that entry can be updated.
Would there be a way of displaying each “name”-field from the database in each account name input form, if they are not individual data types?
It seems that you only have access to a field, and not a particular entry
in that field? which does make sense but doesn’t help me.
So you would have a repeating group of account, using the list of accounts on the user.
And then each one would pull the input field from the item in the list and display it as initial content. Auto-binding would allow it save as soon as they edit.
