I've put up two proof-of-concept sites that share a database (the genealogical part, that is) with different configurations of Welcome pages, favorites, default person, etc.
This is an experiment with having customized websites for different branches of my family. It can be compared to the approach of having separate gedcoms and switching between them for different branches.
If you're allowing on-line edits of that shared database from both instances of PhpGedView, you MUST turn off the "Synchronize edits into GEDCOM file" option in both. You'll find this option in the GEDCOM configuration, "Edit Options" section.
Thanks, fortunately I set this to 'No' already as a speed optimization.
Yes, full editing is possible on both. I opted to share the users so they could be administered by logging in to either site.
There is no qualitative difference in performance on the two sites, and I don't think it's possible to distinguish the "main" site just by using the website, logged in or not, except that it's pretty obvious in this case that one is a subdomain.
I wouldn't bother with a subdomain - I'd simply use two different directories within the same domain:
This lets you have as many instances of PGV as you wish, without their gobbling up subdomain names.
This method of sharing a database between PGV sites requires multiple complete installations of PGV.
It has been suggested to use multiple Gedcoms, which PGV currently supports, for this purpose. Multiple Gedcoms is not the same thing as database sharing. Although the data for the several Gedcoms is indeed stored in one database, it really amounts to database fracturing rather than database sharing since you need to switch gedcoms to get to the data in another gedcom. This works well for some uses, such as hosting non-overlapping databases. It is not a good solution for the problem of presenting the data of one coherent database to different parts of the family with different interests.
A more elegant method would have PGV detect the domain used to reach it - or perhaps use a URL variable, like "site=xxxxxx", the way "ged=yyyyyy" is used in PGV URLs now. This would require only one PGV installation, but allow a custom experience of Welcome page, default ID, favorites, etc.
Gedcom sharing suggests a possible easy path to database sharing. The multiple Gedcom method already supports independent Welcome pages, gedcom settings, etc. I haven't looked at the details, but with this infrastructure in place it may be a small step to "turning the tables" on multiple gedcoms and multiple sites. The step basically is to recharacterize all the "Gedcom" settings in PGV as "Site" settings, and remove the distinction between sites/gedcoms in the genealogy data (individuals, families, sources, etc.). In other words, all the data (subject to privacy restrictions) is available to every site.
If you want PGV to show independent data (like the current Gedcom sharing) then you'll need an independent installation. No extra charge for the software, a few minutes to set it up, and it's only a few MBs on the server, not significant with most hosts.
Another alternative would be to have both multiple Gedcoms and multiple Sites supported by PGV.
After thinking about this for a few days, it occurs to me that one criticism of replacing Gedcom sharing (multiple Gedcoms) with site sharing (multiple 'sites' on a PGV installation) is that it would create an upgrade headache for site admins who have multiple Gedcoms.
Responding to this straw man:
If the change were made so that both multiple sites and multiple Gedcoms were supported then this problem won't exist.
If multiple Gedcoms were no longer supported (easier, perhaps much easier, to code and support) then multiple Gedcoms could still be implemented either by combining the Gedcoms and assigning the different root id's to different sites or by installing multiple instances of PGV in subdirectories or subdomains.
The multiple sites model is better than the current multiple Gedcom model for those cases where the Gedcoms contain overlapping or adjoining genealogies because there will be no need to repeat data or do remote links. In fact, the remote links might be removed at the same time - they would be less needed and they're buggy and the advice from those who've tried them is to avoid them. This would remove a whole class of bugs and usage scenarios to support.
Some people use the multiiple Gedcoms feature to inspect and analyze Gedcom data on a temporary basis. This is an argument for keeping this feature even if multiple sites are implemented. On the other hand it wouldn't be _too_ hard for these admins to install a separate test PGV site for this purpose. If you've installed PGV once the second installation should be easy even if you were among the few who have significant problems initially installing PGV.
There have been several forum posts that touch on this or similar needs. If there's more feedback from others I'll be more motivated to investigate further. This would be of little or no value if it's not accepted into PGV.
One of the prime reasons for the existence of the remote site linking (I wish there were a better name for this) feature that's currently so very buggy is:
My site hosts one database, and yours hosts a completely different one. However, we discovered that there is at least one person who is common to both databases. Rather than copying all of your stuff into my database, and you doing the same with mine into yours, we can just link the two together at the common individual. Thus, the information from your database is now visible to my site's users, while my information is visible to your users. I can't change anything in your database, and you can't change anything in mine - the "foreign" information is read-only.
I know that there are several GEDCOMs out there that have individuals who also appear in my database. However, I don't allow the remote site linking described above since I value the integrity and accuracy of my information. I can't vouch for anybody else's. Furthermore, not all of these "foreign" GEDCOMS are using PhpGedView, so remote site linking isn't a possibility for all of them anyway.