Hi excellent TB community,
Building out our tables now. Per parent/child relationships, the logic makes sense to me that (for example)
(child) SALES>INCOME>FINANCE (parent)
and
(child) BILLS>EXPENSES>FINANCE (parent)
…but does this risk making FINANCE a behemoth that staggers under its own weight, or does it just make appropriate relationships that help all the programming feel intuitive?
Thanks all, sorry if this question is too general.
—Sean
Hi Sean,
You’re on the right track with your approach to structuring tables based on parent/child relationships. This method is indeed recommended as it helps in creating intuitive relationships that simplify the logic and programming of your database.
The concern about the FINANCE table becoming too large and unwieldy is understandable. However, the impact on performance or manageability usually comes more from how calculated fields within each table are used, rather than the sheer volume of nested child and grandchild records.
Keep in mind with this structure you can dynamically display any data from a parent when viewing a child. For example, when looking a Bills you can dynamically load any data about its parent Expense.
I hope this answers your question, don’t hesitate to reach out if you have more questions!
Love it.
Thank you, Mr. Moe!
Hi again Mr. M,
Circumstance: I’m importing data from our existing database to Tadabase and reorganizing the tables for greater flexibility and functionality.
Problem: if I move the items from, say, Invoices to a new, higher-level table, Income, then I won’t be able to import the data right across from the old DB when we finally move over because the tables would all be different.
Is there a solution for this in Import Templates somehow?
And if not, I’m open to comments and suggestions.
Cheers all!
—S
I think I understand what you’re saying, correct me if I’m wrong.
In Tadabase, you’ll have a different schema than your existing database? For example, in your existing database - you might have 3 tables to manage financial data but in Tadabase you might have 4 or 5?
Yes sir, precisely so. Our existing DB was never plotted properly, and I’d love to fix that, but if I want to move our data from there to here, I don’t know how to prepare for that.
A rounder view of the circumstance:
I have full tables for AR INVOICES and AP BILLS with completely different fields in each.
I want to move them to Tada under a parent, FINANCES, which I believe would necessitate putting all those fields in that single table, FINANCES, and then splitting up that data into INVOICES and BILLS.
Fine, but once I do that, how do I move the data from our old DB into our new TB?
Alternately, can I move all the data over as-is, THEN reorganize it somehow for more intuitive programming, functionality, and such?
I don’t really expect a voila! solution to this, but looking for advice, comments, thoughts, whether this is really a problem or what.
Cheers!
