Best practices with events and multiple databases

1

Hello everyone!

New to Coda and this whole way of working, even though I did a very little bit of this in Notion a few years back.

I am setting up a document for our small organization that hosts weddings and rental events. My 1st thought was to use one DB for all events, but weddings have different info required than for a music rental let’s say. And looking at other templates (like to-dos and others) it seems they break this stuff up into different tables/DB

Does this method make sense:

  • I created separate Tables for Weddings (named, DB:Weddings) and Events (DB:Events), both on the same page.
  • I created a table (DB:Room) for the 4 rooms we host these events in. (I am not sure why this should be this way, but looking at various examples, seems like it is most flexible to keep these things separate. Also, then I can add additional rooms if needed?)
  • I created a table for the Type (DB:Type) of event: Wedding, Rental, Internal. Again, not sure this is best, instead of just using these as select field in each table? But it seems to make sense all tables get this info from one place?

So, if that all makes sense - can I make a “master” calendar view that will draw from both Wedding and Events tables? So we can see all events coming up in one place?

Thank you for your help. Hoping to learn as I go, so I can ask “better” questions.

Cheers
Kayle

2

Hi Kayle,

Welcome to Coda and the community! Hope you will enjoy making in Coda.

First off, there are many different ways to do things in Coda, and as long as the doc you create works for you, that is ok.

I do frequently give this advice to new-comers: Do not expect to get your doc right the first time you start building. Play around, try it out, build some more, tar it down and rebuild. For me it was as if a light went up after about a year. I then no longer though in spreadsheet, programming or Access, but in Coda.

For thee kinds of docs, I start with the date driven/ calendar table first, and build it out from there.

Making this up as I go along:
Calendar table: Date, event id(for a specific function on a specific date), event type(lookup), room (lookup), maybe a canvas column for notes etc about the event and it’s planning
So then we need a table for events: Event type (Wedding, Event, Internal). (yes I would put it all in one table, saves me figuring out how to put it all in one calendar list.)
And a table for rooms, with details about the rooms.

Using the calendar, with a view sorted on date, you can see all events in date sequence.
Using the same table, with a view sorted/grouped/block on room, then date, you can see your room availability at a glance.

So very similar to what you have, except that I combined events and weddings in one table.

Going further, information about events and weddings that are applicable to all events and weddings respectively would be stored on the events table.

Any information that is applicable to a specific wedding, or a specific event, would be stored on the calendar table, which uniquely identifies a wedding(or event) by date.

Now the next question - do you not hold planning meetings with minutes and a todo list? So I would add another Event type called meeting, which you schedule on your calendar list. Including the resulting todo items.

What I have discussed above is mostly already included in this example doc:
(Change what is called project in the Todo List with your Events, and you’ll be really close, I think.

Anyway, it’s just a ramble… :wink:
Rambling Pete

2 Likes
3

Thanks @Piet_Strydom I appreciate your comments and I will check out your Doc. I am pretty amazed (and a bit overwhelmed) with what can be done in Coda.

Cheers
kc

1 Like
4

Ditto what @Piet_Strydom said what works for you is what’s best. His idea is a great way to approach it. If you haven’t looked at the Coda video tutorials done by Maria, those are a great place to get some ideas on database structures. You can always go the “one big table” route which some people prefer or you can “normalize” your data and break things down. The great thing about Coda is there is not just one way of doing things.

From an old database programmer’s perspective, I always look at similarities and differences. If things are similar, keep them in one table, different, make new tables. The difference between choosing to use a table to do a lookup or just create a select list, I typically decide if that item needs more stuff with it. If I just need a status of something I might make it just a select list. But if attached to a status I want some other information linked to that then I’d make it a table. Example: Status, usually might stand alone but if I had a room that room might have a room number as well as how many tables will fit into a room. So then the room would need to become it’s own table.

Although you can always make status a table, I typically will do this when I’m writing for someone else to use. That way if they want to add more status types in the future, they just have to go to the table and add them rather than edit the select list in the table. So consider your end user and it might be that adding tables for every select makes the best sense even if it seems silly to have such tiny tables.

And WELCOME to Coda! I’ve found this not just to be the best product I’ve used in a long time, but they have the best support team and the Coda Community is very active in helping users figure things out.

1 Like
5

Thank you Susan. That is very helpful. Still working my way through it, but I think I will error on the side of more tables/more flexibility. Hopefully, it will make sense as I go along.

Cheers
kc

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.