Doppelten Eintrag entfernen in einer Tabelle ohne Primary Key

[Mephisto]

@Horny%
Habe das mal entsprechend angepasst. Bin aber jetzt schon ewig dran, diese Datei da rein zu bekommen, was auch im Prinzip klappt (COPY mit DELIMITER E'\t'). Der bleibt aber immer hängen, weil eine Spalte angeblich zu kurz ist:

SQL-Fehler:

FEHLER:  Wert zu lang für Typ character varying(4096)
CONTEXT:  COPY cities, Zeile 3205, Spalte 3: „'Alepea Fakatahataha,A-la-pak Lien-hap Thai-kung-koet,Ab'adnanya Arabskia Emiraty,Al Imarat al `Arab...“

4096 !!!? Aber mit der MariaDB hat das doch auch funktioniert !? (mit VARCHAR(45) in allen Spalten)

 

[Mephisto]

PostGreSQL funktioniert ! Datei eingelesen. Musste character varying in string umwandeln. MariaDB hat die Zellen offensichtlich einfach abgehackt !

 

[Mephisto]

8,6 Millionen Datensätze ! Ohne Murren ! Macht ja schon mal einen wesentlich gediegeneren Eindruck als die MariaDB... War ein sehr guter Tip ! Danke Euch !

 

[akretschmer]

PostGreSQL funktioniert ! Datei eingelesen. Musste character varying in string umwandeln. MariaDB hat die Zellen offensichtlich einfach abgehackt !

Das sind so die Dinge, die @Hony% romantisch als 'seltsam' bezeichnete. MySQL verfälscht Daten, einfach so. Es arbeitet auch direkt falsch, Demo:

mysql> select * from demo;
+------+------+
| c  | val  |
+------+------+
| a  |  10 |
| b  |  10 |
| a  |  20 |
+------+------+
3 rows in set (0.00 sec)

mysql> select c, sum(val) from demo;
+------+----------+
| c  | sum(val) |
+------+----------+
| a  |  40 |
+------+----------+
1 row in set (0.00 sec)

Das ist 2-fach falsch. Zum einen akzeptiert MySQL einen fetten Syntaxfehler, zum anderen ist das Resultat schlicht und ergreifend komplett falsch.

PostgreSQL:

test=*# select * from demo;
 c | val
---+-----
 a |  10
 b |  10
 a |  20
(3 rows)

test=*# select c, sum(val) from demo;
ERROR:  column "demo.c" must appear in the GROUP BY clause or be used in an aggregate function at character 8
STATEMENT:  select c, sum(val) from demo;
ERROR:  column "demo.c" must appear in the GROUP BY clause or be used in an aggregate function
LINE 1: select c, sum(val) from demo;

Es merkt den Syntaxfehler, den MySQL nicht sieht. Macht man es richtig, kommt auch das richtige raus:

test=*# select c, sum(val) from demo group by c;
 c | sum
---+-----
 b |  10
 a |  30
(2 rows)

Ich will gar nicht wissen, was für ein schlechtes Kraut die Jungs von MySQL da geraucht haben, als Sie in der SQL-Spec was von Check-Constraints lasen und dachten: 'Hey cool...'

mysql> create table demo2(i int check(i < 10));
Query OK, 0 rows affected (0.01 sec)

mysql> insert into demo2 values (20);
Query OK, 1 row affected (0.00 sec)

Richtig macht es PostgreSQL:

test=*# create table demo2(i int check(i < 10));
CREATE TABLE
test=*# insert into demo2 values (20);
ERROR:  new row for relation "demo2" violates check constraint "demo2_i_check"
DETAIL:  Failing row contains (20).
STATEMENT:  insert into demo2 values (20);
ERROR:  new row for relation "demo2" violates check constraint "demo2_i_check"
DETAIL:  Failing row contains (20).

Dafür hat MySQL natürlich hammerharte Features wie z.B. Storage-Engine Blackhole: faszinierend schnell und unglaublich sparsam im Speicherverbrauch. Nur das Lesen von gespeicherten Daten gestaltet sich hoffnungslos, da es in /dev/null speichert.

Soviel dazu ;-)

(man könnte das noch episch fortsetzen, keine Angst)

 

[Mephisto]

@akretschmer

Ich will gar nicht wissen, was für ein schlechtes Kraut die Jungs von MySQL da geraucht haben...

Das war ja mal ein guter Spruch am Morgen und des Resümee für mich von gestern ! Aber der Vorteil bei der MariaDB war, dass dadurch, dass die Daten teilweise abgehackt und am Ende sogar wahrscheinlich gar nicht alle Datensätze gelesen wurden (MariaDB hatte ja irgendwann über 1 Mio disconnected und hatte ja auch nicht gemeldet, wie viele Datensätze jetzt da nun eingelesen wurden), konnte man schon nach 36 Sekunden bei einer Suche nach einer Ortschaft ein Ergebnis bekommen. Bei der PG-DB dauert das 60 Sekunden. Aber Spass beiseite. Ich hoffe ja, dass man dann später mit einem Index oder so etwas schneller an die Daten kommt.

Übrigens kann ich jetzt auch keinen doppelten Datensatz mehr finden (hat den MySQL auch erfunden ? ) ! Hatte ihn auch schon vorher im Kate-Editor nicht finden können. ). Aber jetzt kann ich der ersten Spalte so einfach keine Primary-Key Eigenschaft mehr geben. Muss ich heute mal unterwegs mit dem Tab mal etwas forschen. Oder halt das Ganze noch mal von Vorne.

Danke übrigens für Dein ausführliches Statement für die PostGreSQL-DB ! Hatte mich irgendwie sofort überzeugt ! Da kann ich jetzt zum 100000. Mal den (warum so dämlichen ?) Mainstream nicht verstehen !

Mit dem phpPGAdmin bin ich aber noch nicht so ganz glücklich, weil ich meine Übungs-SQL-Skripte nicht abspeichern kann. Den pgModeler habe ich gestern nicht ans Laufen bekommen. Ich brauche immer was Visuelles, bin halt von Windows ziemlich konsolenunfreundlich erzogen worden.

 

[akretschmer]

@akretschmer
Bei der PG-DB dauert das 60 Sekunden. Aber Spass beiseite. Ich hoffe ja, dass man dann später mit einem Index oder so etwas schneller an die Daten kommt.

Sicher. Schau Dir Explain <abfrage> und Explain analyse <abfrage> an, das zeigt den Ausführungsplan an. Deutlich besser als bei MySQL, wir haben einen kostenbasierten Optimizer ;-)

Übrigens kann ich jetzt auch keinen doppelten Datensatz mehr finden (hat den MySQL auch erfunden ? ) ! Hatte ihn auch schon vorher im Kate-Editor nicht finden können. ). Aber jetzt kann ich der ersten Spalte so einfach keine Primary-Key Eigenschaft mehr geben. Muss ich heute mal unterwegs mit dem Tab mal etwas forschen. Oder halt das Ganze noch mal von Vorne.

test=*# \d demo2
  Table "public.demo2"
 Column |  Type  | Modifiers
--------+---------+-----------
 i  | integer |
Check constraints:
  "demo2_i_check" CHECK (i < 10)

test=*# alter table demo2 add primary key(i);
ALTER TABLE

test=*# \d demo2
  Table "public.demo2"
Column |  Type  | Modifiers
--------+---------+-----------
i  | integer | not null
Indexes:
  "demo2_pkey" PRIMARY KEY, btree (i)
Check constraints:
  "demo2_i_check" CHECK (i < 10)

Mit dem phpPGAdmin bin ich aber noch nicht so ganz glücklich, weil ich meine Übungs-SQL-Skripte nicht abspeichern kann. Den pgModeler habe ich gestern nicht ans Laufen bekommen. Ich brauche immer was Visuelles, bin halt von Windows ziemlich konsolenunfreundlich erzogen worden.

Schau Dir PGAdmin an, http://www.pgadmin.org/.


Andreas

 

[Hony%]

Schau Dir PGAdmin an, http://www.pgadmin.org/.

Gewöhnungsbedürftig aber eine runde Sache. Kann auch EXPLAIN visuell darstellen.

MariaDB hat die Zellen offensichtlich einfach abgehackt !

Übrigens kann ich jetzt auch keinen doppelten Datensatz mehr finden (hat den MySQL auch erfunden ? ) ! Hatte ihn auch schon vorher im Kate-Editor nicht finden können.

Das sind die Dinge die man als seltsam empfindet wenn man andere Datenbanken kennt. Der »Mainstream« kennt es nur meistens nicht anders.

Aber jetzt kann ich der ersten Spalte so einfach keine Primary-Key Eigenschaft mehr geben.

ALTER TABLE [table] ADD PRIMARY KEY( [col1 {, col2, …, coln}] )

Gibt Schwierigeres

 

[Mephisto]

Das war ja ne gute Idee, hier mal vorbeizuschauen ! Bei MySQL war ich immer schon skeptisch, schon weil unsere DB-Entwickler (meist Oracle) immer so geringschätzig davon gesprochen haben. PG-Admin werde ich mir mal anschauen (wenn es das bei Arch gibt, bzw. wenn es auch funzt).

Mit den Abfragen muss ich mal schauen. Eigentlich hatte ich ja gar nicht vor, diese Ortsdaten mal in mein Programm einzubauen, aber wenn man die Abfrage wesentlich schneller hinbekommen würde, wäre das doch ne gute Sache. Diese Tabelle war nur zum manuellem Nachschlagen gedacht. Da kann man echt jedes "Kleinklickersdorf" drin finden, und das ganze auch noch umsonst.

In meinem Programm gibt es bislang nur meine Berechungen und die Zeitzonendaten, wahlweise aus der Online-Datenbank oder einer SQLite-DB (aktuelle Baustelle). Ob aber die SQLite überhaupt eine so grosse Datenmenge händeln kann, weiss ich aber auch noch nicht.

ALTER TABLE werde ich heute abend mal Probieren.

Was mich gestern gewundert hat, dass die PG-DB im phpPgAdmin Zeilenumbrüche haben wollte.

Grüsse

Gesendet vom NEXUS7 mit Hilfe von tchibo-online

 

[Hony%]

Ob aber die SQLite überhaupt eine so grosse Datenmenge händeln kann, weiss ich aber auch noch nicht.

The theoretical maximum number of rows in a table is 2^64 (18446744073709551616 or about 1.8e+19). This limit is unreachable since the maximum database size of 140 terabytes will be reached first. A 140 terabytes database can hold no more than approximately 1e+13 rows, and then only if there are no indices and if each row contains very little data.

http://sqlite.org/limits.html

SQLite kann theoretisch bis zu 62 solcher Datenbankdateien per ATTACH zusammenfügen und wie eine Einzige behandeln.

Viel Spaß beim Limit erreichen

Was mich gestern gewundert hat, dass die PG-DB im phpPgAdmin Zeilenumbrüche haben wollte.

Was meinst du damit?

 

[Hony%]

PG-Admin werde ich mir mal anschauen (wenn es das bei Arch gibt, bzw. wenn es auch funzt).

pgAdmin ist im Quellcode verfügbar. Die Installation sieht für mich recht einfach aus. Aber laut Webseite ist auch ein pgadmin3 Package verfügbar.

 

[Mephisto]

PgAdmin gibts auch im Arch/AUR, wie ich heute gesehen habe. Ist das so das üblich Programm ?

Mit den Zeilenumbrüchen meinte ich die Formatierung von der SQL-Eingabe. Später etwas genauer... Ist etwas mühselig aud der Android-Kiste..

 

[akretschmer]

PgAdmin gibts auch im Arch/AUR, wie ich heute gesehen habe. Ist das so das üblich Programm ?

Mit den Zeilenumbrüchen meinte ich die Formatierung von der SQL-Eingabe. Später etwas genauer... Ist etwas mühselig aud der Android-Kiste..

Ich komme mit psql bestens zurecht.

 

[Mephisto]

psql ist Kommandozeile, womit man bestimmt auch alles machen kann, vielleicht in dem einen oder anderen Fall sogar noch besser, weil man sich die Strings bestimmt von da aus noch besser zusammenbasteln kann. Aber ich bin wie gesagt der windows-erzogene Gui-Fan und ein sehr visueller Mensch.

Deshalb habe erst mal gerade PgAdmin3 installiert und mich darin ein wenig umgeschaut. Bei der Anmeldung wollte das Programm eine Service-Angabe haben, noch keine Ahnung, was da gemeint ist. Den Linux-Service-Namen mag es nicht, hat aber auch ohne die Angabe sofort funktioniert. Gefällt mir auf den ersten schärferen Blick echt sehr gut ! Man hat einen richtig guten Überblick über den DB-Server und das Prog integriert sich sauber in der KDE!

Das mit den Zeilenumbrüchen habe ich wohl mit meinem gestrigen Stress mit den Tabellen-Namen verwechselt. Ich hatte die Tabellen mit 1,2,3...19 benannt und PG meinte, das wären Integers und keine Namen, mit entsprechendem Syntaxfehlern.

Heute habe ich jedenfalls den ganzen Tag einiges über Contraints gelesen und jetzt muss ich erst mal raustüfteln, wie ich das mit dem Suchen beschleunigen kann (momentan 60sec für SELECT * FROM table WHERE name = (oder LIKE) 'Düsseldorf').

Dann will ich eventuell ein paar veraltete Einträge (gibt eine Spalte mit dem Eintrags-Datum) rausschmeissen, vielleicht auch nur für die SQLite, damit man das Gigabyte nicht immer am Programm kleben hat.

Für die optimierte Abfrage werde ich wohl ein neues Thema aufmachen, weil sich das mit dem doppelten Eintrag ja erledigt hat und wir hier sowieso in der falschen Rubrik sind mit der PG-DB.

 

[Hony%]

Das mit den Zeilenumbrüchen habe ich wohl mit meinem gestrigen Stress mit den Tabellen-Namen verwechselt. Ich hatte die Tabellen mit 1,2,3...19 benannt und PG meinte, das wären Integers und keine Namen, mit entsprechendem Syntaxfehlern.

Nur Zahlen sind da schon problematisch. In dem Fall hilft normalerweise "1".

Heute habe ich jedenfalls den ganzen Tag einiges über Contraints gelesen und jetzt muss ich erst mal raustüfteln, wie ich das mit dem Suchen beschleunigen kann (momentan 60sec für SELECT * FROM table WHERE name = (oder LIKE) 'Düsseldorf').

Da dürfte schon ein einfacher Index reichen:

CREATE INDEX table_name_index ON table (name);

http://www.postgresql.org/docs/current/interactive/indexes-intro.html

 

[Mephisto]

Die Leute hier im Ruhrpott würden sagen: "BOAH Ey !!! 37ms statt 60s !

Tja, nicht schlecht, so ein B-Baum (hab ich vor Jahrzehnten mal gelernt und war damals schon echt fasziniert davon. Aber das war leider nur theoretisch)