This just blew my mind. Due to the fact that editing a column name, format, etc on a view changes the base table, I thought that adding a column to a view added them to the base table. But it doesn’t- it adds them to the view only, making the view a first class table in it’s own right.
I’m still getting my head around what this means. At a minimum, it means that you can uses views as a way of splitting up a large table into a bunch of 1:1 linked tables- one master and a bunch of small views.
I totally missed this fundamental aspect of notion- it’s not mentioned in the docs, and I guess I’m just kinda stupid 
Two questions:
- Has anyone else missed this?
- If I wanted to refactor a table and move some columns into a view, but I already have a bunch of formulae and views etc using the existing column names, how would I go about this? I thought about creating a view showing the existing column I want to “move”, scripting copy the values across to a new view column using a button, deleting the old column and renaming the existing column. But this deletes the old column from everywhere I use it
Hey @John_Krani, not sure if I get you right, but have you checked if the added columns are just not “visible” on your original table?
If you add columns to views, the layout of the original table stays the same, but the columns should be there and “hidden”.
Best,
Daniel
I can see columns I add to views. But now that I understand that I can add columns to views, I want to “move” columns from my original table to views, as my base table is getting unwieldy. This seems to be hard.
Say I have table 1 with column A B C. I create view 2 of table 1, and create (in the view) column D that I actually want to be C in the end state. I can copy the data from C to D using copy paste, and then rename D to C. However every formula and view that referenced C is now broken.
Hi John,
I think perhaps you are misunderstanding how "View"s work. When you create a Table, all data is stored in and can be viewed from this base table. When you create a View, it is exactly the same data, just viewed in a different way. In fact, Tables and Views are essentially the same thing, storing the same data, and can be viewed in the same way, except for one small difference: you can remove Views as you like, but the Table should not be deleted. (There are other small differences, but that is in my opinion the most important)
With that in mind, this discussion around adding columns to a View over the Table is not helping your thought process. When you add a column to a View, it also adds it to the Table, and vice-versa. As @Daniel_Stieber pointed out, Coda “Hides” these new columns by default because it assumes you don’t want to clutter existing Views with new columns (and I agree with this design decision).
This is done via the button @Daniel_Stieber pointed out. Make the column visible in your View. If by “move” you mean “remove from the base table and only have visible in the View,” this is simply not possible. All data in a View is also in the Table, albeit perhaps hidden.
Lloyd
2 Likes
Awesome, so glad I posted this. What you’ve just said is what I thought at first- the table is the source of truth, views just are windows onto it. What confused me was that when I added a column to the view, it didn’t appear on the base table (as Daniel pointed out, I hadn’t turned on the new columns to view).
Thanks both for the quick response. I was about to go off on a tangent 
3 Likes
Sorry to open an old topic, and hey this is my first post!
I was just having this same issue and totally get the train of thought about why they will be hidden by coda.
However, is there a way to say to all ‘view of’ tables, that this “new” column is important and must be visible along side all other views?
