MariaDB - Fremdschlüssel deaktivieren

[dabadepdu]

Bei der Erstellung der ersten Tabelle gibt es schon erhebliche Probleme.
..

Das ist mega anstrengend für mich...

Das ist ein typisches Phänomen, wenn man die Sprache/ das System / den Standard wechselt.
Erheblich würde ich die Probleme auch nicht nennen, da gibt es schlimmeres.

Und Du kannst das ohne Schmerzen ganz Straight Forward machen, es gibt eine gute Dokumentation:

8.1. Numeric Types

8.1. Numeric Types 8.1.1. Integer Types 8.1.2. Arbitrary Precision Numbers 8.1.3. Floating-Point Types 8.1.4. Serial Types Numeric types consist of two-, …

www.postgresql.org

Was eher problematisch scheint, aber am Lange Ende eher das Gegenteil ist:
Postgres nimmt viele Sachen genauer als mySQL. Das bedeutet für Anfänger und erst Recht für Umsteiger, der Start ruckelt mglw. mehr.
Am Projektanfang ist das jedoch 1000x besser, als ein System in Produktion zu haben, wo man plötzlich merkt, das merkwürdige Dinge passieren. Eine faule Typumwandlung von mySQL, die an einer Stelle nicht so "funktioniert" wie gedacht, missachtete Constraints, die viele Datensätze unbrauchbar machen usw. usf.
Wenn man mit mySQL (oder andere) anfängt und auf Postgres umsteigt, meint man, Schwierigkeiten zu haben. Tatsächlich ist Postgres deutlich näher am SQL Standard als viele andere. Und es ist so typen-stark, wie kein anderes SQL System, das ich kenne.

 

[merovinger]

Das mit der isbn ist nur beispielhaft.
Der Primary Key soll nur dann automatisch erstellt werden wenn keine explizite Angabe vorhanden ist. Also manuel und automatisch.
Bin mir noch unsicher ob ich auf Postgres umsteige.
Gibt es eine Übersicht wo die Differenzen zwischen MariaDB und Postgres sind ?

Ich werde später den Code und die Fehlermeldung posten. Nur damit du mal siehst was gemeint ist.

 

[merovinger]

Wenn man mit mySQL (oder andere) anfängt und auf Postgres umsteigt, meint man, Schwierigkeiten zu haben. Tatsächlich ist Postgres deutlich näher am SQL Standard als viele andere. Und es ist so typen-stark, wie kein anderes SQL System, das ich kenne.

Nachvollziehbar.
Danke dafür.
Werde ich berücksichtigen.

 

[merovinger]

Ich habe es mal so stumpf eingegeben im pgAdmin.
So hat es dann auch funktioniert.
Aber erst nachdem ich den Datentyp 'int' vor 'serial' entfernt habe. Vorher hat mit der Editor einen Fehler auf 'serial' angemerkt.
Warum auch immer. Das hatte ich auch bei MariaDB. Was sollst.

Passt das so für euch?
Verbesserungsvorschläge ?

 

[castorp]

Grundsätzlich ist serial eine veraltete Methode um automatisch PK Werte zu erzeugen, die man nicht mehr verwenden sollte.
Besser wäre integer generated by default as identity. Das ist kompatibel mit dem SQL Standard und würde so z.B. auch mit Oracle, DB2 und einigen anderen Datenbanken funktionieren (die den SQL Standard respektieren)

Aber nachdem Du auch geschrieben hast, Du willst mal den PK selber generieren und mal von der Datenbank ist das eigentlich eine schlechte Idee. Wenn man den Generator "umgeht", dann laufen die Werte der dahinter liegenden Sequence und die in der Tabelle auseinander. Beim nächsten INSERT der den Wert generiert knallt es dann. Grundsätzlich würde ich dazu raten den PK entweder immer selber oder immer über die DB generieren zu lassen, aber ein Mix ist normalerweise ein guter Weg um sich Probleme einzuhandeln. Ich persönlich definiere Identity Spalten immer als integer generated always as identity - das führt sofort zu einem Fehler wenn man die Generierung in der DB umgehen möchte.

Einzige Ausnahme: UUIDs die kann man sowohl in der Anwendung als auch in der DB erzeugen lassen, ohne dass es Probleme gibt

 

[merovinger]

@castorp , alles klar. Sehr guter Einwand. Werde ich beachten.

 

[dabadepdu]

Beim nächsten INSERT der den Wert generiert knallt es dann.

Das ist wahrscheinlich ein Grund, der bei achtloser Datenbearbeitung häufig die Ursache für Probleme ist, egal in welchem System man "mixt".

Nach meiner Erfahrung (in Foren) ist es so, dass viele genau diesen Mix wollen oder glauben in wollen zu müssen. Bestes Beispiel, die fortlaufende Rechnungsnummer. Aus Angst, das Kunden mit einem System Schwierigkeiten mit dem Finanzamt bekommen, möchte man Lücken, die durch Löschungen/Stornierungen .. entstehen, wieder verwenden. Wahrscheinlich gibt es noch andere Fälle.
Für diesen Fall kann ich nur sagen, es gibt kein Gesetz, das fortlaufende Rechnungsnummern vorschreibt. Es geht lediglich um Transparenz. Die wäre bspw. gegeben, wenn die Löschung (mit Grund) im System zu finden ist. Man muss einem Prüfer entsprechende Fragen beantworten können.

Knallen würde es an der Stelle dann nicht notwendiger Weise, weil man ja (hoffentlich) algorithmisch die Lücken schließt. Einem Unique Constraint, der für PK das Minimum ist, ist die Abfolge der Wert ziemlich egal.

Fazit
In solchen oder ähnlichen Fällen sollte man genau feststellen, wie die (technischen) Möglichkeiten und die fachlichen Anforderungen sind. Und sich immer für den sichersten (stabilsten) Weg entscheiden.

 

[dabadepdu]

Gibt es eine Übersicht wo die Differenzen zwischen MariaDB und Postgres sind ?

Es gibt diverse, Verweise dazu findet man auch hier im Forum glaub ich einige.
M.E. sind die meisten etwas schräg, nicht durchgängig, aber letztlich unbrauchbar / unausgewogen und viel zu oberflächlich, um sich ein Urteil bilden zu können. In vielen Fällen ist die bloße Information mySQL versus Postgres gerade für Anfänger auch nichts sagend.
Beispiel "engines": mySQL hat dutzende, Postgres eine(?). Also hat mySQL gewonnen?
Nein, was mySQL mit verschiedenen Engines erreicht, macht PG mit einer.

 

[merovinger]

@dabadepdu Danke für deine Rückmeldungen.

 

[castorp]

Gibt es eine Übersicht wo die Differenzen zwischen MariaDB und Postgres sind ?

Ich finde diese beiden eigentlich ganz OK

• Postgres 9.1 vs Mysql 5.6 InnoDB?
• SQL Feature Comparison

Solche Listen können aber immer nur eine Momentaufnahme liefern und sind natürlich stark geprägt von den Vorlieben des Autors. Um es überspitzt auszudrücken: Ein MySQL Fan könnte natürlich ein Kriterium erstellen "Erlaube jeden Ausdruck als Bool'schen Ausdruck zu behandeln" und die Tatsache, dass ein where '1StupidExpression' akzeptiert wird, als Vorteil darzustellen.

Unterm Strich geht es im Regelfall um mehr als nur "Features", vor allem beim Einsatz in Unternehmen. Bestehendes Wissen und Kompatibilität mit gekaufter Software spielen sehr häufig eine größere Rolle als "Checklisten" mit Features.

Ich glaube nicht, dass es das eine Killer-Feature gibt welches die eine DB von der anderen absetzt. Was mir bei Postgres gefällt ist deren Bestreben möglichst eng am SQL Standard zu bleiben - was aus meiner Sicht vor allem für Anfänger wichtig ist, weil man halt erstmal die richtige Syntax lernt und nicht Sachen, die so auf keiner anderen Datenbank funktionieren. Auch die Tatsache, dass Postgres deutlich strengere Regeln hat was den Vergleich von verschiedenen Datentypen betrifft mag auf den Anfänger wie ein Nachteil wirken, ist aber auf lange Sicht ein Vorteil, weil Fehler halt früh erkannt werden.

Postgres hat viele (kleine) Features die in der Summe das Arbeiten einfach angenehmer machen, z.B. ist auch die Auswahl an Datentypen deutlich umfangreicher - die von Dir angesprochenen unsigned integers hat es zwar nicht, aber ich habe die in mehr 20 Jahren Arbeit mit Oracle und Postgres noch nie vermisst. Auf physischer Ebene (Speicherbedarf) macht es wirklich wenig Unterschied und auf fachlich/logischer Ebene kann ich das immer mit einen CHECK constraint abfangen - etwas was MySQL/MariaDB wirklich erst seit kurzem beherrscht (nachdem das Bug-Ticket 15 Jahre offen war).

Vor allem MariaDB hat in den letzten Jahren aufgeholt - meiner Meinung nach aber nicht _überholt_.

Was ich bei Postgres vermisse (auch wenn ich es wirklich sehr selten z.B. in Oracle einsetze), sind "temporale Tabellen" (wie sie im SQL Standard heißen). Das bedeutet, dass alte Versionen der Datensätze aufgehoben werden und ich eine Abfrage starten kann "gib mir mal den Stand der Daten wie er am 23. Juli 2019 war".