Ah, I'm glad you've brought this up. You see, we have implemented the m:m model in our fork.
I was hesitant to diverge from the original code much at first but there are several instances where we have essentially the same service at different locations. The result was I was asked to make this change by several of my test users.
Instead of ServiceAtLocation we've got a table called 'Availabilities', it's essentially the same thing though, I just thought it natural to say 'service x is available at location y'.
We've found that this is works well enough for data entry. You create a service, and then you select where it is available. This means you don't need to repeat yourself when you want to list essentially the same service at another location. Also, consider what you have to do when a service moves to a different location. Under this system you just need to remove an availability and add another one.
I understand that this causes an issue when you want to transfer things in a flat format like a spreadsheet. However, I think it's an issue that can be overcome. In particular, it can be overcome with the help of automation.
A further possibility the 'Availability' entries could provide for is the time information - so an availability record could say 'this service is available at this location at these times'. However, in my fork I haven't gone down that route, keeping the schedule tables intact, mainly to avoid over-complicating things.
You received this message because you are subscribed to the Google Groups "OpenReferral" group.
To unsubscribe from this group and stop receiving emails from it, send an email to OpenReferral...@googlegroups.com.
To post to this group, send email to OpenRe...@googlegroups.com.
Visit this group at http://groups.google.com/group/OpenReferral.
For more options, visit https://groups.google.com/d/optout.
Thanks, Rory!I just finished creating a spreadsheet that summarizes the issue and provides the pros and cons of each solution. Rory's comments confirm what I say in the Conclusion. In Rory's situation, he is treating every Service as exactly the same across Locations. For that specific use case, n:m is perfect. However, as far as I can tell, his implementation does not allow for certain Service attributes to be different in one Location versus another.
In OpenReferral, we absolutely have to design for that scenario since it is pretty much guaranteed that at least one attribute will be different. Rory acknowledges that with respect to hours of operation (one of many attributes that could be different), but says he has not implemented it stating over-complication as a reason.
Sorry, I should clarify my post about the schedule. The hours of operation are related to the availabilities. So the times can be different for the same service* at different locations. What I meant was you could potentially put schedule or other availability related data in the availabilities table (e.g. I have a field called 'notes').
That's right, but only thing I'd say is, this method gives you the option of treating services as exactly the same across all locations. If certain properties differ then you can always create another service / location / whatever.