Export in XML Format

Moin Moin

Vor einiger Zeit hat uns ein Entwickler von heute auf morgen verlassen - und eine postgreSQL Datenbank und XML Dateien hinterlassen. Der Sinn des (fast fertiggestellten) war, dass man aus den XML Dateien eine MySQL Datenbank befüllen kann (vorher wurden die Daten in den XML Dateien noch stark bearbeitet und das Programm dafür steht und funktioniert). Nun weiß ich nicht, wie ich die Daten aus der postgreSQL Datei in diese XML Form bringe - und habe die Hoffnung, dass es ein einfacher Befehl (Debian Server) ist. Hier der Anfang einer XML Datei:

<?xml version="1.0" encoding="US-ASCII" ?>
<data>
        <header>
                <column name="object_id" type="int8" />
                <column name="user_id" type="int8" />
                <column name="group_id" type="int8" />
                <column name="language_id" type="int8" />
                <column name="country_id" type="int8" />
                <column name="lock_user_id" type="int8" />
                <column name="rights" type="bit" />
                <column name="createuser_id" type="int8" />
                <column name="createdate" type="timestamptz" />
                <column name="modifyuser_id" type="int8" />
                <column name="modifydate" type="timestamptz" />
                <column name="homepage" type="varchar" />
                <column name="comment" type="text" />
                <column name="contacttype_id" type="int8" />
                <column name="longcomment" type="text" />
        </header>
        <records>
                <row>
                        <column name="object_id">7735008836627650005</column>
                        <column name="user_id">1</column>
                        <column name="group_id">1</column>
                        <column name="language_id" null="null"></column>
                        <column name="country_id" null="null"></column>
                        <column name="lock_user_id" null="null"></column>
                        <column name="rights">000000011111111100010100000100110000000000000000</column>
                        <column name="createuser_id">1</column>
                        <column name="createdate">2011-06-14 16:03:06.626395+02</column>
                        <column name="modifyuser_id" null="null"></column>
                        <column name="modifydate" null="null"></column>
                        <column name="homepage" null="null"></column>
                        <column name="comment" null="null"></column>
                        <column name="contacttype_id">2445588383757234603</column>
                        <column name="longcomment" null="null"></column>
                </row>

Das Ganze soll der letzte Export sein, dann kommt das alles weg :slight_smile:

lenny

Da steht auch, wie man Tabellen nach XML mappen kann.

Das Ganze soll der letzte Export sein, dann kommt das alles weg :slight_smile:

lenny

Viel Spaß in der Zukunft mit MySQL.

Hi,

sieht genauso aus wie beim export mit phpPgAdmin!

  • phpPgadmin installieren (falls nicht auf dem Server vorhanden: /var/www/phpPgAdmin)
    In phpPgAdmin Tabelle auswählen
    Auf Exportieren klicken
    xml auswählen

Schade, aber trotzdem viel Spaß mit MySQL

Gruß

Micha

Ist das nicht ein Widerspruch in sich selbst? - SCNR :rolleyes:
Wir machen gerade in einem Projekt den Upgrade von MySQL zu Postgres und die Entwickler freuen sich alle tierisch. In anderen einem Projekt wechseln wir gerade von Oracle zu Postgres und das finden das alle auch cool - vor allem das transaktionale DDL…

Yeah.

Jepp das ist es - vielen Dank!

Und ja PostgreSQL hat bestimmt seine Anwedungsgebiete - aber a) kennen wir uns viel besser mit MySQL aus und b) funktioniert das einfach zu gut um das running system zu changen :wink: ach ja und c) sind postgreSQL Entwickler einfach zu teuer :smiley:

Oder ihr seid mit eurem MySQL und so zu billig, und daher ging auch der Entwickler.

Der Markt macht den Preis - viele MySQL Entwickler == günstig, wenig PostgreSQL Entwickler == teuer. Und für jedes normale Webprojekt in PHP (CMS, CRM, Shop, Webseite, Buchungssystem etc.) reicht einfach MySQL (und damit “günstiger”) völlig aus. Bei größeren Projekten halte ich mich raus - wir sind nur für < 10.000 User Projekte zuständig und mit MySQL noch nie an irgendwelche Grenzen gestoßen (obwohl es bei dem von uns verwendeten ZF2 und Doctrine ja eh fast wurscht ist was dahinter läuft). Aber darum geht es ja in diesem Thread gar nicht und wurde bestimmt schon tausendmal diskutiert.

Auf jeden Fall wird das Projekt jetzt komplett eingestampft und die XML Dateien sind das letzte Stück, dass noch gefehlt hat (um die vorgesehene Export / Import Funktion des Programms ein letztes Mal zu nutzen) - nun sind die Daten im neuen System und alle happy :slight_smile:

PS: Keine Ahnung warum dieser Weg von dem Programmierer gewählt wurde, aber dieses Export Skript nimmt die XML Dateien (statt die DB direkt) und macht daraus die SQL Statements die wir für den Import brauchen.

Würdest Du PG und seine Möglichkeiten kennen würdest Du anders denken. Du hast keine Ahnung über Dinge wie Datentypen, Indexmöglichkeiten und Abfragetechniken. Dinge, die Du jetzt mehr oder weniger umständlich, fehleranfällig und unperformant in der Applikation abwickelst gingen erheblich einfacher in einer richtigen DB wie PostgreSQL. Mit eurer Billig-Einstellung seid ihr damit teurer als nötig - und eines Tages auch teurer als Eure Mitbewerber. Du wirst eines Tages an meine Worte denken.

Eines Tages gehe ich hoffentlich in Rente :smiley: Glaub mir, beide DBMS haben Ihre Einsatzgebiete - und ob sich mit PostgreSQL und dem bisher eh schon verwendeten DoctrineORM für mich und meine Entwicklungen soviel ändern würde, wage ich zu bezweifeln - nein ich sehe wirklich keinen Grund für 0815 Programme auf ein mir unbekanntes DBMS umzustellen. Bei unseren 2 größten Projekten wäre dies auch gar nicht möglich, da wir nur ein kleiner Teil des Entwicklerteams sind und nur Module beisteuern - allerdings kam hier auch noch nie der Wunsch (weder bei den Kunden noch anderen Entwicklern) auf ausgerechnet das DBMS zu wechseln.

PS: Und wenn ich in den nächsten Jahren Lust bekommen sollte mich mit dem Thema zu beschäftigen, dann wird es sicherlich MongoDB o.ä. sein (also noch mal in eine ganz andere Richtung) was mein Portfolio erweitern wird.

Datentyp JSON/JSONB.

Viel Spaß!

Gruß Uwe

Yeah, wollt ich auch schon sagen. PG kann das, was MongoDB kann. Offenbar sogar schneller. Und einiges mehr. Aber hey: vielleicht ist es besser, wenn er erst mal durch Schmerzen lernt.

Man muss schon ehrlich sein: MySQL ist nicht soo schlecht wie es oft hingestellt wird (nicht falsch versehen: für mich ist es kein ernst zu nehmende Platform). Was aber gerne von den Leuten die MySQL einsetzen übersehen wird, ist dass es nichts kann was andere DBMS nicht auch (und meistens: besser) können.
Die anderen Datenbank bieten aber zusätzlich deutlich mehr Features. MySQL hat sich seit 10 Jahren, was die Sprache SQL angeht, nicht mehr weiterentwickelt (und mit der Qualität hatten sie auch sehr lange große Probleme). Die letzte wirklich neuen Features waren die Einführung von foreign keys, stored procedures und triggern mit der 5.0er Version. Aber alles was im 21 Jahrhundert im SQL Standard dazugekommen ist, hat MySQL einfach verschlafen.

Eine kleine Übersicht über Features die man heute im als selbstverständlich in einem (modernen) DBMS erwarten kann ist hier: SQL Feature Comparison

Die NoSQL Datenbanken haben sicherlich ihre Berechtigung, aber mit Postgres kann man auch beides in einem haben:

Postgres als Document-Store ist vermutlich nicht ganz so mächtig wie MonoDB, Cassandra oder ähnliche Systeme, aber für viele Situationen sicherlich ausreichend, vor allem wenn man das mit relationale Daten zusammenbringen will (Stichwort: Aggregationen)

Wenn ich mir die Entwicklung der NoSQL DBs in den letzten Jahren so ansehe, dann haben doch einige angefangen, Funktionalitäten einzubauen die in relationalen Datenbanken schon lange vorhanden sind: Read Consistency, Transaktionen, Indizes, deklarative Abfragesprchen (die zum Teil SQL sehr ähnlich sind) usw. Und das obwohl die alle am Anfang behauptet haben das brauche man nicht. Die NoSQL DBs haben bei der horizontalen Skalierung immer noch die Nase vorn (schliesslich sind die meisten um diese Architektur herum entstanden). Aber mit Projekten wie Postgres-XC oder Postgres-XL holt das “relational Lager” auch langsam auf.

Und letztendlich sind die diversen Projekte die SQL und NoSQL zusammenbringen (BigSQL, Hive usw) ja ein Zeichen dafür, dass man nicht nur ein System braucht, sondern im Regelfall mehrere. Wer weiß, vielleicht verschmelzen die Konzept ja irgendwann wirklich zu einem Hybriden Ansatz aus “einem Guß”.

Ich nehme noch PostGIS als Argument für Postgres dazu, IMHO durchaus angebracht, da immer mehr geodatenbezogene Analysen erstellt werden. Und selbst in Projekten, die zu Beginn gar nicht darauf ausgelegt sind, bietet es die Möglichkeit, dem Kunden weitere Optionen anzubieten, die auch genutzt werden. MIttlerweile hat das eine Qualität, da stelle ich sogar Oracle Spatial hinten an. MySQL wird hier auch in absehbarer Zeit nichts bieten können, da sich ‘the big red O’ sich sicher nicht selbst das Wasser abgraben wird.

Gruß Uwe