Why does NINOX recommend entering data from a form?
Hi everybody. Really struggling, trying to understand views, tables vs forms, relationships, parent-child, etc. So on a Friday afternoon where the stock market has been very kind to me (well... the U.S. markets at least), I decide to go back to the absolute basics. Watching the Ninox videos. Re-reading the documentation and I come across this little gem: "We recommend that you enter your data in a form".
Why??? What is the alternative: entering data directly in a table? Is this just "philosophy" or is there a technically valid reason for this statement? What are the perils of not following this recommendation?
Thanks for your comments!
5 replies
-
It was only till v3.8 that you could enter data in other ways beside a form. So yes, you can double click on a space in a column in a table view and you can enter data.
Why they would recommend form view when they support both is beyond me. Makes it sound like they don't completely trust inline editing.
said:
Really struggling, trying to understand views, tables vs forms, relationships, parent-child, etc.Do you still need help with this?
-
said:
Do you still need help with this?Oh Yes! Thanks for asking.
[Some context: so far I've only used Ninox in "flat files" applications, to keep a list of passwords, for instance, etc. I look at Ninox on average once a year (Ha ha) and rapidly forget what I know. I'm in the process of re-reading the "manual" and watching the tutorial videos. Which help to a limited extent...]
I'm just trying to create a fairly simple (I think) database to record stock market transactions. And I'm having trouble with two "concepts":
- How to model the tables in the database
- How to organize the "data entry"
As far as organizing the tables, my thinking is this: First, there are brokers (a parent); at each broker I have one or several accounts (children of a broker); each account has several positions (children of an account); each position consists of one (if the position has been opened but not yet closed) or several transactions, buys or sells (children of a position).
On that basis, this is how Ninox presents the model (Model A):
BUT. Do I really have to model the data this way?
What I am primarily interested in is the positions. Were they profitable or not? By how much? How long between opening and closing the position? What were the total Profit or Loss (P&L) for December? For January? Etc, etc.
Of course, each position inhabits an account (which is held at a broker's). But I view that aspect as a necessary evil. I would not necessarily be interested in statistics about the accounts nor the brokers: I already get that information from the brokers themselves in a way that satisfies me. No: the positions is where the action is.
So, on the basis of that thinking, would it be OK to separate the Brokers/Accounts tables from the Positions/Transactions tables? Like so (Model B):
So... What do you think? (We can talk about "data entry" later...)
And thanks for your help!
-
said:
BUT. Do I really have to model the data this way?You can model DBs any way you want. Model A makes the most sense, to me, even if you don't care about what is happening at the Broker level. You may not need the structure now, but it will come in handy when you do need it, don't ask how I know. Model A allows all the data to flow up and down the chain quickly and logically.
I think where you might be getting caught is data entry. You said that your previous experience using Ninox is as a flat file, i.e. spreadsheet style. So now is the time to spend a few moments to think different. May I recommend that you look at dashboards then imagine them as your way of entering data instead of entering data in the Position table directly, or at least you can access the Position table through the dashboard with view elements.
Try to create a dashboard/Page that you can select a broker then account. Which will then update a view element that shows you all the related position records.
Then you can add fields and a button to the dashboard that you can use to add new position records.
You can look at this post where I talk about the changes to how I enter data to my DB. I'm not saying you should do it this way. It just shows you how to think different.
-
Not to throw too much at you, but when you get the a chance you should see if your brokers allow API calls so you can access your brokerage data in Ninox (if you have a public cloud account). This could save a lot of data entry time if you are doing lots of transactions.
Content aside
- 10 mths agoLast active
- 5Replies
- 109Views
-
2
Following