This is our upcoming events page. There is a section at the bottom called "Events for August 8, 2020". This page is static for now. We want to make it dynamic. We want the user to be able to click on a date in the calendars to the left and re-populate this section with events for that date.
We will have an events coordinator who will be uploading events to our backend which this page will pull from.
The question I have to answer is: what would be a better approach? When the events coordinate creates a new event, do we created it as a new content item of the document type "Event" which is a child of the Upcoming Events content item, or do we not use Umbraco and simply save all the event data in a separate database table?
Though we could make the first approach work, I don't think this is how content items were meant to be used (correct me if I'm wrong). Content items, from what I understand, are meant to represent pages, not data records. There could be literally hundreds of events being maintained, and I can't guarantee the events coordinator will remember to delete them once the date is passed (I'm not even sure we WANT to delete them), which means the list will just grow bigger as time passes.
So what is recommended here. Save events in a separate database table or make use of content items?
Content nodes don't have to be pages as well - if no template is assigned to the document type then they can just be handy containers of content data used on other pages (usually the parent but not always). Most Umbraco websites have some amount of them. A lot of child data can be put in the new blocks or nested content but having them as separate content nodes can still be a good model and is probably the right one here.
My general rule is if it feels like content then it should probably be in the CMS if it feels more like data and changes frequently based on something the visitor can do then use DB tables / something else.
An example where you wouldn't use content nodes, and instead use a separate data table, would be if you were trying to keep ticket stock - here you wouldn't want to publish an umbraco node each time to update a number of tickets left (too many publishes, too slow and risks a race condition). This would definitely be better handled in a DB table but you might still keep the event info in a content node.
I think I'll do a combination of both. I'll go with content items for upcoming events, but a separate database table for past events. The thing is, we'll most likely want to keep a history of events, so we don't necessarily want to delete them once the date is passed. I think I'll setup a cron job to run once a day which takes all of the previous day's events and transfers them to the history table, effectively deleting the content items for that day.
And just to answer your questions:
Quantity of events: like I said, hundreds just to start and possibly growing from there (depending on if we want to keep a history).
How frequently they change: usually won't change (except if mistakes are made, or the events themselves change), but events will be added probably on a daily basis.
Where you expect the editors to be able to administer it from: this depends on if we go with content items or something else. If content items, the editor will use the Umbraco backoffice itself, otherwise we'll create a UI on our platform.
Are content items good substitutes for data records?
Please have a look at our website:
http://hollandandbarnes.azurewebsites.net/upcoming-events/upcoming-events/
This is our upcoming events page. There is a section at the bottom called "Events for August 8, 2020". This page is static for now. We want to make it dynamic. We want the user to be able to click on a date in the calendars to the left and re-populate this section with events for that date.
We will have an events coordinator who will be uploading events to our backend which this page will pull from.
The question I have to answer is: what would be a better approach? When the events coordinate creates a new event, do we created it as a new content item of the document type "Event" which is a child of the Upcoming Events content item, or do we not use Umbraco and simply save all the event data in a separate database table?
Though we could make the first approach work, I don't think this is how content items were meant to be used (correct me if I'm wrong). Content items, from what I understand, are meant to represent pages, not data records. There could be literally hundreds of events being maintained, and I can't guarantee the events coordinator will remember to delete them once the date is passed (I'm not even sure we WANT to delete them), which means the list will just grow bigger as time passes.
So what is recommended here. Save events in a separate database table or make use of content items?
Thanks.
"So what is recommended here. Save events in a separate database table or make use of content items?"
Impossible to answer the absolute best approach without more information as it depends on:
Based on what you've said and taking a few leaps I would guess you would be best to have all events as content nodes.
I would then to add an API that gets events by date (the API will go to the root Events node and then search for child events with a matching date) and Ajaxs them in. https://our.umbraco.com/documentation/Reference/Routing/WebApi/
Content nodes don't have to be pages as well - if no template is assigned to the document type then they can just be handy containers of content data used on other pages (usually the parent but not always). Most Umbraco websites have some amount of them. A lot of child data can be put in the new blocks or nested content but having them as separate content nodes can still be a good model and is probably the right one here.
My general rule is if it feels like content then it should probably be in the CMS if it feels more like data and changes frequently based on something the visitor can do then use DB tables / something else.
An example where you wouldn't use content nodes, and instead use a separate data table, would be if you were trying to keep ticket stock - here you wouldn't want to publish an umbraco node each time to update a number of tickets left (too many publishes, too slow and risks a race condition). This would definitely be better handled in a DB table but you might still keep the event info in a content node.
HTH Steve
Thanks for your response Steve,
I think I'll do a combination of both. I'll go with content items for upcoming events, but a separate database table for past events. The thing is, we'll most likely want to keep a history of events, so we don't necessarily want to delete them once the date is passed. I think I'll setup a cron job to run once a day which takes all of the previous day's events and transfers them to the history table, effectively deleting the content items for that day.
And just to answer your questions:
Quantity of events: like I said, hundreds just to start and possibly growing from there (depending on if we want to keep a history).
How frequently they change: usually won't change (except if mistakes are made, or the events themselves change), but events will be added probably on a daily basis.
Where you expect the editors to be able to administer it from: this depends on if we go with content items or something else. If content items, the editor will use the Umbraco backoffice itself, otherwise we'll create a UI on our platform.
is working on a reply...