[TYPO3-german] Nativer SQL mit zwei Tabellen

[Stephan Schuler]

Hallo David,

damit Du beim Union nicht in Probleme läufst würde ich dafür sorgen, dass sowohl die Reihenfolge der Felder als auch die Bezeichnungen identisch sind. Im ersten Teil hast Du die Felder uid, null und bezeichnung, im zweiten Teil hast Du die Felder uid, vorname und nachname. Das ist keine so wahnsinnig gute Idee.

Das Ergebnis Deines Anfrage ist ja ohnehin weder ein Gebäude noch ein Ansprechpartner. Du wirst also aus dem Repository nie die entsprechenden Objekte vom Typ Ansprechpartner oder Gebäude bekommen sondern immer nur das, was Du "FeSearch" genannt hast.

Die UIDs der Suchtreffer solltest Du überschneidungsfrei halten. Wenn Du grob den Wertebereich der UIDs von Adressen und Ansprechpartnern kennst, kannst Du sie im SELECT nummerisch nach oben verschieben:

> SELECT
>     (uid+1000000) AS uid,
>     bezeichnung AS name,
>     '' AS name1,
>     bezeichnung AS name2,
>     uid AS gebaeude,
>     null AS ansprechpartner
> FROM
>     tx_kkbaybw_domain_model_gebaeude
> UNION ALL
> SELECT
>     (uid+2000000) AS uid,
>     CONCAT(vorname, nachname) AS name,
>     vorname AS name1,
>     nachname AS name2,
>     null AS gebaeude,
>     uid AS ansprechpartner
> FROM
>     tx_kkbaybw_domain_model_ansprechpartner

Ab jetzt haben Deine Treffer UIDs ab 1000000 wenn es sich um Gebäude handelt und UIDs ab 2000000 wenn es sich um Ansprechpartner handelt. Solange Du nicht mehr als 1000000 Gebäude hast überscheiden die sich auch nicht.

Diesen SELECT solltest Du auch als View in der Datenbank anlegen, dann musst Du kein hässliches Statement im Repository anlegen.
Insbesondere kannst Du über Statements im Repository ja z.B. auch nicht paginieren oder filtern. Solltest Du also z.B. mit dem PaginateViewHelper hantieren wollen, ist das Statement in PHP ohnehin falsch.

Wenn Du den View in der Datenbank jetzt tx_kkbaybw_domain_model_fesearch nennst, kannst Du trotzdem problemlos ein Model darauf mappen und ein Repository dafür verwenden. Das Model hat dann die Properties $name, $name1 und $name2 jeweils als String sowie $gebaeude als Relation zu einem Gebäude bzw. $ansprechpartner als Relation zu einem Ansprechpartner.

Schöner als im SELECT Zahlen zu addieren wäre, wenn Du in Deiner Tabelle das Auto-Increment gleich so einstellen würdest, dass sich die Nummern nicht überlappen. Dann hat der View weniger zu rechnen.

Allerdings erschließt sich mir der Sinn dieser Übung noch nicht so ganz. Spätestens wenn Du an dem Punkt angekommen bist, wo Gebäude und Ansprechpartner jeweils "Adressen" oder "Kontakte" sind oder haben, gehört das ins Model. "sind" heißt "leiten davon ab", also "extends" in PHP, "haben" heißt Relation.

Wenn Du ein reine Suche über unterschiedliche Objekttypen haben möchtest landest Du besser gleich bei Solr oder Elastic. Die Ergebnisse sind dort von Haus aus "Documents".

Beste Grüße,


Stephan Schuler
Softwareentwickler | netlogix Web Solutions

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Web: websolutions.netlogix.de



----------------------------
Case Study: 1&1-Vertriebspartnerportale – prämiertes Neos-Projekt
Lesen Sie, wie wir mit unseren Projektpartnern eine moderne, ausbaufähige Grundlage auf Basis von Neos CMS für den Betrieb der 1&1-Vertriebspartnerportale schaffen konnten und uns so den Neos Award Gold für herausragende Projekte sicherten. Mehr erfahren…https://websolutions.netlogix.de/referenzen/1und1
----------------------------




netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Web: 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: Matthias Schmidt



________________________________________
Von: typo3-german-bounces at lists.typo3.org <typo3-german-bounces at lists.typo3.org> im Auftrag von David Brünner <david.bruenner at t-online.de>
Gesendet: Montag, 15. Januar 2018 16:45
An: typo3-german at lists.typo3.org
Betreff: [TYPO3-german]  Re: Nativer SQL mit zwei Tabellen

Was ich eigentlich vorhabe, ist eine UNION-Select

(...)

Damit bekomme ich auch die richtige Anzahl an Datensätzen geliefert, aber die Resultate die vom zweiten Teil (rechts vom UNION) herkommen sind leer.

(...)

Hier sieht man, das das QueryResult-Obj von 0 bis 16 gefüllt ist (das kommt vom linken Teil des UNION).
Mit '+' markiert um zu verdeutlichen, das hinter dem Object noch was da ist - Ausgabe von DebuggerUtility.