zwei Tabellen

Hallo,
ich habe ine mittelschweres Problem. Ich muß zwei Datenbanken vergleichen.
Es werden jeweils immer nur ein integer eld verglichen, also Feld 1 in
Tabelle 1 != Feld 3 in Tabelle 2.
Dabei enthält Tabelle 1 65000 Zeilen und Tabelle 2 enthält 150000 Zeilen.
Wenn ich nun über php und einer Schleife eine sql Abfrage erstelle und
durchführe, braucht mein rechner dazu 3 Stunden.

Momentan lese ich per LIMIT immer nur 100 Datensätze aus Tabelle1 und
vergleiche diese mit der Tabelle2, danach kommen die nächsten 100 dran,
u.s.w.. Das mache ich per Javascript, welches immer wieder das selbe php
Script aufruft.

Wenn ich eine komplette Abfrage durchführe steigt mein mysql-Server aus.
Auch mit INNEr JOIN komme ich nicht so richtig weiter. Ich würde aber schon
gern den Hauptteil der Arbeit den Datenbankserver machen lassen und nur das
nötigste mit dem php. Hat jemand einen Tipp für mich, wie ich das
bewerkstelligen kann?

mfg

Mathias

Re: zwei Tabellen

Mathias Fiedler wrote:

> Hallo,
> ich habe ine mittelschweres Problem. Ich muß zwei Datenbanken vergleichen.
> Es werden jeweils immer nur ein integer eld verglichen, also Feld 1 in
> Tabelle 1 != Feld 3 in Tabelle 2.

Und welche Gemeinsamkeiten haben die beiden Tabellen? (Tabellenstruktur,
SHOW CREATE TABLE ) [#1]


> Dabei enthält Tabelle 1 65000 Zeilen und Tabelle 2 enthält 150000 Zeilen.
> Wenn ich nun über php und einer Schleife eine sql Abfrage erstelle und
> durchführe, braucht mein rechner dazu 3 Stunden.

Das ist klar. Das macht man ja auch nicht :-}


> Momentan lese ich per LIMIT immer nur 100 Datensätze aus Tabelle1 und
> vergleiche diese mit der Tabelle2, danach kommen die nächsten 100 dran,
> u.s.w.. Das mache ich per Javascript, welches immer wieder das selbe php
> Script aufruft.

Autsch.


> Wenn ich eine komplette Abfrage durchführe steigt mein mysql-Server aus.
> Auch mit INNEr JOIN komme ich nicht so richtig weiter.

Was heißt das? Was hast Du versucht? [#2]


> Ich würde aber schon gern den Hauptteil der Arbeit den Datenbankserver
> machen lassen und nur das nötigste mit dem php.

Ist sinnvoll. Evtl. kannst Du das sogar komplett MySQL überlassen, so daß Du
PHP weglassen kannst und direkt per Kommandozeile steuerst.


> Hat jemand einen Tipp für mich, wie ich das bewerkstelligen kann?

Vielleicht. Wenn Du zu [#1] und [#2] mehr Infos lieferst.


Thomas
--
> Bitte nicht gleich losschimpfen,
Das ist hier auch nicht Sitte. Denn hier ist hamster.all und nicht de.all.
(Maik Bauch und Joern Weber in hamster.de.config; 2000-09-24)

Re: zwei Tabellen

Mathias Fiedler schrieb:

> ich habe ine mittelschweres Problem. Ich muß zwei Datenbanken vergleichen.
> Es werden jeweils immer nur ein integer eld verglichen, also Feld 1 in
> Tabelle 1 != Feld 3 in Tabelle 2.

Mit welchem Ziel? Gemeinsamkeiten finden? Unterschiede finden? Beides
lässt sich mit einfachen SQL-Abfragen erreichen:

select t1.feld1 from tabelle1 t1, tabelle2 t2
where t1.feld1 = t2.feld3;

select feld1 from tabelle1
where feld1 not in (select feld3 from tabelle2);

> Wenn ich eine komplette Abfrage durchführe steigt mein mysql-Server aus.

Der _Server_ steigt aus? Das hätte ich gerne genauer.

Was meinst Du mit "komplette Abfrage"?

Gruß. Claus

Re: zwei Tabellen

Am Thu, 07 Sep 2006 16:31:27 +0200 schrieb Thomas Rachel:

> Mathias Fiedler wrote:
>
>> Hallo,
>> ich habe ine mittelschweres Problem. Ich muß zwei Datenbanken vergleichen.
>> Es werden jeweils immer nur ein integer eld verglichen, also Feld 1 in
>> Tabelle 1 != Feld 3 in Tabelle 2.
>
> Und welche Gemeinsamkeiten haben die beiden Tabellen? (Tabellenstruktur,
> SHOW CREATE TABLE ) [#1]
>

Tabelle 1

CREATE TABLE IF NOT EXISTS `temp_1157633846` (
`temp_ID` bigint(20) NOT NULL auto_increment,
`partner_id` bigint(10) NOT NULL default '0',
`fingerprint` longtext,
`zeit` longtext,
`opts` longtext,
`kauf_id` longtext,
`kd_nr` longtext,
`status` bigint(10) NOT NULL default '0',
`rate` bigint(10) NOT NULL default '0',
`optionaler_stornogrund` longtext,
PRIMARY KEY (`temp_ID`)
) TYPE=MyISAM AUTO_INCREMENT=1 ;

Tabelle 2

CREATE TABLE IF NOT EXISTS `teilnehmer` (
`id` bigint(20) NOT NULL auto_increment,
`gesperrt` tinyint(4) NOT NULL default '0',
`confirmtime` tinytext,
`confirm` int(6) default NULL,
`spiel` tinytext NOT NULL,
`agb` tinytext NOT NULL,
`tstamp` tinytext NOT NULL,
`IP` tinytext NOT NULL,
`sxref` text,
`referer` text,
`uid` text,
`anrede` text,
`vorname` text,
`nachname` text,
`tag` text,
`monat` text,
`jahr` text,
`strasse` text,
`nr` text,
`plz` text,
`stadt` text,
`land` text,
`email` text NOT NULL,
`vorwahl` text,
`telefon` text,
`mobilvorwahl` text,
`mobiltelefon` text,
`PrWahl` text NOT NULL,
`code` tinytext,
`optionen` text,
`returnvalue` text,
PRIMARY KEY (`id`),
KEY `email` (`email`(50))
) TYPE=MyISAM AUTO_INCREMENT=1 ;



In jeder Tabelle gibt es ein INTEGER Feld (tabelle 1 -> / Parner_ID Tabelle
2 -> confirm ) mit Einträgen. Diese beiden Zellen müssen verglichen werden.
Wenn der
Wertt aus Tabelle 1 in Tabelle 2 vorkommt, muß ein Eintrag in Tabelle 1
(Feld `optionaler_stornogrund`) getätigt werden.
Gleich noch hinterher. Die Tabellen bekomme ich so vorgegeben, also daran
kann ich nichts ändern.

>> Dabei enthält Tabelle 1 65000 Zeilen und Tabelle 2 enthält 150000 Zeilen.
>> Wenn ich nun über php und einer Schleife eine sql Abfrage erstelle und
>> durchführe, braucht mein rechner dazu 3 Stunden.
>
> Das ist klar. Das macht man ja auch nicht :-}

Wie dann besser ?

>
>
>> Momentan lese ich per LIMIT immer nur 100 Datensätze aus Tabelle1 und
>> vergleiche diese mit der Tabelle2, danach kommen die nächsten 100 dran,
>> u.s.w.. Das mache ich per Javascript, welches immer wieder das selbe php
>> Script aufruft.
>
> Autsch.
Mag sein, aber es funktioniert. Es dauert nur elend lange.

>
>> Wenn ich eine komplette Abfrage durchführe steigt mein mysql-Server aus.
>> Auch mit INNER JOIN komme ich nicht so richtig weiter.
>
> Was heißt das? Was hast Du versucht? [#2]

SELECT t.temp_ID FROM $tableName as t INNER JOIN $dbTable as db ON
t.$csvField = db.$dbField

Da kommt nach 2 Min Server Overload. Es muß über php auf dem Webserver
angesteuert werden. Eingabe an der Komandozeile auf dem Localen Rechner ist
nicht.
>
>
>> Ich würde aber schon gern den Hauptteil der Arbeit den Datenbankserver
>> machen lassen und nur das nötigste mit dem php.
>
> Ist sinnvoll. Evtl. kannst Du das sogar komplett MySQL überlassen, so daß Du
> PHP weglassen kannst und direkt per Kommandozeile steuerst.
>
>
>> Hat jemand einen Tipp für mich, wie ich das bewerkstelligen kann?
>
> Vielleicht. Wenn Du zu [#1] und [#2] mehr Infos lieferst.
>
>
> Thomas

Re: zwei Tabellen

Am Thu, 07 Sep 2006 18:40:04 +0200 schrieb Claus Reibenstein:

> Mathias Fiedler schrieb:
>
>> ich habe ine mittelschweres Problem. Ich muß zwei Datenbanken vergleichen.
>> Es werden jeweils immer nur ein integer eld verglichen, also Feld 1 in
>> Tabelle 1 != Feld 3 in Tabelle 2.
>
> Mit welchem Ziel? Gemeinsamkeiten finden? Unterschiede finden? Beides
> lässt sich mit einfachen SQL-Abfragen erreichen:
>
> select t1.feld1 from tabelle1 t1, tabelle2 t2
> where t1.feld1 = t2.feld3;
>
> select feld1 from tabelle1
> where feld1 not in (select feld3 from tabelle2);
>

Siehe Posting an Thomas. Damit steigt der Server mit Overloadet aus.

>> Wenn ich eine komplette Abfrage durchführe steigt mein mysql-Server aus.
>
> Der _Server_ steigt aus? Das hätte ich gerne genauer.
>
> Was meinst Du mit "komplette Abfrage"?
>
Siehe ebenfalls Posting an Thomas. Ich wäre für schnelle Hilfe dankbar. Das
macht mir wirklich Kopfzerbrechen.

Mathias

Re: zwei Tabellen

Mathias Fiedler schrieb:

> Tabelle 1
>
> CREATE TABLE IF NOT EXISTS `temp_1157633846` (
> `temp_ID` bigint(20) NOT NULL auto_increment,
> `partner_id` bigint(10) NOT NULL default '0',
> ...
> PRIMARY KEY (`temp_ID`)
> ) TYPE=MyISAM AUTO_INCREMENT=1 ;
>
> Tabelle 2
>
> CREATE TABLE IF NOT EXISTS `teilnehmer` (
> ...
> `confirm` int(6) default NULL,
> ...
> KEY `email` (`email`(50))
> ) TYPE=MyISAM AUTO_INCREMENT=1 ;
>
>
>
> In jeder Tabelle gibt es ein INTEGER Feld (tabelle 1 -> / Parner_ID Tabelle
> 2 -> confirm ) mit Einträgen. Diese beiden Zellen müssen verglichen werden.

*Argh!* Irgendwie ist das Äpfel und Birnen. temp_1157633846.partner_id
ist BIGINT, teilnehmer.confirm ist INTEGER.

> SELECT t.temp_ID FROM $tableName as t INNER JOIN $dbTable as db ON
> t.$csvField = db.$dbField

Unknown table '$tableName', unknown table '$dbTable', unknown field
'$csvField', unknown field '$dbField'. Ist das so schwer, das
SQL-Statement so zu posten, wie es der Server erhält?!

> Da kommt nach 2 Min Server Overload. Es muß über php auf dem Webserver
> angesteuert werden. Eingabe an der Komandozeile auf dem Localen Rechner ist
> nicht.

Najo. Du joinst über Felder, die

1.: unterschiedliche Datentypen haben
2.: nicht indiziert sind
3.: keins davon ein PK oder unique ist

Dass dann nix vernünftig geht, braucht dich aber nicht zu wundern.

gruss, heli

Re: zwei Tabellen

Mathias Fiedler wrote:

> Tabelle 1
>
> CREATE TABLE IF NOT EXISTS `temp_1157633846` (
> `temp_ID` bigint(20) NOT NULL auto_increment,
> `partner_id` bigint(10) NOT NULL default '0',
> `fingerprint` longtext,
> `zeit` longtext,
> `opts` longtext,
> `kauf_id` longtext,
> `kd_nr` longtext,
> `status` bigint(10) NOT NULL default '0',
> `rate` bigint(10) NOT NULL default '0',
> `optionaler_stornogrund` longtext,
> PRIMARY KEY (`temp_ID`)
> ) TYPE=MyISAM AUTO_INCREMENT=1 ;
>
> Tabelle 2
>
> CREATE TABLE IF NOT EXISTS `teilnehmer` (
> `id` bigint(20) NOT NULL auto_increment,
> `gesperrt` tinyint(4) NOT NULL default '0',
> `confirmtime` tinytext,
> `confirm` int(6) default NULL,
> `spiel` tinytext NOT NULL,
> `agb` tinytext NOT NULL,
> `tstamp` tinytext NOT NULL,
> `IP` tinytext NOT NULL,
> `sxref` text,
> `referer` text,
> `uid` text,
> `anrede` text,
> `vorname` text,
> `nachname` text,
> `tag` text,
> `monat` text,
> `jahr` text,
> `strasse` text,
> `nr` text,
> `plz` text,
> `stadt` text,
> `land` text,
> `email` text NOT NULL,
> `vorwahl` text,
> `telefon` text,
> `mobilvorwahl` text,
> `mobiltelefon` text,
> `PrWahl` text NOT NULL,
> `code` tinytext,
> `optionen` text,
> `returnvalue` text,
> PRIMARY KEY (`id`),
> KEY `email` (`email`(50))
> ) TYPE=MyISAM AUTO_INCREMENT=1 ;

Die extessive Verwendung dieser text-Typen ist IMHO auch nicht gerade der
Performance zuträglich. varchar-Felder sinf AFAIK *wesentlich* billiger.


> In jeder Tabelle gibt es ein INTEGER Feld (tabelle 1 -> / Parner_ID
> Tabelle 2 -> confirm ) mit Einträgen.

Stimmt nicht. Das eine ist BIGINT, das andere INT. Läßt sich wohl
vergleichen, ist aber mit Sicherheit teurer als ein Vergleich unter
passenden Typen.


> Diese beiden Zellen müssen
> verglichen werden. Wenn der
> Wertt aus Tabelle 1 in Tabelle 2 vorkommt, muß ein Eintrag in Tabelle 1
> (Feld `optionaler_stornogrund`) getätigt werden.

> Gleich noch hinterher. Die Tabellen bekomme ich so vorgegeben, also
> daran kann ich nichts ändern.

Gar nichts? Auch keine Indizes? Die sind nämlich Grundvoraussetzung für
das, was Du vorhast.


>>> Dabei enthält Tabelle 1 65000 Zeilen und Tabelle 2 enthält 150000
>>> Zeilen. Wenn ich nun über php und einer Schleife eine sql Abfrage
>>> erstelle und durchführe, braucht mein rechner dazu 3 Stunden.
>>
>> Das ist klar. Das macht man ja auch nicht :-}
>
> Wie dann besser ?

Direkt als Verknüpfung in SQL.


>>> Momentan lese ich per LIMIT immer nur 100 Datensätze aus Tabelle1 und
>>> vergleiche diese mit der Tabelle2, danach kommen die nächsten 100
>>> dran, u.s.w.. Das mache ich per Javascript, welches immer wieder das
>>> selbe php Script aufruft.
>>
>> Autsch.
> Mag sein, aber es funktioniert. Es dauert nur elend lange.

Ja eben.


>>> Wenn ich eine komplette Abfrage durchführe steigt mein mysql-Server
>>> aus. Auch mit INNER JOIN komme ich nicht so richtig weiter.
>>
>> Was heißt das? Was hast Du versucht? [#2]
>
> SELECT t.temp_ID FROM $tableName as t INNER JOIN $dbTable as db ON
> t.$csvField = db.$dbField

Äh, ok. Wie Helmut schon sagte: Was soll man damit anfangen? Die
Variablenersetzung hättest Du sicher noch hinbekommen, oder?

Ich rate jetzt einfach mal: t ist die obige temp_-Tabelle, db die
Teilnehmertabelle. Dann kriegst Du hier schonmal die t-Felder, für die
passende db-Felder existieren und kannst dann in einer Schleife updaten.

Sind die einzusetzenden Werte bereits vorher bekannt und gleich? Dann
kannst Du nämlich auch gerade

UPDATE SET optionaler_Stornogrund=
machen.


> Da kommt nach 2 Min Server Overload.

Wie gesagt - Du hast keine passenden Indizes. Somit müssen

65000 Zeilen mit 150000 Zeilen verknüpft werden. Ergibt 9750000000
verknüpfte Zeilen. Das er da zu kotzen beginnt, ist verständlich...

Du solltest zumindest die Felder indizieren, mit denen verknüpft wird.
Das sind hier, äh, ja. $csvField und $dbField. Zur Not könnte auch eines
von beiden ausreichen - dann ist auf der anderen zwar ein Full Table
Scan nötig, aber zumindest ist das Verknüpfen dann schneller. Falls die
Anzahl der überlappenden (also gemeinsam vorkommenden) Zeilen
tendenziell eher groß ist, wird wohl eh bei einer Tabelle ein Fll Table
Scan gemacht, andernfalls sollten besser beide Indizes existieren.

Ich nehme an, Dein "Die Tabellenstruktur ist so vorgegeben" bezieht sich
auf die vorhandenen Felder, weil die Applikation eben darauf eingestellt
ist, und daß Du Schlüssel erstellen kannst. Wenn nicht - gute Nacht.


Thomas

Re: zwei Tabellen

Am Thu, 07 Sep 2006 23:16:26 +0200 schrieb Thomas Rachel:

> Mathias Fiedler wrote:
>
>> Tabelle 1
>>
>> CREATE TABLE IF NOT EXISTS `temp_1157633846` (
>> `temp_ID` bigint(20) NOT NULL auto_increment,
>> `partner_id` bigint(10) NOT NULL default '0',
>> `fingerprint` longtext,
>> `zeit` longtext,
>> `opts` longtext,
>> `kauf_id` longtext,
>> `kd_nr` longtext,
>> `status` bigint(10) NOT NULL default '0',
>> `rate` bigint(10) NOT NULL default '0',
>> `optionaler_stornogrund` longtext,
>> PRIMARY KEY (`temp_ID`)
>> ) TYPE=MyISAM AUTO_INCREMENT=1 ;
>>
>> Tabelle 2
>>
>> CREATE TABLE IF NOT EXISTS `teilnehmer` (
>> `id` bigint(20) NOT NULL auto_increment,
>> `gesperrt` tinyint(4) NOT NULL default '0',
>> `confirmtime` tinytext,
>> `confirm` int(6) default NULL,
>> `spiel` tinytext NOT NULL,
>> `agb` tinytext NOT NULL,
>> `tstamp` tinytext NOT NULL,
>> `IP` tinytext NOT NULL,
>> `sxref` text,
>> `referer` text,
>> `uid` text,
>> `anrede` text,
>> `vorname` text,
>> `nachname` text,
>> `tag` text,
>> `monat` text,
>> `jahr` text,
>> `strasse` text,
>> `nr` text,
>> `plz` text,
>> `stadt` text,
>> `land` text,
>> `email` text NOT NULL,
>> `vorwahl` text,
>> `telefon` text,
>> `mobilvorwahl` text,
>> `mobiltelefon` text,
>> `PrWahl` text NOT NULL,
>> `code` tinytext,
>> `optionen` text,
>> `returnvalue` text,
>> PRIMARY KEY (`id`),
>> KEY `email` (`email`(50))
>> ) TYPE=MyISAM AUTO_INCREMENT=1 ;
>
> Die extessive Verwendung dieser text-Typen ist IMHO auch nicht gerade der
> Performance zuträglich. varchar-Felder sinf AFAIK *wesentlich* billiger.
>
>
>> In jeder Tabelle gibt es ein INTEGER Feld (tabelle 1 -> / Parner_ID
>> Tabelle 2 -> confirm ) mit Einträgen.
>
> Stimmt nicht. Das eine ist BIGINT, das andere INT. Läßt sich wohl
> vergleichen, ist aber mit Sicherheit teurer als ein Vergleich unter
> passenden Typen.
>

Ds int kann ich bei der Erstellung der tabelle 1 noch ändern.

>> Diese beiden Zellen müssen
>> verglichen werden. Wenn der
>> Wertt aus Tabelle 1 in Tabelle 2 vorkommt, muß ein Eintrag in Tabelle 1
>> (Feld `optionaler_stornogrund`) getätigt werden.
>
>> Gleich noch hinterher. Die Tabellen bekomme ich so vorgegeben, also
>> daran kann ich nichts ändern.
>
> Gar nichts? Auch keine Indizes? Die sind nämlich Grundvoraussetzung für
> das, was Du vorhast.
>

Kannst Du m ir das mit den Indizies etwas genauer erklären? Laut Manual
lohnt sich das nur, wenn es um Texte oder mehrere Spalten geht. Da ich aber
eine int Zahl mit einer int Zahl vergleiche, habe ich gedacht, das macht
keinen Unterschied.

>>>> Dabei enthält Tabelle 1 65000 Zeilen und Tabelle 2 enthält 150000
>>>> Zeilen. Wenn ich nun über php und einer Schleife eine sql Abfrage
>>>> erstelle und durchführe, braucht mein rechner dazu 3 Stunden.
>>>
>>> Das ist klar. Das macht man ja auch nicht :-}
>>
>> Wie dann besser ?
>
> Direkt als Verknüpfung in SQL.
>
>
>>>> Momentan lese ich per LIMIT immer nur 100 Datensätze aus Tabelle1 und
>>>> vergleiche diese mit der Tabelle2, danach kommen die nächsten 100
>>>> dran, u.s.w.. Das mache ich per Javascript, welches immer wieder das
>>>> selbe php Script aufruft.
>>>
>>> Autsch.
>> Mag sein, aber es funktioniert. Es dauert nur elend lange.
>
> Ja eben.
>
>
>>>> Wenn ich eine komplette Abfrage durchführe steigt mein mysql-Server
>>>> aus. Auch mit INNER JOIN komme ich nicht so richtig weiter.
>>>
>>> Was heißt das? Was hast Du versucht? [#2]
>>
>> SELECT t.temp_ID FROM $tableName as t INNER JOIN $dbTable as db ON
>> t.$csvField = db.$dbField
>
> Äh, ok. Wie Helmut schon sagte: Was soll man damit anfangen? Die
> Variablenersetzung hättest Du sicher noch hinbekommen, oder?
>
SELECT t.temp_ID FROM tabelle1 as t INNER JOIN tabelle2 as db ON
t.tabelle1 = db.tabelle2

Entschuldige bitte, aber was ist daran jetzt anders?

Die Namen sind uninteressant. Die Tabelle 1 also $dbtableName wird aus
einer CSV Datei generiert. Diese kann jedesmal anders aussehen. Weder die
Feldnamen, die Anzahl der Felder noch die Anzahl der Einträge ist vorher
bekannt. Die Tabelle auf dem Server ist vorgegeben. Keine Änderung möglich.
Wenn ich per php und mysql die Tabelle nachträglich indizieren kann, würde
ich das tun. Aber wie?

> Ich rate jetzt einfach mal: t ist die obige temp_-Tabelle, db die
> Teilnehmertabelle. Dann kriegst Du hier schonmal die t-Felder, für die
> passende db-Felder existieren und kannst dann in einer Schleife updaten.
>
> Sind die einzusetzenden Werte bereits vorher bekannt und gleich? Dann
> kannst Du nämlich auch gerade
>
> UPDATE SET optionaler_Stornogrund=
> machen.
>

Klingt gut. Aber da mein Server bereits jetzt schon aussteigt, wäre das
wohl endgültig zu viel. Da muß erst mal die einfache Abfrage funktionieren.
Deshalb habe ich ja gefragt. Wie bekomme ich einen Index hin? Die tabelle1
erstelle ich ja per mysql Code und php auf dem Server. Also kann ich auch
einen Index einbringen. Die Frage ist nur, wie? Und wie muß ich das dann
benutzen?

>> Da kommt nach 2 Min Server Overload.
>
> Wie gesagt - Du hast keine passenden Indizes. Somit müssen
>
> 65000 Zeilen mit 150000 Zeilen verknüpft werden. Ergibt 9750000000
> verknüpfte Zeilen. Das er da zu kotzen beginnt, ist verständlich...
>
Das weis ich, deshalb frage ich ja.

> Du solltest zumindest die Felder indizieren, mit denen verknüpft wird.
> Das sind hier, äh, ja. $csvField und $dbField. Zur Not könnte auch eines
> von beiden ausreichen - dann ist auf der anderen zwar ein Full Table
> Scan nötig, aber zumindest ist das Verknüpfen dann schneller. Falls die
> Anzahl der überlappenden (also gemeinsam vorkommenden) Zeilen
> tendenziell eher groß ist, wird wohl eh bei einer Tabelle ein Fll Table
> Scan gemacht, andernfalls sollten besser beide Indizes existieren.
>
> Ich nehme an, Dein "Die Tabellenstruktur ist so vorgegeben" bezieht sich
> auf die vorhandenen Felder, weil die Applikation eben darauf eingestellt
> ist, und daß Du Schlüssel erstellen kannst. Wenn nicht - gute Nacht.
>
>
> Thomas

Re: zwei Tabellen

Am Thu, 07 Sep 2006 21:50:19 +0200 schrieb Helmut Chang:

> Mathias Fiedler schrieb:
>
>> Tabelle 1
>>
>> CREATE TABLE IF NOT EXISTS `temp_1157633846` (
>> `temp_ID` bigint(20) NOT NULL auto_increment,
>> `partner_id` bigint(10) NOT NULL default '0',
>> ...
>> PRIMARY KEY (`temp_ID`)
>> ) TYPE=MyISAM AUTO_INCREMENT=1 ;
>>
>> Tabelle 2
>>
>> CREATE TABLE IF NOT EXISTS `teilnehmer` (
>> ...
>> `confirm` int(6) default NULL,
> > ...
>> KEY `email` (`email`(50))
>> ) TYPE=MyISAM AUTO_INCREMENT=1 ;
>>
>>
>>
>> In jeder Tabelle gibt es ein INTEGER Feld (tabelle 1 -> / Parner_ID Tabelle
>> 2 -> confirm ) mit Einträgen. Diese beiden Zellen müssen verglichen werden.
>
> *Argh!* Irgendwie ist das Äpfel und Birnen. temp_1157633846.partner_id
> ist BIGINT, teilnehmer.confirm ist INTEGER.
>
>> SELECT t.temp_ID FROM $tableName as t INNER JOIN $dbTable as db ON
>> t.$csvField = db.$dbField
>
> Unknown table '$tableName', unknown table '$dbTable', unknown field
> '$csvField', unknown field '$dbField'. Ist das so schwer, das
> SQL-Statement so zu posten, wie es der Server erhält?!
>
>> Da kommt nach 2 Min Server Overload. Es muß über php auf dem Webserver
>> angesteuert werden. Eingabe an der Komandozeile auf dem Localen Rechner ist
>> nicht.
>
> Najo. Du joinst über Felder, die
>
> 1.: unterschiedliche Datentypen haben
> 2.: nicht indiziert sind
> 3.: keins davon ein PK oder unique ist
>
Damit ist mir leider nicht geholfen. Ich habs doch gesagt, die
Servertabelle also tabelle2 steht fest. Der Vergleich bezieht sich imemr
auf das gleiche Feld, also könte ich nachträglich einen Index einbauen,
wenn das geht? Einen PK hat die Tabelle schon. Die zu vergleichenden Felder
können den gleichen Wert in mehreren Datensätzen haben, also nichts für PK
oder unique. Da bleibt mir blos noch der index. Bitte, kannst Du mir sagen,
wie ich damit umgehe?

> Dass dann nix vernünftig geht, braucht dich aber nicht zu wundern.

Mathias

Re: zwei Tabellen

Ach so. Noch ein Nachtrag. Weder die Spalte aus Tabelle 1 noch die Spalte
aus Tabelle2 sind von Anfang an bekannt. Zuerst wird eine CSV Datei
eingelesen und daraus eine Tabelle erstellt. Erst dann erfolgt die
Auflsitung der Spaltennamen gegenüber den Spaltennenamen aus Tabelle 2.
Erst jetzt wird festgelegt, welche Spalten verglichen werden. Ich kan also
entweder erst jetzt den Index für die entsprechende Spalte hinzufügen,
falls das geht, oder von Anfang alle int Felder mit einem Index belegen.
Was ist da sinnvoller?

Mathias

Re: zwei Tabellen

Mathias Fiedler wrote:

>> Stimmt nicht. Das eine ist BIGINT, das andere INT. Läßt sich wohl
>> vergleichen, ist aber mit Sicherheit teurer als ein Vergleich unter
>> passenden Typen.
>>
>
> Ds int kann ich bei der Erstellung der tabelle 1 noch ändern.

Wie gesagt, ich weiß nicht, ob es einen großen Einfluß hat, aber besser
ist es wohl schon.


> Kannst Du m ir das mit den Indizies etwas genauer erklären? Laut Manual
> lohnt sich das nur, wenn es um Texte oder mehrere Spalten geht.

Dann hast Du entweder was falsch verstanden, oder es steht
mißverständlich da.

Indizes brauchst Du immer, wenn Du einen Spalteninhalt schnell finden
willst. Sie sind, vereinfacht geesagt, eine Zuordnung zwischen Wert
einer Spalte und Position der passenden Zeile(n) in der Tabelle. Sie
sind als Baum aufgebaut, so daß auch bei einer Tabelle mit zigtausenden
von Einträgen eine Suche nach einem bestimmten Wert nur wenige Zugriffe
benötigt.

Vergleiche mal in Deiner obigen Tabelle teilnehmer zeitmäßig die Suche
nacheiner bestimmten id (sollte dank vorhandenem Index auf id sehr
schnell gehen) mit einer Suche nach einem bestimmten confirm-Wert
(dürfte relativ viel Zeit in Anspruch nehmen, da die gesamte Zabelle
Zeile für Zeile nach dem Wert durchsucht werden muß).

Mit anderen Worten, der Index hilft bei der Suche nach einem bestimmten
Wert.

Hast Du nun keine Indizes, mußt Du (bzw. der Server) eine Tabelle
komplett durchlaufen und für jeden gefundenen Eintrag die 2. auch
nochmal. Das dauert.

Mit Indizes kann für jeden gefundenen Eintrag direkt der dazu passende
Partner gefunden werden. Eine Tabelle muß (wenn nicht weiter
eingeschränkt wird) dabei komplett durchlaufen werden, die andere wird
dann quasi 1:1 abgebildet.


>>> SELECT t.temp_ID FROM $tableName as t INNER JOIN $dbTable as db ON
>>> t.$csvField = db.$dbField
>>
>> Äh, ok. Wie Helmut schon sagte: Was soll man damit anfangen? Die
>> Variablenersetzung hättest Du sicher noch hinbekommen, oder?
>>
> SELECT t.temp_ID FROM tabelle1 as t INNER JOIN tabelle2 as db ON
> t.tabelle1 = db.tabelle2
>
> Entschuldige bitte, aber was ist daran jetzt anders?

Man versteht, wie das zu den oben angegebenen Tabellendefinitionen paßt
und welche Felder gemeint sind. Das ist wesentlich. Und das was Du da
geschrieben hast (ON t.tabelle1 = db.tabelle2) kann nicht sein, da
gehören Feldnamen, keine Tabellennamen hin. Ich vermute mal, wie gesagt,
es ist ON t.partner_id = db.confirm.

Wesentlich ist, daß auf mindestens eines dieser Felder ein Index gesetzt
ist.

Wenn Du auf beide Felder ein Index setzt, kann der Server entscheiden,
welche Tabelle er komplett durchläuft und welche er dann referenziert.
Das kann auch nochmal einen Unterschied machen, bei Dir Faktor 2 - 65000
zu 150000, wenn Du in Tabelle2 auch noch einen Index hinbekommst.


> Weder die Feldnamen, die Anzahl der Felder noch die Anzahl der Einträge
> ist vorher bekannt.

Das ist insofern ungünstig, als Du dann beim Indexerstellen nochmal
separat aufpassen mußt. Insbesondere mußt Du beim Erstellen der
temporären Tabelle schon wissen, auf welche Spalte Du verknüpfen willst
(oder eben direkt vorm Verknüpfen den Index hinzufügen).


> Die Tabelle auf dem Server ist vorgegeben. Keine
> Änderung möglich. Wenn ich per php und mysql die Tabelle nachträglich
> indizieren kann, würde ich das tun. Aber wie?

Was jetzt - keine Änderung möglich oder doch? Also falls doch, geht das
(siehe auch Handbuch) mit

ALTER TABLE xxx ADD INDEX (spaltenname)

oder

ALTER TABLE xxx ADD UNIQUE (spaltenname), wenn jeder Wert nur einmal
vorkommen soll, kann und darf.

Falls nicht, dauert Dein Durchlauf, wie gesagt, immerhin doppelt so lang,
aber es geht schneller als jetzt.


>> UPDATE SET optionaler_Stornogrund=
>> machen.

> Klingt gut. Aber da mein Server bereits jetzt schon aussteigt, wäre das
> wohl endgültig zu viel.

Naja, jetzt teste erstmal, wie das SELECT-Verhalten mit den Indizes wird
(Lerneffekt: Setze vor und nach dem Indexerstellen jeweils mal den
Befehl "EXPLAIN SELECT ... (wie oben)" ab; da bekommst Du Informationen
über die Art, wie die Verknüpfung nun gehandhabt wird. Vorher solltest
Du eben diese 65000 und 150000 angezeigt bekommen, hinterher steht in
der zweiten Zeile dann eine 1, weil (optimalerweise) zu jedem Eintrag
aus 1 auch nur einer aus 2 in Betracht gezogen werden muß.


> Wie bekomme ich einen Index hin?

s.o. - geht auch direkt beim Tabellenerstellen, wenn Du das ADD INDEX
(...) oder ADD UNIQUE (...) an geeigneter Stelle im CREATE TABLE
unterbringst.


> Und wie muß ich das dann benutzen?

Das geht dann automatisch.


Thomas
--
Chancengleichheit besteht nicht darin, dass jeder einen Apfel pflücken
darf, sondern dass der Zwerg eine Leiter bekommt.
(Reinhard Turre, deutscher Theologe)

Re: zwei Tabellen

Mathias Fiedler schrieb:

> Damit ist mir leider nicht geholfen. Ich habs doch gesagt, die
> Servertabelle also tabelle2 steht fest. Der Vergleich bezieht sich imemr
> auf das gleiche Feld, also könte ich nachträglich einen Index einbauen,
> wenn das geht?

Natürlich geht das. Das Manual sagt dir, wie.

> Einen PK hat die Tabelle schon.

Die schon. Aber normalerweise joint man Tabellen über t1.PK_Feld =
t2.FK_Feld_mit_Index.

So wie deine CREATE TABLE-Statements aussehen könnte man raten:

temp_*.partner_id ist Primary Key, teilnehmer.confirm ist der Foreign Key.

> Die zu vergleichenden Felder
> können den gleichen Wert in mehreren Datensätzen haben, also nichts für PK
> oder unique.

In beiden Tabellen?

> Da bleibt mir blos noch der index. Bitte, kannst Du mir sagen,
> wie ich damit umgehe?

Indem man das Manual bezüglich Erstellung der Indizes konsultiert.

gruss, heli

Re: zwei Tabellen

Am Fri, 08 Sep 2006 08:04:46 +0200 schrieb Helmut Chang:

> Mathias Fiedler schrieb:
>
>> Damit ist mir leider nicht geholfen. Ich habs doch gesagt, die
>> Servertabelle also tabelle2 steht fest. Der Vergleich bezieht sich imemr
>> auf das gleiche Feld, also könte ich nachträglich einen Index einbauen,
>> wenn das geht?
>
> Natürlich geht das. Das Manual sagt dir, wie.
>
>> Einen PK hat die Tabelle schon.
>
> Die schon. Aber normalerweise joint man Tabellen über t1.PK_Feld =
> t2.FK_Feld_mit_Index.
>
> So wie deine CREATE TABLE-Statements aussehen könnte man raten:
>
> temp_*.partner_id ist Primary Key, teilnehmer.confirm ist der Foreign Key.
>
>> Die zu vergleichenden Felder
>> können den gleichen Wert in mehreren Datensätzen haben, also nichts für PK
>> oder unique.
>
> In beiden Tabellen?
>
>> Da bleibt mir blos noch der index. Bitte, kannst Du mir sagen,
>> wie ich damit umgehe?
>
> Indem man das Manual bezüglich Erstellung der Indizes konsultiert.
>
> gruss, heli

Na Spitze, ich sitze hier mit 5 Büchern vor meinem Computer und habe
mächtig Zeitdruck. Der Hinweis auf das Manual ist zwar richtig, nutzt mir
aber momentan nicht. Bis ich das durch hab, dauert einfach zu lange. Ich
hab ja vorher nicht gewusst, das ich jetzt damit konfrontiert werde. Es hat
sich halt aus der Aufgabenstellung so ergeben. Hätrte ich es gewußt, hätte
ich auch das Manual diesbezüglich eher studiert. Aber ich habe im
Normalfall nur mit kleineren Tabellen zu tun. Da benötige ich keine Indexe.
Kannst Du nicht mal ein Beispiel geben?

mfg

Mathias

Re: zwei Tabellen

Am Fri, 08 Sep 2006 07:59:10 +0200 schrieb Thomas Rachel:

> Mathias Fiedler wrote:
>
>>> Stimmt nicht. Das eine ist BIGINT, das andere INT. Läßt sich wohl
>>> vergleichen, ist aber mit Sicherheit teurer als ein Vergleich unter
>>> passenden Typen.
>>>
>>
>> Ds int kann ich bei der Erstellung der tabelle 1 noch ändern.
>
> Wie gesagt, ich weiß nicht, ob es einen großen Einfluß hat, aber besser
> ist es wohl schon.
>
>
>> Kannst Du m ir das mit den Indizies etwas genauer erklären? Laut Manual
>> lohnt sich das nur, wenn es um Texte oder mehrere Spalten geht.
>
> Dann hast Du entweder was falsch verstanden, oder es steht
> mißverständlich da.
>
> Indizes brauchst Du immer, wenn Du einen Spalteninhalt schnell finden
> willst. Sie sind, vereinfacht geesagt, eine Zuordnung zwischen Wert
> einer Spalte und Position der passenden Zeile(n) in der Tabelle. Sie
> sind als Baum aufgebaut, so daß auch bei einer Tabelle mit zigtausenden
> von Einträgen eine Suche nach einem bestimmten Wert nur wenige Zugriffe
> benötigt.
>
> Vergleiche mal in Deiner obigen Tabelle teilnehmer zeitmäßig die Suche
> nacheiner bestimmten id (sollte dank vorhandenem Index auf id sehr
> schnell gehen) mit einer Suche nach einem bestimmten confirm-Wert
> (dürfte relativ viel Zeit in Anspruch nehmen, da die gesamte Zabelle
> Zeile für Zeile nach dem Wert durchsucht werden muß).
>
> Mit anderen Worten, der Index hilft bei der Suche nach einem bestimmten
> Wert.
>
> Hast Du nun keine Indizes, mußt Du (bzw. der Server) eine Tabelle
> komplett durchlaufen und für jeden gefundenen Eintrag die 2. auch
> nochmal. Das dauert.
>
> Mit Indizes kann für jeden gefundenen Eintrag direkt der dazu passende
> Partner gefunden werden. Eine Tabelle muß (wenn nicht weiter
> eingeschränkt wird) dabei komplett durchlaufen werden, die andere wird
> dann quasi 1:1 abgebildet.
>
>
>>>> SELECT t.temp_ID FROM $tableName as t INNER JOIN $dbTable as db ON
>>>> t.$csvField = db.$dbField
>>>
>>> Äh, ok. Wie Helmut schon sagte: Was soll man damit anfangen? Die
>>> Variablenersetzung hättest Du sicher noch hinbekommen, oder?
>>>
>> SELECT t.temp_ID FROM tabelle1 as t INNER JOIN tabelle2 as db ON
>> t.tabelle1 = db.tabelle2
>>
>> Entschuldige bitte, aber was ist daran jetzt anders?
>
> Man versteht, wie das zu den oben angegebenen Tabellendefinitionen paßt
> und welche Felder gemeint sind. Das ist wesentlich. Und das was Du da
> geschrieben hast (ON t.tabelle1 = db.tabelle2) kann nicht sein, da
> gehören Feldnamen, keine Tabellennamen hin. Ich vermute mal, wie gesagt,
> es ist ON t.partner_id = db.confirm.
>

richtig war mein fehler
> Wesentlich ist, daß auf mindestens eines dieser Felder ein Index gesetzt
> ist.
>
> Wenn Du auf beide Felder ein Index setzt, kann der Server entscheiden,
> welche Tabelle er komplett durchläuft und welche er dann referenziert.
> Das kann auch nochmal einen Unterschied machen, bei Dir Faktor 2 - 65000
> zu 150000, wenn Du in Tabelle2 auch noch einen Index hinbekommst.
>
>
>> Weder die Feldnamen, die Anzahl der Felder noch die Anzahl der Einträge
>> ist vorher bekannt.
>
> Das ist insofern ungünstig, als Du dann beim Indexerstellen nochmal
> separat aufpassen mußt. Insbesondere mußt Du beim Erstellen der
> temporären Tabelle schon wissen, auf welche Spalte Du verknüpfen willst
> (oder eben direkt vorm Verknüpfen den Index hinzufügen).
>
>
>> Die Tabelle auf dem Server ist vorgegeben. Keine
>> Änderung möglich. Wenn ich per php und mysql die Tabelle nachträglich
>> indizieren kann, würde ich das tun. Aber wie?
>
> Was jetzt - keine Änderung möglich oder doch? Also falls doch, geht das
> (siehe auch Handbuch) mit
>
> ALTER TABLE xxx ADD INDEX (spaltenname)
>
> oder
>
> ALTER TABLE xxx ADD UNIQUE (spaltenname), wenn jeder Wert nur einmal
> vorkommen soll, kann und darf.
>
> Falls nicht, dauert Dein Durchlauf, wie gesagt, immerhin doppelt so lang,
> aber es geht schneller als jetzt.
>
Dauert so eine nachträgliche Indizierung nicht auch ziemlich lange? Die
ganze Tabelle muß doch auch erst durchgearbeitet werden, oder sehe ich das
falsch?

>>> UPDATE SET optionaler_Stornogrund=
>>> machen.
>
>> Klingt gut. Aber da mein Server bereits jetzt schon aussteigt, wäre das
>> wohl endgültig zu viel.
>
> Naja, jetzt teste erstmal, wie das SELECT-Verhalten mit den Indizes wird
> (Lerneffekt: Setze vor und nach dem Indexerstellen jeweils mal den
> Befehl "EXPLAIN SELECT ... (wie oben)" ab; da bekommst Du Informationen
> über die Art, wie die Verknüpfung nun gehandhabt wird. Vorher solltest
> Du eben diese 65000 und 150000 angezeigt bekommen, hinterher steht in
> der zweiten Zeile dann eine 1, weil (optimalerweise) zu jedem Eintrag
> aus 1 auch nur einer aus 2 in Betracht gezogen werden muß.
>
>
>> Wie bekomme ich einen Index hin?
>
> s.o. - geht auch direkt beim Tabellenerstellen, wenn Du das ADD INDEX
> (...) oder ADD UNIQUE (...) an geeigneter Stelle im CREATE TABLE
> unterbringst.
>



>> Und wie muß ich das dann benutzen?
>
> Das geht dann automatisch.
>
>
> Thomas

Danke, das war schon eine große Hilfe. Bin Dir wirklich sehr Dankbar dafür.
Das ist sehr wichtig für mich. Ich habe normalerweise mit diesen großen
Tabellen nichts zu tun.

Mathias

Re: zwei Tabellen

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: zwei Tabellen

Mathias Fiedler schrieb:
> Ach so. Noch ein Nachtrag. Weder die Spalte aus Tabelle 1 noch die Spalte
> aus Tabelle2 sind von Anfang an bekannt. Zuerst wird eine CSV Datei
> eingelesen und daraus eine Tabelle erstellt. Erst dann erfolgt die
> Auflsitung der Spaltennamen gegenüber den Spaltennenamen aus Tabelle 2.

Das liest sich jetzt so, als ob Eure Spalten überhaupt keine semantische
Bedeutung haben. Man vergleicht doch nicht wüst in der Gegend rum -
Nachnamen mit Postleitzahlen oder JPEGs mit dem Datum der letzten
Änderung. Vielleicht ist euer Datenmodell nicht ganz so sinnvoll?


> Erst jetzt wird festgelegt, welche Spalten verglichen werden. Ich kan also
> entweder erst jetzt den Index für die entsprechende Spalte hinzufügen,
> falls das geht, oder von Anfang alle int Felder mit einem Index belegen.
> Was ist da sinnvoller?

Ein Datenmodell, das die abzubildende Wirklichkeit möglichst gut
wiederspiegelt. Ein paar grundsätzliche Überlegungen, *was* man
sinnvollerweise mit was vergleichen kann und will. Und dann die
geeigneten Indizes auf diese Felder.

Re: zwei Tabellen

Mathias Fiedler wrote:

[snip]

Bitte nur soviel zitieren, wie zum schnellen,zusammenhängenden Verständnis
notwendig ist. Danke.


>> Was jetzt - keine Änderung möglich oder doch? Also falls doch, geht das
>> (siehe auch Handbuch) mit
>>
>> ALTER TABLE xxx ADD INDEX (spaltenname)
>>
>> oder
>>
>> ALTER TABLE xxx ADD UNIQUE (spaltenname), wenn jeder Wert nur einmal
>> vorkommen soll, kann und darf.
>>
>> Falls nicht, dauert Dein Durchlauf, wie gesagt, immerhin doppelt so lang,
>> aber es geht schneller als jetzt.
>>
> Dauert so eine nachträgliche Indizierung nicht auch ziemlich lange? Die
> ganze Tabelle muß doch auch erst durchgearbeitet werden, oder sehe ich das
> falsch?

Ja, aber nur 1x. Ich schätze mal 10-15 Sekunden.


> Danke, das war schon eine große Hilfe. Bin Dir wirklich sehr Dankbar
> dafür. Das ist sehr wichtig für mich. Ich habe normalerweise mit diesen
> großen Tabellen nichts zu tun.

150000 Zeilen sind nicht viel.


Thomas
--
Lebe jeden Tag so, als wäre es Dein letzter!
Irgendwann wird es die Wahrheit sein.

Re: zwei Tabellen

Hallo,

ich habe jetzt die Tabelle 1 mit Index erstellen lassen

CREATE TABLE IF NOT EXISTS temp_1157697593 (temp_ID bigint(20) NOT NULL
auto_increment,partner_id int(6) NOT NULL default '0',fingerprint longtext
NULL,zeit longtext NULL,opts longtext NULL,kauf_id longtext NULL,kd_nr
longtext NULL,status int(6) NOT NULL default '0',rate int(6) NOT NULL
default '0',optionaler_stornogrund longtext NULL,PRIMARY KEY (temp_ID),
INDEX(partner_id,status,rate)) TYPE=MyISAM AUTO_INCREMENT=1


Dann habe ich die Tabelle 2 erst mal "per Hand" (phpMyAdmin) auf meinem
Testserver für die Spalte confirm mit einem Index versehen.

Ich vergleiche nun die Spalten partner_ID int(6) mit confirm int(6).

Tabelle 2

CREATE TABLE IF NOT EXISTS `teilnehmer` (
`id` bigint(20) NOT NULL auto_increment,
`gesperrt` tinyint(4) NOT NULL default '0',
`confirmtime` tinytext,
`confirm` int(6) default NULL,
`spiel` tinytext NOT NULL,
`agb` tinytext NOT NULL,
`tstamp` tinytext NOT NULL,
`IP` tinytext NOT NULL,
`sxref` text,
`referer` text,
`uid` text,
`anrede` text,
`vorname` text,
`nachname` text,
`tag` text,
`monat` text,
`jahr` text,
`strasse` text,
`nr` text,
`plz` text,
`stadt` text,
`land` text,
`email` text NOT NULL,
`vorwahl` text,
`telefon` text,
`mobilvorwahl` text,
`mobiltelefon` text,
`PrWahl` text NOT NULL,
`code` tinytext,
`optionen` text,
`returnvalue` text,
PRIMARY KEY (`id`),
KEY `email` (`email`(50)),
KEY `confirm` (`confirm`)
) TYPE=MyISAM AUTO_INCREMENT=1;


Dazu verwende ich

SELECT t.temp_ID FROM temp_1157697593 as t Left JOIN teilnehmer as db ON
t.partner_id = db.confirm

Das geht jetzt wirklich schnell. Danke nochmal.

Mathias

Re: zwei Tabellen

Am Fri, 08 Sep 2006 09:05:52 +0200 schrieb Christian Kirsch:

> Mathias Fiedler schrieb:
>> Ach so. Noch ein Nachtrag. Weder die Spalte aus Tabelle 1 noch die Spalte
>> aus Tabelle2 sind von Anfang an bekannt. Zuerst wird eine CSV Datei
>> eingelesen und daraus eine Tabelle erstellt. Erst dann erfolgt die
>> Auflsitung der Spaltennamen gegenüber den Spaltennenamen aus Tabelle 2.
>
> Das liest sich jetzt so, als ob Eure Spalten überhaupt keine semantische
> Bedeutung haben. Man vergleicht doch nicht wüst in der Gegend rum -
> Nachnamen mit Postleitzahlen oder JPEGs mit dem Datum der letzten
> Änderung. Vielleicht ist euer Datenmodell nicht ganz so sinnvoll?
>
>
>> Erst jetzt wird festgelegt, welche Spalten verglichen werden. Ich kan also
>> entweder erst jetzt den Index für die entsprechende Spalte hinzufügen,
>> falls das geht, oder von Anfang alle int Felder mit einem Index belegen.
>> Was ist da sinnvoller?
>
> Ein Datenmodell, das die abzubildende Wirklichkeit möglichst gut
> wiederspiegelt. Ein paar grundsätzliche Überlegungen, *was* man
> sinnvollerweise mit was vergleichen kann und will. Und dann die
> geeigneten Indizes auf diese Felder.

Ich dachte eigentlich ich hätte das klar gesagt. Ich habe eine Tabelle auf
dem Server, die steht fest. Mit der Zeit kann sich diese Tabelle aber auch
noch erweitern, dann kämen also neue Felder hinzu. Außerdem enthält die
Tabelle mehrere int Felder, die für bestimmt Zustände stehen.

Die zweite Tabelle wird aus einer CSV Datei generiert. Die bekomme ich von
Zulieferern. Auch diese können sich ändern. Jeder hat seine eigene
Datenstruktur. Ich muß jetzt eben unbekannte CSV Daten in eine Tabelle
schreiben und darauf jeweils 1 Feld mit einem feld der Servertabelle
vergleichen. Da kann man nicht schön planen. Da muß man nehmen, was man
kriegt. Also lass bitte diese altklugen Hinweise.

Mathias

Re: zwei Tabellen

Am Fri, 8 Sep 2006 08:53:48 +0200 schrieb Andreas Kretschmer:

> begin Mathias Fiedler schrieb:
>> Na Spitze, ich sitze hier mit 5 Büchern vor meinem Computer und habe
>> mächtig Zeitdruck. Der Hinweis auf das Manual ist zwar richtig, nutzt mir
>> aber momentan nicht. Bis ich das durch hab, dauert einfach zu lange. Ich
>
> Klarer Fall von von Vergabe einer Aufgabe an eine falsche Person.
> Empfehle Deinem Chef, Dich zu entlassen und einen mit Ahnung
> einzustellen.
>
> Sorry, aber mehr fällt mir dazu nicht ein.
>
Danke für die Blumen, Du mich auch !
>
>> hab ja vorher nicht gewusst, das ich jetzt damit konfrontiert werde. Es hat
>> sich halt aus der Aufgabenstellung so ergeben. Hätrte ich es gewußt, hätte
>> ich auch das Manual diesbezüglich eher studiert. Aber ich habe im
>> Normalfall nur mit kleineren Tabellen zu tun. Da benötige ich keine Indexe.
>> Kannst Du nicht mal ein Beispiel geben?
>
> Du bist nicht imstande, in der Doku oder über Google Basiswissen zu
> Indexen zu finden? OMFG!
>
Ich bin imstande dazu und habe es auch geschafft. Es war keine Schulung
nötig, sondern nur ein kleiner Anstoss. Die Antwort von Thomas war dazu
genau richtig. Ich bin nunmal kein mysql Experte. Aber das kommt schon
noch. Nur mit der Hilfe wie von Dir oder von Christian (auch so ein Spezi)
werden wir unwissenden wohl alle dumm sterben müssen.
Es tut mir leid, wenn ich seine Hoheit den Datenbankkönig verärgert habe,
er ist warscheinlich schon mit dem vollen Wissen auf die Welt gekommen.
Verneigung Verneigung

und Tschüß

Re: zwei Tabellen

Mathias Fiedler wrote:

> Ich kan also entweder erst jetzt den Index für die entsprechende Spalte
> hinzufügen, falls das geht, oder von Anfang alle int Felder mit einem
> Index belegen.
> Was ist da sinnvoller?

Wenn der Speicherplatz da ist, würde ich die Indzes einmal erstellen und
dann bestehen lassen.


Thomas
--
Auch in dnq hat man gelegentlich das Gefühl, daß news.cis.dfn.de
mittlerweile 42 abgelöst hat. (Oliver »Socke« Ding in dang)

Re: zwei Tabellen

Mathias Fiedler wrote:

> Na Spitze, ich sitze hier mit 5 Büchern vor meinem Computer und habe
> mächtig Zeitdruck.

http://dev.mysql.com/ soltle eigentlich ausreichen.


> Der Hinweis auf das Manual ist zwar richtig, nutzt mir aber momentan
> nicht. Bis ich das durch hab, dauert einfach zu lange.

Es reicht aus, die relevanten Stellen zu lesen.


> Kannst Du nicht mal ein Beispiel geben?

Siehe Parallelposting.


Thomas
--
Hier hätte ich ja gerne eine Signatur hingesetzt. Aber erstens ist mir kein
sinnvoller Inhalt eingefallen, für den es sich gelohnt hätte, einen eigenen
Eintrag in die Signaturdatei aufzunehmen, und zum anderen sind Signaturen ja
auch meistens völlig überflüssig und nehmen nur unnötig Platz weg.

Re: zwei Tabellen

Mathias Fiedler wrote:

> CREATE TABLE IF NOT EXISTS temp_1157697593

Kleiner Hinweis noch: Du schreibst, daß die Tabellenspalten dynamisch
generiert werden. Wenn nun der jeweilige Spaltenname bereits existiert,
aber eine komplett andere Struktur hat, fliegt Dir hiermit die Anwendung um
die Ohren - und zwar später irgendwann. Wenn Du hier das IF NOT EXISTS
wegläßt, bekommst Du die Fehlermeldung frühzeitig, bevor Du irrtümlich
irgendwelche Daten irgendwo einfügst, wo sie gar nicht hingehören.

Sind diese vielen longtext wirklich notwendig? Falls sichergestellt werden
kann,daß die Länge der Einträge < 256 ist, arbeitest Du besser mit varchar.

> INDEX(partner_id,status,rate)

Kombinierte Indizes machen nur bei kombinierten Abfragen / JOINS Sinn.
Besser separate Indizes anlegen.


> SELECT t.temp_ID FROM temp_1157697593 as t Left JOIN teilnehmer as db ON
> t.partner_id = db.confirm
>
> Das geht jetzt wirklich schnell. Danke nochmal.

Bitte. Und jetzt könntest Du Dir überlegen, ob der erwähnte UPDATE-Befehl
evtl. sinnvoll wäre...


Thomas
--
Hier hätte ich ja gerne eine Signatur hingesetzt. Aber erstens ist mir kein
sinnvoller Inhalt eingefallen, für den es sich gelohnt hätte, einen eigenen
Eintrag in die Signaturdatei aufzunehmen, und zum anderen sind Signaturen ja
auch meistens völlig überflüssig und nehmen nur unnötig Platz weg.

Re: zwei Tabellen

Mathias Fiedler meinte:

>> begin Mathias Fiedler schrieb:
>>> Na Spitze, ich sitze hier mit 5 Büchern vor meinem Computer und habe
>>> mächtig Zeitdruck. Der Hinweis auf das Manual ist zwar richtig, nutzt mir
>>> aber momentan nicht. Bis ich das durch hab, dauert einfach zu lange. Ich

>> Klarer Fall von von Vergabe einer Aufgabe an eine falsche Person.
>> Empfehle Deinem Chef, Dich zu entlassen und einen mit Ahnung
>> einzustellen.
>>
>> Sorry, aber mehr fällt mir dazu nicht ein.

ACK.

> Danke für die Blumen, Du mich auch !

Tut's weh, die Wahrheit? Immerhin: Du bist unter Zeitdruck, brauchst
Hilfe - da ist rumsudern und pöbeln sicher die beste Methode weiter zu
kommen...

>> Du bist nicht imstande, in der Doku oder über Google Basiswissen zu
>> Indexen zu finden? OMFG!
>>
> Ich bin imstande dazu und habe es auch geschafft. Es war keine Schulung
> nötig, sondern nur ein kleiner Anstoss. Die Antwort von Thomas war dazu
> genau richtig. Ich bin nunmal kein mysql Experte.

Und kein PHP-Experte, wenn ich mir deine Anfragen in d.c.l.p.m so
anschaue. Die besten Voraussetzungen also, um Aufträge anzunehmen und
dann "unter Zeitdruck" zu kommen.

> Aber das kommt schon
> noch. Nur mit der Hilfe wie von Dir oder von Christian (auch so ein Spezi)
> werden wir unwissenden wohl alle dumm sterben müssen.

Tja, nicht nur in dclpm wirst du gegenüber Regulars pampig, sonder auch
hier. Erfolgversprechend...

> Es tut mir leid, wenn ich seine Hoheit den Datenbankkönig verärgert habe,
> er ist warscheinlich schon mit dem vollen Wissen auf die Welt gekommen.
> Verneigung Verneigung

Eigentlich wär's Zeit für's Killfile, aber dein zukünftiges
Nichtweiterkommen hat evtl. doch einen gewissen Unterhaltungswert.

Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: zwei Tabellen

Andreas Kretschmer schrieb:

> begin Mathias Fiedler schrieb:

Der Witz ist alt und mittlerweile ziemlich langweilig.

> Klarer Fall von von Vergabe einer Aufgabe an eine falsche Person.
> Empfehle Deinem Chef, Dich zu entlassen und einen mit Ahnung
> einzustellen.
>
> Sorry, aber mehr fällt mir dazu nicht ein.

Dann wäre es besser gewesen, die Klappe zu halten.

> Du bist nicht imstande, in der Doku oder über Google Basiswissen zu
> Indexen zu finden? OMFG!

Und Du scheinst nicht imstande zu sein, Anfängern bei Problemen
sinnvolle Hilfestellung zu geben. Traurig ist das. Sehr traurig.

Sorry, aber mehr fällt mir dazu nicht ein.

Gruß. Claus

Re: zwei Tabellen

Am Fri, 08 Sep 2006 09:56:14 +0200 schrieb Gregor Kofler:

> Mathias Fiedler meinte:
>
>>> begin Mathias Fiedler schrieb:
>>>> Na Spitze, ich sitze hier mit 5 Büchern vor meinem Computer und habe
>>>> mächtig Zeitdruck. Der Hinweis auf das Manual ist zwar richtig, nutzt mir
>>>> aber momentan nicht. Bis ich das durch hab, dauert einfach zu lange. Ich
>
>>> Klarer Fall von von Vergabe einer Aufgabe an eine falsche Person.
>>> Empfehle Deinem Chef, Dich zu entlassen und einen mit Ahnung
>>> einzustellen.
>>>
>>> Sorry, aber mehr fällt mir dazu nicht ein.
>
> ACK.
>
>> Danke für die Blumen, Du mich auch !
>
> Tut's weh, die Wahrheit? Immerhin: Du bist unter Zeitdruck, brauchst
> Hilfe - da ist rumsudern und pöbeln sicher die beste Methode weiter zu
> kommen...
>
>>> Du bist nicht imstande, in der Doku oder über Google Basiswissen zu
>>> Indexen zu finden? OMFG!
>>>
>> Ich bin imstande dazu und habe es auch geschafft. Es war keine Schulung
>> nötig, sondern nur ein kleiner Anstoss. Die Antwort von Thomas war dazu
>> genau richtig. Ich bin nunmal kein mysql Experte.
>
> Und kein PHP-Experte, wenn ich mir deine Anfragen in d.c.l.p.m so
> anschaue. Die besten Voraussetzungen also, um Aufträge anzunehmen und
> dann "unter Zeitdruck" zu kommen.
>
>> Aber das kommt schon
>> noch. Nur mit der Hilfe wie von Dir oder von Christian (auch so ein Spezi)
>> werden wir unwissenden wohl alle dumm sterben müssen.
>
> Tja, nicht nur in dclpm wirst du gegenüber Regulars pampig, sonder auch
> hier. Erfolgversprechend...
>
>> Es tut mir leid, wenn ich seine Hoheit den Datenbankkönig verärgert habe,
>> er ist warscheinlich schon mit dem vollen Wissen auf die Welt gekommen.
>> Verneigung Verneigung
>
> Eigentlich wär's Zeit für's Killfile, aber dein zukünftiges
> Nichtweiterkommen hat evtl. doch einen gewissen Unterhaltungswert.
>
> Gregor

Na dann bleib ich euch ja noch eine Weile erhalten.

Mathias

Re: zwei Tabellen

Am Fri, 08 Sep 2006 10:09:11 +0200 schrieb Claus Reibenstein:

> Andreas Kretschmer schrieb:
>
>> begin Mathias Fiedler schrieb:
>
> Der Witz ist alt und mittlerweile ziemlich langweilig.
>
>> Klarer Fall von von Vergabe einer Aufgabe an eine falsche Person.
>> Empfehle Deinem Chef, Dich zu entlassen und einen mit Ahnung
>> einzustellen.
>>
>> Sorry, aber mehr fällt mir dazu nicht ein.
>
> Dann wäre es besser gewesen, die Klappe zu halten.
>
>> Du bist nicht imstande, in der Doku oder über Google Basiswissen zu
>> Indexen zu finden? OMFG!
>
> Und Du scheinst nicht imstande zu sein, Anfängern bei Problemen
> sinnvolle Hilfestellung zu geben. Traurig ist das. Sehr traurig.
>
> Sorry, aber mehr fällt mir dazu nicht ein.
>
> Gruß. Claus

Danke. Endlich mal einer, der einen Nichtexperten versteht. Ich mach das
schon eine Weile, aber wie gesagt, bisher eben nicht in dieser Größe. Ich
weiß das Mysql auch mit mehreren Millionen DS umgehen kann. Man muß nur
wissen wie. Ich versuche so viel wie möglich aus den Büchern und Manuals zu
holen. Aber manchmal ist ein kurzer Anstoß eines Kenners der Materie
hilfreicher als 1 Woche Studium.

Nochmals danke.

Mathias

Re: zwei Tabellen

Am Fri, 08 Sep 2006 09:46:37 +0200 schrieb Thomas Rachel:

> Mathias Fiedler wrote:
>
>> Na Spitze, ich sitze hier mit 5 Büchern vor meinem Computer und habe
>> mächtig Zeitdruck.
>
> http://dev.mysql.com/ soltle eigentlich ausreichen.
>
>
>> Der Hinweis auf das Manual ist zwar richtig, nutzt mir aber momentan
>> nicht. Bis ich das durch hab, dauert einfach zu lange.
>
> Es reicht aus, die relevanten Stellen zu lesen.
>
Du hast Recht und das hab ich auch gemacht.
>
>> Kannst Du nicht mal ein Beispiel geben?
>
> Siehe Parallelposting.
>
>
> Thomas

Re: zwei Tabellen

Am Fri, 08 Sep 2006 09:52:29 +0200 schrieb Thomas Rachel:

> Mathias Fiedler wrote:
>
>> CREATE TABLE IF NOT EXISTS temp_1157697593
>
> Kleiner Hinweis noch: Du schreibst, daß die Tabellenspalten dynamisch
> generiert werden. Wenn nun der jeweilige Spaltenname bereits existiert,
> aber eine komplett andere Struktur hat, fliegt Dir hiermit die Anwendung um
> die Ohren - und zwar später irgendwann. Wenn Du hier das IF NOT EXISTS
> wegläßt, bekommst Du die Fehlermeldung frühzeitig, bevor Du irrtümlich
> irgendwelche Daten irgendwo einfügst, wo sie gar nicht hingehören.
>
> Sind diese vielen longtext wirklich notwendig? Falls sichergestellt werden
> kann,daß die Länge der Einträge < 256 ist, arbeitest Du besser mit varchar.
>
>> INDEX(partner_id,status,rate)
>
> Kombinierte Indizes machen nur bei kombinierten Abfragen / JOINS Sinn.
> Besser separate Indizes anlegen.
>
>
>> SELECT t.temp_ID FROM temp_1157697593 as t Left JOIN teilnehmer as db ON
>> t.partner_id = db.confirm
>>
>> Das geht jetzt wirklich schnell. Danke nochmal.
>
> Bitte. Und jetzt könntest Du Dir überlegen, ob der erwähnte UPDATE-Befehl
> evtl. sinnvoll wäre...
>
Es ist auf jeden Fall sinnvoll und ich werde es auch einbringen.

Mathias

Re: zwei Tabellen

Thomas Rachel schrieb:

> Mathias Fiedler wrote:
>
>> Der Hinweis auf das Manual ist zwar richtig, nutzt mir aber momentan
>> nicht. Bis ich das durch hab, dauert einfach zu lange.
>
> Es reicht aus, die relevanten Stellen zu lesen.

Und welche sind das? Ich weiß es, Du anscheinend auch, Mathias aber
nicht. Warum nennst Du sie ihm nicht?

Ich stelle mit Bedauern fest, dass hier hin dieser NG ein ziemlich
arroganter Ton gegenüber Anfängern herrscht. Offensichtlich haben einige
Herrschaften hier schon vergessen, dass sie auch mal Anfänger waren,
oder sind mittlerweise schon zu abgehoben, um sich in die Probleme eines
Anfängern reinzudenken. Schade. Sehr schade.

Aber zum Glück gibt es auch noch vereinzelte Personen, die willens und
auch fähig sind, sinnvolle Hinweise zu geben. Davon sollte sich die
"Elite" dieser Gruppe mal ein paar dicke Scheiben abschneiden.

Gruß. Claus

Re: zwei Tabellen

Claus Reibenstein schrieb:
> Andreas Kretschmer schrieb:

....

> Und Du scheinst nicht imstande zu sein, Anfängern bei Problemen
> sinnvolle Hilfestellung zu geben.
>

Und wie erklärst Du Dir (oder uns), dass jemand vier Jahre lang
Anfänger bleibt? Denn das war der gute Mathias ja schon 2002:

http://groups.google.com/group/de.comp.datenbanken.mysql/bro wse_frm/thread/3e389da5a0de3e6c/91528b472e2020a3?lnk=st&q=&r num=7&hl=de#91528b472e2020a3

Ich tippe da eher auf Lernresistenz.

Re: zwei Tabellen

Christian Kirsch schrieb:

> Und wie erklärst Du Dir (oder uns), dass jemand vier Jahre lang
> Anfänger bleibt? Denn das war der gute Mathias ja schon 2002:
>
> http://groups.google.com/group/de.comp.datenbanken.mysql/bro wse_frm/thread/3e389da5a0de3e6c/91528b472e2020a3?lnk=st&q=&r num=7&hl=de#91528b472e2020a3

Und was hat dieses Problem mit dem jetzigen Thema zu tun?

Gruß. Claus

Re: zwei Tabellen

Claus Reibenstein wrote:


>> Es reicht aus, die relevanten Stellen zu lesen.
>
> Und welche sind das? Ich weiß es, Du anscheinend auch, Mathias aber
> nicht. Warum nennst Du sie ihm nicht?

Weil ich es nicht auswendig weiß, und nachzuschauen fehlt mir manchmal die
Zeit. Aber das Inhaltsverzeichnis gibt AFAIR direkt an, welche Kapitel für
das Thema "Indizes" relevant ist - was er sich, wenn er nochmal Zeit hat,
ja auch anschauen kann.

Das akute Problem scheint ja (erstmal) gelöst zu sein, nachdem ich ihn in
einem anderen Posting mit ein paar Tips versorgt habe.


> Ich stelle mit Bedauern fest, dass hier hin dieser NG ein ziemlich
> arroganter Ton gegenüber Anfängern herrscht.

Da muß ich Dir leider recht geben. Aber manchmal ist einem selbst nicht
immer bewußt, daß das, was man da schreibt, evtl. falsch rüberkommen kann.


Thomas
--
Windows 98 - from the people who brought you EDLIN

Re: zwei Tabellen

Claus Reibenstein schrieb:
> Thomas Rachel schrieb:
>
>> Mathias Fiedler wrote:
>>
>>> Der Hinweis auf das Manual ist zwar richtig, nutzt mir aber momentan
>>> nicht. Bis ich das durch hab, dauert einfach zu lange.
>> Es reicht aus, die relevanten Stellen zu lesen.
>
> Und welche sind das? Ich weiß es, Du anscheinend auch, Mathias aber
> nicht. Warum nennst Du sie ihm nicht?
>

Warum beschäftigt sich jemand vier Jahre lang mit MySQL und schafft es
in dieser Zeit nicht, *einmal* das Handbuch zu lesen? Warum darf so
jemand Anwendungen entwickeln? Fragen über Fragen.

> Ich stelle mit Bedauern fest, dass hier hin dieser NG ein ziemlich
> arroganter Ton gegenüber Anfängern herrscht.

Flasche Voraussetzung, flasche Schlussfolgerung. Der Betreffende *ist*
kein Anfänger. Und Handbuch-Lektüre gehört überall im Leben dazu - bei
Waschmaschinen ebenso wie bei MySQL.

> Offensichtlich haben einige
> Herrschaften hier schon vergessen, dass sie auch mal Anfänger waren,
> oder sind mittlerweise schon zu abgehoben, um sich in die Probleme eines
> Anfängern reinzudenken. Schade. Sehr schade.

Das hat damit nichts zu tun. Wenn ich Anfänger in irgendwas bin, dann
mache ich mir zumindest die Mühe, einmal die (in diesem Fall sogar
gute und vollständige!) Dokumentation zu lesen. Das ist eine
Voraussetzung für die *ernsthafte* Beschäftigung mit dem Produkt. Und
um die geht es doch vorgeblich in diesem Fall, oder?

Der Betreffende ist meiner Meinung nach einfach nur faul oder dumm,
wenn er in vier Jahren nicht in der Lage ist (und sei es nur durch
Verfolgen der Postings in dieser Newsgroup) zu verstehen, wozu Indizes
gut sind, wie man SELECTs mit Join formuliert usw.

BTW: Anstatt rumzujammern, wie böse die andern sind - warum verrätst
*Du* ihm denn nicht, wo er das geheimnisvolle CREATE INDEX finden
könnte - in einem Manual, das man einfach DURCHSUCHEN kann, und zwar
im Web?

C.

Re: zwei Tabellen

Christian Kirsch schrieb:

> Warum beschäftigt sich jemand vier Jahre lang mit MySQL und schafft es
> in dieser Zeit nicht, *einmal* das Handbuch zu lesen? Warum darf so
> jemand Anwendungen entwickeln? Fragen über Fragen.

Wieso "darf"? Wenn ich ihn richtig verstanden habe, wurde er dazu
verdonnert. Dass er unter diesen Umständen keine große Lust hat, sich
damit weiter zu beschäftigen als unbedingt nötig, ist doch wohl
verständlich.

> Flasche Voraussetzung, flasche Schlussfolgerung. Der Betreffende *ist*
> kein Anfänger. Und Handbuch-Lektüre gehört überall im Leben dazu - bei
> Waschmaschinen ebenso wie bei MySQL.

Ich glaube kaum, dass sich die Dokumentation einer Waschmaschine mit der
von MySQL vergleichen lässt.

> Das hat damit nichts zu tun. Wenn ich Anfänger in irgendwas bin, dann
> mache ich mir zumindest die Mühe, einmal die (in diesem Fall sogar
> gute und vollständige!) Dokumentation zu lesen. Das ist eine
> Voraussetzung für die *ernsthafte* Beschäftigung mit dem Produkt. Und
> um die geht es doch vorgeblich in diesem Fall, oder?

Du liest also _wirklich_ erst 1000 Seiten Manual durch, bevor Du Dich an
etwas Neues heranwagst? Ich lese mir ein paar einleitende Kapitel durch
und mache mich dann möglichst bald an die Arbeit. Der Rest kommt im
Laufe der Zeit dazu. Learning by doing.

> Der Betreffende ist meiner Meinung nach einfach nur faul oder dumm,
> wenn er in vier Jahren nicht in der Lage ist (und sei es nur durch
> Verfolgen der Postings in dieser Newsgroup) zu verstehen, wozu Indizes
> gut sind, wie man SELECTs mit Join formuliert usw.

Die Frage ist, ob er so etwas bisher gebraucht hat. Da er bislang
offensichtlich nur mit kleinen Tabellen gearbeitet hat, bestand wohl
keine Notwendigket. Möglicherweise hat er sich nur am Rande mit der
Thematik auseinandersetzen müssen.

Mit Faulheit oder Dummheit muss das nichts zu tun haben.

> BTW: Anstatt rumzujammern, wie böse die andern sind - warum verrätst
> *Du* ihm denn nicht, wo er das geheimnisvolle CREATE INDEX finden
> könnte - in einem Manual, das man einfach DURCHSUCHEN kann, und zwar
> im Web?

Weil ich Threads erst lese, bevor ich etwas dazu schreibe. Weil ich
nicht Dinge wiederhole, die schon gesagt wurden. Es sei denn, der
Angesprochene hat etwas nicht verstanden. Dann versuche ich eventuell,
es noch einmal anders zu erklären. War in diesem Fall aber nicht notwendig.

Zum Suchen muss man auch erst einmal wissen, wonach man suchen muss.
Wenn einem die Stichworte fehlen, nützen einem die besten Suchmaschinen
nichts.

Gruß. Claus

Re: zwei Tabellen

Claus Reibenstein schrieb:
> Christian Kirsch schrieb:
>
>> Warum beschäftigt sich jemand vier Jahre lang mit MySQL und schafft es
>> in dieser Zeit nicht, *einmal* das Handbuch zu lesen? Warum darf so
>> jemand Anwendungen entwickeln? Fragen über Fragen.
>
> Wieso "darf"? Wenn ich ihn richtig verstanden habe, wurde er dazu
> verdonnert. Dass er unter diesen Umständen keine große Lust hat, sich
> damit weiter zu beschäftigen als unbedingt nötig, ist doch wohl
> verständlich.
>

Mag sein. Aber genauso verständlich ist es, dass andere Leute keine
Lust haben, unbezahlt die Arbeit zu erledigen, für die er bezahlt wird.

>> Flasche Voraussetzung, flasche Schlussfolgerung. Der Betreffende *ist*
>> kein Anfänger. Und Handbuch-Lektüre gehört überall im Leben dazu - bei
>> Waschmaschinen ebenso wie bei MySQL.
>
> Ich glaube kaum, dass sich die Dokumentation einer Waschmaschine mit der
> von MySQL vergleichen lässt.

Die von MySQL ist im Zweifel detaillierter, stimmt. Oder was wolltest
Du sagen?

>
>> Das hat damit nichts zu tun. Wenn ich Anfänger in irgendwas bin, dann
>> mache ich mir zumindest die Mühe, einmal die (in diesem Fall sogar
>> gute und vollständige!) Dokumentation zu lesen. Das ist eine
>> Voraussetzung für die *ernsthafte* Beschäftigung mit dem Produkt. Und
>> um die geht es doch vorgeblich in diesem Fall, oder?
>
> Du liest also _wirklich_ erst 1000 Seiten Manual durch, bevor Du Dich an
> etwas Neues heranwagst?

Ich versuche es - und vor allem versuche ich, ein Problem durch Lesen
und Nachdenken zu lösen, bevor ich es in die Welt hineinposaune. Denn
es ist erstmal *mein* Problem. Erst wenn ich mir einigermaßen sicher
sein kann, dass ich trotz intensiven Suchens und Nachdenkens keine
Lösung gefunden habe, frage ich laut in der Gegend rum.

> Ich lese mir ein paar einleitende Kapitel durch
> und mache mich dann möglichst bald an die Arbeit. Der Rest kommt im
> Laufe der Zeit dazu. Learning by doing.
>

Auch gut. Aber hier ging's ja um "Asking instead of learning, reading
or thinking". Das ist ein ganz anderes Konzept.

>> Der Betreffende ist meiner Meinung nach einfach nur faul oder dumm,
>> wenn er in vier Jahren nicht in der Lage ist (und sei es nur durch
>> Verfolgen der Postings in dieser Newsgroup) zu verstehen, wozu Indizes
>> gut sind, wie man SELECTs mit Join formuliert usw.
>
> Die Frage ist, ob er so etwas bisher gebraucht hat. Da er bislang
> offensichtlich nur mit kleinen Tabellen gearbeitet hat, bestand wohl
> keine Notwendigket. Möglicherweise hat er sich nur am Rande mit der
> Thematik auseinandersetzen müssen.

Zumindest JOINs kennt er doch seit ein paar Monaten:

http://groups.google.com/group/de.comp.datenbanken.mysql/bro wse_frm/thread/1f33f247e693b4bf/5bb3f16f428dd376?lnk=st&q=&r num=9&hl=de#5bb3f16f428dd376

Und wenn man sich "mit einer Thematik auseinandersetzen muss" - tut
man dass dann dadurch, dass man Dinge in die Gegend fragt, die sowohl
in dieser Gegend (nämlich d.c.d.m) als auch in Standardtexten zu
(My)SQL ad nauseum breitgetreten wurden - nämlich die Benutzung von
Indizes zur Beschleunigung von Abfragen?

>
> Mit Faulheit oder Dummheit muss das nichts zu tun haben.
>

Sondern? Man könnte google.groups benutzen und fände haufenweise
Erklärungen zu Indizes und JOINs. Oder möchtest Du andeuten, dass er
die Suchmöglichkeiten des Netzes nicht kennt?

>
> Zum Suchen muss man auch erst einmal wissen, wonach man suchen muss.
> Wenn einem die Stichworte fehlen, nützen einem die besten Suchmaschinen
> nichts.

Das Wort "Index" erwähnte der Betreffende selbst in seinem Posting.
Sowas kann man sehr wohl in die Suche der Online-Dokumentation
füttern. Wenn man denn will.

Re: zwei Tabellen

Claus Reibenstein wrote:
> Christian Kirsch schrieb:
>
>> Warum beschäftigt sich jemand vier Jahre lang mit MySQL und schafft es
>> in dieser Zeit nicht, *einmal* das Handbuch zu lesen? Warum darf so
>> jemand Anwendungen entwickeln? Fragen über Fragen.
>
> Wieso "darf"? Wenn ich ihn richtig verstanden habe, wurde er dazu
> verdonnert. Dass er unter diesen Umständen keine große Lust hat, sich
> damit weiter zu beschäftigen als unbedingt nötig, ist doch wohl
> verständlich.

Nein. Wenn er zu einer Arbeit "verdonnert" wird, die offensichtlich
seinen geistigen Horizon überschreitet, dann hat er zwei Möglichkeiten:

1. er lehnt ab
2. er setzt sich hin und *lernt* das

>> Der Betreffende ist meiner Meinung nach einfach nur faul oder dumm,
>> wenn er in vier Jahren nicht in der Lage ist (und sei es nur durch
>> Verfolgen der Postings in dieser Newsgroup) zu verstehen, wozu Indizes
>> gut sind, wie man SELECTs mit Join formuliert usw.
>
> Die Frage ist, ob er so etwas bisher gebraucht hat. Da er bislang
> offensichtlich nur mit kleinen Tabellen gearbeitet hat, bestand wohl
> keine Notwendigket. Möglicherweise hat er sich nur am Rande mit der
> Thematik auseinandersetzen müssen.

Dem OP fehlen wirklich grundlegende Kenntnisse, wie z.B. die, was ein
Index ist und wann man sowas braucht. Das ist noch nicht mal MySQL-
spezifisch, das ist elementares Grundlagenwissen. So jemanden würde ich
nie im Leben an einer Datenbank-Anwendung schreiben lassen.

> Mit Faulheit oder Dummheit muss das nichts zu tun haben.

Wenn der OP Hinweise auf "mach dich schlau" ableht, dann ist das sehr
wohl Faulheit. Wenn er mit Fragen wartet, bis "es brennt", dann ist das
sehr wohl Dummheit. Wenn er eine Aufgabe annimmt, die schon brandeilig
ist und die seine Fähigkeiten übersteigt, dann ist das auch Dummheit.

>> BTW: Anstatt rumzujammern, wie böse die andern sind - warum verrätst
>> *Du* ihm denn nicht, wo er das geheimnisvolle CREATE INDEX finden
>> könnte - in einem Manual, das man einfach DURCHSUCHEN kann, und zwar
>> im Web?
>
> Weil ich Threads erst lese, bevor ich etwas dazu schreibe. Weil ich
> nicht Dinge wiederhole, die schon gesagt wurden. Es sei denn, der
> Angesprochene hat etwas nicht verstanden. Dann versuche ich eventuell,
> es noch einmal anders zu erklären. War in diesem Fall aber nicht notwendig.
>
> Zum Suchen muss man auch erst einmal wissen, wonach man suchen muss.
> Wenn einem die Stichworte fehlen, nützen einem die besten Suchmaschinen
> nichts.

M.a.W. du hattest eigentlich nichts zu sagen. Du wolltest nur mal den
Gutmenschen raushängen lassen. Mach bitte die Tür leise zu, wenn du
rausgehst. Danke.


XL

Re: zwei Tabellen

Am Fri, 08 Sep 2006 10:19:16 +0200 schrieb Christian Kirsch:

> Claus Reibenstein schrieb:
>> Andreas Kretschmer schrieb:
>
> ...
>
>> Und Du scheinst nicht imstande zu sein, Anfängern bei Problemen
>> sinnvolle Hilfestellung zu geben.
>>
>
> Und wie erklärst Du Dir (oder uns), dass jemand vier Jahre lang
> Anfänger bleibt? Denn das war der gute Mathias ja schon 2002:
>
> http://groups.google.com/group/de.comp.datenbanken.mysql/bro wse_frm/thread/3e389da5a0de3e6c/91528b472e2020a3?lnk=st&q=&r num=7&hl=de#91528b472e2020a3
>
> Ich tippe da eher auf Lernresistenz.

Da hat Du zwar Recht, aber seit dem sind meine Fragen auch andere geworden.
Damals war die Frage:
Hallo NG,
also ich beschäftige mich erst seit kurzer Zeit mit php und MySql. Und
da habe ich auch schon das erste Problem....
Ein Feld ist als auto increment
gesetzt und hat den Feldtyp TINYINT (4). Nun schreibt mir mein Script
die Dat5en eigentlich richtig darein. Ich habe aber eine ganze Zeit lang
getestet und auch wieder einige Datensätze gelöscht. Jetzt allerdings
kann ich nur noch einen Datensatz in die Tabelle schreiben. Der bekommt
die ID 127 (auto increment) zugewiesen. Weitere Datensätze kann ich
nicht mehr einfügen. Was hab ich da falsch gemacht ?

Man beachte die erste Zeile (seit kurzer Zeit) !

Zwischen dem Datum und heute habe ich 2 Jahre Kindererziehungsjahr
(Zwillige)genommen, in verschiedenen Arbeiststellen gearbeitet die mit IT
gar nichts gemein hatten, bin noch zweimal umgezogen, hab ein Haus gebaut
und nebenbei habe ich mich noch rein autodidaktisch weitergebildet. Dann
habe ich noch eine Ausbildung zum Fachinformatiker an einer privaten Schule
finanziert von Arbeitsamt abgeschlossen. Der Hauptteil dort bestand aber in
kaufmännischen Fragen und ein wenig von allen Programmiersprachen inkl.
Datanbank mit mysql (insgesamt 3 Monate Programmmierung). Dazu gleich erst
nochmal vielen Dank an die EU, die diesen sch... Lehrplan entwickelt hat.
Mit dem, was ich in dieser Zeit trotzdem zu meinem Hobby dazugelernt habe,
bin ich sehr zufrieden.

Meine Bildung, auch wenn Du vielleicht keine erkennst, ist inzwischen
trotzdem schon weiter fortgeschritten. Aber es gibt Probleme, mit denen hat
man einfach nicht täglich zu tun. Da wird man doch wohl mal fragen dürfen.
Wenn Du keine Antwort weist, und danach sieht es ja aus (denn sonst wäre ja
vielleicht ein kostruktiver Ansatz gekommen), dann ignoriere den Beitrag
doch einfach.
Das Du hier Experte für MySql, php und was ich nicht noch alles bist, hast
Du noch nicht gezeigt. Bis dato kann man das aus Deinen Beiträgen nur
andeutungsweise herauslesen. Ich gabe ja wenigstens noch zu, das ich
manches nicht weis.

Mathias

Re: zwei Tabellen

Claus Reibenstein schrieb:
> Christian Kirsch schrieb:

>> Der Betreffende ist meiner Meinung nach einfach nur faul oder dumm,
>> wenn er in vier Jahren nicht in der Lage ist (und sei es nur durch
>> Verfolgen der Postings in dieser Newsgroup) zu verstehen, wozu Indizes
>> gut sind, wie man SELECTs mit Join formuliert usw.
>
> Die Frage ist, ob er so etwas bisher gebraucht hat. Da er bislang
> offensichtlich nur mit kleinen Tabellen gearbeitet hat, bestand wohl
> keine Notwendigket. Möglicherweise hat er sich nur am Rande mit der
> Thematik auseinandersetzen müssen.

Entschuldige, daß ich das ein wenig anders sehe. Indexe gehören
IMHO zum absoluten Grundwissen. Wenn man sich dann auch noch,
wie Matthias scheinbar, seit Jahren mit dem Thema Datenbank beschäftigt,
gibt das zu denken.

> Mit Faulheit oder Dummheit muss das nichts zu tun haben.

Der passende Hinweis war da, frühzeitig!

Nachdem Mathhias seine Tabellenstruktur gepostet hatte, wies ihn Helmut
auf die fehlenden Indexe hin. Vielleicht hätte er noch einen Link
posten können, ok, aber ausreichend sollte der Hinweis auch ohne sein.
Matthias ist ja kein ganz blutiger Anfänger und sollte wirklich in der
Lage sein, sein Problem nach diesem Hinweis dann schnell lösen zu können,
bzw. schnell zu finden, wie man einen Index anlegt.
Aber er antwortete nur:
"Da bleibt mir blos noch der index. Bitte, kannst Du mir sagen,
wie ich damit umgehe?"
oder:
"Kannst Du m ir das mit den Indizies etwas genauer erklären?"

Nachdem er Thomas dann etwas mehr aus der Nase ziehen konnte und
den Index angelegt hatte, ging es dann wie gewünscht.

Also ich denke: Ja, hier kann man wirklich von Faulheit reden.

Gruß
JPM

Re: zwei Tabellen

Am Fri, 08 Sep 2006 10:43:10 +0200 schrieb Christian Kirsch:

> Claus Reibenstein schrieb:
>> Thomas Rachel schrieb:
>>
>>> Mathias Fiedler wrote:
>>>
>>>> Der Hinweis auf das Manual ist zwar richtig, nutzt mir aber momentan
>>>> nicht. Bis ich das durch hab, dauert einfach zu lange.
>>> Es reicht aus, die relevanten Stellen zu lesen.
>>
>> Und welche sind das? Ich weiß es, Du anscheinend auch, Mathias aber
>> nicht. Warum nennst Du sie ihm nicht?
>>
>
> Warum beschäftigt sich jemand vier Jahre lang mit MySQL und schafft es
> in dieser Zeit nicht, *einmal* das Handbuch zu lesen? Warum darf so
> jemand Anwendungen entwickeln? Fragen über Fragen.
>
Wer hat Dir gesagt, das ich mich 4 Jahr mit mysql beschäftigt habe? Ds ist
eine reine Annahme dienrseits.

>> Ich stelle mit Bedauern fest, dass hier hin dieser NG ein ziemlich
>> arroganter Ton gegenüber Anfängern herrscht.
>
> Flasche Voraussetzung, flasche Schlussfolgerung. Der Betreffende *ist*
> kein Anfänger. Und Handbuch-Lektüre gehört überall im Leben dazu - bei
> Waschmaschinen ebenso wie bei MySQL.
>
Handbuchlektüre schon, wobei das Manual zu Mysql wohl weit über ein
Handbuch hinausgehen dürfte.

>> Offensichtlich haben einige
>> Herrschaften hier schon vergessen, dass sie auch mal Anfänger waren,
>> oder sind mittlerweise schon zu abgehoben, um sich in die Probleme eines
>> Anfängern reinzudenken. Schade. Sehr schade.
>
> Das hat damit nichts zu tun. Wenn ich Anfänger in irgendwas bin, dann
> mache ich mir zumindest die Mühe, einmal die (in diesem Fall sogar
> gute und vollständige!) Dokumentation zu lesen. Das ist eine
> Voraussetzung für die *ernsthafte* Beschäftigung mit dem Produkt. Und
> um die geht es doch vorgeblich in diesem Fall, oder?
>
Sagte ich doch bereits, das ich das tue. Nur bis man das durch hat vergehen
Wochen.

> Der Betreffende ist meiner Meinung nach einfach nur faul oder dumm,
> wenn er in vier Jahren nicht in der Lage ist (und sei es nur durch
> Verfolgen der Postings in dieser Newsgroup) zu verstehen, wozu Indizes
> gut sind, wie man SELECTs mit Join formuliert usw.
>
Du nimmst schon wieder nur etwas an. Du unterstellst mir, das ich genau wie
Du, in den letzten Jahren nichts anderes gemacht habe. Das stimmt aber eben
nicht.

Du meinst also ich sei dumm? Was bist Du dann? Ich sags lieber nicht.

> BTW: Anstatt rumzujammern, wie böse die andern sind - warum verrätst
> *Du* ihm denn nicht, wo er das geheimnisvolle CREATE INDEX finden
> könnte - in einem Manual, das man einfach DURCHSUCHEN kann, und zwar
> im Web?
>
Das kannte ich übrigens schon. Mir war nur die Bedeutung und Verwednung des
Indexes nicht so ganz klar. Aber ich habe schon wieder etwas dazugelernt.
An dieser Stelle möchte ich mich dann gleich noch dafür entschuldigen, dass
ich immer noch nicht alles weis und warscheinlich wieder mal etwas fragen
werde. Und dann, lieber Christian, lass bitte mein Posting einfach links
liegen. Das verursacht weniger Traffic, weniger Ärger und haufenweise
zufriedene Leute.

Mathias

Re: zwei Tabellen

Wo hat man Dich denn rausgelassen? Von mir aus kannst Du die Tür ruhig laut
zumachen, hauptsache Du machst sie zu !



Am Fri, 8 Sep 2006 12:46:28 +0200 schrieb Axel Schwenke:

> Claus Reibenstein wrote:
>> Christian Kirsch schrieb:
>>
>>> Warum beschäftigt sich jemand vier Jahre lang mit MySQL und schafft es
>>> in dieser Zeit nicht, *einmal* das Handbuch zu lesen? Warum darf so
>>> jemand Anwendungen entwickeln? Fragen über Fragen.
>>
>> Wieso "darf"? Wenn ich ihn richtig verstanden habe, wurde er dazu
>> verdonnert. Dass er unter diesen Umständen keine große Lust hat, sich
>> damit weiter zu beschäftigen als unbedingt nötig, ist doch wohl
>> verständlich.
>
> Nein. Wenn er zu einer Arbeit "verdonnert" wird, die offensichtlich
> seinen geistigen Horizon überschreitet, dann hat er zwei Möglichkeiten:
>
> 1. er lehnt ab
> 2. er setzt sich hin und *lernt* das
>
>>> Der Betreffende ist meiner Meinung nach einfach nur faul oder dumm,
>>> wenn er in vier Jahren nicht in der Lage ist (und sei es nur durch
>>> Verfolgen der Postings in dieser Newsgroup) zu verstehen, wozu Indizes
>>> gut sind, wie man SELECTs mit Join formuliert usw.
>>
>> Die Frage ist, ob er so etwas bisher gebraucht hat. Da er bislang
>> offensichtlich nur mit kleinen Tabellen gearbeitet hat, bestand wohl
>> keine Notwendigket. Möglicherweise hat er sich nur am Rande mit der
>> Thematik auseinandersetzen müssen.
>
> Dem OP fehlen wirklich grundlegende Kenntnisse, wie z.B. die, was ein
> Index ist und wann man sowas braucht. Das ist noch nicht mal MySQL-
> spezifisch, das ist elementares Grundlagenwissen. So jemanden würde ich
> nie im Leben an einer Datenbank-Anwendung schreiben lassen.
>
>> Mit Faulheit oder Dummheit muss das nichts zu tun haben.
>
> Wenn der OP Hinweise auf "mach dich schlau" ableht, dann ist das sehr
> wohl Faulheit. Wenn er mit Fragen wartet, bis "es brennt", dann ist das
> sehr wohl Dummheit. Wenn er eine Aufgabe annimmt, die schon brandeilig
> ist und die seine Fähigkeiten übersteigt, dann ist das auch Dummheit.
>
>>> BTW: Anstatt rumzujammern, wie böse die andern sind - warum verrätst
>>> *Du* ihm denn nicht, wo er das geheimnisvolle CREATE INDEX finden
>>> könnte - in einem Manual, das man einfach DURCHSUCHEN kann, und zwar
>>> im Web?
>>
>> Weil ich Threads erst lese, bevor ich etwas dazu schreibe. Weil ich
>> nicht Dinge wiederhole, die schon gesagt wurden. Es sei denn, der
>> Angesprochene hat etwas nicht verstanden. Dann versuche ich eventuell,
>> es noch einmal anders zu erklären. War in diesem Fall aber nicht notwendig.
>>
>> Zum Suchen muss man auch erst einmal wissen, wonach man suchen muss.
>> Wenn einem die Stichworte fehlen, nützen einem die besten Suchmaschinen
>> nichts.
>
> M.a.W. du hattest eigentlich nichts zu sagen. Du wolltest nur mal den
> Gutmenschen raushängen lassen. Mach bitte die Tür leise zu, wenn du
> rausgehst. Danke.
>
>
> XL

Re: zwei Tabellen

Am Fri, 08 Sep 2006 12:52:51 +0200 schrieb Jens Peter Moeller:

> Entschuldige, daß ich das ein wenig anders sehe. Indexe gehören
> IMHO zum absoluten Grundwissen. Wenn man sich dann auch noch,
> wie Matthias scheinbar, seit Jahren mit dem Thema Datenbank beschäftigt,
> gibt das zu denken.

Genau, scheinbar.

Re: zwei Tabellen

Christian Kirsch schrieb:

> Mag sein. Aber genauso verständlich ist es, dass andere Leute keine
> Lust haben, unbezahlt die Arbeit zu erledigen, für die er bezahlt wird.

Das verlangt ja auch niemand. Es genügt, ihn in die richtige Richtung zu
schubsen.

>> Ich glaube kaum, dass sich die Dokumentation einer Waschmaschine mit der
>> von MySQL vergleichen lässt.
>
> Die von MySQL ist im Zweifel detaillierter, stimmt. Oder was wolltest
> Du sagen?

Genau diese Art von Antworten sind es, die mich stören.

>> Du liest also _wirklich_ erst 1000 Seiten Manual durch, bevor Du Dich an
>> etwas Neues heranwagst?
>
> Ich versuche es - und vor allem versuche ich, ein Problem durch Lesen
> und Nachdenken zu lösen, bevor ich es in die Welt hineinposaune. Denn
> es ist erstmal *mein* Problem. Erst wenn ich mir einigermaßen sicher
> sein kann, dass ich trotz intensiven Suchens und Nachdenkens keine
> Lösung gefunden habe, frage ich laut in der Gegend rum.

Und Du meinst, Mathias hätte es _nicht_ erst selbst versucht, sondern
_gleich_ hier gefragt? Wie kommst Du darauf? Woraus schließt Du das?

>> [...] Learning by doing.
>
> Auch gut. Aber hier ging's ja um "Asking instead of learning, reading
> or thinking". Das ist ein ganz anderes Konzept.

Wohl eher "Asking after unsuccessful learning, reading and thinking".
Wer nicht fragt, bleibt dumm.

> Zumindest JOINs kennt er doch seit ein paar Monaten:

Mit denen konnte ich mich auch noch nie anfreunden. Die habe ich bis
heute nicht gecheckt. Ich weiß aber, dass sie existieren. Falls ich sie
also wirklich mal brauchen sollte, weiß ich, wonach ich suchen muss.
Mathias wusste es offensichtlich nicht.

Falls ich damit dann nicht weiterkomme, werde ich mich vertrauensvoll an
Euch wenden ...

> Und wenn man sich "mit einer Thematik auseinandersetzen muss" - tut
> man dass dann dadurch, dass man Dinge in die Gegend fragt [...]

Natürlich. Was soll man denn sonst tun, wenn man alleine nicht weiterkommt?

>> Mit Faulheit oder Dummheit muss das nichts zu tun haben.
>
> Sondern?

Damit:

>> Zum Suchen muss man auch erst einmal wissen, wonach man suchen muss.
>> Wenn einem die Stichworte fehlen, nützen einem die besten Suchmaschinen
>> nichts.
>
> Das Wort "Index" erwähnte der Betreffende selbst in seinem Posting.

In welchem? In seiner ursprünglichen Frage taucht es nicht auf, sondern
erst in <6agyuyxyrwxt$.8wve5vjjvsgw.dlg@40tude.net> (heute morgen um
7:34 Uhr), und auch da nur, weil Helmut ihn in
<4mbbflF5f0skU1@individual.net> darauf hingewiesen hat.

Gruß. Claus

Re: zwei Tabellen

Am Fri, 08 Sep 2006 12:52:51 +0200 schrieb Jens Peter Moeller:

> Nachdem er Thomas dann etwas mehr aus der Nase ziehen konnte und
> den Index angelegt hatte, ging es dann wie gewünscht.

Ich denke nun eben gar nicht, das das etwas mit Faulheit zu tun hat. Ich
brauchte schnell einen Lösungsansatz und den habe ich bekommen. Allerdings
nicht von den ganzen selbsternannten Experten. Was ist daran schlimm,
jemanden etwas zu erklären? Nächstens schaffen wir noch die Schule abb. Die
Kinder kriegen alle Ihre Bücher von der Klasse 1 bis zur 10. Dann können
die zu Hause schön lernen und werden klug. Zu was braucht man schon Lehrer,
sind doch eh alles nur faules Pack, die Schüler heute ! Dein erstes Wort
auf dieser Welt war warscheinlich mysql oder php oder Linux. Bei mir war es
halt anders. Ich habe meine Lehrer gebraucht um die Bücher richtig zu
verstehen. Da es bei Dir anders war verzeihe ich Dir Deine Unwissenheit.

Mathias

Re: zwei Tabellen

Hallo Christian,

ich danke Dir nochmal für Deine Hilfe. Aber Du mußt hier nicht Deinen guten
Ruf verspielen. Es reicht, wenn die >einen< haben, auf dem sie herumhacken
können. Das bin nunmal ich. Die werden es nie verstehen, weil sie nicht
wollen. Das ist wie bei einem Kleinkind, dem man sein Spielzeug wegenommen
hat. Da zählt nichts anderes mehr.
Ich bin das von dieser NG schon gewohnt. Es macht immer wieder Spass, das
zu lesen. Allerdings kann ich es bald auswendig.
Ich werde trotzdem weiter fragen. Wie ich immer wieder voller Freude
feststelle, gibt es doch noch Menschen wissen das man nicht alles wissen
kann und bereits sind ihr Wissen auch mal mit anderen zu teilen.

Mathias

Re: zwei Tabellen

Mathias Fiedler schrieb:

> ich danke Dir nochmal für Deine Hilfe. Aber Du mußt hier nicht Deinen guten
> Ruf verspielen.

Das lass mal meine Sorge sein.

> Es reicht, wenn die >einen< haben, auf dem sie herumhacken
> können. Das bin nunmal ich. Die werden es nie verstehen, weil sie nicht
> wollen.

Für solche Fälle gibt es Filter.

> Ich bin das von dieser NG schon gewohnt. Es macht immer wieder Spass, das
> zu lesen.

Ach so, Du möchtest Dir den Spaß nicht nehmen lassen. Na dann ...

> Ich werde trotzdem weiter fragen. Wie ich immer wieder voller Freude
> feststelle, gibt es doch noch Menschen wissen das man nicht alles wissen
> kann und bereits sind ihr Wissen auch mal mit anderen zu teilen.

Und das ist gut so.

Gruß. Claus

[OT] Trollkindergarten (was: Re: zwei Tabellen)

Claus Reibenstein meinte:

> Mathias Fiedler schrieb:

[...]

Dann weiterhin viel Erfolg bei euren gegenseitigen Befruchtungen.

Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: zwei Tabellen

Christian Kirsch wrote:

> Und wie erklärst Du Dir (oder uns), dass jemand vier Jahre lang
> Anfänger bleibt? Denn das war der gute Mathias ja schon 2002:

Wenn er schon anderen seine vorgegaukelten Kenntnisse verkaufen will
(siehe http://psygonis.de) dann kann er doch auch gerne frech werden
hier. Er kann sichs doch leisten! Schliesslich bietet er ja selbst PHP &
MySql-Kurse an. ;-)

MfG, Ulf

Re: zwei Tabellen

Ulf Kadner meinte:

> Wenn er schon anderen seine vorgegaukelten Kenntnisse verkaufen will
> (siehe http://psygonis.de) dann kann er doch auch gerne frech werden
> hier. Er kann sichs doch leisten! Schliesslich bietet er ja selbst PHP &
> MySql-Kurse an. ;-)

Aber nur *Grundlagen*. Am Kapitel "Wie finde ich wo was selber" wird
gerade gearbeitet...

Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: zwei Tabellen

Am Fri, 08 Sep 2006 20:05:32 +0200 schrieb Ulf Kadner:

> Christian Kirsch wrote:
>
>> Und wie erklärst Du Dir (oder uns), dass jemand vier Jahre lang
>> Anfänger bleibt? Denn das war der gute Mathias ja schon 2002:
>
> Wenn er schon anderen seine vorgegaukelten Kenntnisse verkaufen will
> (siehe http://psygonis.de) dann kann er doch auch gerne frech werden
> hier. Er kann sichs doch leisten! Schliesslich bietet er ja selbst PHP &
> MySql-Kurse an. ;-)
>
> MfG, Ulf

Was hat das jetzt damit zu tun? Du hast nicht einen einzigen konstruktiven
Beitrag geleistet aber maßt es Dir an über andere herzuziehen die nur eine
simple Frage gestellt haben. Wieder ein typisches Beispiel von
Selbstüberschätzung. Ich habe nach etwas gefragt, daraus kann man
schliessen, daß ich etwas nicht weiss. Na und, Das ist vollkommen ok. Von
Dir kam keine Antwort. Also kann man daraus schliessen, das Du es ebenfalls
nicht weist. Also, dann halte die Klappe.

Die von mir angebotenen Kurse sind als Grundlagenkurse angegeben. Wie ich
das handhabe, geht Dich überhaupt nichts an. Ich vertreibe
IT-Dienstleistungen, wie Du ja gesehen hast (falls Du lesen kannst). Meine
Frage bezog sich nicht auf Grundlagen, sondern weiterführende Kenntnisse.
Es mag ja sein das die ganzen Experten hier bereits ein derartiges Wissen
angehäuft haben, das alles unterhalb der Genialität zu den Grundlagen
gehört. Leidere sieht die Wirklichleit etwas anders aus. Ich habe eine
Ausbildung zum Fachinformatiker gemacht. Nach den neuen Lehrplanrichtlinien
der EU. Wir hatten innerhalb von 2 Jahren nur 6 Monate Programmierung.
Alles andere war kaufmännisches Grundlagenwissen, Office Anwendung,
einfache Netzwerktechnik, BWL und Recht. Dabei wurde nur auf die
Programmiersprachen C++, Java, VB eingegangen. Der Access Kurs war länger
als mysql. PHP wurde nur am Rande kurz erwähnt. Die IHK Prüfung umfasste 3
Prüfungskategorien. Je Kategorie gab es zwischen 5 und 10 Fragen, so
gestaltet das es am Ende immer 100 Punkte ergibt. Dabei waren 3 Fragen zu
Programmierung, davon eine zu sql. Soviel zu fachgerechter Ausbidlung in
Deutschland. Ich will damit niemanden angreifen und auch nicht meine
Unwissenheit verteidigen. Wenn ich etwas nicht weis, frage ich. Unsere
Lehrer waren uns teilweise auch nur 1 oder 2 Unterrichtseinheiten voraus.
Das ist aber nicht nur dort so gewesen. Aus meinem verwandschafltlichem
Umfeld kenne ich das auch in Mittelschulen und Gymnasien.

Wenn ich nun Grundlagenkurse in php uns mysql anbiete, weis ich schon was
ich tue. Sollte es also zu einem solchen Kurs kommen, werde ich mich
ausführlich darauf vorbereiten. Nur in diesem Fall, bezüglich meiner Frage
zu index, ging das zeitlich eben nicht. Das kann man auch aus dem
zeitlichen Abstand zwischen meine Fragen in der NG ableiten.

Und in diesem Zusammenhang gleich noch hinterher, das ist keine
Auftragsprogrammierung, für die ich Geld bekomme. Das war auch nur wieder
eine Annahme eines Experten.

Re: zwei Tabellen

Mathias Fiedler wrote:

> Was hat das jetzt damit zu tun? Du hast nicht einen einzigen konstruktiven
> Beitrag geleistet aber maßt es Dir an über andere herzuziehen die nur eine
> simple Frage gestellt haben.

So ists im Usenet nunmal! :-)

> Die von mir angebotenen Kurse sind als Grundlagenkurse angegeben.

Ja z.b. MySql-Grundlagen. Dazu zählen auch die Dinge, nach denen Deine
Frage gerichtet war.

> (falls Du lesen kannst).

Nein ich kann nur schreiben. Lesen wird wohl erst wenn ich Rentner bin.
Ist mir zu komplex...

> Frage bezog sich nicht auf Grundlagen, sondern weiterführende Kenntnisse.

Das sehe ich anders. Sowas findest Du in jedem vernünftigen
Mysql-Basics-Buch

> Es mag ja sein das die ganzen Experten hier bereits ein derartiges Wissen
> angehäuft haben, das alles unterhalb der Genialität zu den Grundlagen

Kann es sein das Du bei berechtigter Kritik den Überblick verlierst?
Kann ja mal passieren!

> gehört. Leidere sieht die Wirklichleit etwas anders aus. Ich habe eine
> Ausbildung zum Fachinformatiker gemacht. Nach den neuen Lehrplanrichtlinien
> der EU. Wir hatten innerhalb von 2 Jahren nur 6 Monate Programmierung.
> Alles andere war kaufmännisches Grundlagenwissen, Office Anwendung,
> einfache Netzwerktechnik, BWL und Recht.

Gehört halt alles dazu. Ich hatte dazu 3 Jahre Zeit.

> Programmiersprachen C++, Java, VB eingegangen. Der Access Kurs war länger
> als mysql.

War wohl MS ein Studien-Sponsor? :-)

> Deutschland. Ich will damit niemanden angreifen und auch nicht meine
> Unwissenheit verteidigen. Wenn ich etwas nicht weis, frage ich. Unsere
> Lehrer waren uns teilweise auch nur 1 oder 2 Unterrichtseinheiten voraus.
> Das ist aber nicht nur dort so gewesen. Aus meinem verwandschafltlichem
> Umfeld kenne ich das auch in Mittelschulen und Gymnasien.

Du kannst das doch aber nicht mit einer NG vergleichen! Oder warum
erzählst Du das jetzt.

Hier wird keiner dafür bezahlt das DU etwas lernst. Also wird im
Gegenzug von Dir ein maximales Engagement erwartet.

> Wenn ich nun Grundlagenkurse in php uns mysql anbiete, weis ich schon was
> ich tue.

Ich glaube Dir das Du das denkst. Aber das ist offensichlich nicht der
Fall. Bsp. Die von Dir verwendeten vermursten Tabellennamen und das
schlimme Design allgemein.

> Sollte es also zu einem solchen Kurs kommen, werde ich mich
> ausführlich darauf vorbereiten.

Ach Du hast noch keinen durchgeführt? Naja dann hast Du ja noch ein
wenig Zeit Dein Wissen zu verbessern. Du solltest allerdings, schon
allein um Missverständnisse zu vermeiden und fair gegenüber Kunden zu
sein, auf Deiner Webseite darauf hinweisen, das nur rudimentäres
SQL-Wissen besteht!

> Und in diesem Zusammenhang gleich noch hinterher, das ist keine
> Auftragsprogrammierung, für die ich Geld bekomme. Das war auch nur wieder
> eine Annahme eines Experten.

Das ist auch nicht so sehr von Bedeutung. Du selbst bist in einer NG
immer der jenige der Sich mit Abstand die meiste Arbeit machen muss um
ans gewünschte Ziel zu gelangen.

Wenn Du kein Geld dafür bekommst hast Du auch keine so strikten
Zeitrahmen. Und Wenn doch, dann solltest Du Dir bei nächsten mal vor
Deiner Zustimmung zu einer Arbeit etwas mehr Gedanken darüber machen.

Ich nehme an Du hast Dich bei der Zustimmung zur Arbeit einfach in
Deinen Kenntnissen überschätzt. Also erst mal ne etwas kritische
Selbsteinschätzung Deinerseits bitte. :-)

Sowas lernt man aber im Ökonomischen Bereich als Informatiker. Haste
wohl nicht aufgepast wa? ;-)

MfG, Ulf

Re: zwei Tabellen

Am Sun, 10 Sep 2006 17:40:26 +0200 schrieb Ulf Kadner:

Hallo Ulf,

ok, nun nochmal.

> Mathias Fiedler wrote:
>
>> Was hat das jetzt damit zu tun? Du hast nicht einen einzigen konstruktiven
>> Beitrag geleistet aber maßt es Dir an über andere herzuziehen die nur eine
>> simple Frage gestellt haben.
>
> So ists im Usenet nunmal! :-)
>
Das ist schade
>> Die von mir angebotenen Kurse sind als Grundlagenkurse angegeben.
>
> Ja z.b. MySql-Grundlagen. Dazu zählen auch die Dinge, nach denen Deine
> Frage gerichtet war.
>
Eben nicht. Selbt in Unterrichtsbüchern vom Herdverlag für
Datenbankgrundlagen wird das nur am Rande erwähnt.
>> (falls Du lesen kannst).
>
> Nein ich kann nur schreiben. Lesen wird wohl erst wenn ich Rentner bin.
> Ist mir zu komplex...
>
>> Frage bezog sich nicht auf Grundlagen, sondern weiterführende Kenntnisse.
>
> Das sehe ich anders. Sowas findest Du in jedem vernünftigen
> Mysql-Basics-Buch

Eben nicht in jedem.
>
>> Es mag ja sein das die ganzen Experten hier bereits ein derartiges Wissen
>> angehäuft haben, das alles unterhalb der Genialität zu den Grundlagen
>
> Kann es sein das Du bei berechtigter Kritik den Überblick verlierst?
> Kann ja mal passieren!
>
Nein, definitiv nicht. Wir scheinen nur eine verschiedene Auffassung von
berechtigt zu haben.

>> gehört. Leidere sieht die Wirklichleit etwas anders aus. Ich habe eine
>> Ausbildung zum Fachinformatiker gemacht. Nach den neuen Lehrplanrichtlinien
>> der EU. Wir hatten innerhalb von 2 Jahren nur 6 Monate Programmierung.
>> Alles andere war kaufmännisches Grundlagenwissen, Office Anwendung,
>> einfache Netzwerktechnik, BWL und Recht.
>
> Gehört halt alles dazu. Ich hatte dazu 3 Jahre Zeit.
>
Ich 2 Jahre, es war eine Umschulung. Die IHK prüfung ist aber die selbe.

>> Programmiersprachen C++, Java, VB eingegangen. Der Access Kurs war länger
>> als mysql.
>
> War wohl MS ein Studien-Sponsor? :-)

Nie, war es nicht. Du solltest wissen, das nur zugelassene und
zertifizierte Schulungsunternehmen das machen dürfen. Die Vorgaben sind
alle gleich.
>
>> Deutschland. Ich will damit niemanden angreifen und auch nicht meine
>> Unwissenheit verteidigen. Wenn ich etwas nicht weis, frage ich. Unsere
>> Lehrer waren uns teilweise auch nur 1 oder 2 Unterrichtseinheiten voraus.
>> Das ist aber nicht nur dort so gewesen. Aus meinem verwandschafltlichem
>> Umfeld kenne ich das auch in Mittelschulen und Gymnasien.
>
> Du kannst das doch aber nicht mit einer NG vergleichen! Oder warum
> erzählst Du das jetzt.

Weil es um den Wissensstand für Schulung geht. Es ist doch keine Schande,
wenn man auch als Lehrer, mal etwas nicht weis. Man kann sich doch auch
spezifisch weiterbilden. Das heist, bestimmte Kenntnisse werden eben erst
bei bestimmten Voraussetzungen benötigt.

>
> Hier wird keiner dafür bezahlt das DU etwas lernst. Also wird im
> Gegenzug von Dir ein maximales Engagement erwartet.
>
>> Wenn ich nun Grundlagenkurse in php uns mysql anbiete, weis ich schon was
>> ich tue.
>
> Ich glaube Dir das Du das denkst. Aber das ist offensichlich nicht der
> Fall. Bsp. Die von Dir verwendeten vermursten Tabellennamen und das
> schlimme Design allgemein.
>
Ich hatte es doch gesagt, die Tabellennamen und Muster waren vorgegeben.
Die kann ich nicht ändern. Ansonsten sollen Tabellennamen aussagekräftige
Namen haben und die Muster sollten der Anwendung entsprechen. Wenn für mich
"pppppp" einen aussagekräftigen Namen darstellt verwende ich den. Wenn Di
die gesamte Anwendung nicht kennst, woher willst Du dann wissen, das es
sich hierbei nicht um einen richtigen Bezug zur Anwendung handelt? Das sind
nur Vermutungen. Und die gehören hier nicht her. Im übrigen ist dem Server
völlig egel, ob eine Tabelle nun "Adresse" oder "jsadlögsajgäsaln" heißt.
Für die eventuellen Programmierer, die später mal daran arbeiten sollen,
gbt es eine Dokumentation.

> > Sollte es also zu einem solchen Kurs kommen, werde ich mich
>> ausführlich darauf vorbereiten.
>
> Ach Du hast noch keinen durchgeführt? Naja dann hast Du ja noch ein
> wenig Zeit Dein Wissen zu verbessern. Du solltest allerdings, schon
> allein um Missverständnisse zu vermeiden und fair gegenüber Kunden zu
> sein, auf Deiner Webseite darauf hinweisen, das nur rudimentäres
> SQL-Wissen besteht!
>
Das ist, mit Verlaub gesagt, Blödsinn. Dann müßte jeder Mediamarkt seine
Kunden ebenfalls darauf hinweisen.

>> Und in diesem Zusammenhang gleich noch hinterher, das ist keine
>> Auftragsprogrammierung, für die ich Geld bekomme. Das war auch nur wieder
>> eine Annahme eines Experten.
>
> Das ist auch nicht so sehr von Bedeutung. Du selbst bist in einer NG
> immer der jenige der Sich mit Abstand die meiste Arbeit machen muss um
> ans gewünschte Ziel zu gelangen.
>
> Wenn Du kein Geld dafür bekommst hast Du auch keine so strikten
> Zeitrahmen. Und Wenn doch, dann solltest Du Dir bei nächsten mal vor
> Deiner Zustimmung zu einer Arbeit etwas mehr Gedanken darüber machen.
>
> Ich nehme an Du hast Dich bei der Zustimmung zur Arbeit einfach in
> Deinen Kenntnissen überschätzt. Also erst mal ne etwas kritische
> Selbsteinschätzung Deinerseits bitte. :-)
>
Ich habe meine Kenntnisse nicht überschätzt. Ich habe lediglich nicht mit
dem Aufkommen dieses Problems, sprich INDEX, gerechnet. Die Dateien, um die
es sich anfangs gehandelt hat waren nur wenige Zeilen groß. Das es dann
auch um CSV Dateien mit 5 - 8 MB geht, war vorher nicht bekennt.

> Sowas lernt man aber im Ökonomischen Bereich als Informatiker. Haste
> wohl nicht aufgepast wa? ;-)
>
Und wie ich da aufgepasst habe. Übrigens ist mein ursprünglich erlernter
Beruf Kaufmann. Ich weis schon, worauf ich mich einlassen kann und woarauf
nicht. Natürlich hätte ich auch die Programmierung an der Stelle, wo die
Erweiterungen bekannt wurden, wieder abblasen könnnn. Aber ich wollte es
eben wissen, wies geht. Dashalb der Versuche es doch hinzubekommen, deshalb
auch die Frage hier.

mfg

Mathias

Re: zwei Tabellen

Mathias Fiedler schrieb:

>>>Wenn ich nun Grundlagenkurse in php uns mysql anbiete, weis ich schon was
>>>ich tue.
>>
>>Ich glaube Dir das Du das denkst. Aber das ist offensichlich nicht der
>>Fall. Bsp. Die von Dir verwendeten vermursten Tabellennamen und das
>>schlimme Design allgemein.
>>
>
> Ich hatte es doch gesagt, die Tabellennamen und Muster waren vorgegeben.
> Die kann ich nicht ändern. Ansonsten sollen Tabellennamen aussagekräftige
> Namen haben und die Muster sollten der Anwendung entsprechen. Wenn für mich
> "pppppp" einen aussagekräftigen Namen darstellt verwende ich den. Wenn Di
> die gesamte Anwendung nicht kennst, woher willst Du dann wissen, das es
> sich hierbei nicht um einen richtigen Bezug zur Anwendung handelt? Das sind
> nur Vermutungen. Und die gehören hier nicht her. Im übrigen ist dem Server
> völlig egel, ob eine Tabelle nun "Adresse" oder "jsadlögsajgäsaln" heißt.
> Für die eventuellen Programmierer, die später mal daran arbeiten sollen,
> gbt es eine Dokumentation.

Hallo,
sei mir nicht böse, aber Du redest stellenweise wirklich Unsinn.
Du bietest Dienstleistung und (Grundlagen)-Kurse zum Thema MySQL an
und hast ganz offensichtlich die Bedeutung vin Indexen noch nicht
erkannt. Vielleicht solltest Du (sobald Du das laufende Projekt vollens
versenkt hast) mal das Mysql-Handbuch durchlesen (und ich sage nicht
auswendiglerne, nur mal durchlesen. Dann wirkst Du lernen, das Begriffe
wie Primärschlüssel, Index, ... genauso wichtig sind wie Tabelle.

Und wenn ich höre: "Die Tabellen sind mir von einer höheren Macht
vorgegeben" und ich dann sehe, dass das Datenmodell dermassen Müll ist
(solltest Du das nicht sehen, lass bitte die Finger von Projekten, die
auch nur in die Nähe einer Datenbank kommen) bekomme ich vorsichtig
gesprochen Verdauungsstörungen. Sag Deinem Kunde, dass das was er will
mit dem Datenmodell nicht klappen kann und mache ihm einen Vorschlag,
was er ändern muss. (Beschränkung von Datentypen auf Date, Varchar und
number wäre ein Ansatz. Mehr braucht es in 99.9% der Fälle nicht)

Je früher Du lernst, welche Faktoren die Performance bis zum Stillstand
beeinflussen können, (und das ist nunmal fehlende Indexe und der
Vergleich von Äpfeln mit Birnen, und bevor Du das jetzt als 2 Punkte
betrachtest, lies die den Teil über Index durch.)

Übrigens: Wenn man das Datenmodell anschaut und feststellt, dass es
völlig verkorxt ist muss man sich die Applikation nicht anschauen um
beurteilen zu können, das das zu schweren Problemen führen wird.

Oder würdest Du einen Architekt, der festgestellt hat, dass das
Fundament Deines Hauses völlig kaputt ist, fragen: Wie können sie
behaupten, dass das Haus einsturzgefärdet ist, sie haben doch den
Firstbalken noch garnicht angeschaut.


Und jetzt noch viel Glück,
Michael

Re: zwei Tabellen

Hallo,
es tut mir ja leid, aber ich kann der Argumentation nicht folgen.
1. Ein Index ist eine wichtige Sache, wird aber in den meisten kleine
Anwendungen mit 100 - 500 Datenzeilen einfach nicht benötigt, ist also kein
Grundlagen wissen. Wenn man mit Indexen arbeiten muß, hat man schon ein
größeres Datenbnbankdesign zu bewältigen als man benötigt um nur ein paar
Newsartikel auf einer Homepage zu verwalten. Damit zählt der gesamte
Sachverhalt für mich zum erweiterten Wissen.
2. Ein Index war mir nicht unbekannt. Ich bin nur nicht darauf gekommen,
den zu verwenden. Es handelt sich um den Vergleich von Int werten. Das
dabei in Index einen Vorteil bringt, habe ich so nicht gesehen. Ich bin
davon ausgegangen, das mit einem Index so etwas wie ein binärer Baum
angelget wird. Das dieses bei einem reinen Integer Vergleich etwas bringt,
habe ich schlichtweg nicht gedacht. Das nun der Indes in mysql doch etwas
anders aufgebaut ist, habe ich ja nun mitbekommen. Das die DB damit
wesentlich schneller durchsuxht werden kann, auch. Die Tatsache, das ich
nicht wusste, wie man einen Index anlegt, ist doch kein Beinbruch. Sicher,
mit einem einfachen Versuch in php MyAdmin hätte (bzw. habe) ich den Befehl
schnell erhalten. IIch dachte halt, das auch die Benutzung und Verwendung
indexierter Spalten besonderheiten in der Abfrage unterliegt. Mittlerweile
weis ich, das dem nicht so ist.Aber das ist jetzt dazu der 54. Beitrag.
Bereist im 2. Beitrag, also bei der ersten Antwort auf meine Frage hätte
man das erschöpfend klären könnne. Und zwar ohne Komplettlösungen wie Claus
ja gezeigt hat. So geht es eben übrigens auch.
3. Es geht nicht um eine höhere Macht. Wenn mir jemand sagt, das ist die
Ausgagssituation, kannst Du damit dieses und jenes machen, dann schau ich
es mir an und wenn es geht sage ich ja. Dabei ist es unerheblich, ob seine
Datenbankstruktur ok ist oder nicht. Er braucht eine Lösung und die bekommt
er. Das Projekt, wie Du es nennst, habe ich übrigens nicht versenkt,
sondern zufriedenstellend abgeschlossen. Man bekommt nicht immer alles
mundgerecht aufbereitet. Wenn ich meinem Kunden sage, sein Datenbankmodell
ist Mist, kann ich auch gleich sagen, er sei blöd. Das führt nur dazu, das
ich keinen Kunden mehr habe. Das ist nicht der Sinn der Übung.

> Hallo,
> sei mir nicht böse, aber Du redest stellenweise wirklich Unsinn.
> Du bietest Dienstleistung und (Grundlagen)-Kurse zum Thema MySQL an
> und hast ganz offensichtlich die Bedeutung vin Indexen noch nicht
> erkannt. Vielleicht solltest Du (sobald Du das laufende Projekt vollens
> versenkt hast) mal das Mysql-Handbuch durchlesen (und ich sage nicht
> auswendiglerne, nur mal durchlesen. Dann wirkst Du lernen, das Begriffe
> wie Primärschlüssel, Index, ... genauso wichtig sind wie Tabelle.
>
> Und wenn ich höre: "Die Tabellen sind mir von einer höheren Macht
> vorgegeben" und ich dann sehe, dass das Datenmodell dermassen Müll ist
> (solltest Du das nicht sehen, lass bitte die Finger von Projekten, die
> auch nur in die Nähe einer Datenbank kommen) bekomme ich vorsichtig
> gesprochen Verdauungsstörungen.

Ich sagte es schon, das werde ich meinem Kunden nicht sagen. Du kannst das
ja gern tun, Dein Chef wird sich freuen. Wenn Du von der teilweisen
Einsicht in zwei Tabellen, bereits das gesamte Datenbankmodell kennst, bist
Du auch eines dieser Genies in dieser NG. Vielleicht macht Ihr am Besten
einen Club der Genies auf, da könnt Ihr Euch dann 24 am Tag
selbstbeweiräuchern und müßt euch nicht mit solch gewöhnlichen Leuten wie
mir abgeben. Deine Verdauungsstörungen kannst Du übrigens für Dich
behalten.

>Sag Deinem Kunde, dass das was er will
> mit dem Datenmodell nicht klappen kann und mache ihm einen Vorschlag,
> was er ändern muss. (Beschränkung von Datentypen auf Date, Varchar und
> number wäre ein Ansatz. Mehr braucht es in 99.9% der Fälle nicht)
>
> Je früher Du lernst, welche Faktoren die Performance bis zum Stillstand
> beeinflussen können, (und das ist nunmal fehlende Indexe und der
> Vergleich von Äpfeln mit Birnen, und bevor Du das jetzt als 2 Punkte
> betrachtest, lies die den Teil über Index durch.)
>
Mysql ist aber durchaus in der Lage, unterscheidliche typen zu casten, so
dass es damit klar kommen sollte. Steht auch im handbuch. Ich denke, das
hast Du gelesen.

> Übrigens: Wenn man das Datenmodell anschaut und feststellt, dass es
> völlig verkorxt ist muss man sich die Applikation nicht anschauen um
> beurteilen zu können, das das zu schweren Problemen führen wird.
>
> Oder würdest Du einen Architekt, der festgestellt hat, dass das
> Fundament Deines Hauses völlig kaputt ist, fragen: Wie können sie
> behaupten, dass das Haus einsturzgefärdet ist, sie haben doch den
> Firstbalken noch garnicht angeschaut.
>
Das ist jetzt Äpfel mit Birnen vergleichen, und wie hast Du dazu nochmal
gesagt .......?

Mathias

Re: zwei Tabellen

Mathias Fiedler wrote:

> 1. Ein Index ist eine wichtige Sache, wird aber in den meisten kleine
> Anwendungen mit 100 - 500 Datenzeilen einfach nicht benötigt,

Das kommt zusätzlich auch noch auf andere Faktoren, wie etwa die
Tabellenzahl an.


> ist also kein Grundlagen wissen.

Natürlich kommt es hier auf die Definition des Begriffes
"Grundlagenwissen" an - IMHO ist Grundlagenwissen das, was man
mindestens braucht, um die wesentlichen Teile eines Systems zu kennen.
Und sobald zwei Tabellen geJOINt werden - unerheblich, wie viele Zeilen
sie hat - gehört ein Index rein.

Aber Du siehst es ja selbst - Du hattest ursprünglich nur eine CSV-Datei
mit "wenigen" Zeilen erwartet, und was sich nachher ergab, war, daß sie
einige zehntausend hat. An dieser Stelle liegt die Grenze zwischen
"Grundlagen" und "erweitert" sicherlich nicht richtig.


> Es handelt sich um den Vergleich von Int werten.

Jein. Nicht ganz - es handelt sich um das Durchlaufen einer Tabelle und
das Finden eines dazu passenden Int-Wertes. Und genau dieses Finden ist
es, was den Index erforderlich macht.

> Das dabei in Index einen Vorteil bringt, habe ich so nicht
> gesehen. Ich bin davon ausgegangen, das mit einem Index so etwas wie
> ein binärer Baum angelget wird.

So ungefähr ist es ja auch.


> Wenn mir jemand sagt, das ist die Ausgagssituation,
> kannst Du damit dieses und jenes machen, dann schau ich es mir an und
> wenn es geht sage ich ja. Dabei ist es unerheblich, ob seine
> Datenbankstruktur ok ist oder nicht.

Nein - ich kann ihm auch Verbesserungsvorschläge machen.


> Wenn ich meinem Kunden sage, sein Datenbankmodell ist Mist, kann ich
> auch gleich sagen, er sei blöd.

Es ist natürlich eine Frage der Wortwahl - man könnte ihm beispielsweise
mitteilen, daß sein Datenbankmodell aufgrund von Mängeln früher oder
später an Grenzen stoßen wird und man sie deshalb möglichst frühzeitig
verbessern sollte.


> Du kannst das ja gern tun, Dein Chef wird sich freuen.

Natürlich wird er das, wenn ich ihm einen Verbesserungsvorschlag machen
kann.


> Wenn Du von der teilweisen Einsicht in zwei Tabellen, bereits das
> gesamte Datenbankmodell kennst,

Vom gesamten hat niemand geredet. Aber einen Teileinblick hat man damit
logischerweise und kann somit erkennen, ob da evtl. was nicht stimmt.

>> Je früher Du lernst, welche Faktoren die Performance bis zum
>> Stillstand beeinflussen können, (und das ist nunmal fehlende Indexe
>> und der Vergleich von Äpfeln mit Birnen, und bevor Du das jetzt als 2
>> Punkte betrachtest, lies die den Teil über Index durch.)
>
> Mysql ist aber durchaus in der Lage, unterscheidliche typen zu casten,
> so dass es damit klar kommen sollte. Steht auch im handbuch. Ich denke,
> das hast Du gelesen.

Für geeignete Werte von "klarkommen". Ich weiß jetzt nicht spontan,
welchen Teil des Handbuches Michael hier genau meint, aber die exzessive
Verwendung eines Casts - wie es bei einem Table-Join vorkommt - ist
natürlich auch entsprechend teuer, da es dabei selbstverständlich zu
Verzögerungen durch die Umwandlung kommen kann (und wird), weil es ja
eine zusätzliche Aktion ist.


>> Übrigens: Wenn man das Datenmodell anschaut und feststellt, dass es
>> völlig verkorxt ist muss man sich die Applikation nicht anschauen um
>> beurteilen zu können, das das zu schweren Problemen führen wird.
>>
>> Oder würdest Du einen Architekt, der festgestellt hat, dass das
>> Fundament Deines Hauses völlig kaputt ist, fragen: Wie können sie
>> behaupten, dass das Haus einsturzgefärdet ist, sie haben doch den
>> Firstbalken noch garnicht angeschaut.
>>
> Das ist jetzt Äpfel mit Birnen vergleichen, und wie hast Du dazu
> nochmal gesagt .......?

Das ist im Gegenteil eine 1:1-Abbildung:

Datenmodell -> Fundament
Applikation -> Dachfirst

wackeliges Fundament (schlechtes Datenmodell) -> Probleme sind
applikationsunabhängig vorprogrammiert.


Thomas
--
»Willst du meine Frau werden?« - »Fällt dir nichts Besseres ein?« -
»Doch, aber die wollen alle nicht...«

Re: zwei Tabellen

Mathias Fiedler wrote:

> es tut mir ja leid, aber ich kann der Argumentation nicht folgen.

Es kristallisiert sich immer mehr heraus, daß das das Problem ist.

> 1. Ein Index ist eine wichtige Sache, wird aber in den meisten kleine
> Anwendungen mit 100 - 500 Datenzeilen einfach nicht benötigt,

Und schon falsch. Der Index ist das, was eine Datenbank von einem
Flatfile (etwa CSV) unterscheidet. Ohne Index ist es keine Datenbank.

> Wenn man mit Indexen arbeiten muß, hat man schon ein
> größeres Datenbnbankdesign zu bewältigen als man benötigt um nur ein paar
> Newsartikel auf einer Homepage zu verwalten. Damit zählt der gesamte
> Sachverhalt für mich zum erweiterten Wissen.

Du phantasierst dir da eine Scheinwelt zusammen. Kein Wunder daß es
jedes Mal kracht, wenn du mit einem Einwohner *unseres* Universums
zusammentriffst.

Die Idee eines Suchbaums (nix anderes ist ein Index) ist ganz grund-
legend für jede Datenhaltung, die Daten schneller als O(n) finden soll.
Das ist elementares Grundwissen aus "Algorithmen und Datenstrukturen".
Das ist auch *nicht* schwer. Jeder Laie kann den "Index" eines Telefon-
buchs benutzen, um einen Namen zu finden.

Das Konzept "Index" ist *nicht* MySQL-spezifisch. Das ist noch nicht
mal Datenbank-spezifisch.

> 2. Ein Index war mir nicht unbekannt. Ich bin nur nicht darauf gekommen,
> den zu verwenden. Es handelt sich um den Vergleich von Int werten. Das
> dabei in Index einen Vorteil bringt, habe ich so nicht gesehen.

Vollkommen klar. Wenn du nicht weißt, was ein Index ist, kannst du den
Vorteil nicht erkennen.


XL

Re: zwei Tabellen

Mathias Fiedler wrote:

> Am Sun, 10 Sep 2006 schrieb Ulf Kadner:
>>Ja z.b. MySql-Grundlagen. Dazu zählen auch die Dinge, nach denen Deine
>>Frage gerichtet war.
>
> Eben nicht. Selbt in Unterrichtsbüchern vom Herdverlag für
> Datenbankgrundlagen wird das nur am Rande erwähnt.

Hallo Mathias!

Dann sind die Bücher schlecht.

>>War wohl MS ein Studien-Sponsor? :-)
>
> Nie, war es nicht. Du solltest wissen, das nur zugelassene und
> zertifizierte Schulungsunternehmen das machen dürfen. Die Vorgaben sind
> alle gleich.

Das Smiley sollte aussagen das es nicht ganz ernst gemeint war.

>>Du kannst das doch aber nicht mit einer NG vergleichen! Oder warum
>>erzählst Du das jetzt.
>
> Weil es um den Wissensstand für Schulung geht. Es ist doch keine Schande,
> wenn man auch als Lehrer, mal etwas nicht weis.

Alles weis kaum einer aber Basics sollte man schon drauf haben. Sonst
kommts ganz schnell zu einer Situation die peinlich werden könnte.

> Für die eventuellen Programmierer, die später mal daran arbeiten sollen,
> gbt es eine Dokumentation.

Das ist kein guter Stil! Den solltest Du Dir garnicht erst angewöhnen.
Im allgemeinen Programmierumfeld gilt immer. "Je mehr Dokumentation
notwendig ist um so kaputter ist das Design". Damit will ich nicht
sagen, das Dokumentationen unnötig sind. Aber z.B. selbstredende Namen
durch Dokumentationen zu ersetzen ist nicht im Sinne eines guten Stils.

>>Ach Du hast noch keinen durchgeführt? Naja dann hast Du ja noch ein
>>wenig Zeit Dein Wissen zu verbessern. Du solltest allerdings, schon
>>allein um Missverständnisse zu vermeiden und fair gegenüber Kunden zu
>>sein, auf Deiner Webseite darauf hinweisen, das nur rudimentäres
>>SQL-Wissen besteht!
>
> Das ist, mit Verlaub gesagt, Blödsinn. Dann müßte jeder Mediamarkt seine
> Kunden ebenfalls darauf hinweisen.

Es immer leicht ein schlechtes Beispiel zu nennen um seinen Standpunkt
zu verteidigen. Machs doch einfach besser wie die. Deine Kunden werdens
Dir danken!

> Ich habe meine Kenntnisse nicht überschätzt. Ich habe lediglich nicht mit
> dem Aufkommen dieses Problems, sprich INDEX, gerechnet.

*lach* Damit hast Du Deine Kenntnisse eindeutig überschätzt.

> Und wie ich da aufgepasst habe. Übrigens ist mein ursprünglich erlernter
> Beruf Kaufmann. Ich weis schon, worauf ich mich einlassen kann und woarauf
> nicht.

Scheinbar doch nicht.

> Natürlich hätte ich auch die Programmierung an der Stelle, wo die
> Erweiterungen bekannt wurden, wieder abblasen könnnn. Aber ich wollte es
> eben wissen, wies geht.

Eieiei. Bitte entschuldige aber mir kommt es so vor als hättest Du in
keiner Weise darüber nachgedacht was Du da gerad geschrieben hast.
Besonders im Kontext das Du Zeitprobleme hast.

Du läst Dich also auf etwas ein von dem Du spätestens seit dem Zeitpunkt
des Bekanntwerdens von Erweiterungen weist, das Du lernen must um dies
umzusetzen und kommst dann hier an und erzählst was von Zeitproblemen?
Was für nen schlechter Kaufman muss man den dazu sein?

Sorry, aber das verschlägt mir ja Direkt den Atem. Viel Spass noch bei
Lernen.

MfG, Ulf

Re: zwei Tabellen

Mathias Fiedler schrieb:
> Hallo,
> [...]
>
>
> Mysql ist aber durchaus in der Lage, unterscheidliche typen zu casten, so
> dass es damit klar kommen sollte. Steht auch im handbuch. Ich denke, das
> hast Du gelesen.
>

Ja und da liegt einer Deiner Irrtumer. Für Dich als Mensch sieht ein INT
genauso aus wie ein BIGINT, für eine Maschine aber nicht.

Stelle Dir vor ich gebe Dir 2 Liste a 1000 Zahlen ( beide bunt sortiert)
und fordere Dich aus, alle aus Liste 1 zu suchen, die auch in Liste 2
vorkommen. Ich nehme an, Du wirst dazu einige Zeit brauchen.

Ach ja, ich bin davon ausgegangen, dass Du Zahlen in arabischer
Schreibeweise und in römischer Schreibweise problemlos casten kannst,
deshalb ist eine der Listen in arabischen Ziffern, die andere nach Art
der Römer geschrieben. Verstehst Du, was ich Dir sagen möchte?

Hätte ich Dir die Listen aber dem Wert nach sortiert und vor allem im
gleichen Format gegeben, wärst Du um einiges schneller gewesen, oder?

In der Grundschule mag man sich vielleicht auch nur im Zahlenraum bis
100 aufhalten, aber trotzdem erwarte ich von den Lehrern, dass sie etwas
weiter als nur bis 110 rechnen können und mir nicht erzählen: "He, ich
kann mir den Rest immernoch anlesen, wenn ich mal die 5te Klasse
unterrichten sollte)

Gruß,
Michael