[TYPO3-german] Best practice: Daten aus externer Datenbank auslesen und im Frontend darstellen

Thu Sep 11 12:26:01 CEST 2014

Oh, vielen Dank für die ausführliche Bewertung. Es ist aber ein bisschen 
mit Kanonen auf Spatzen geschossen.

Das Szenario sieht so aus, dass vielleicht alle paar Wochen Änderungen 
in einem Kunden-Datenbestand von ca. 500 Adressen stattfinden und dann 
auch auf dem Webserver nachgepflegt werden müssen. Der Kunde hat dafür 
keine redaktionellen Kapazitäten. Auf der Website wird es sonst keinen 
Content geben, der sich öfter mal ändert und redaktionelle Eingriffe 
erfordern würde. Die Änderungen an eine Agentur zu mailen, die diese 
dann zeitnah einpflegt, ist, da muss ich dem Kunden Recht geben, eine 
fehleranfällige Prozedur.

Die Änderungen müssen auch nicht auf die Minute genau auf dem Webserver 
erscheinen, sondern können auch noch am nächsten Tag auftauchen.

Die Datenbank-Applikation des Kunden wird genau unseren Anforderungen 
gemäß arbeiten. Wenn der Kunde dadran irgendwas ändert und schreddert 
die Typo3-Tabelle, ist er selber Schuld. Referenzen wird es keine geben.

Für die Sicherheit ist der Provider (Mittwald wahrscheinlich, aber ich 
suche noch nach Alternativen) zuständig, der sich dieses Feature auch 
mit einem deutlichen Preisaufschlag bezahlen läst. Der Kunde will das 
bezahlen.

Dem Kunden ist es letztendlich egal, in welcher Form und wohin er die 
Daten schieben soll. Er gibt sie gerne auch als XML- oder JSON-Datei aus 
und lädt sie an eine vereinbarte Stelle auf dem Webserver. Da könnte ich 
sie mir dann auslesen. Das wäre ein Pull-Verfahren. Ich finde das 
Push-Verfahren aber elegenater, wegen der niedrigen Änderungsrate der Daten.

Untersuchen wir mal die Service-Variante. Du schreibst:

 > Wenn der Kunde schon selbst aktiv Daten schreiben möchte, würde ich
 > eine kleine Schnittstelle basteln. Der Server soll JSON oder XML per
 > POST oder PUT an eine von mir definierte Action schreiben, darf die
 > Daten per GET auf eine listAction auflisten  oder per GET an eine
 > showAction im Detail sehen. REST würde ich das nicht nennen weil dazu
 > mehr gehört.

GET ist nicht nötig. Der will die Daten nicht selber ansehen können. PUT 
geht bei den meisten Providern nicht oder erst ab einer Preisklasse, die 
hier nicht in Frage kommt. Bleibt nur POST. Dann könnte er also per POST 
eine XML-Datei auf den Server hochladen und einer updateViaXmlfileAction 
übergeben.

 > Ein kleiner Controller, der genau das kann, ist schnell geschrieben,
 > die Validierung hab ich in der Hand und nicht der, der mir die Daten
 > gibt und diese Schnittstelle kann ich per HTTPS und BasicAuth super
 > einfach beschränken.

Das ist sicherlich der sauberere Weg. Der ist in der Erstellung der 
Extension etwas teurer, aber dafür spart man ja dann bei den 
Serverkosten wieder ein. Das kann ich gut verargumentieren.

Besten dank für die Hinweise
Stefan

Am 10.09.2014 um 22:09 schrieb Stephan Schuler:
> Hallo zusammen.
>
> Ich würde es noch drastischer formulieren als Bernd:
> Um Himmels Willen! Unter keinen Umständen schreibt eine Frendanwendung in meine Datenbank!
>
> Einer der Aspekte ist natürlich Caching. Es müssen ja nicht unbedingt die clearCacheCmd sein. Gerade mit 6.2 zum Beispiel wird, wenn ein Datensatz via TCEMain geschrieben wird, jeder Cache mit "$tabellenname_$recordUid" geflusht.
>
> Beispiel anhand von News -- weil sich das jeder vorstellen kann:
> Wenn sich der Newsrecord mit der ID 2341 ändert, wird der Cachetag "tx_news_domain_model_news_2341" in allen Caches weggeräumt. Das hat den Vorteil, dass man z.B. die die News-Detailansicht jeweils mit dem Cachetag der aktuell taggt und sich durch das Ändern der News 2341 eben nur die Detailansicht der News 2341 neu generieren muss und nicht auch noch alle anderen News-Detailansichten.
>
> Der zweite Punkt wäre die History.  Das trifft auf banale Daten vielleicht weniger zu, aber ich bekommen häufig Anrufe von Kunden, warum ein Datensatz jetzt mit xxx gefüllt ist obwohl da yyy drin stehen sollte, und seit wann das so ist und wer das war. Wenn der Speizalfall lautet, dass Redakteure im BE unter keinen Umständen mit diesen Daten in Kontakt kommen sollen, dann ist das vielleicht vernachlässigbar. Aber spätestens wenn man rausfinen muss, *seit wann* da Blödsinn importiert wurde um dann zu ermitteln *warum eigentlich* ist man dankbar die History zu haben.
>
> Der dritte Grund sind Datenbankberechtigungen. Solange es eine Tabelle betrifft die zu 100% vom Fremdsystem beschrieben wird, ist der MySQL-Zugrif noch handhabbar. Wenn ich mir aber vorstelle, dass z.B. Stellenangebote von einem zentralen System in einen Sysfolder importiert werden sollen wärend Redakteure ggf. noch weitere Stellenangebote in einen zweiten Sysfolder von Hand einpflegen wollen, kann ich die Tabelle schon nicht ehr so einfach schützen. Der Fremdserver kann dann zwangsläufig auch die Daten bearbeiten an die er eigentlich überhaupt nicht muss, wenn ich keine Kopfstände mit Stored Procedure machen will.
>
> Und nicht zuletzt ist es auch noch eine Prinzipsache. Das Datenbankschema gehört zu den Innereien meiner Applikation. Unter keinen Umständen ist das eine definierte Schnittstelle die ich veröffentlichen will.
>
> Was passiert mit Referenzen? Wenn z.B. News getaggt oder kategorisiert sind? Muss der Server dann das Mapping zwischen Tagname und Tag-UID kennen? Oder darf er auch die sys_category-Tabelle beschreiben?
>
> Wenn der Kunde schon selbst aktiv Daten schreiben möchte, würde ich eine kleine Schnittstelle basteln. Der Server soll JSON oder XML per POST oder PUT an eine von mir definierte Action schreiben, darf die Daten per GET auf eine listAction auflisten  oder per GET an eine showAction im Detail sehen. REST würde ich das nicht nennen weil dazu meh gehört.
> Ein kleiner Controller der genau das kann ist schnell geschrieben, die Validierung hab ich in der Hand und nicht der der mir die Daten gibt und diese Schnittstelle kann ich per HTTPS und BasicAuth super einfach beschränken.
>
> Wenn Kunden mir aktiv Daten zuschieben wollen dann definiere ich die Schnittstelle als Service. Schreibzugriff auf die Infrastruktur gibt es jedenfalls nicht.
>
> Würde der Kunde die Daten nicht aktiv schreiben wollen würde ich übriens einen Importservice schreiben, der die Daten in die TYPO3-Datenbank legt. Caching und History will ich auch hier haben. Und nachdem ich meine Server für besser verfügbar halte als die meiner Kunden und die Webseite für die im Zweifelsfall ich die Verfügbarkeit garantiere bitte nicht vom Zuliefersystem blockiert werden soll geht das nur asynchron.
>
> Gruß,
>
>
> Stephan Schuler
> Web-Entwickler
>
> Telefon: +49 (911) 539909 - 0
> E-Mail: Stephan.Schuler at netlogix.de
> Website: media.netlogix.de
>
>
>
> ----------------------------
> netlogix MobileDay: 4 Hersteller, 4 Lösungen, 1 Thema
> Erfahren Sie, welche Lösung im Mobile Device Management für Sie die richtige ist. Jetzt anmelden:
> http://it-training.netlogix.de/leistungen-angebote/events/netlogix-mobileday
>
> netlogix auf der it-sa 2014:
> Jetzt anmelden zum kostenlosen Mobile Device Management-Check
> MDM-Check buchen oder Freikarten beanspruchen: http://it-services.netlogix.de/it-sa-2014
>
> ----------------------------
>
>
>
>
> netlogix GmbH & Co. KG
> IT-Services | IT-Training | Media
> Neuwieder Straße 10 | 90411 Nürnberg
> Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
> E-Mail: info at netlogix.de | Internet: http://www.netlogix.de
>
> netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
> Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
> Umsatzsteuer-Identifikationsnummer: DE 233472254
> Geschäftsführer: Stefan Buchta, Matthias Schmidt
>
>
>
> ________________________________________
> Von: typo3-german-bounces at lists.typo3.org [typo3-german-bounces at lists.typo3.org]&quot; im Auftrag von &quot;bernd wilke [t3ng at bernd-wilke.net]
> Gesendet: Mittwoch, 10. September 2014 17:04
> An: typo3-german at lists.typo3.org
> Betreff: Re: [TYPO3-german] Best practice: Daten aus externer Datenbank auslesen und im Frontend darstellen
>
> Am 10.09.14 14:48, schrieb Stefan Padberg:
>> Ganz anders: der Kunde will die Daten mit seiner Datenbank-Applikation
>> direkt in die Typo3-Tabelle schreibe, wenn sie sich ändern. Wenn das
>> kein Service ist...
>>
>> Thema erledigt, wenn der Provider mitspielt.
>>
>
> d.h. aber dass du kein Caching für die Seiten mit den Adresssen benutzen
> kannst. Es wird ja kein entsprechender Cache bei Datensatzänderungen
> gelöscht.
>
>          TCEMAIN.clearCacheCmd = <Seitennummern>
> wird bei dieser Methode ja nicht mehr getriggert.
>
> (also wieder die Frage nach Aktualität vs. Performance)
>
> bernd
> --
> http://www.pi-phi.de/cheatsheet.html
> _______________________________________________
> TYPO3-german mailing list
> TYPO3-german at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
>

-- 
Bergische Webschmiede
Typo3 Dienstleistungen
:: Dipl.-Ing. Stefan Padberg
:: www.bergische-webschmiede.de

---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
http://www.avast.com