Re: Umstellung von MySQL auf PostgreSQL

Andreas Kretschmer <[email protected]>
Newsgroups gmane.comp.db.postgresql.german
Message-ID <1469163483.39698.1342430274298.JavaMail.open-xchange@ox.ims-firmen.de>



Guenther Boelter <[email protected]> hat am 16. Juli 2012 um 11:06 geschrieben:

> On 07/16/2012 03:34 PM, Albe Laurenz wrote:
> > Andreas Kretschmer schrieb:
> >> Guenther Boelter <[email protected]> wrote:
> >>>   1. Unter MySQL habe ich fuer meine Anwendung eine Datenbank namens
> >>> 'erpel'
> >>>      'sozusagen' fuer die Verwaltung und dann je eine Datenbank pro
> >>> Mandant.
> >>>      Dieses Konzept will ich dem Grunde nach auch beigehalten, daher
> >>> hierzu
> >>>      folgende Frage:
> >>>
> >>>      Wenn ich eine database mit Namen 'davaosoft' anlege und darunter dann
> >>>      jeweils ein schema pro Mandant, also Mandant01, Mandant02 etc. Sollte
> >>> ich
> >>>      dann auch ein eigenes Schema fuer 'erpel' anlegen, oder kann ich fuer
> >>> diese
> >>>      Daten auch das Schema 'public' benutzen? Es geht bei 'erpel'
> >>> letztlich nur
> >>>      um 2 tables mit zusammen ca. 12 Spalten.
> >> Geschmackssache, Dir überlassen.
> > Ich weiß auch nicht die richtige Lösung, das hängt von der Software ab,
> > aber bei "public" sind zwei Dinge zu beachten:
> >
> > 1) In der Standardeinstellung hat jeder Schreibzugriff auf "public".
> >     Das kann man natürlich leicht ändern, ich wollte es nur gesagt haben.
> >
> > 2) Das Schema "public" is standardmäßig im Suchpfad, Objekte darin werden
> >     also be Zugriff ohne Schema-Qualifikation gefunden.
> >     Das kann man natürlich auch ändern.
> >
> > Die Übersetzung in ein eigenes Schema "erpel" wäre wahrscheinlich
> > dem MySQL-Setup am ähnlichsten (was natprlich nicht heißt, das das die
> > beste Methode sein muß).
> >
> > Liebe Grüße,
> > Laurenz Albe
> >
> Moin!
>
> Zunaechst mal vielen Dank Euch beiden fuer's 'Mutmachen' und natuerlich
> fuer die Hinweise.
>
> Ich denke, ich werde zunaechst mal meine MySQL Datenbank ein wenig
> 'aufraeumen', unter anderem Feld- und Tablenamen auf Kleinschreibung
> umstellen. Das sollte in zwei/drei Tagen erledigt sein, zumal das nur so
> 30% der Namen betrifft. Irgendwann habe ich naemlich schon angefangen
> dort nur noch Kleinschreibung zu verwenden.
>
> Dann werde ich noch mal meine diversen Queries durchgehen. Da duerften
> aus der Anfangszeit auch noch einige etwas eher 'ungewoehnliche'
> Konstruktionen existieren.
>
> Und erst danach werde ich dann mit mysql2postgres die eigentliche
> Umstellung vornehmen. Ausserdem habe ich mich nach Albes Hinweis nun
> endgueltig entschlossen das public-Schema dann doch nicht zu verwenden.
>
> Einsteigen will ich uebrigens mit der 9.1, die sollte nach Andreas
> Ausage dann wohl in Ordnung sein.
>
> Zwei Fragen habe ich aber aktuell noch:
>
> Was ist dieses 'CTE', dass da mit der 8.4 eingefuehrt wurde und wie kann
> ich den 'search_path' per User bzw. per Mandant passend setzen?

CTE steht für Common Table Expressions und bietet recht umfangreiche
Abfragemöglichkeiten, z.B.:
- rekursive Abfragen zum Klättern in Bäumen
- Definition von 'Fenstern' (z.B. Saldo eines Kontos von Anfang bis aktuellen
Datensatz oder für den laufenden Monat oder oder oder ...)
- writeableCTE, damit kannst Du z.B. in einem Ruck Datensätze in tabelle A
löschen und in B einfügen

und vieles mehr, guggst Du
http://www.postgresql.org/docs/9.0/static/sql-select.html, google listet dir
Tonnen von weiteren Links.

Den search_path eines Users kannst Du dauerhaft via alter user set search_path
setzen.


Viel Erfolg ;-)


Andreas


-- 
Sent via pgsql-de-allgemein mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.