Hi Oli, Oliver Welter wrote:
Ok, it is really complex. so I try a rudimentary example of the internal logic.2. export data to child 2.1. export config (e.g. dataexchange.xml) 2.2. check which objects of which datatype must be exported to the child 2.3. export these objects 2.4. write logs of this 2.5. export my import logs from this childI hope this gives an overview about the logic inside. I don't like more details because the details are to implementation specific for a design discussion. Point 2.2 is the most performance critical one.
Hmm, I dont see a real performance problem here when we put some indexes on the database and use well-balanced querys,
The old design calculates joins (which should now be handled and written by the maintenance command) in perl during the export. I think it is not necessary to give more details right ;)
I am aggainst a second table because it will be prone to inconsitency or we have to spend some additional sync flag......
I think the same way now and make the next proposal in a mail two minutes ago.
Michael -- _______________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin _______________________________________________________________
smime.p7s
Description: S/MIME Cryptographic Signature
