Hello!
My question is in regards to Doc design. I’m finding that over time my docs become larger, more complex with a lot of column formula’s and connections between tables. I’m wondering if it would be a good idea to create a “Front end” and “Back end” doc for each project.
The back end would be where all the formula columns/calculations/syncing would go, and then I’d just cross doc the necessary data to the front end doc where users would do their work. Does this work how I think it works? Or is it better to keep everything in one doc, even if it’s very slow.
Hi Samuel,
Is your doc getting slow, or are you concerned that it might get slow in the future?
Either way, I would recommend that if performance becomes a problem, you rather try and address that first.
If performance still is a problem, I would look at embedding functionality, rather than cross-doc functionality. Cross-doc functionality is not that friendly to work with. (My understanding is that cross-doc was an interim solution, while Coda works on the more comprehensive embedding functionality.)
The embedding functionality is being delivered in 4 phases, two of which has been implemented, the 3rd is in progress. As it is currently implemented, embedding will allow you to create a “simple” view of some pages in the main doc, it is NOT going to prevent access to the main doc. That will come in later phases.
Regards
Piet
They are slow, yeah. Do you know the best way to address the performance issues?
Hello @Piet_Strydom ,
Have you experienced improvements in speed by embedding pages? As far as I understand, embedded pages still load the complete doc and maintain all the functionality of the source doc. So working with the data on the embedded page is going to be just as slow.
I have given it a try (but it has been a while ago) and found it to only have disadvantages as opposed to working in the source doc.
The only advantage at this point is being able to give your users access to multiple documents from one place, with the disadvantage that your users might end up in one of the source docs and don’t understand how or where they ended up.
Greetings, Joost
Hello @Samuel_Langford ,
I have had similar problems and I ended up changing my formulas to keep my doc useable. There often is a lot op optimization possible.
First you need to find out where the problems (slow calculations) are, then you can start to optimize.
In order to check your document, go to the document settings (the little gear top right in your document), go to Doc Map, click on the kebap menu and click on debug calculations. Use the start button and keep an eye of what is going on in your document. For me, it was an eyeopener and I still use it regularly if I want to check the best approach for some actions in my doc.
Good luck,
Greetings, Joost
1 Like
I have not done any testing around this - What I have for my users is a view of a table with a fraction of the rows. This view I then embedded in a separate doc. I have found that filtered views are quicker, which admittedly is not the same as saying that embedded portions will be quicker.
In my case I have a fairly large, “personal corporate” Wiki. Two of the pieces of info that I want to share with end-users is “How-to” and “Error fix” records. So they have one doc with two pages, rather than (by default) nearly 200 pages. I can afford to wait for “Phase 4”.
P