Hi, I have been trying to clean up the database that we have for our organizational flow. Initially, different forms for different kinds of people specifications all lead to the population of one People DB. However, this has resulted in many columns in the People DB that do not apply to everyone.
As a result, I want to restructure to:
People DB that has all the contact information
3 separate DBs that all have their own specific columns for their type of person
The Name column in each separate DB connects to a row in People DB that has all the contact information.
The goal of this normalize the databases, removing unnecessary columns. We are trying to use the Primary Key and Foreign Key logic to apply here.
My Questions:
Is this possible on Coda while retaining normalization?
Hide vs Delete. From a functional perspective, what is the difference between Hide and Delete? Our motivation for making separate tables has stemmed from a goal of normalization, as well as better overall organization of our DBs. Would Hiding be able to serve the same goal? I am really trying to avoid this.
I wouldn’t suggest this approach. While it might seem redundant that not all columns are used by each person type, the “View” concept in Coda makes it not-an-issue.
I would typically set this up as:
People DB table which is on a hidden page, or not obvious
People page with a People view of the People DB table tailored for that person type (irrelevant columns hidden, etc)
Volunteer page with a People view of the People DB table tailored for that person type (irrelevant columns hidden, etc)
etc
You can also create different detail views, or forms for the table which is relevant for each of the person types.
Separating out into different tables and then trying to join them on things like name (or even email which would be better) is not ideal and becomes difficult to manage and run reports on in the future.
Data normalisation is not important in the new cloud database environments.
As an example, SAP has moved their ERP to a cloud database called HANA. In the process they replaced eleven tables with financial data with a single table.
The final reason I was hoping to separate the tables was because of some cross doc issues errors I am running into (forms crashing, “failed to get cross-docs metadata”). I had hypothesized that the larger tables with columns that didn’t apply to most rows might be a contributing factor, hence was hoping the separate tables would help.
Do you think there might be a connection or is the cross doc error completely unrelated? From what you have said so far, I assume they are disconnected since the current way we have organized our databases is similar to what you suggested, Daragh. Would appreciate some final clarification/any hypotheses for what might be leading to cross doc errors, if not this!
Hi @Kavya_Doraswamy, it’s harder to diagnose potential issues there, as cross doc problems would require a better understanding of the specific issues and context of how the docs are setup.
There’s no guarantee that splitting out the docs would solve the problem, so it seems a lot of work to prove a hypothesis right or not.
