MariaDB - Fremdschlüssel deaktivieren

  • Ersteller Ersteller merovinger
  • Erstellt am Erstellt am
M

merovinger

Guest
Hallo.

Leider muss ich mich mit dem SQL beschäftigen. Hat berufliche Gründe.
Jedenfalls habe ich eine kleine Testdatenbank (MariaDB) erstellt. Die Struktur steht schon mal. Nun meine Fragen was mir beim erlernen aufgefallen ist.

1. Wie kann man mehrere Zeilen für eine Spalte mit einem Befehl abfeuern ?
Ich musste es jetzt so machen das alle Spalten benannt werden müssen und dann jeweils die Werte in genau der Reihenfolge gelistet werden mussten.
Da muss es was geileres geben. Das nervt ja extrem ab. Ich will mehrere X-Daten für eine Zeile pro Spalte reinhämmern.

2. Zwischenzeitlich musste ich die Fremdschlüsselbeziehungen aufheben damit ich die Eigenschaften der entsprechenden Primärschlüssel ändern konnte.
Das hat auch funktioniert. Siehe Command unten. Nach ein paar Tagen wollte ich das nochmal machen. Seitdem geht das nicht mehr.
Es wird auch keine Fehlemeldung zurück gegeben. Die Ausgabe ist immer die gleiche. Das Resultat aber nicht.


SET FOREIGN_KEY_CHECKS=0;
SET GLOBAL foreign_key_checks=OFF;
SET SESSION foreign_key_checks=OFF;

Sorry wenn ich das mal so sagen muss, aber bei solchen Dingen platzt mir echt der Arsch. Vielleicht kann jemand helfen.

Gruß.

Mero
 
Werbung:
1. nicht sicher, ob Du das meinst, versuch:
Beispiel
Code:
insert into meineTabelle (<feld3>, <feld9>, <feld1>)
values 
(12,'test','AA'),
(11,'rest','AB'),
(22,'best','AB'),
..
(99,'zest','AA');

2.
Wie lautet denn die immer gleiche Ausgabe und woran erkennst Du, dass es nicht geht?
Wenn ein Fehler auftritt, sollte eine Fehlermeldung kommen. Dies kann eigentlich nur dann "übergangen" werden, wenn nicht mit einem DB Tool gearbeitet wird, sondern mit eigenem Programmcode, der die Fehlermeldung unterdrückt.

3. Wenn Du Dich "leider mit SQL beschäftigen musst" und die Vorgaben ansonsten nicht weiter spezifiziert sind, würde ich nicht MariaDB nehmen, sondern Postgres.
Es gibt dafür viele Gründe, für Anfänger interessant:
- bessere, genauere Fehlermeldungen
- näher am "Standard"
- weniger, weniger schlimme bugs / Stolpersteine
 
@dabadepdu, genau so habe ich es mit einer Tabelle gemacht.
Finde ich zu umständlich wenn ich 30 oder mehr Datensätzen pro Tabelle reinhauen will.

Gibt es ein commandlet mit der man Daten für 30+ Zeilen für eine Spalte abfeuern kann ?
Das würde die Sache erheblich vereinfachen.
 
Das Beispiel von @dabadepdu kannst Du auch auf 100, 1000 oder mehr Werte erweitern. Und wenn Du es noch schneller haben willst: in PostgreSQL kannst Du via COPY ganze CSV-Dateien in einem Rutsch einlesen, ich ich glaube, dies zumindest kann auch MySQL. Auch wenn es sonst nicht viel kann ...
 
Was genau willst Du machen? Das ist unklar.

Zu 2.: geht das auch nachvollziehbar zu erklären?
Ich will die Testdatenbank einfach nur schnell und effizient mit Daten befüllen.

zu2)
Zum Beispiel wollte ich den Primärschlüssel auf auto_increment umstellen. Geht aber nicht wegen dem Fremdschlüssel-Constraint.
Daher habe ich die Fremdschlüsselbeziehungen aufgehoben, Änderungen gemacht, und die vorherige Einstellung iweder rückgängig gemacht.
 
Das Beispiel von @dabadepdu kannst Du auch auf 100, 1000 oder mehr Werte erweitern. Und wenn Du es noch schneller haben willst: in PostgreSQL kannst Du via COPY ganze CSV-Dateien in einem Rutsch einlesen, ich ich glaube, dies zumindest kann auch MySQL. Auch wenn es sonst nicht viel kann ...

Ist PostgrSQL soviel besser ?
Hast du entsprechende Erfahrungen ?
 
ch will die Testdatenbank einfach nur schnell und effizient mit Daten befüllen.
dazu nehme ich sehr gerne generate_series(). 1 Million Datensätze? Kein Problem ..

Code:
postgres=# create table merovinger(id int generated always as identity primary key, val numeric);
CREATE TABLE
postgres=# insert into merovinger (val) select random() * 100000 from generate_series(1,1000000)s;
INSERT 0 1000000
postgres=# select count(*) from merovinger;
  count  
---------
 1000000
(1 row)

postgres=#
 
Gut. Werde dann einen neuen virtuellen Ubunutu-Server aufsetzen und das testen.
Kannst du mir hierzu irgendetwas mit auf den Weg geben ?
Webseiten ?
Community ?
Usw. .....

Danke.
 
Ich weiß jetzt nicht, wie man "insert into table (columnlist) values (valuelist),.. nennenswert vereinfachen sollte / könnte, ohne Funktionalität zu verlieren. Das ist inkl. Kopfteil sehr nahe an einer CSV Datei.
Falls es dir z.B. um solche CSV Dateien geht, die kann mit "copy" als Ganzes laden oder exportieren. (In Postgres, in mySQL geht das auch irgendwie, kannst Du nachschlagen, ich müsste es auch, weiß es nicht auswendig)
Ansonsten gibt es einige tolle Tools, die sogar Copy / Paste können, falls Du aus der Ecke Excel & Co kommst. Dazu habe ich aber keine aktuellen Infos und schon gar nicht zu mySQL. Da diese Tools allerdings DB unabhängig sind, sollte es auch mit mySQL / MariaDB gehen. Diese Art tools kann aber dann mal gern ein paar Tausend Euros kosten, hab ich schon länger nicht benutzt.
 
@akretschmer , ich habe PostgreSQL getestet.
Bei der Erstellung der ersten Tabelle gibt es schon erhebliche Probleme.
Hier ein mein code.

create table artikel (
artikelnummer smallint(5) unsigned auto_increment primary key,
titel varchar(50),
isbn int(10) unsigned,
einkaufpreis decimal(4,2),
verkaufspreis decimal(4,2),
erscheinungsjahr year(4)
);

Scheinbar kennt PostgreSQL kein "unsigned". Will aber nur positive Zahlen verwenden.
"auto_increment" kennt es auch nicht. Nehme ich smallserial fängt er an zu meckern. Nehme ich serial fängt er an zu meckern. Usw.......

Das ist mega anstrengend für mich. Ich habe den Code mittels Validator durchlaufen lassen.
Ich denke ihr/du wisst was mit den Werten in den Klammern bezweckt werden soll.
Wie sieht die Lösung aus für PostgreSQL ?
 
Werbung:
Wenn deine Artikelnummer aut_increment (MySQL) sein soll, soll sie also automatisch generiert werden. Du wirst also nicht bereits definierte Artikel aus z.B. einer CSV-Datei mit bereits vorhandenen Artikelnummern verwenden wollen. Dafür hat PG 'generate always as identity' als Zusatz, Serial oder bigserial würden auch gehen. Bei dem generated always hast Du aber den Vorteil, daß PG VERBIETET, dort auch manuell was vorzugeben - was immer wieder zu Problemenführt.Dein ISBN soll sicher eine international gültige ISBN-Nummer beinhalten. Dafür hat PG, nach Installation einer Extension, sogar einen passenden Datentyp, der die ISBN-Prüfziffer kennt und berechnet und keine falschen Nummern akzeptiert.

Alles zusammen:

Code:
postgres=# create extension isn;
CREATE EXTENSION
postgres=# create table artikel (id int generated always as identity primary key, isbn isbn, name text);
CREATE TABLE
postgres=#

So, nun sehe ich noch Erscheinungsjahr. Das könnte man so lösen:

Code:
postgres=# create table artikel2 (id int generated always as identity primary key, isbn isbn, name text, erscheinungsjahr int, check(erscheinungsjahr between 2000 and 2050));
CREATE TABLE

PostgreSQL beachtet den check-constraint - und setzt ihn durch (nicht so wie MySQL, welches solche Constraints ignoriert...) Längenconstraints kann man auch setzen:

Code:
postgres=# create table artikel3 (id int generated always as identity primary key, isbn isbn, name varchar(50), erscheinungsjahr int, check(erscheinungsjahr between 2000 and 2050));
CREATE TABLE
postgres=#

Und wenn Dir INT zu groß ist bei der Nummer: das ist eher irrelevant, da wegen wenigen Bytes zu sparen. Wenn Du eines Tages feststellst, daß INT zu klein ist und Du eine ID-Spalte von INT auf BIGINT erweitern willst wird es kompliziert, weil eine solche Änderung ein Rewrite und damit einen exklusiven Tabellenlock erfordert, was bei 2 Milliarden Rows eher unangenehm ist. Also: bei solchen Spalten auch immer in die Zukunft schauen...
 
Zurück
Oben