Expression Engine: When to use channels and when not to use them?

Question

I am still a relative newcomer to Expression Engine as a developer and a user. I am faced with the problem that a lot of my knowledge is being passed to me by users who have found ways to accomplish tasks traditionally undertaken by developers (eg product libraries) by using the channels system.

What I wondered was what people's views are on when it is best to advise a client to use this and when not to.

Let me use an example, a client wants a system which had venues where events could take place. The previous developer had chosen to use the membership system for the venues and the channels system for the events and write some custom code to attempt to knit the two together, specifically because there are not enough hooks to accomplish some background automated tasks like looking up the long/lat of the address of a venue when it is created or updated.

I am picking up after someone else's work largely but its not their fault, it was the information they were given as they were also new to the system.

In any other project this would be a master-detail type setup, events belong to venues, i'd probably write 2 custom tables, editors in the admin area via modules and then use regular custom code in the pages to display and act upon the info - this way, I could control what's happening when a user hits submit.

However, the instigating party is a veteran user of Expression Engine and instructed the previous developer in the manner of "oh, just put it all in the channels and then there's this tag and that tag and so on".

So, am I missing the point or am I right that this does not fit the channels system and when should you use channels and when not?

Thanks friends.

Answer 1

This question is very hypothetical and every developer will give you a different answer as it all depends on the requirement and how that EE developer rolls.

Fundamentally ExpressionEngine allows you to approach builds in many ways, none are right and wrong, albeit some are easier, some harder, others just plain daft.

Basically Channels are groups of data "entries" - these can be anything. Using your example, venues could be one channel with fields created relevant to the subject (e.g. location, size, price, etc). And another channel for events with different fields (e.g. date, type, location).

Mostly anything can be slotted into a channel. But member details are best held within the native member functionality (although there is a commercial add-on that holds member data in a channel).

You reference the previous developers approach - this could be because they used a third-party add-on that required the data to be held separately to channels, or a lack of understanding on best approach. Or just because the developer decided to approach it that way! I suspect the last developer then associated a member (venue) to an entry (event) to link the event to the venue. Basic EE functionality allows for related entries which allows you to associate 1 entry with another (e.g. Event -> Venue), or using the excellent Playa add-on, so this approach is really not necessary.

Personally I would always store the data in channels, and people/members in the native membership functionality (e.g. admin, visitors to the site, customers, etc). I'd only build an add-on (utilising it's own tables/data) to store additional information if it was way outside what EE could store.

Answer 2

To answer your practical question (it's stretching the scope of what Stack Overflow questions are supposed be honestly): you should use a channel for Venues and channel for Events, and the Venue field in the Event entry is a "Related Entries" fieldtype linked to the Venues channel. That's the "standard" EE way, and the most similar to a traditional database schema.