Ankündigung

Einklappen
Keine Ankündigung bisher.

Objektdaten beziehen: XML- oder SQL?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Objektdaten beziehen: XML- oder SQL?

    Hallo,

    ich arbeite gerade an ein Website, die Daten in Abhängigkeit eines Suchfilters oder seitenspezifisch voreingestellter Parameter aus einer XML-Datei liest und darstellt. Die XML-Datei folgt dem OpenImmo-Standard - ein meiner Meinung nach unglaublich dämlicher Standard, aber egal. Meine Aufgabe ist es alles zu machen! Screendesign steht. HTML steht. Backend ist schon sehr fortgeschritten.

    Der Immobilienmakler lädt die XML-Datei hoch, immer wenn er eine neue Immobilie im "Sortiment" hat. Diese soll dann gleich dargestellt werden. Nun bin ich schon mitlerweile soweit, dass Immobilien-Daten erfolgreich dargestellt werden. Es fehlt nur noch feintuning.

    Meine Frage: Wäre es sinnvoller das Backend derart anzulegen, dass sich ein PHP-Skript durch alle XML-Daten crawlt und diese in eine SQL-DB einschreibt, immer dann wenn die Daten aktualisiert werden. Oder ist es bei einem Projekt dieser Größe (ca. 100 Datensätze) auch okay den XML-Standard direkt zu nutzen?

    Ich frage, weil mir SQL performanter und praktischer erscheint, als bei jeder Suchanfrage / Filterung den XML-DOM abzugrasen. Andererseits läuft das ja schon fast (allerdings nicht mit dem original-Datensatz) und ich hab schon soviel Arbeit reingesteckt.


  • #2
    Intern solltest du auf eine Datenbank setzen und XML als Schnittstelle sehen, mit der Daten in das System gelangen oder auch wieder exportiert werden.
    Das ist in jedem Fall performanter und sollte sich der Uvertragungsstandard ändern, heißt es für dich nur den import und Export neu zu schreiben.
    War der Beitrag hilfreich? Dann Bedank dich mit einem klick auf .

    Kommentar


    • #3
      sicher nicht so schlect mit db.
      kannst wohl auch alles mithilfe von libxslt direct aus xml ziehen.

      tr0y hat man was von recht grossen xml dateien geschrieben, welche mithilfe von xslt recht fix durchsucht werden.
      genaue zahlen hat der sicher besser drauf.
      das verhoindern invalider xsml dateien ist dann allerdings ein nicht zu verachtendes thema.

      Kommentar


      • #4
        Das hängt IMHO total von Deiner Infrastruktur ab. 100 Datensätze aus "einer" Datei einlesen und dann in der Session halten erscheint mir vordergründig performanter als ein DB-Zugriff (oder mehrere). Und es hängt davon ab, wieviele Datensätze Du ständig persistent ändern musst.... Vermutlich musst Du selbst ein wenig experimentieren...
        Greets
        joergy

        Kommentar


        • #5
          Hallöchen,

          Zitat von joergy Beitrag anzeigen
          Das hängt IMHO total von Deiner Infrastruktur ab. 100 Datensätze aus "einer" Datei einlesen und dann in der Session halten (..)
          Stopp! Die Session ist keineswegs ein Ersatz für eine Datenbank und auch nicht als solche zu missbrauchen. Wenn man es performant haben möchte, sollte man den RAM seines Servers nutzen bspw. mit XCache, memcached, .. - wobei ich bezweifle, dass die Performance der Datenbank hier an ihre Grenzen stößt. Also ganz klar: Datenbank.

          Viele Grüße,
          lotti

          Kommentar


          • #6
            Ach verdammt, es gibt einfach zu viele gute Gründe alles in eine Datenbank einzulesen. Sind einmal alle Daten eingelesen, nämlich immer dann, wenn eine neue Immobilie dazu kommt, sollte denke ich die Abfrage beim Seitenaufruf über einen SQL-Query einfach schneller gehen.

            Es sollen beim Upload neuer Daten auch immer Bilder zugeschnitten und Thumbnails erzeugt werden (Imagick). Also macht es glaube ich prinzipiell schon Sinn den Datenimport und die Datenabfrage prinzipiell zu trennen. Denn genau hier entstehen Daten, die nicht mehr Bestandteil des XML-Dokuments sind, da die Erzeugung der XML-Datei aus einem Immobilien-Programm nicht die Verknüfung von Bildern mit Thumbnails vorsieht.

            Kommentar


            • #7
              Habe mich dazu entschieden nochmal alles neu zu schreiben und XML über ein PHP-Script in eine SQL-Tabelle zu parsen. Wichtig dabei ist, dass dies ohne besondere PHP-extensions von statten geht, da ich keine exklusiven Zugriffsrechte auf den Server habe.

              Ich will zunächst die DB anlegen und dann über DOMDocument() und DOMXpath() (da ich hier schon kleine Kenntnisse aufgebaut habe) alle Knoten und Kindknoten, sowie Attribute in ein PHP-Objekt einlesen und dieses dann in die Datenbank schreiben. Der Daten-Upload ist nicht besonders Zeitkritisch.

              Meine konzeptionelle Frage: Macht es Sinn hier für alle XML-Knoten, die Kindknoten oder Attribute enthalten eine eigene Tabelle in der DB zu definieren oder gibt es eine gescheitere Lösung? Oder ist mein Plan prinzipiell für die Katz?

              Kommentar


              • #8
                Zitat von Agent49 Beitrag anzeigen
                Meine konzeptionelle Frage: Macht es Sinn hier für alle XML-Knoten, die Kindknoten oder Attribute enthalten eine eigene Tabelle in der DB zu definieren oder gibt es eine gescheitere Lösung? Oder ist mein Plan prinzipiell für die Katz?
                Verstehe nicht ganz. Die XML wird ja vermutlich den gleichen Aufbau/die gleichen Werte haben (Name, Straße, Ort, Wert, ...). Diesen aufbau kannst du dann 1zu1 in die Tabelle abbilden. Wenn für einen Key mehrere Werte existieren (Extras -> Ofen, Fussbodenheizung) sollten diese der Normalisierung zuliebe in eine eigene Tabelle.
                Zitat von nikosch
                Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.

                Kommentar


                • #9
                  Hallöchen,

                  Zitat von Agent49 Beitrag anzeigen
                  Meine konzeptionelle Frage: Macht es Sinn hier für alle XML-Knoten, die Kindknoten oder Attribute enthalten eine eigene Tabelle in der DB zu definieren oder gibt es eine gescheitere Lösung? Oder ist mein Plan prinzipiell für die Katz?
                  Zunächst gilt es zu identifizieren, welche in der XML-Struktur enthaltenen Daten deine Anwendung überhaupt benötigt. Diese Informationen musst du extrahieren und in die eigene Tabellenstruktur übertragen. Welche Informationen für deine Anwendung hier von Relevanz sind, kannst nur du selbst entscheiden.

                  Viele Grüße,
                  lotti

                  Kommentar


                  • #10
                    Verstehe nicht ganz. Die XML wird ja vermutlich den gleichen Aufbau/die gleichen Werte haben (Name, Straße, Ort, Wert, ...). Diesen aufbau kannst du dann 1zu1 in die Tabelle abbilden. Wenn für einen Key mehrere Werte existieren (Extras -> Ofen, Fussbodenheizung) sollten diese der Normalisierung zuliebe in eine eigene Tabelle.
                    Welche Informationen für deine Anwendung hier von Relevanz sind, kannst nur du selbst entscheiden.
                    Absolut richtig. Ich werde alle Daten importieren und die XML-Struktur soweit abbilden wie es mir sinnvoll erscheint. An einigen Stellen scheint mir der Standard nicht gut durchdacht. Im Endeffekt konzipiere ich die Datenbank mit MySQL Workbench und normalisiere soweit es geht. Gott ich hätte nicht gedacht, dass ich das ER-Modell aus der Vorlesung so schnell brauchen werde...

                    Ich werde auch nicht den Weg über DOMDocument() und DOMXpath(), sondern XML LOAD direkt in MySQL verwenden. Dass ich das vorher nicht entdeckt habe...

                    Kommentar


                    • #11
                      Wenn es die Daten schon in XML Form gibt... Warum dann noch mal ein neues Format daraus bauen? Warum kein XSLT? Zudem kann mysql ein wenig xml. Hat aber alles Grenzen. Für Immobilien-Daten würde ich sogar MongoDB in Betracht ziehen...
                      Standards - Best Practices - AwesomePHP - Guideline für WebApps

                      Kommentar


                      • #12
                        Bei 100 Objekten sollte wohl jede Lösung praktikabel sein, auch die XML Datei direkt zu durchsuchen. Wird zwar nicht skalieren, dürfte aber kein Problem sein.

                        Kommentar


                        • #13
                          Wenn es die Daten schon in XML Form gibt... Warum dann noch mal ein neues Format daraus bauen?
                          Der Open-Immo-Standard ist in meinen Augen schrott. Keine Ahnung wie sich das durchsetzen konnte. Außerdem ist er alles andere als "Open". Die Dokumentation kostet Geld. Für die Suche in Knoten mittels DOMDocument() und DOMXpath() sind verschachtelte foreach-Schleifen notwendig, die jedes Mal erneut abgegrast werden müssen.

                          Auch wenn die Anzahl der Datensätze nicht so hoch ist, es sind jeweils dann doch recht viele Knoten. Für die Darstellung im Web reicht aber eine kleine Auswahl an Attributen. Zusätzlich müssen Bilder generiert werden, welche sowieso eine eigene DB benötigen.

                          Ich werde es auf jeden Fall in mit MySQL umsetzen. Habe mich entschlossen. Vielen Dank für die Tipps, ich werde mich nochmal melden wenn die Kiste läuft.

                          Kommentar


                          • #14
                            Zitat von Agent49 Beitrag anzeigen
                            Der Open-Immo-Standard ist in meinen Augen schrott. Keine Ahnung wie sich das durchsetzen konnte. Außerdem ist er alles andere als "Open". Die Dokumentation kostet Geld. Für die Suche in Knoten mittels DOMDocument() und DOMXpath() sind verschachtelte foreach-Schleifen notwendig, die jedes Mal erneut abgegrast werden müssen.
                            Das ist nicht ganz richtig, hängt aber auch vielleicht von deinen XPath / XQuery Fähigkeiten ab.
                            Zitat von Agent49 Beitrag anzeigen
                            Auch wenn die Anzahl der Datensätze nicht so hoch ist, es sind jeweils dann doch recht viele Knoten. Für die Darstellung im Web reicht aber eine kleine Auswahl an Attributen. Zusätzlich müssen Bilder generiert werden, welche sowieso eine eigene DB benötigen.
                            Für genau diesen Fall wurde XSL erfunden, Knotenmengenreduzierung.

                            Performance-Probleme hat DOMDocument erst bei Knoten die sehr viele Daten tragen im oberen Hundertausender bereich. Kleine Datenmengen wie beispielsweise 4-5 Zahlen schieben die Grenze sogar in den Millionen-Bereich.

                            Konkret gearbeitet habe ich mit XMLs im Gigabyte-Bereich.

                            Es ist auch bedeutend performance-intensiver etwas in eine existierende große XML zu schreiben als etwas auszulesen.

                            Zitat von Agent49 Beitrag anzeigen
                            Ich werde es auf jeden Fall in mit MySQL umsetzen. Habe mich entschlossen. Vielen Dank für die Tipps, ich werde mich nochmal melden wenn die Kiste läuft.
                            MySQL ist kein Allheilmittel und kann mitunter weniger performant werden als eine XML. Gerade hinsichtlich Abbildung von Knotenstrukturen als Adjecency List oder Nested Set.

                            In Summe, um deine Frage zu beantworten die du im Start-Post gestellt hast. XMLs die 100 Root-Kind-Elemente besitzen dessen Kind-Element-Anzahl sich bei 1-10 Kind-Elemente bewegt sind absolut kein Problem. Selbst 1000 dieser Root-Kind-Elemente sind kein Problem. Darüber hinaus würde ich aber mit XSL den XML-Brei beim Upload in kleinere Segmente auftrennen. XSL kannst du außerdem dazu verwenden um deinen "Blöden Standard" in eine Form zu bringen die du besser Handhaben kannst, eh die Datei irgendwo gespeichert wird.
                            [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                            Kommentar

                            Lädt...
                            X