[ic] Multiple catalog control and/or editing
Paul Jordan
paul at gishnetwork.com
Sat Oct 8 15:47:50 UTC 2011
Hello
I am wondering if anyone has any tips, tricks, or clever setups that assist
with editing/maintaining multiple systems. Imagine you have systems for
clients and anywhere from 10% - 60% of each system could be identical on
almost all clients. For example, order processing might be the same for
everyone.
Is there a way to setup a server, using vendroot/pages/admin style
overrides, symlinks, etc, so that:
#1 the base system is installed on multiple catalogs (no matter if they
served by the same IC deamon or not).
#2 in a way I can add pages to any number of installs instantly.
#3 in a way I can edit pages on any number of installs instantly.
#4 in a way that I can override, or add pages to one or more installs.
Basically, I want to more efficiently manage multiple semi-similar Admins,
and use the same code (pages) wherever possible. I want to avoid needing to
"roll out" changes to standard components for each client individually.
Also, regarding base/shared data. Obviously I can create a schema and then
JOIN a table in that schema with multiple tables in multiple other schemas
to facilitate "base" or default data for multiple systems. Is this the only
way and is there anything more clever or robust? I want to avoid having
redundant default data in separate client installs, and if that data needs
to be updated or added to, I don't want to edit each one individually. I
used to use Views to do some similar type of tricks, but I've learned that
Views can't be indexed, at least in Mysql. Someone mentioned to me
copy-on-write updating as well. I'd like to know if anybody is using setups
in ways described above and if they are happy or what problems they run
into.
I use Mysql but would consider changing to Postgres.
Yes, I realize it makes the catalogs less portable. But, I'd rather take
more time when moving systems, which is rare, than taking more time for all
edits, which can be daily or at least weekly.
Paul
More information about the interchange-users
mailing list