Question

I am using ZF2 and Doctrine to develop a project that manages calendar events. All of the events share a common set of data elements, but unique types of events share their own unique sets of type-specific data elements. For example, all of the events include common elements such as eventID, eventName and eventDate. In addition to those common elements, events that are “meetings” will have additional elements like agenda, minutes or attendees that are specific to meetings, events that are “training” will have additional elements that are specific to training, events that are “conferences” will have additional unique elements, and so on.

The project’s index view will want to be able to list all events, but will not require any data beyond the “common” data set. If an event belongs to a certain type, it WILL NOT also belong to another type; so each event will only be associated with one supplemental data set. Some event types might have more than one router: the router sales/meetings[/action] will want to access the same or identical entities, fieldsets and forms as the router marketing/meetings[/action].

In my database I will have a table named events to index all of the events and record common data, and I’ll have a collection of associated tables like events_meetings, events_training, events_conferences, and so on to record type-specific data.

I’m contemplating a number of different solutions for the project:

Solution one: a single module, a single events entity and fieldset, and entities and fieldsets for each of the type-specific data element groups. This solution would require that the events entity have multiple OneToMany elements: one for each of the associated data sets. I don’t know whether this is possible; and even if it is possible, I don’t know whether it is a good idea.

Solution two: a single module and duplicate copies of the common “events” entity and fieldset: events_1 is linked to the events table and is associated with the events_meetings entity; events_2 is identical to events_1 except for the OneToMany element and it is associated with the events_training entity; and events_3, events_4, events_5, and so on are each associated with their own supplemental data set entities. I can see this working, but it requires a lot of nearly identical copies of the common data entity.

Solution three: multiple modules, each with a single events entity and fieldset, and a single associated events_foo entity and fieldset. This is perhaps the cleanest solution, although it seems to create a lot of identical code.

Solution four: reconfigure the data schema so that all of the supplemental data could be stored in a single table. For example, rather than having an events_meetings table that has a single row for each meeting event and a column for agenda, a column for minutes and a column for attendees, it’s possible to create an events_alt_data table that has a different row for each element and columns such as eventID, elementType, elementTitle and eventValue. Wordpress does something like this for unique data, but in my project the supplemental data sets are where the majority of the data will be stored and I’m concerned that it may affect performance as the data grows. This solution will also require some creative coding to deal with the conditional nature of data elements and how to validate and set options for data that could be any type or length.

Any advice?

Was it helpful?

Solution

Single Table Inheritance is the way to go.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top