By a multi-site system I am referring to a system that has multiple panes of the same version. An example of this is Gamespot, where it shows different release dates and even different games depending on whether you are on uk.gamespot, us.gamespot, etc.
The site selection isn’t this issue here. The issue is the process and ease of development and how site specific data is selected or entered. There is also the potential of various system components being not required to be site specific, and in some rare cases it will be required that all data from all sites be visible and selectable for reporting and administrative purposes.
The following techniques have been considered, and although we know they will work, we are unhappy with the cumbersome nature of their implementations:
Table Views –
By creating multiple views for each site on each table we can load data to be queried that is specific to the site. However, inline SQL would have to dynamically call on the correct view, and in the event of a new site being created, a full set of new views would have to be created.
SQL Modification –
By creating an SQL intermediary function, SQL can be modified to change the where clauses and joins to target columns that select only the data specific to a site. However, we believe that to run all of our queries through such a device could have serious problems down the road, and could limit our queries flexibility.
Inline site clauses –
Despite this being the most cumbersome and irritating to implement, it would prove to be the most reliable providing we are able to enforce standards on the way we code. Although this is potentially the most reliable, it is also the least appealing to our developers, it would mean writing site clauses for almost every single query.
So, rather than finding the best means to implement this system on the higher levels of the system, we are trying to find a methodology that will allow a fairly simple implementation of site specific data selection at a base level.
Please let me know if this question is too broad in any respect and I will try to narrow it down further.
First Edit:
The type of data across the sites is identical in respect to the tables. A users table will be shared across all sites and each user may only have access to one, some or all sites.
Lets take the Gamespot example a bit further. One user is given the responsibility of managing the UK version.
The information about games and their reviews are drawn from records accessibly to all sites, because this is globally relevant information
However, lets say the release dates come from another table which is site specific.
The information about the game is retrieved in a typical manner, however getting the release date takes a little extra code to get the correct one for the correct site.
Regarding the user, whichever site that user is currently managing, should be the site that the selection and insertions target.
As you can imagine, the release date is not a core table, and each date cannot simply be mapped against it’s respective game directly.
(I do not imply to have any knowledge of the workings of Gamespot, the example is hypothetical)
I don’t think there is a general answer here, because we don’t know enough about the actual sites you are building. Here are a few examples of questions that will have a major bearing on the best design:
My advice is to focus your energy on the correct table structure to store your data. If you get that right, a good software design should flow naturally from it.
And of course, feel free to ask any specific questions you have along the way!
Edit: after your question update, I still think there is a lot of ambiguity, which can only be resolved as you work out your specific design. But if you want a quick answer, I think inline site clauses are the best of the three options you have suggested. The others add unnecessary layers of complexity.
I don’t see why inline site clauses are “cumbersome” and “irritating”. They won’t introduce repetition in a good design, because you can handle them programmatically in PHP.