Normal
Hi,der Speicherplatz macht mir da eher weniger sorgen, kostet ja nix mehr heututuage. Eher die Anzahl der Zeilen, wenn ich mir den einen Hersteller anschaue, der hat 200k Artikel x 10 User (da jeder andere Preise, usw haben kann) dann dauern die Updates ewig oder? Ich könnte die Tabelle der Hersteller auch pro Kunde anlegen, dann hab ich aber da wieder bisschen overhead, dann müsste ich mich ums löschen der DB und anlegen kümmern wenn ein neuer User kommt. Andere Möglichkeit wäre, einmal alle Daten abzuspeichern mit den Daten die unser Testlogin vom Hersteller bekommt und dann die kundenspezifischen Änderungen abspeichern, aber da kann es wieder passieren dass ein Kunde Artikel XYZ nicht bekommen darf (ist dann in seinem API, CSV Feed nicht enthalten)Mit dem Listener bekomm ich echt nicht gebacken, ich hätte am liebsten für jeden User einen eigenen Query (macht das Sinn?) Übersichtlich ist es auch jeden Fall. Dann könnte der Grohandelservice schön in jeden "Briefkasten" für den Kunden pumpen und ein Listener arbeitet nur dieses Query nach und nach ab. (Parallel zu anderen Listenern, welche andere Queries abarbeiten).Ein anderes Problem dass ich grad mit dem Test-Service sehe ich dass am 14.07. Wartungsarbeiten angekündigt wurden vom Hoster. Nun liegt der Service und die DB auf einem Server - somit wäre morgen der gesamte Hersteller nicht online. Ich müsste jetzt die DB und den Service wo anders hin zieehen wenn der morgen unbedingt laufen müsste. Aber da könnte man mit einer zentralen DB iwo anders Abhilfe schaffen was aber wiederum Netzwerklatenz mit sich bringt und andere Netzwerkprobs. Ich geh jetzt mal nicht davon aus, dass der Service da morgen 1 Tag weg ist, aber so ein Server kann ja auch mal abschmieren.
Hi,
der Speicherplatz macht mir da eher weniger sorgen, kostet ja nix mehr heututuage. Eher die Anzahl der Zeilen, wenn ich mir den einen Hersteller anschaue, der hat 200k Artikel x 10 User (da jeder andere Preise, usw haben kann) dann dauern die Updates ewig oder? Ich könnte die Tabelle der Hersteller auch pro Kunde anlegen, dann hab ich aber da wieder bisschen overhead, dann müsste ich mich ums löschen der DB und anlegen kümmern wenn ein neuer User kommt. Andere Möglichkeit wäre, einmal alle Daten abzuspeichern mit den Daten die unser Testlogin vom Hersteller bekommt und dann die kundenspezifischen Änderungen abspeichern, aber da kann es wieder passieren dass ein Kunde Artikel XYZ nicht bekommen darf (ist dann in seinem API, CSV Feed nicht enthalten)
Mit dem Listener bekomm ich echt nicht gebacken, ich hätte am liebsten für jeden User einen eigenen Query (macht das Sinn?) Übersichtlich ist es auch jeden Fall. Dann könnte der Grohandelservice schön in jeden "Briefkasten" für den Kunden pumpen und ein Listener arbeitet nur dieses Query nach und nach ab. (Parallel zu anderen Listenern, welche andere Queries abarbeiten).
Ein anderes Problem dass ich grad mit dem Test-Service sehe ich dass am 14.07. Wartungsarbeiten angekündigt wurden vom Hoster. Nun liegt der Service und die DB auf einem Server - somit wäre morgen der gesamte Hersteller nicht online. Ich müsste jetzt die DB und den Service wo anders hin zieehen wenn der morgen unbedingt laufen müsste. Aber da könnte man mit einer zentralen DB iwo anders Abhilfe schaffen was aber wiederum Netzwerklatenz mit sich bringt und andere Netzwerkprobs. Ich geh jetzt mal nicht davon aus, dass der Service da morgen 1 Tag weg ist, aber so ein Server kann ja auch mal abschmieren.
