SQL für Dummies?

Hallo zusammen,
eigentlich arbeite ich nur administrativ mit SQL und entsprechenden
Datenbanken, daher fehlt mir jetzt irgendwie der richtige Weg...

Es geht um folgendes, wahrscheinlich ein Standartproblem für die
meisten, ich habe sagen wir mal 2 Tabellen:

Tab1
============================
ID fortlaufende Nummer
Name Vorname
Name2 Nachname z.b.

Tab2
============================
ID sollte mit der aus der ersten korrsponieder, Foreign Key?
Komm Feld für div. Information Telefon 1, email etc...

Das ist jetzt nur ein sehr einfaches Modell, ich möchte die Daten so
normalisiert (so nennt man das glaube ich?) halten wie nur möglich,
daher die Aufteilung.

Wenn ich jetzt Daten einfüge, geht das in einem Schritt über SQL oder
muss ich das von der Programmlogik abfangen? Mein Problem ist das ich
die ID nicht kenne (diese wird ja automatisch vergeben, von der DB) und
sie somit auch der 2ten Tabelle nicht mit übergeben kann. Funktioniert
ein Insert ÜBERHAUPT über 2 Tabellen?

Und wie funktioniert das mit dem Foreign Key? Wird beim anlegen in Tab2
dann geprüft ob die gerade anzulegende ID schon in der Tab1 exisitiert
und wenn nicht gibt es einen Fehler, oder wie darf ich mir das vorstellen?

Für alle Anregungen bin ich euch dankbar - auch für Links

Danke schon einmal

Gruß
Carsten Bliessen

Re: SQL für Dummies?

Carsten Bliessen schrieb:
> Hallo zusammen,
> eigentlich arbeite ich nur administrativ mit SQL und entsprechenden
> Datenbanken, daher fehlt mir jetzt irgendwie der richtige Weg...
>
> Es geht um folgendes, wahrscheinlich ein Standartproblem für die
^^^^^^^^
s/art/ard/

Es sei denn, Du meinst Flaggen, die vorne an Autos flattern.

> meisten, ich habe sagen wir mal 2 Tabellen:
>
> Tab1
> ============================
> ID fortlaufende Nummer
> Name Vorname
> Name2 Nachname z.b.
>

Warum nennst Du den Vornamen 'Name' und den Nachnamen 'Name2'?

> Tab2
> ============================
> ID sollte mit der aus der ersten korrsponieder, Foreign Key?
> Komm Feld für div. Information Telefon 1, email etc...
>

Möchtest Du jetzt in einem Feld mehrere Informationen speichern, also
Telefon, Email, Fax, Mobil, oder möchtest Du für *jede* dieser
Informationen einen eigenen Eintrag anlegen? Das kann man anhand
Deiner wirren Grammatik leider nicht erkennen. Im ersten Fall wirst Du
recht schnell Schwierigkeiten bekommen, das Gewünschte zu finden bzw.
einen Datensatz zu ändern...

> Das ist jetzt nur ein sehr einfaches Modell, ich möchte die Daten so
> normalisiert (so nennt man das glaube ich?) halten wie nur möglich,
> daher die Aufteilung.
>

Zum Thema Normalisierung wird hier immer wieder derselbe Text
empfohlen -> Google ist Dein Freund. Allerdings weiß ich nicht,
welcher Sinn darin stecken soll, Telefonnummern und E-Mail-Adressen
vom Namen der Person zu trennen - das hätte nur dann einen Zweck, wenn
mueller@blafasel.com für *mehrere* Personen eine sinnvolle
E-Mail-Adresse wäre. Oder wenn Du wirklich beliebig viele
verschiedenen Mail-Adressen und Telefonnummern für jede Person
vorsiehst. Für die meisten praktischen Fälle halte ich das für
Overkill, da tun es auch zwei Mail- und Telefonfelder sowie je eins
für Handy und Fax.

> Wenn ich jetzt Daten einfüge, geht das in einem Schritt über SQL oder
> muss ich das von der Programmlogik abfangen?
> Mein Problem ist das ich
> die ID nicht kenne (diese wird ja automatisch vergeben, von der DB) und
> sie somit auch der 2ten Tabelle nicht mit übergeben kann.

Du könntest die Datenbank ja *fragen*, welche ID sie als letzte
vergeben hat. Meistens ist sie nett und verrät es Dir.

>Funktioniert
> ein Insert ÜBERHAUPT über 2 Tabellen?

Nein. Übrigens gibt es eine Dokumentation zu MySQL unter dev.mysql.com

>
> Und wie funktioniert das mit dem Foreign Key? Wird beim anlegen in Tab2
> dann geprüft ob die gerade anzulegende ID schon in der Tab1 exisitiert
> und wenn nicht gibt es einen Fehler, oder wie darf ich mir das vorstellen?

Je nachdem. Wenn MySQL *weiß*, dass es ein FK ist und Du einen
geeigneten Tabellentyp benutzt, dann macht es das Richtige. Sonst nicht.

>
> Für alle Anregungen bin ich euch dankbar - auch für Links

Wie wäre es - Zaunpfahl - erstmal mit der Dokumentation zu MySQL?
Wahlweise dem Kofler?

Re: SQL für Dummies?

>> Tab1
>> ============================
>> ID fortlaufende Nummer
>> Name Vorname
>> Name2 Nachname z.b.
>>
>
> Warum nennst Du den Vornamen 'Name' und den Nachnamen 'Name2'?

Weil es für ein Beispiel ziemlich egal ist, oder?

>
>> Tab2
>> ============================
>> ID sollte mit der aus der ersten korrsponieder, Foreign Key?
>> Komm Feld für div. Information Telefon 1, email etc...
> Möchtest Du jetzt in einem Feld mehrere Informationen speichern, also
> Telefon, Email, Fax, Mobil, oder möchtest Du für *jede* dieser
> Informationen einen eigenen Eintrag anlegen? Das kann man anhand

Im grunde sollen da die Nutzdaten rein und in ein weiteres Feld die
Beschreibung. ID, KOMMART, KOMM hätte ich dann ...

> Deiner wirren Grammatik leider nicht erkennen. Im ersten Fall wirst Du
> recht schnell Schwierigkeiten bekommen, das Gewünschte zu finden bzw.
> einen Datensatz zu ändern...

Danke für die Blumen. Das ich mit nur einem Feld nicht auskomme war
klar, es ging bzw. geht ja auch mehr um das Prinzip.

> empfohlen -> Google ist Dein Freund. Allerdings weiß ich nicht,
> welcher Sinn darin stecken soll, Telefonnummern und E-Mail-Adressen
> vom Namen der Person zu trennen - das hätte nur dann einen Zweck, wenn

Mal abgesehen davon das es nur ein Beispiel ist, könnte es durchaus sein
das eine Person über mehrere Festnetznummern verfügt, oder? Oder
wahlweise über mehrere Handynummern oder emailadressen. Mit einer
starren Tabelle hätte ich da ein echtes Problem.

>> Wenn ich jetzt Daten einfüge, geht das in einem Schritt über SQL oder
>> muss ich das von der Programmlogik abfangen?
>> Mein Problem ist das ich
>> die ID nicht kenne (diese wird ja automatisch vergeben, von der DB) und
>> sie somit auch der 2ten Tabelle nicht mit übergeben kann.
>
> Du könntest die Datenbank ja *fragen*, welche ID sie als letzte
> vergeben hat. Meistens ist sie nett und verrät es Dir.

Echt? Die spricht nicht mit mir ... habe sie jetzt über fünf Minuten
angebrüllt und keine Reaktion provozieren können ... verdammt.

Na um es mal in meine wirre Grammatik bzw. Ausdrucksweise zu
transformieren: Ich benutze die Programmlogik. Danke für deine Antwort :-)

>> Funktioniert
>> ein Insert ÜBERHAUPT über 2 Tabellen?
> Nein. Übrigens gibt es eine Dokumentation zu MySQL unter dev.mysql.com

Ich weiss das es die gibt ... leider konnte ich darin aber nichts
entsprechendes finden. Sonst hätte ich ja nicht gefragt, oder? Wie ich
eingangs geschrieben hatte bin ich mehr in der Administration und komme
mit meinen selects, inserts und (vor allem) drops ganz gut zurecht, aber
ich bin eben kein Entwickler.

>> Und wie funktioniert das mit dem Foreign Key? Wird beim anlegen in Tab2
>> dann geprüft ob die gerade anzulegende ID schon in der Tab1 exisitiert
>> und wenn nicht gibt es einen Fehler, oder wie darf ich mir das vorstellen?
>
> Je nachdem. Wenn MySQL *weiß*, dass es ein FK ist und Du einen
> geeigneten Tabellentyp benutzt, dann macht es das Richtige. Sonst nicht.

Aha. Und *WAS* ist das richtige??? Lehnt die Tabelle das ab? Das ich der
Tabelle den freundlichen Hinweis geben muss ist mir schon klar!

Da fragt man mal freundlich was und wird direkt so angepatzt! Das Net
hat auch mal mehr spass gemacht...

Re: SQL fürDummies?

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: SQL für Dummies?

Carsten Bliessen schrieb:

> Mal abgesehen davon das es nur ein Beispiel ist, könnte es durchaus sein
> das eine Person über mehrere Festnetznummern verfügt, oder? Oder
> wahlweise über mehrere Handynummern oder emailadressen. Mit einer
> starren Tabelle hätte ich da ein echtes Problem.
>

Was versprichst Du Dir davon, derart selektiv zu zitieren? Ich hatte ja
selbst von mehreren Nummern gesprochen. Und natürlich hättest Du kein
besonderes Problem mit einer starren Tabelle. Hinreichend viele
Adressverwaltungen funktionieren genau so. Man kann Dinge auch durch
zuviel Design in den Defekt treiben.

>
> Na um es mal in meine wirre Grammatik bzw. Ausdrucksweise zu
> transformieren: Ich benutze die Programmlogik. Danke für deine Antwort :-)
>
Es gibt in jedem mir bekannten API für MySQL Funktionen, die die ID des
letzten eingefügten Datensatzes liefern. Auch in MySQLs Dialekt gibt es
die, also auf der Kommandozeile.

> Ich weiss das es die gibt ... leider konnte ich darin aber nichts
> entsprechendes finden.

Dann hast Du sie nicht gründlich gelesen. Die Online-Dokumentation kann
man durchsuchen.

>> Je nachdem. Wenn MySQL *weiß*, dass es ein FK ist und Du einen
>> geeigneten Tabellentyp benutzt, dann macht es das Richtige. Sonst nicht.
>
> Aha. Und *WAS* ist das richtige??? Lehnt die Tabelle das ab? Das ich der
> Tabelle den freundlichen Hinweis geben muss ist mir schon klar!
>
Wie wäre es denn, wenn Du mal die Suchfunktion in der Dokumentation
benutztest? Foreign Key sollte könnte ja die eine oder andere
Information liefern.

> Da fragt man mal freundlich was und wird direkt so angepatzt! Das Net
> hat auch mal mehr spass gemacht...

Das hier ist kein Vorleseclub. Die Syntax von INSERT ist dokumentiert.
Die Fähigkeiten von MySQL bzgl. Foreign Key Constraints auch. Warum
möchtest Du, dass Dir das jemand vorliest?

Re: SQL für Dummies?

> Was versprichst Du Dir davon, derart selektiv zu zitieren? Ich hatte ja
> selbst von mehreren Nummern gesprochen. Und natürlich hättest Du kein
> besonderes Problem mit einer starren Tabelle. Hinreichend viele
> Adressverwaltungen funktionieren genau so. Man kann Dinge auch durch
> zuviel Design in den Defekt treiben.

stimmt wohl

>> Na um es mal in meine wirre Grammatik bzw. Ausdrucksweise zu
>> transformieren: Ich benutze die Programmlogik. Danke für deine Antwort :-)
>>
> Es gibt in jedem mir bekannten API für MySQL Funktionen, die die ID des
> letzten eingefügten Datensatzes liefern. Auch in MySQLs Dialekt gibt es
> die, also auf der Kommandozeile.

Schön das du sie kennst ... MITLERWEILE weiss ich das auch ...


>> Ich weiss das es die gibt ... leider konnte ich darin aber nichts
>> entsprechendes finden.
>
> Dann hast Du sie nicht gründlich gelesen. Die Online-Dokumentation kann
> man durchsuchen.

Oh, echt? Nein wirklich? Und wonach? Finde mir den Begriff den ich nicht
kenne und dessen Erklärung bei den bisher gelesenem nicht dabei war???
Also mal im ernst, was glaubst DU eigentlich wofür solche Groups da
sind? Sicherlich nicht damit sich ein Experte mit seinem Wissen
gegenüber dem anderen profilieren kann!

>>> Je nachdem. Wenn MySQL *weiß*, dass es ein FK ist und Du einen
>>> geeigneten Tabellentyp benutzt, dann macht es das Richtige. Sonst nicht.
>> Aha. Und *WAS* ist das richtige??? Lehnt die Tabelle das ab? Das ich der
>> Tabelle den freundlichen Hinweis geben muss ist mir schon klar!
>>
> Wie wäre es denn, wenn Du mal die Suchfunktion in der Dokumentation
> benutztest? Foreign Key sollte könnte ja die eine oder andere
> Information liefern.

Da ich die Wirkungsweise nicht kannte war es nicht wirklich einfach das
richtige zu finden! JETZT wo ich weiss wonach ich suchen muss habe ich
natürlich auch entsprechende Kapitel in der Doku gefunden.

>> Da fragt man mal freundlich was und wird direkt so angepatzt! Das Net
>> hat auch mal mehr spass gemacht...
>
> Das hier ist kein Vorleseclub. Die Syntax von INSERT ist dokumentiert.
> Die Fähigkeiten von MySQL bzgl. Foreign Key Constraints auch. Warum
> möchtest Du, dass Dir das jemand vorliest?

Dokumentiert und Dokumentiert sind zwei verschiedene Dinge, wenn du dich
eingehender mit der IT beschäftigt hast, solltest du eigentlich wissen
das nicht alle Möglichkeiten IMMER dokumentiert sind. Ich habe nie darum
gebeten das mir irgendwas vorgelesen wird! Sondern nur um entsprechende
Hinweise gebeten.Gut das du noch nie ein Problem hattest und auf der
Suche nach hilfe warst ... die Ausgeburt an Toleranz! Unfassbar.

Sorry an alle für dieses OT Geschwätz!

Re: SQL für Dummies?

>> Echt? Die spricht nicht mit mir ... habe sie jetzt über fünf Minuten
>> angebrüllt und keine Reaktion provozieren können ... verdammt.
>
> Du könntest Deinen Ton etwas besser modulieren. Hint: Wald, Echo und
> so...

Ich werds versuchen

> Ich geb Dir mal ein Bleistift. Achtung: das ist _NICHT_ MySQL, also
> Copy&Paste könnte fehlschlagen:
>
> test=# begin;
> BEGIN
> test=# create table master (id serial primary key, name text);
> NOTICE: CREATE TABLE will create implicit sequence "master_id_seq" for serial column "master.id"
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "master_pkey" for table "master"
> CREATE TABLE
> test=# create table slave (id int references master, email text);
> CREATE TABLE
> test=# insert into master (name) values ('ich');
> INSERT 0 1
> test=# insert into slave (id, email) values (currval('master_id_seq'), 'ich@invalid.org');
> INSERT 0 1
> test=# insert into slave (id, email) values (2, 'ich@invalid.org');
> ERROR: insert or update on table "slave" violates foreign key constraint "slave_id_fkey"
> DETAIL: Key (id)=(2) is not present in table "master".

Danke für das Beispiel! Konnte anhand der Infos unter anderem
last_insert_id() (für dein currval() - Postgres?) finden. Kämpfe jetzt
zwar noch ein bisschen mit den Foreign Keys aber ich denke da wird mir
die Doku jetzt weiterhelfen können.

Danke dir noch mal!

Re: SQL fürDummies?

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: SQL für Dummies?

Hallo,

ich habe vor ca. 2 Wochen angefangen mich mit PHP und damit zwangsläufig
mit mySQL zu befassen.

Natürlich hab ich auch durch entsprechende Suchbegriffe nach Gropus
gesucht, die zum Thema passen.

Ehrlich gesagt, Gott sei Dank, bin ich als Anfänger in diesen Dingen
zuerst auf andere Foren gestoßen. Wenn ich mir jetzt so überlege, was
ich hier auf meine "Anfängerprobleme" so für Antworten bekommen hätte,
oh Gott, ich hätte mich in Grund und Boden geschämt.

Hier lese ich fast in jedem Posting,

mein Glasauge ....
Google ist Dein Freind .....
empfehle Dir erst mal ein gutes Buch zu lesen ....
wie wär's, wenn du erts Mal in der Hilfe nachschlägst ....
usw. usw.

Fürchterlich ein Ton, Mann oh Mann.

Ich gehe mal davon aus, dass es andere Anfänger und Nichtwissende
genauso machen wie ich.

Mann hat ein Problem und googelt erstmal mit den entsprechenden
Begriffen. Meistens gibt's Mio von Einträgen, also schränkt man weiter
ein. Trotzdem kein brauchbares Ergebnis. Ihr müßt ja auch bedenken, wenn
ich ein Problem so eingrenze, dass es nur ein paar Google-Einträge gibt,
kann ich das Problem meist alleine lösen.

Wenn ich dann in einem Forum oder einer Group frage, weiß ich einfach
nicht mehr weiter.

Wenn man dann erstmal um die Ohren bekommt, dass man zu blöd ist, um
....., also ehrlich, ich bin froh, dass es auch andere Foren und
Newsgroups zum Thema PHP, HTML und mySQL gibt.

Vielleicht denkt Ihr Profis trotzdem mal etwas über meine ersten
Eindrücke nach.

Viele Grüße

Josef

Re: SQL fürDummies?

Josef Koller wrote:

> ich habe vor ca. 2 Wochen angefangen mich mit PHP und damit zwangsläufig
> mit mySQL zu befassen.

Wieso zwangsläufig? Das eine hat mit dem anderen nur wenig zu tun.
Auch PostgrSQL läßt sich über PHP ansteuern. :-}


> Hier lese ich fast in jedem Posting,
>
> mein Glasauge ....

s/auge/kugel/. Das ist ein dezenter Hinweis darauf, daß ohne gewisse weitere
Angaben keine Hilfe möglich ist.

> Google ist Dein Freind .....

Stimmt.


> empfehle Dir erst mal ein gutes Buch zu lesen ....
> wie wär's, wenn du erts Mal in der Hilfe nachschlägst ....

Diese beiden Sachen sind auch wichtig.


> Fürchterlich ein Ton, Mann oh Mann.

Das stimmt leider - manche Hinweise sind etwas hart im Ton. Aber
andererseits kann ich die Ungehaltenheit einiger Mitlesender ebenfalls
verstehen - denn oft sind es dauernd dieselben Fragen, die sich
wiederholen. Solche Fragen lassen sich vermeiden, indem man erstmal eine
Weile mitliest und evtl. bereits gestellte/beantwortete Fragen sich zu
Gemüte zieht. Dort steht meistens auch schon ein Link zum Handbuch drin, in
welchem man dann weiterlesen kann. Und wenn das nichts hilft, kann man ja
immer noch hier fragen.

Thomas

Re: SQL für Dummies?

Josef Koller schrieb:

> mein Glasauge ....

Du meinst Glas*kugel*

> Google ist Dein Freind .....
> empfehle Dir erst mal ein gutes Buch zu lesen ....
> wie wär's, wenn du erts Mal in der Hilfe nachschlägst ....
> usw. usw.
>
> Fürchterlich ein Ton, Mann oh Mann.
>
> Ich gehe mal davon aus, dass es andere Anfänger und Nichtwissende
> genauso machen wie ich.
>
> Mann hat ein Problem und googelt erstmal mit den entsprechenden
> Begriffen.

Du irrst Dich. Viele Leute (nicht nur Männer, BTW) schlagen hier mit
den banalsten Fragen auf, die sie durch Lesen des *Handbuchs* (nicht
durch Googeln, wohlgemerkt!) beantworten könnten. Dafür gibt es
Handbücher: Damit man sie liest und aus ihnen alles Wichtige über ein
Produkt lernt. Newsgroups sind nicht dafür gedacht, solche Text
vorzulesen. Google hat auch nicht diese Funktion: Da kann man
Antworten auf Fragen finden, unter Umständen. Aber zum Lernen (und
darum sollte es doch wohl bei Anfängern gehen, oder?) ist das ein
denkbar ungeeignetes Medium.

> Meistens gibt's Mio von Einträgen, also schränkt man weiter
> ein. Trotzdem kein brauchbares Ergebnis. Ihr müßt ja auch bedenken, wenn
> ich ein Problem so eingrenze, dass es nur ein paar Google-Einträge gibt,
> kann ich das Problem meist alleine lösen.
>
Na, dann ist doch gut.

> Wenn ich dann in einem Forum oder einer Group frage, weiß ich einfach
> nicht mehr weiter.
>

Aber Du hast immer noch nicht das Handbuch gelesen, weil Du immer nur
Google benutzt. Warum nicht? Fragst Du bei Deiner neuen Waschmaschine
auch erst Google, oder guckst Du vielleicht vor dem Anschließen doch
mal in die mitgelieferte Gebrauchsanleitung?

> Wenn man dann erstmal um die Ohren bekommt, dass man zu blöd ist, um
> ...., also ehrlich, ich bin froh, dass es auch andere Foren und
> Newsgroups zum Thema PHP, HTML und mySQL gibt.
>
> Vielleicht denkt Ihr Profis trotzdem mal etwas über meine ersten
> Eindrücke nach.

Nein. Die Lebenserfahrung spricht dafür, dass das von Dir Beschriebene
("Erstmal selber suchen") die Ausnahme ist. Abgesehen davon benutzt
auch Du eine untaugliche Strategie, um Dich mit einem Produkt vertraut
zu machen - wie haufenweise Leute, die hier aufschlagen. Mit "zu blöd"
hat das gerade gar nichts zu tun, sondern mit "zu bequem" und "zu
faul". Und *das* werde ich weiterhin jedem um die Ohren hauen, bei dem
es passt.

MySQL ist eine Datenbank, kein Spielzeugauto. Wer damit arbeiten
(arbeiten!) will, der möge bitte ein Mindestmaß an Professionalität
und Engagement mitbringen. Dazu gehört zuerst die Lektüre des
Handbuchs, dann das Lesen weiterer Bücher zum Thema (etwa der Kofler
zu MySQL & PHP, wenn man denn beides zusammen benutzen muss). Fragen,
die danach noch bleiben, kann man mit Hilfe einer Suchmaschine
versuchen zu klären.
Wem das alles zuviel Arbeit (Arbeit!) ist, der muss halt damit leben,
dass andere ihm die nicht abnehmen. That's live in a big city.

Re: SQL für Dummies?

Josef Koller schrieb:
>=20
> Ich gehe mal davon aus, dass es andere Anfänger und Nichtwissende
> genauso machen wie ich.
>=20
> Mann hat ein Problem und googelt erstmal mit den entsprechenden
> Begriffen. Meistens gibt's Mio von Einträgen, also schränkt man wei=
ter
> ein. Trotzdem kein brauchbares Ergebnis. Ihr müßt ja auch bedenken,=
wenn
> ich ein Problem so eingrenze, dass es nur ein paar Google-Einträge gi=
bt,
> kann ich das Problem meist alleine lösen.
>=20

Das halte ich für den falschen Einstieg, wenn ich Dein "Anfänger und
Nichtwissende" ernst nehme. Google konsultieren hat erst Sinn, wenn ich
die Grundlagen, egal von was, halbwegs begriffen habe.

Erst kommt die Suche nach einer Einführung, gedruckt oder online, die
das Zeug, hier meinetwegen SQL, im Zusammenhang erklärt. Das kann keine=

Newsgroup oder Mailingliste ersetzen, ganz egal, ob sie sich
anfängerfreundlich zu verhalten versucht oder nicht.

--=20
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg
e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE

Re: SQL fürDummies?

Sibylle Koczian wrote:

> Das halte ich für den falschen Einstieg, wenn ich Dein "Anfänger und
> Nichtwissende" ernst nehme. Google konsultieren hat erst Sinn, wenn ich
> die Grundlagen, egal von was, halbwegs begriffen habe.

Jein, denn...

> Erst kommt die Suche nach einer Einführung, gedruckt oder online, die
> das Zeug, hier meinetwegen SQL, im Zusammenhang erklärt.

.... die kann auch über Google gefunden werden - allerdings nur mit den
richtigen Suchbegriffen.


Thomas

Re: SQL für Dummies?

Hallo,

ich möchte gerne an zwei Beispielen erläutern, was ich meine:

In diesem Posting SQL für Dummies geht schon aus dem Betreff hervor,
dass der Verfaser nicht zu den Cracks dieser Materie gehört. Da wäre es
doch ein leichtes für Profis z. B. auf seine Frage, wie er denn die ID
des gerade per INSERT eigetragenen Datensatzes bekommt.

Eine Antwort könnte dann so ausehen:

mysql_insert_id()

Weiter könnte dann immer noch der Verweis auf das Manual erfolgen. Der
Fragende hat mit dieser antwort ja dann auch schon ein passendes
Schlüsselwort. Wenn er dieses mysql_insert nicht hat, muss er beim
Suchen schon wieder alles mögliche eintragen mysql, insert, neue, ID,
Rückgabe oder so ähnlich.

Man kommt damit wieder vom 100-sten ins 1000-ste.

Oder ein weiteres Beispiel:

Jemand hat ein Probelm mit der Jahrtausendwende. Wie soll er in einer
SQL-Abfrage zustandebringen, dass .67, .88, .00, .05 in der
aufsteigenden Reihenfolge soriert und ausgegeben werden?

select ''19'' as JH, KoNummer, KoJahr from zucht where KoJahr >= ''.80''
union select ''20'' as JH, Konummer, KoJahr from zucht where KoJahr <
''.80'' order by JH desc, Kojahr desc'

(Das Ding ist nicht vollständig, hab's nur mal schnell eben bei mir
rauskopiert.

Wenn man dann als Fragender solche Antworten sieht, sieht man, ahaa auf
das UNION incl. zweitem SELECT kommt es an.

Der Fragende hat dann zwei Schlüsselwörter, die ihm bei der Suche in
Manualen weiterhelfen. Wenn er nicht weiß, dass er nach UNION suchen
muss und es ihm keiner sagt, wie soll er da zu einem Ergebnis kommen?

Also springt über eueren Schatten und bringt Euere Sprüche erst nach
einer konkreten Antwort zu Papier, ähaa zum Monitor. Auch falsch, ist ja
egal.

Natürlich stimmt es, dass man sich bestimmte Dinge durch Lesen von
Büchern und Trutorials aneignen kann. Ich habe es auch nicht anderes
gemacht.

Ich denke aber, nichts ersetzt die Praxis. Selbst wenn man meint,
momentan alles Grundlegende gelesen zu haben, stößt man bei einem
eigenen Testprojekt sehr schnell an seine Grenzen.

Da ist es einfach gut, wenn man eine Newsgroup kennt, die einem dann
über Hürden hinweghilft. Für den Fragenden sind diese Hürden riesige
Berge für den Antwortenden würden meistens 2 Zeilen reichen.

Viele Grüße

Josef

P.S.
Übrigens das Beispiel mit der Waschmaschine war gut. Aber merkst Du den
Unterton darin? Wenn Du ein paar Worter umdrehen würdest, wäre der Sinn
der Gleiche, nur es käme halt freundlicher und weniger verletzend rüber.
Etwas Respekt und Höflichkeit untereinander gepaart mit
Hilsfbereitschaft kostet nichts, ist schnell erledigt und macht glücklich.

Re: SQL für Dummies?

Thomas Rachel schrieb:
> Sibylle Koczian wrote:
>=20
>=20
>>Das halte ich für den falschen Einstieg, wenn ich Dein "Anfänger un=
d
>>Nichtwissende" ernst nehme. Google konsultieren hat erst Sinn, wenn ich=

>>die Grundlagen, egal von was, halbwegs begriffen habe.
>=20
>=20
> Jein, denn...
>=20
>=20
>>Erst kommt die Suche nach einer Einführung, gedruckt oder online, die=

>>das Zeug, hier meinetwegen SQL, im Zusammenhang erklärt.
>=20
>=20
> ... die kann auch über Google gefunden werden - allerdings nur mit de=
n
> richtigen Suchbegriffen.
>=20

Kann. Aber zuerst würde ich da die Informationen direkt beim Hersteller=

heranziehen (führt mich im Fall von MySQL mindestens direkt auf die
offizielle Dokumentation, in anderen Fällen evtl. auf eine ganze Auswah=
l
von Online-Tutorials), und außerdem Bibliothekskataloge, ersatzweise
eine ordentliche Buchhandlung. Scheint mir der direktere Weg (und
liefert im Erfolgsfall die richtigen Suchbegriffe). Das ist allerdings
sekundär gegenüber der Feststellung, dass erst mal zusammenhängende=

Grundinformationen her müssen und dann offen gebliebene Einzelfragen
geklärt werden können.

So weit einig?

--=20
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg
e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE

Re: SQL fürDummies?

Sibylle Koczian wrote:

> Kann. Aber zuerst würde ich da die Informationen direkt beim Hersteller
> heranziehen (führt mich im Fall von MySQL mindestens direkt auf die
> offizielle Dokumentation, in anderen Fällen evtl. auf eine ganze Auswahl
> von Online-Tutorials),

.... die man aber auch über Google finden kann.

> ... Feststellung, dass erst mal zusammenhängende Grundinformationen her
> müssen und dann offen gebliebene Einzelfragen geklärt werden können.
>
> So weit einig?

Das auf jeden Fall.


Thomas

Re: SQL für Dummies?

Josef Koller schrieb:
> Hallo,
>=20
> ich möchte gerne an zwei Beispielen erläutern, was ich meine:
>=20
> In diesem Posting SQL für Dummies geht schon aus dem Betreff hervor,
> dass der Verfaser nicht zu den Cracks dieser Materie gehört. Da wär=
e es
> doch ein leichtes für Profis z. B. auf seine Frage, wie er denn die I=
D
> des gerade per INSERT eigetragenen Datensatzes bekommt.
>=20
Es geht doch nicht darum, dass die Antwort für Kenner leicht zu geben
ist. Es geht darum, dass hundert oder tausend oder hunderttausend
Antworten auf Einzelfragen kein Wissen ergeben, wenn sie nicht in ein
vorhandenes Grundgerüst eingebaut werden können.

> Eine Antwort könnte dann so ausehen:
>=20
> mysql_insert_id()
>=20

Und das ist noch nicht einmal richtig, jedenfalls nicht für den
Kommandozeilen-Client.

>=20
> Natürlich stimmt es, dass man sich bestimmte Dinge durch Lesen von
> Büchern und Trutorials aneignen kann. Ich habe es auch nicht anderes
> gemacht.
>=20

Der Witz ist, dass es _ohne_ das _nicht_ geht. Und die unfreundlichen
Antworten stammen aus der Annahme, dass jemand eben diesen untauglichen
Versuch macht.

> Ich denke aber, nichts ersetzt die Praxis. Selbst wenn man meint,
> momentan alles Grundlegende gelesen zu haben, stößt man bei einem
> eigenen Testprojekt sehr schnell an seine Grenzen.
>=20

Mit Grundlagenwissen wirst Du aber Deine Fragen von allein geschickter
formulieren und dann auch vernünftige Antworten kriegen.

Es gab mal eine Wissenschaftssendung mit dem Untertitel "... was nicht
im Lexikon steht". Dafür sind Newsgroups da.

--=20
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg
e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE

Re: SQL für Dummies?

Josef Koller schrieb:
> Hallo,
>
> ich möchte gerne an zwei Beispielen erläutern, was ich meine:
>
> In diesem Posting SQL für Dummies geht schon aus dem Betreff hervor,
> dass der Verfaser nicht zu den Cracks dieser Materie gehört. Da wäre es
> doch ein leichtes für Profis z. B. auf seine Frage, wie er denn die ID
> des gerade per INSERT eigetragenen Datensatzes bekommt.
>
> Eine Antwort könnte dann so ausehen:
>
> mysql_insert_id()
>

Klar. Und was wäre damit gewonnen? "Gib einem Hungrigen einen Fisch,
und er ist für einen Tag satt. Gib ihm eine Angel, und er hat für den
Rest seines Lebens was zu essen."

MaW: Warum sollte ich ihm das Manual vorlesen und ihn daran gewöhnen,
dass da schon irgendwelche Leute sind, die ihm die Arbeit (ja, immer
wieder dieses Wort) abnehmen?

> Weiter könnte dann immer noch der Verweis auf das Manual erfolgen. Der
> Fragende hat mit dieser antwort ja dann auch schon ein passendes
> Schlüsselwort. Wenn er dieses mysql_insert nicht hat, muss er beim
> Suchen schon wieder alles mögliche eintragen mysql, insert, neue, ID,
> Rückgabe oder so ähnlich.
>

Und was genau spräche Deiner Meinung nach dagegen, einfach mal das
Handbuch einer komplexen Software von vorne bis hinten durchzulesen,
bevor man damit anfängt zu arbeiten? Bei jeder hinreichend komplexen
Technik gilt das als allgemein übliches Verfahren - nur bei MySQL soll
es plötzlich anders sein?

Wer aber einmal den ganzen Kram durchgelesen hat, der *weiß*, dass es
da irgendwo so eine Funktion gab, und der weiß dann auch, wo er/sie
suchen kann.

Im konkreten Fall ist Dein Einwand übrigens Unsinn: Ich habe mal
'auto_increment' als Suchbegriff in die Online-Version des Handbuchs
eingegeben. Der zweite Treffer war
http://dev.mysql.com/doc/refman/5.0/en/example-auto-incremen t.html,
und genau dort taucht auch last_insert_id() auf. Das ist ein Abschnitt
aus dem TUTORIAL. Du möchtest also die Bequemlichkeit verteidigen,
dass jemand nicht mal das Tutorial aufmerksam gelesen hat. Warum?

> Jemand hat ein Probelm mit der Jahrtausendwende. Wie soll er in einer
> SQL-Abfrage zustandebringen, dass .67, .88, .00, .05 in der
> aufsteigenden Reihenfolge soriert und ausgegeben werden?
>
> select ''19'' as JH, KoNummer, KoJahr from zucht where KoJahr >= ''.80''
> union select ''20'' as JH, Konummer, KoJahr from zucht where KoJahr <
> ''.80'' order by JH desc, Kojahr desc'
>
> (Das Ding ist nicht vollständig, hab's nur mal schnell eben bei mir
> rauskopiert.
>

Yuck. Darf man das jetzt so interpretieren, dass Du die Zehner- und
Einerstellen eines Jahres als Floats in einer Spalte speicherst und
anschließend versuchst, genau *was* rauszubekommen? The mind boggles.

UNION ist in diesem Fall *nicht* die Lösung des Problems (was auch
immer das Problem ist).
Du bastelst aufwendig damit rum, hast aber offenbar noch nicht mal
kapiert, wozu es sowas wie DATE als Datentyp in (My)SQL gibt. Jetzt
willst Du wissen, wie man irgendwelche obskuren Jahrhundertdinge
lösen kann, wenn man ein kapottes Datenmodell hat -> flasche Frage.
Reparier' Deine Datentypen. Dann kann man nämlich einfach "ORDER BY
YEAR(datumsspalte)" machen und fertig. Und *das* wiederum ist
Basistechnik, also Handbuchmaterial.

> Wenn man dann als Fragender solche Antworten sieht, sieht man, ahaa auf
> das UNION incl. zweitem SELECT kommt es an.
>

Echt? Das hätte ich nicht gesehen, aber ich habe noch nicht mal die
Frage verstanden.

> Der Fragende hat dann zwei Schlüsselwörter, die ihm bei der Suche in
> Manualen weiterhelfen. Wenn er nicht weiß, dass er nach UNION suchen
> muss und es ihm keiner sagt, wie soll er da zu einem Ergebnis kommen?
>

Wenn jemand nicht weiß, dass es UNION in SQL gibt, warum will er dann
so einen komplizierten Kram machen? Weil das jetzt irgendwie dazu
gehört, so wie WM-Begeisterung und Müsli beim Frühstück? Solche
Datenmodelle sind krank, die muss man heilemachen (immer unter der
Prämisse, dass ich überhaupt verstanden habe, was das Ziel dieser
Abfrage ist).

> Ich denke aber, nichts ersetzt die Praxis. Selbst wenn man meint,
> momentan alles Grundlegende gelesen zu haben, stößt man bei einem
> eigenen Testprojekt sehr schnell an seine Grenzen.
>

Bei Deinen Beispielen ging es jedesmal um trivialen Kram (ich bitte um
Entschuldigung, falls das zweite eine echt komplizierte Angelegenheit
gewesen sein sollte - da hab' ich dann wohl die Erklärung nicht
verstanden). Und zwar genau der Art, die man ohne besondere Praxis
durch (Mit)lesen und vernünftiges Suchen lösen kann.

> Übrigens das Beispiel mit der Waschmaschine war gut. Aber merkst Du den
> Unterton darin? Wenn Du ein paar Worter umdrehen würdest, wäre der Sinn
> der Gleiche, nur es käme halt freundlicher und weniger verletzend rüber.
> Etwas Respekt und Höflichkeit untereinander gepaart mit
> Hilsfbereitschaft kostet nichts, ist schnell erledigt und macht glücklich.

Hier ist kein Kindergarten, in dem eine nette Tante den Kleinen über
den Kopf streicheln und "eieiei" sagen muss: Wer seine eigene
Bequemlichkeit und Faulheit für wichtiger hält als die Zeit *anderer*,
muss halt mit dem Echo leben. Wer ein echtes Problem hat, dem wird
hier immer geholfen. Aber der Verweis auf das Handbuch ist eben auch
Hilfe.

Re: SQL für Dummies?

Hallo,

ich dachte, mit meinen Beispielen würde ich aufzeigen können, woran es
m.E. in dieser Group mangelt.

Noch ein Versuch:
Schau einfach mal in andere Groups (Delphi Datenbanken. z. b.)
vielleicht verstehst du dann, was ich meine.

Dass mit den Jahreszahlen ist, wenn ich es selbst mache, so wie Du
schreibst. Manchmal muss man aber auch Dinge in Kauf nehmen, die man
nicht beeinflussen kann und man braucht trotzdem eine Lösung.

Ich würde aber den "Erzeuger" einer derartigen Tabellenstruktur nicht
als krank oder sonstwas bezeichnen. Er hatte bestimmt auch irgendwelche
Zwänge oder was weiß ich, um zu einem derartigen Tabellenaufbau zu kommen.

Aber, ich sehe schon, wäre wahrscheinlich besser gewesen, ich hätte
nicht mit diesem "Benimm-Thema" angefangen. Wenigstens wollte ich mal
auf diesen braschen Ton hier hingewiesen haben.

Josef

Re: SQL für Dummies?

Josef Koller wrote:
>
> ich dachte, mit meinen Beispielen würde ich aufzeigen können, woran es
> m.E. in dieser Group mangelt.

Das ist dir mißlungen.

> Dass mit den Jahreszahlen ist, wenn ich es selbst mache, so wie Du
> schreibst. Manchmal muss man aber auch Dinge in Kauf nehmen, die man
> nicht beeinflussen kann und man braucht trotzdem eine Lösung.
>
> Ich würde aber den "Erzeuger" einer derartigen Tabellenstruktur nicht
> als krank oder sonstwas bezeichnen.

Das hat Christian nicht getan. Er hat die Struktur krank genannt.

> Er hatte bestimmt auch irgendwelche
> Zwänge oder was weiß ich, um zu einem derartigen Tabellenaufbau zu kommen.

Die wenigsten Leute haben das. Die Erfahrung zeigt, daß viele Leute
einfach keine Ahnung haben.

> Aber, ich sehe schon, wäre wahrscheinlich besser gewesen, ich hätte
> nicht mit diesem "Benimm-Thema" angefangen. Wenigstens wollte ich mal
> auf diesen braschen Ton hier hingewiesen haben.

Du scheinst sehr wenig Erfahrung im Usenet zu haben. Aber du bist
herzlich eingeladen, hierzubleiben und für die nächsten Wochen und
Monate das Handbuch vorzulesen. Wenn du die gleiche Frage dann das
zehnte Mal in 3 Wochen beantwortest hast, werden wir sehen, wie lange
deine guten Vorsätze halten.


XL

Re: SQL für Dummies?

Hallo,

ich nochmal. Vor lauter Begeisertung über die Reaktionen auf mein
Posting hätte ich fast eine Frage vergessen:

Dieser Jahrtausendwechsel, den ich mit meinem Beispiel aufgeführt habe,
ist ein reeles Problem für mich.

Es handelt sich dabei um einen Zuchtverein. Die Abstammung wird seit
ehedem so geschrieben:

B1(KK) = .04-B12(II) ins B25(IK)

Erläuterung dazu:

B1(KK) ist das Zuchttier.
..04 ist das Geburtsjahr dieses Zuchttiers.
B12(II) ist die Mutter des Zuchtiers B1(KK)
ins bedeutet instrumentelle Besammung
B25(IK) ist der Vater

Diese Abstammungsnachweise reichen bis zum Jahr 1919 zurück. Also .19

Ich habe mir momentan damit beholfen, dass ich eben dieses >80 usw.
verwendete, um die Jahresangaben eben von 04 auf 2004 und von .89 auf
1989 zu erweitern.

Wie schon geschrieben, dass exestiert alles schon so. Die Schreibweise
wird auch nicht geändert. Nun bin ich am Reden mit denen, diese ganze
Abstammungsgeschichte übers Internet direkt von den Züchtern abwickeln
bzw. eintragen zu lassen. Vielleicht kann ich dann bei sieser Umstellung
auch gleich diese Datums-Jahresgeschichte bereinigen.

Sie erwarten also dann ein Eingabefeld(Textfeld), in dass sie z. B. wie
gewohnt .04 oder eben .75 für das Geburtsjahr eingeben können.

Jetzt steht in dem Feld .75. Ich müßte dann mit (so denke ich mir das
wenigstens abfragen:

If Textfeld > 00 dann mache aus .xx 20xx, if kleiner dann 19xx, um das
ganze in ein Datenbankfeld zu bekommen, um dann so weitermachen zu
können wie du schreibst:

[...]Dann kann man nämlich einfach "ORDER BY
YEAR(datumsspalte)" machen und fertig.[...]

Wie würdest Du an sowas rangehen?

Vielen Dank

Josef

P.S.
Wenn's irgend geht, bitte keine Antwort nach dem Motto:
[...]
Du bastelst aufwendig damit rum, hast aber offenbar noch nicht mal
kapiert, wozu es sowas wie DATE als Datentyp in (My)SQL gibt.
[...]

Re: SQL fürDummies?

Hi,

eigentlich enthalte ich mich diesen Diskussionen, denn die habe ich in
beinahe 20 Jahren viel zu oft geführt. Fakt ist, das der Umgangston im
Usenet nicht mehr der ist, der er mal war und Fakt ist auch, das
Anfänger in vielen Gruppen keine sinnvollen Antworten mehr bekommen. Der
Hinweis auf Google ist anmaßend und unverschämt.

Josef - Du sprichst mir aus der Seele!

--
Webmaster-Onlineforum - Alles zu MyQL, PHP, (X)HTML und Co...
http://www.buecher-von-ruettger.de

Re: SQL für Dummies?

Josef Koller schrieb:
> Es handelt sich dabei um einen Zuchtverein. Die Abstammung wird seit
> ehedem so geschrieben:
>=20
> B1(KK) =3D .04-B12(II) ins B25(IK)
>=20
> Erläuterung dazu:
>=20
> B1(KK) ist das Zuchttier.
> .04 ist das Geburtsjahr dieses Zuchttiers.
> B12(II) ist die Mutter des Zuchtiers B1(KK)
> ins bedeutet instrumentelle Besammung
> B25(IK) ist der Vater
>=20
> Diese Abstammungsnachweise reichen bis zum Jahr 1919 zurück. Also .19=

>=20
> Ich habe mir momentan damit beholfen, dass ich eben dieses >80 usw.
> verwendete, um die Jahresangaben eben von 04 auf 2004 und von .89 auf
> 1989 zu erweitern.
>=20
> Wie schon geschrieben, dass exestiert alles schon so. Die Schreibweise
> wird auch nicht geändert. Nun bin ich am Reden mit denen, diese ganze=

> Abstammungsgeschichte übers Internet direkt von den Züchtern abwick=
eln
> bzw. eintragen zu lassen. Vielleicht kann ich dann bei sieser Umstellun=
g
> auch gleich diese Datums-Jahresgeschichte bereinigen.
>=20

Unbedingt, und zwar jetzt. So lange man noch mit einiger Sicherheit die
unvollständigen Jahreszahlen richtig interpretieren kann. Oder bist Du
ganz sicher, dass die Daten als solche (nicht unbedingt die Anwendung,
die Du jetzt schreibst) nach 2080 nicht mehr interessieren?

> Sie erwarten also dann ein Eingabefeld(Textfeld), in dass sie z. B. wie=

> gewohnt .04 oder eben .75 für das Geburtsjahr eingeben können.
>=20
> Jetzt steht in dem Feld .75. Ich müßte dann mit (so denke ich mir d=
as
> wenigstens abfragen:
>=20
> If Textfeld > 00 dann mache aus .xx 20xx, if kleiner dann 19xx, um das
> ganze in ein Datenbankfeld zu bekommen, um dann so weitermachen zu
> können wie du schreibst:
>=20

Ich meine, dass man nach dem Theater um die Jahreswende 1999/2000 von
_jedermann_ erwarten kann, Jahreszahlen vollständig hinzuschreiben. Das=

heißt, ich würde keine Tänze in der Anwendung veranstalten, sondern=
auf
eine unvollständige Jahresangabe mit einer Fehlermeldung reagieren. Den=
n
ich verstehe Dein Beispiel so, dass die Daten, die jetzt eingegeben
werden, durchaus ins vorige Jahrhundert gehören können.

(Und die Abfrage "Textfeld > 00" war sicher ein Tippfehler? Da ist das
Ergebnis immer "wahr".)

--=20
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg
e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE

Re: SQL für Dummies?

Josef Koller schrieb:
> ich nochmal. Vor lauter Begeisertung über die Reaktionen auf mein=20
> Posting hätte ich fast eine Frage vergessen:

Du hast übrigens auch immer vergessen zu quoten. Schau mal auf=20
http://learn.to/quote vorbei und liess es dir durch.

> Es handelt sich dabei um einen Zuchtverein. Die Abstammung wird seit=20
> ehedem so geschrieben:
>=20
> B1(KK) =3D .04-B12(II) ins B25(IK)
>=20
> Erläuterung dazu:
>=20
> B1(KK) ist das Zuchttier.
> .04 ist das Geburtsjahr dieses Zuchttiers.
> B12(II) ist die Mutter des Zuchtiers B1(KK)
> ins bedeutet instrumentelle Besammung
> B25(IK) ist der Vater
>=20
> Diese Abstammungsnachweise reichen bis zum Jahr 1919 zurück. Also .19=

>=20
> Ich habe mir momentan damit beholfen, dass ich eben dieses >80 usw.=20
> verwendete, um die Jahresangaben eben von 04 auf 2004 und von .89 auf=20
> 1989 zu erweitern.
>=20
> Wie schon geschrieben, dass exestiert alles schon so. Die Schreibweise =

> wird auch nicht geändert.=20

Spätestens in 13 Jahren _muss_ man das ändern.

> Sie erwarten also dann ein Eingabefeld(Textfeld), in dass sie z. B. wie=
=20
> gewohnt .04 oder eben .75 für das Geburtsjahr eingeben können.
>=20
> Jetzt steht in dem Feld .75. Ich müßte dann mit (so denke ich mir d=
as=20
> wenigstens abfragen:

Und da ist das Problem. Nimm doch nicht einfach an, was die User=20
eingeben, sondern zerlege es sinnvoll.
B1(KK) =3D .04-B12(II) ins B25(IK)

Wird zu:

Tabelle Tier:
Bezeichnung VARCHAR()
Geburtsjahr DATE()
Vatertier VARCHAR()
Muttertier VARCHAR()
Besamungstechnik VARCHAR()

Natürlich würde ich die Tiere noch ausnormalisieren usw.
Du solltest also deinem Frontend beibringen, die Werte auseinander zu=20
nehmen und dann mit den richtigen Datentypen in die richtigen Spalten zu =

speichern.

m/([A-Z]\d+\([A-Z]{2}\) =3D \.(\d{2})-([A-Z]\d+\([A-Z]{2}\) (.*?)=20
([A-Z]\d+\([A-Z]{2}\)/

Würdest du ja zur Kontrolle der Eingabe eh verwenden (oder so ähnlich=
).=20
Dann hast du schon die einzelnen Felder und kannst sie richtig=20
speichern. Bei der Ausgabe stellst du es wieder in der gewohnten Syntax=20
dar... nur mit Zusatzfunktionen wie: Klick auf die Bezeichnung der=20
Mutter führt zur Abstammung eben dieser.


> If Textfeld > 00 dann mache aus .xx 20xx, if kleiner dann 19xx, um das =

> ganze in ein Datenbankfeld zu bekommen, um dann so weitermachen zu=20
> können wie du schreibst:
>=20
> [...]Dann kann man nämlich einfach "ORDER BY
> YEAR(datumsspalte)" machen und fertig.[...]
>=20
> Wie würdest Du an sowas rangehen?

Wie er schon geschrieben hat: ein vernünftiges Datenmodell. Darstellung=
=20
!=3D Speicherung !=3D Eingabe.


--=20
HTH,
Fabian

Re: SQL für Dummies?

Hallo,
[...]
Ich meine, dass man nach dem Theater um die Jahreswende 1999/2000 von
_jedermann_ erwarten kann, Jahreszahlen vollständig hinzuschreiben. Das
heißt, ich würde keine Tänze in der Anwendung veranstalten, sondern auf
eine unvollständige Jahresangabe mit einer Fehlermeldung reagieren. Denn
ich verstehe Dein Beispiel so, dass die Daten, die jetzt eingegeben
werden, durchaus ins vorige Jahrhundert gehören können.
[...]

Ich habe schon versucht, den Leuten zu erklären, dass es bei derartig langen
Stammbäumen, die Möglichkeit gibt, dass die gekürzte Jahresangabe .17
zweimal vorkommen kann. Eben 1917 und in Zukunft 2017.

Ich kann jetzt, wie ich schon schrieb zwar alles was 00 bis 17 ist um 20,
also auf 2000 bis 2017 erweitern (im Beispiel stand 80, ist auch nur so eine
Krücke), alles was darunter ist mit 19 versehen, um die korrekte Jahreszahl
in die DB zu bekommen.
Vielleicht git es mich ja 2017, wo es dann zu Konflikten kommen kann, nicht
mehr und das Ganze wäre mir dann egal.

Dass blöde an der Geschichte ist eben nur, die sind so an dieses .00
gewohnt, dass sie einfach bei einer Ausgabe die

Zeile so erwarten:

B1(KK) = .04-B12(II) ins B25(IK)

und nicht

B1(KK) = 2004-B12(II) ins B25(IK)

und die Daten auch so eingeben wollen.

Ich sehe momentan auch keine andere Möglichkeit, als einfach von denen zu
verlangen, dass sie in das Textfeld eben 2004 und nicht .04 eingeben.

Bei der Ausgabe könnte ich ja dann die ersten zwei Zeichen wieder
abschneiden. Dann kommt aber bestimmt wieder die Frage, wieso soll ich 2004
eingeben, wenn Du trotzdem .04 draus machen kannst. Irgendwie geb ich's noch
nicht auf. Vielleicht hat ja doch jemand eine Idee, wie man sowas handelt?

Vielen Dank.

Josef

[OT] Arme Newbies? was: SQL für Dummies?

Michael Rüttger meinte:
> Hi,
>
> eigentlich enthalte ich mich diesen Diskussionen, denn die habe ich in
> beinahe 20 Jahren viel zu oft geführt. Fakt ist, das der Umgangston im
> Usenet nicht mehr der ist,

Früher *war* einfach alles besser.

> der er mal war und Fakt ist auch, das
> Anfänger in vielen Gruppen keine sinnvollen Antworten mehr bekommen.

Spricht was gegen den Kauf von Büchern? Etwa "MySQL für Dummies"?

> Der
> Hinweis auf Google ist anmaßend und unverschämt.

Früher hat's Google noch nicht gegeben.

> Josef - Du sprichst mir aus der Seele!

Sein Tipp ist - zumindest in diser NG - unbrauchbar.

> --
> Webmaster-Onlineforum - Alles zu MyQL, PHP, (X)HTML und Co...
> http://www.buecher-von-ruettger.de

Dein Sig-Trenner ist hinüber.


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: SQL für Dummies?

Hallo,

[...]
Würdest du ja zur Kontrolle der Eingabe eh verwenden (oder so ähnlich).
Dann hast du schon die einzelnen Felder und kannst sie richtig
speichern.
[...]

Danke. Ja, ist schon so vorgesehen. Das Problem ist eben nur:

Sie sollen weiter .07 schreiben können. Nur, wie ich schon schrieb, bekomme
ich Probleme, wenn's denn dann 1917 und 2017 gibt.

Ich denke ich mache einfach vor dass "Jahreszahl"-Textfeld noch ein
Auswahlfeld. Dort wird standardmäßig 20 eingeblendet. Als weitere Option
gibt es 19.

Wenn nun einer bei der Eingabe seiner Stammbäume zurückgeht, muss er eben
bei der Eingabe den VALUE-Wert dieses zusätzlichen Auswahlfeldes auf 19
stellen.

Diese beiden Werte kommen dann zusammen in die Datenbank und stimmen dann
(eben 1945 oder 2006). Bei der Ausgabe kann man ja dann die ersten 2 Zeichen
wieder abschneiden und den gewünschten Punkt davorsetzen.

Oder geht es noch einfacher?

Danke.

Josef

P.S.
Was stimmt denn bei meinen Quotes nicht?
Bei mir kommt z. b.

Josef Koller schrieb:
>.....
>.....

Re: SQL für Dummies?

Fabian Schladitz schrieb:
>=20
> Und da ist das Problem. Nimm doch nicht einfach an, was die User
> eingeben, sondern zerlege es sinnvoll.
> B1(KK) =3D .04-B12(II) ins B25(IK)
>=20
> Wird zu:
>=20
> Tabelle Tier:
> Bezeichnung VARCHAR()
> Geburtsjahr DATE()
> Vatertier VARCHAR()
> Muttertier VARCHAR()
> Besamungstechnik VARCHAR()
>=20
> Natürlich würde ich die Tiere noch ausnormalisieren usw.
> Du solltest also deinem Frontend beibringen, die Werte auseinander zu
> nehmen und dann mit den richtigen Datentypen in die richtigen Spalten z=
u
> speichern.
>=20
> m/([A-Z]\d+\([A-Z]{2}\) =3D \.(\d{2})-([A-Z]\d+\([A-Z]{2}\) (.*?)
> ([A-Z]\d+\([A-Z]{2}\)/
>=20
> Würdest du ja zur Kontrolle der Eingabe eh verwenden (oder so ähnli=
ch).
> Dann hast du schon die einzelnen Felder und kannst sie richtig
> speichern. Bei der Ausgabe stellst du es wieder in der gewohnten Syntax=

> dar... nur mit Zusatzfunktionen wie: Klick auf die Bezeichnung der
> Mutter führt zur Abstammung eben dieser.
>=20

Allerdings ändert das nichts an dem Jahreszahl-Problem: wenn der
Benutzer die Jahreszahl nicht vierstellig eingibt, muss eine Annahme
gemacht werden, wie sie zu ergänzen ist. Diese Annahme muss in
regelmäßigen Abständen angepasst werden, und der Benutzer sollte wo=
hl
auch die Möglichkeit haben, das Ergebnis im Einzelfall zu ändern.

Aber wenn zwei Ziffern zu viel sind, dann sind sie wohl zu viel ...
(oder, wenn das Programm spätestens 2019 regelmäßig nachfragt: mein=
ten
Sie 1919 oder 2019?, dann setzt ein langsames Umdenken ein).

--=20
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg
e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE

Re: SQL für Dummies?

Josef Koller schrieb:
> Hallo,
> [...]
>> Ich meine, dass man nach dem Theater um die Jahreswende 1999/2000 von
>> _jedermann_ erwarten kann, Jahreszahlen vollständig hinzuschreiben. Das
>> heißt, ich würde keine Tänze in der Anwendung veranstalten, sondern auf
>> eine unvollständige Jahresangabe mit einer Fehlermeldung reagieren. Denn
>> ich verstehe Dein Beispiel so, dass die Daten, die jetzt eingegeben
>> werden, durchaus ins vorige Jahrhundert gehören können.
> [...]
>
> Ich habe schon versucht, den Leuten zu erklären, dass es bei derartig langen
> Stammbäumen, die Möglichkeit gibt, dass die gekürzte Jahresangabe .17
> zweimal vorkommen kann. Eben 1917 und in Zukunft 2017.
>

Es wäre wirklich schön und sinnvoll gewesen, dafür einen neuen Thread
zu eröffnen. Denn diese Fragestellung hat weder etwas mit
Umgangsformen noch mit der LAST_INSERT_ID() des OP zu tun.

Außerdem ist es sinnvoll, korrekt zu quoten ... Ich habe das oben mal
repariert.

> Ich kann jetzt, wie ich schon schrieb zwar alles was 00 bis 17 ist um 20,
> also auf 2000 bis 2017 erweitern (im Beispiel stand 80, ist auch nur so eine
> Krücke), alles was darunter ist mit 19 versehen, um die korrekte Jahreszahl
> in die DB zu bekommen.

Das Entscheidende hier ist 'in die DB zu bekommen'. Du solltest
vielleicht einfach mental und technisch mal zwischen den Inhalten der
Datenbank und ihrer Darstellung trennen. Man muss nicht jeden Unsinn
oder jede Angewohnheit 1:1 in eine DB übernehmen.

> Vielleicht git es mich ja 2017, wo es dann zu Konflikten kommen kann, nicht
> mehr und das Ganze wäre mir dann egal.
>
> Dass blöde an der Geschichte ist eben nur, die sind so an dieses .00
> gewohnt, dass sie einfach bei einer Ausgabe die
>
> Zeile so erwarten:
>
> B1(KK) = .04-B12(II) ins B25(IK)
>
Ja, dann gib sie halt so aus. Das ist doch ein reines Problem der
Anwendung - den größten Teil davon kannst Du sogar in (My)SQL
erledigen, etwa in der Form
SELECT ... DATE_FORMAT('.%y',deine_datums_spalte) ...

> und nicht
>
> B1(KK) = 2004-B12(II) ins B25(IK)
>
> und die Daten auch so eingeben wollen.

Dito: Ein reines Anwendungsproblem.
>
> Ich sehe momentan auch keine andere Möglichkeit, als einfach von denen zu
> verlangen, dass sie in das Textfeld eben 2004 und nicht .04 eingeben.

Warum nicht? Kannst Du nicht in Deinem INSERT oder vorher ein bisschen
Datenmassage betreiben?

>
> Bei der Ausgabe könnte ich ja dann die ersten zwei Zeichen wieder
> abschneiden. Dann kommt aber bestimmt wieder die Frage, wieso soll ich 2004
> eingeben, wenn Du trotzdem .04 draus machen kannst. Irgendwie geb ich's noch
> nicht auf. Vielleicht hat ja doch jemand eine Idee, wie man sowas handelt?

Richtig. Man trennt die externe von der internen Repräsentation der
Daten. Das ist jetzt wirklich nicht Rocket Science - was anderes tust
Du ja auch nicht, wenn Du 0 für Männchen und 1 für Weibchen in der DB
speicherst und in der Anwendung dann eben 'm' bzw. 'w' anzeigst.

Re: SQL für Dummies?

Josef Koller schrieb:
> Hallo,
>
> [...]
> Würdest du ja zur Kontrolle der Eingabe eh verwenden (oder so ähnlich).
> Dann hast du schon die einzelnen Felder und kannst sie richtig
> speichern.
> [...]
>
> Danke. Ja, ist schon so vorgesehen. Das Problem ist eben nur:
>

Du quotest immer noch nicht. Warum erschwerst Du hier allen mutwillig
das Lesen?

> Sie sollen weiter .07 schreiben können. Nur, wie ich schon schrieb, bekomme
> ich Probleme, wenn's denn dann 1917 und 2017 gibt.
>

Nö. Nicht Du, sondern sie. Die haben ein kapottes Modell. Das müssen
sie eben irgendwann reparieren. Wenn sie das nicht tun wollen ->
zurück an Absender. Ist doch ohnehin ihr Problem, denn sie wissen
demnächst nicht mehr, ob ihr Tierchen nun im letzten oder in diesem
Jahrhundert gezeugt wurde.

> Ich denke ich mache einfach vor dass "Jahreszahl"-Textfeld noch ein
> Auswahlfeld. Dort wird standardmäßig 20 eingeblendet. Als weitere Option
> gibt es 19.
>
Dann kannst Du auch gleich eine Auswahlliste mit sinnvollen
Jahreszahlen anbieten -> geringere Fehleranfälligkeit. Aber das hat
mit einer DB überhaupt nichts zu tun, das ist nur eine Frage des GUI.

>
> P.S.
> Was stimmt denn bei meinen Quotes nicht?
> Bei mir kommt z. b.
>
> Josef Koller schrieb:
>> .....
>> .....
>

Schau Dir mal den Quelltext dazu an. Das sieht definitiv nicht so aus,
wie es sollte. Vielleicht macht Dir Dein lustiger "Newsreader" da was vor.

Re: SQL für Dummies?

Hallo,

ich hab jetzt mal Mozilla Thunderbird zum Antworten genommen.

Wenn ich mit dem die Postings ansehe, kommt beim "ersten" Zitat eine
blaue Markierung, beim Nächsten eine braune.

Wenn ich auf ein Posting antworte, kommen bei mir an Stelle der farbigen
Markierungen eben entweder

>
oder
>>

Hier mal nochmals ein zitierter Text:
.....

> Josef Koller schrieb:
>> Hallo,
>>
>> [...]
>> Würdest du ja zur Kontrolle der Eingabe eh verwenden (oder so ähnlich).
>> Dann hast du schon die einzelnen Felder und kannst sie richtig
>> speichern.
>> [...]
>>
>> Danke. Ja, ist schon so vorgesehen. Das Problem ist eben nur:
>>
>
> Du quotest immer noch nicht. Warum erschwerst Du hier allen mutwillig
> das Lesen?
>

......

Ist es jetzt mit Thunderbird besser oder immer noch falsch?


Für Euere Vorschläge bezüglich meines Stmmbaum-Jahres besten Dank. Ich
denke auch, dass die Angaben der User idesbezüglich eindeutig sein
müssen. Kein Mensch kann von einer Maschine verlangen, dass sie bei .17
selbstständig entscheidet, ob das nun 1917 oder 2017 ist.

Josef

Datenformat für Jahreszahlen (was: SQL für Dummies?)

Josef Koller wrote:

> Dass blöde an der Geschichte ist eben nur, die sind so an dieses .00
> gewohnt, dass sie einfach bei einer Ausgabe die
>
> Zeile so erwarten:
>
> B1(KK) = .04-B12(II) ins B25(IK)
>
> und nicht
>
> B1(KK) = 2004-B12(II) ins B25(IK)
>
> und die Daten auch so eingeben wollen.

Naja, dann laß sie doch - evtl. warne sie aber nach der Eingabe oder gib
ihnen die Möglichkeit (per DropDown oder wie auch immer) "." für
automatische Bestimmung abhängig vom jetzigen Zeitpunkt, "19" oder "20"
auszuwählen.

Wie bereits geschrieben wurde: speichern wirst Du ja hoffentlich die volle
Jahreszahl - und dann kannst Du ja auch beide Formate ausgeben: einmal das
Kurzformat mit .04, einmal das Langformat mit 2004.

Also eben

B1(KK) = .04-B12(II) ins B25(IK)
B1(KK) = 2004-B12(II) ins B25(IK)

übereinander - das alte Format evtl. in Klammern, kursiv, kleiner, je nach
Ausgabeziel, so daß Du den Leuten quasi einen Zaunpfahl um die Ohren haust
"4stellig ist richtig".

Was die Eingabe angeht, so würde ich den String zwischen = und - analysieren
und in Falle von '.##' die jeweils letzten 100 Jahre annehmen.

D.h.: gebe ich heute .07 ein, meine ich naheliegenderweise 1907, denn über
2007 gezeugte/geborene Tiere kann ich ja jetzt noch keine Angaben machen.
Gebe ich aber ab .06 ein, meine ich 2006.

Im Falle der Anzeige eines Datensatzes von 1906 etwa würde ich dann nur noch
das lange Format ausgeben, da das kurze ja für 2006 steht.


> Bei der Ausgabe könnte ich ja dann die ersten zwei Zeichen wieder
> abschneiden. Dann kommt aber bestimmt wieder die Frage, wieso soll ich
> 2004 eingeben, wenn Du trotzdem .04 draus machen kannst.

Damit die Daten weiterhin stimmen und nachvollziehbar bleiben - und damit
nicht irrtümlich jemand .04 für 2004 eingibt.


> Irgendwie geb ich's noch nicht auf. Vielleicht hat ja doch jemand eine
> Idee, wie man sowas handelt?

Meinst Du jetzt "sozial" oder "von der Umsetzung her"?

Sozial hilft nur, mit den Leuten reden und parallel dazu eine
Benutzerführung zu implementieren, die die Leute "an der Hand nimmt".

Umsetzungstechnisch hast Du ja jetzt mittlerweile auch relativ viele
Anregungen bekommen, die Dir sicherlich erstmal weiterhelfen - denn so
richtig ontopic ist das in *.mysql nicht mehr.

Wie gesagt - das Wichtigste ist an dieser Stelle erstmal das vollständige
Abspeichern der Jahreszahl, damit keine Daten unwiederbringlich
verlorengehen.


Thomas

Re: SQL für Dummies?

Axel Schwenke schrieb:
> Josef Koller wrote:
>> ich dachte, mit meinen Beispielen würde ich aufzeigen können, woran es
>> m.E. in dieser Group mangelt.
> Das ist dir mißlungen.

Ich fand es ziemlich treffend! Wenn man viel in anderen Foren unterwegs
ist oder auch früher, wie ich, im Fido dann wird man vom Umgabgston hier
schon ganz schön umgehauen! Es ist nicht der direkte Ton - also niemand
wird beleidigt, nicht direkt - aber diese unterschwellige arroganz die
in den einschlägigen Nachrichten mit schwingt ist unüberlesbar und sehr
verletzend. Ich denke das er DAS meinte, zumindest ist es das was MIR
den Spass an dieser Group hier vermiest hat.

>> Dass mit den Jahreszahlen ist, wenn ich es selbst mache, so wie Du
>> schreibst. Manchmal muss man aber auch Dinge in Kauf nehmen, die man
>> nicht beeinflussen kann und man braucht trotzdem eine Lösung.
>>
>> Ich würde aber den "Erzeuger" einer derartigen Tabellenstruktur nicht
>> als krank oder sonstwas bezeichnen.
>
> Das hat Christian nicht getan. Er hat die Struktur krank genannt.

Aha - und wo genau ist jetzt der Unterschied? Wenn du einem Konstrukeur
erzählst das, dass was er da gerade gebastelt hat vollkommen hirnrissig
ist dann WIRD er das sicherlich auf sich selber projezieren. Überleg
doch mal warum man sich hier hinbegibt. Häufig bastelt man sich einen
zurecht - wenn man sowas nicht gerade hauptberuflich macht - und ist
saustolz das man die dinge gerade mal so zum laufen bekommen hat oder
wenn man seine erste gejointe Abfrage hin bekommen hat und hängt an
einem Problem und kommt nicht weiter. Und dann wird das was man gerade
in mühsamer arbeit produziert hat in sekunden runtergemacht und
vollkommen denunziert ... wie glaubst du fühlt sich die Person dann?
Unabhängig davon ob die Aussage richtig ist das, dass was man da gemacht
hat scheisse ist.

Re: SQL für Dummies?

Carsten Bliessen wrote:
> Axel Schwenke schrieb:
>> Josef Koller wrote:
>>> ich dachte, mit meinen Beispielen würde ich aufzeigen können, woran es
>>> m.E. in dieser Group mangelt.

>> Das ist dir mißlungen.
>
> Ich fand es ziemlich treffend!

Das sei dir unbenommen.

IMNSHO hat Josef zwei Fragen gestellt, die geradezu symptomatisch für
die hiesige Leser- (bzw. eher Schreiber-)schaft sind. Frage 1 war mit
1x ins Handbuch schauen - nicht mal suchen, einfach nur die eine Seite
zum Thema AUTO_INCREMENT mal bis zum Ende lesen - beantwortet.

Frage 2 betrifft einen Designfehler, den man eigentlich nur Leuten
durchgehen lassen kann, die nach 2000 geboren sind. Wer Jahreszahlen
zweistellig speichert, ist entweder hirntot oder hat die 5 Jahre vor
dem Jahr-2000-Wechsel durchgekifft.

> Wenn man viel in anderen Foren unterwegs
> ist oder auch früher, wie ich, im Fido dann wird man vom Umgabgston hier
> schon ganz schön umgehauen!

Die Welt ist schlecht. Früher war alles besser. Film um 11.

>>> Ich würde aber den "Erzeuger" einer derartigen Tabellenstruktur nicht
>>> als krank oder sonstwas bezeichnen.
>>
>> Das hat Christian nicht getan. Er hat die Struktur krank genannt.
>
> Aha - und wo genau ist jetzt der Unterschied?

Wenn du das nicht verstehst - wieso diskutierst du dann überhaupt über
Umgangsformen?

> Wenn du einem Konstrukeur
> erzählst das, dass was er da gerade gebastelt hat vollkommen hirnrissig
> ist dann WIRD er das sicherlich auf sich selber projezieren.

Nur wenige Leute, die hier mit kaputten Datenstrukturen aufschlagen,
haben die selber verbrochen. Ansonsten fällt der Anschiß in etwa
proportional zur Höhe der Dummheit aus. Again: Jahreszahlen zweistellig
zu speichern ist *so* hirntot, dafür gibt es in der deutschen Sprache
noch gar kein passendes Wort.

> Überleg doch mal warum man sich hier hinbegibt.

Tja, die Erfahrung lehrt uns, daß sich die meisten nur-Fragen-Schreiber
hierherbegeben, weil sie sich entweder Grundlagen (z.B. Normalisierung)
oder Detailwissen (wie geht XXX in MySQL) nicht aneignen können oder
wollen. Nur ist es nicht Sinn einer Newsgroup, Grundlagenbücher oder
das Handbuch zum $TOPIC vorzulesen.

Andere Newsgroups haben eine FAQ und erwarten von Fragestellern,
erstmal die FAQ zu konsultieren, bevor sie eine Frage stellen. Wir
hier haben keine FAQ, weil das MySQL-Manual kaum Fragen offen läßt.
Folgerichtig erwarte ich, daß ein Fragesteller zumindest die
offensichtlichen Seiten des Handbuchs gelesen hat.


PS: du bist ein Strich auf der "Bitte lies mir doch mal einer das
Handbuch vor" Liste


XL

Re: SQL für Dummies?

> Frage 2 betrifft einen Designfehler, den man eigentlich nur Leuten
> durchgehen lassen kann, die nach 2000 geboren sind. Wer Jahreszahlen
> zweistellig speichert, ist entweder hirntot oder hat die 5 Jahre vor
> dem Jahr-2000-Wechsel durchgekifft.

Das ist ja richtig, aber es soll Leute geben die einfach eine solche
Sache vorgesetzt bekommen und damit arbeiten *müssen* ohne etwas dran
ändern zu können.

>> Wenn man viel in anderen Foren unterwegs
>> ist oder auch früher, wie ich, im Fido dann wird man vom Umgabgston hier
>> schon ganz schön umgehauen!
>
> Die Welt ist schlecht. Früher war alles besser. Film um 11.

Sehr witzig - das habe ich doch garnicht behauptet. Ein etwas
freundlicherer Umgangston würde doch jedem das leben erleichtern, oder?
Auch wenn der 100te User die selbe Frage zum 1000ten Mal stellt ... WENN
man denn unbedingt der Meinung ist das man darauf antworten MUSS dann
reicht doch einfach der Hinweiss auf das letzte Posting und das die
Frage schon zig mal gestellt wurde, oder?

>>>> Ich würde aber den "Erzeuger" einer derartigen Tabellenstruktur nicht
>>>> als krank oder sonstwas bezeichnen.
>>> Das hat Christian nicht getan. Er hat die Struktur krank genannt.
>> Aha - und wo genau ist jetzt der Unterschied?
>
> Wenn du das nicht verstehst - wieso diskutierst du dann überhaupt über
> Umgangsformen?

Mir sind die Feinheiten schon klar, aber entweder verbringst du dein
Leben nur vor dem Computer oder ignorierst menschliches Verhalten. Die
meisten werden eine solche Aussage derart miteinander vermischen.

>> Wenn du einem Konstrukeur
>> erzählst das, dass was er da gerade gebastelt hat vollkommen hirnrissig
>> ist dann WIRD er das sicherlich auf sich selber projezieren.
>
> Nur wenige Leute, die hier mit kaputten Datenstrukturen aufschlagen,
> haben die selber verbrochen. Ansonsten fällt der Anschiß in etwa
> proportional zur Höhe der Dummheit aus. Again: Jahreszahlen zweistellig
> zu speichern ist *so* hirntot, dafür gibt es in der deutschen Sprache
> noch gar kein passendes Wort.

Von diesem spezifischen Fall habe ich doch garnicht gesprochen, wir
wissen doch jetzt das du es kannst, lass gut sein.

>> Überleg doch mal warum man sich hier hinbegibt.
>
> Tja, die Erfahrung lehrt uns, daß sich die meisten nur-Fragen-Schreiber
> hierherbegeben, weil sie sich entweder Grundlagen (z.B. Normalisierung)
> oder Detailwissen (wie geht XXX in MySQL) nicht aneignen können oder
> wollen. Nur ist es nicht Sinn einer Newsgroup, Grundlagenbücher oder
> das Handbuch zum $TOPIC vorzulesen.

Auch hier gebe ich dir recht in Bezug auf den Sinn der Newsgroups. Aber
die meisten Fragensteller haben sich schon mit der Materie befasst und
suchen schlicht und ergreifend nur den richtigen Tipp, Hinweiss oder
Denkanstoss. Zumal es auch Leute geben soll die sich mit der Materie
eben NICHT professionell auseinander setzen müssen und somit nicht das
Fachspezifische Wissen mitbringen um zu ihrem Ziel zu kommen. Auch sowas
muss es geben, nur weil ein Kleintierzüchter oder ein anderer Verein
oder vielleicht ein Sammler sich eine kleine Datenbank aufbauen will
muss er doch nun nicht wirklich ein solch Perfektes Wissen mitbringen
wie du es in dem Text oben voraussetzt, oder? NATÜRLICH sollte man als
allererstes das Handbuch konsultieren, aber man findet dort eben nicht
sofort das was man sucht, was nicht zuletzt daran liegt das den meisten
die Fachbegriffe fehlen oder sie die richtigen Befehle schlicht und
einfach nicht kennen. Und deshalb darf man denen nicht helfen, bzw. die
Leute erst einmal beschimpfen und dann aufs Handbuch verweisen? Traurig
traurig ...

> Andere Newsgroups haben eine FAQ und erwarten von Fragestellern,
> erstmal die FAQ zu konsultieren, bevor sie eine Frage stellen. Wir
> hier haben keine FAQ, weil das MySQL-Manual kaum Fragen offen läßt.
> Folgerichtig erwarte ich, daß ein Fragesteller zumindest die
> offensichtlichen Seiten des Handbuchs gelesen hat.

Wie ich schon sagte, viele - mich eingeschlossen - wissen schlicht und
ergreifend nicht wonach sie überhaupt suchen müssen. Die FAQ sind aber
auch wesentlich anders aufgebaut als ein Manual, obwohl ich zugeben muss
das, dass MySQL Handbuch eines der am flüssigsten zu lesenden Handbücher
ist das ich die letzten Jahre in den Händen hatte. Aber der Unterschied
zu einer FAQ ist ja nun doch schon ganz gewaltig. Den meisten
unterstelle ich einfach mal das sie vorher versucht haben im Handbuch
etwas zu finden. Zumeist werden sie sogar google gefragt haben und mit
beidem sind sie wahrscheinlich gescheitert - aus welche gründen
letzendlich auch immer.

> PS: du bist ein Strich auf der "Bitte lies mir doch mal einer das
> Handbuch vor" Liste

So bin ich das für dich? Schön, freut mich das ich dein Leben um einen
Strich bereichern konnte.

Re: SQL für Dummies?

Carsten Bliessen schrieb:

> Wie ich schon sagte, viele - mich eingeschlossen - wissen schlicht und
> ergreifend nicht wonach sie überhaupt suchen müssen.

Was spricht denn dagegen, erstmal das Handbuch zu einem Produkt von
vorne bis hinten zu *lesen*, bevor man mit der Arbeit anfängt? Dann
hast Du zumindest eine oberflächliche Vorstellung davon, was es gibt,
wie das Ganze funktioniert etc., denn Du hast alles schon einmal
gesehen. Wenn Du dann auf ein Problem stößt, gibt es eine gute Chance,
dass Du Dich daran erinnern kannst, sowas ähnliches schonmal gesehen
zu haben ...

Du scheinst der Idee anzuhängen, dass man einerseits zwar eine
Datenbank haben müsse (wo es doch oft ein Karteikasten täte!),
andererseits aber bitte nicht die nötige Arbeit investieren will. Die
Regulars in der NG haben sich aber genau diese Arbeit gemacht - und Du
willst davon profitieren.

Mit anderen Worten: Dir ist Deine Zeit deutlich mehr wert als die der
anderen. Mir geht's ähnlich mit meiner Zeit. Also reagiere ich
ungehalten, wenn ich den Eindruck habe, dass sich da jemand auf meine
Kosten Arbeit sparen will. Denn ich empfinde dieses "He, lies mir mal
das Handbuch vor/zeig mir mal die richtige Stelle, ich hab' keine
Zeit, das selber zu suchen" als genau so unfreundlich wie Du meine
Antworten auf solche Ansinnen. Mein Unmut verstärkt sich, wenn
Postings schlampig formuliert sind, sodass man nicht auf Anhieb
verstehen kann, was der Fragesteller meint oder gar meinen könnte
(krude Ortografie und Grammatik). Auch das heißt nämlich wieder: Da
hatte jemand keine Lust, sich ein bisschen anzustrengen, will aber,
dass ich es tue.

> Die FAQ sind aber
> auch wesentlich anders aufgebaut als ein Manual, obwohl ich zugeben muss
> das, dass MySQL Handbuch eines der am flüssigsten zu lesenden Handbücher
> ist das ich die letzten Jahre in den Händen hatte. Aber der Unterschied
> zu einer FAQ ist ja nun doch schon ganz gewaltig. Den meisten
> unterstelle ich einfach mal das sie vorher versucht haben im Handbuch
> etwas zu finden.

Du irrst Dich. Und zwar m.E. in 95% der Fälle. Kaum jemand liest, und
kaum jemand benutzt die Suchfunktion. An dem ersten Beispiel von Josef
(was sich auf einen Teil Deines ersten Postings bezog) konnte man das
ja gut nachvollziehen: Das AUTO_INCREMENT-Thema wird direkt im
Tutorial behandelt. Es ist der zweite Treffer bei der Suche nach
auto_increment. Und trotzdem wird hier immer wieder danach gefragt.
Weil jeder Fragesteller vorher gründlich gesucht hat?

> Zumeist werden sie sogar google gefragt haben und mit
> beidem sind sie wahrscheinlich gescheitert - aus welche gründen
> letzendlich auch immer.
>
Falsche Prämisse, flasche Schlussfolgerung. Kaum jemand sucht, die
meisten fragen lieber gleich hier. Dein erstes Posting in diesem
Thread ist auch ein Beispiel dafür: "Funktioniert ein INSERT überhaupt
über mehrere Tabellen". Da reicht ein Blick in die Dokumentation.

Re: SQL für Dummies?

>> Wie ich schon sagte, viele - mich eingeschlossen - wissen schlicht und
>> ergreifend nicht wonach sie überhaupt suchen müssen.
>
> Was spricht denn dagegen, erstmal das Handbuch zu einem Produkt von
> vorne bis hinten zu *lesen*, bevor man mit der Arbeit anfängt? Dann
> hast Du zumindest eine oberflächliche Vorstellung davon, was es gibt,
> wie das Ganze funktioniert etc., denn Du hast alles schon einmal
> gesehen. Wenn Du dann auf ein Problem stößt, gibt es eine gute Chance,
> dass Du Dich daran erinnern kannst, sowas ähnliches schonmal gesehen
> zu haben ...

Mhm, zeitmangel spricht als allererstes dagegen. Aber im Prinzip hast du
recht, da muss ich dir zustimmen. Ich erwische mich häufig dabei das ich
Anleitungen garnicht oder nur sehr selektiv lese. Aber ich kann ehrlich
gesagt auch nicht alle Handbücher lesen, dass passt zeitlich einfach
nicht, dafür komme ich in meinem Beruf einfach mit zu vielen Anwendungen
in Berührung und letzendlich haben die meisten Programme viele
Ähnlichkeiten und bauen alle auf den selben Prinzipien auf (sehr
überzogen ausgedrückt: auf 0en und 1en ;-)! Ich hoffe du weisst was ich
meinte).

> Du scheinst der Idee anzuhängen, dass man einerseits zwar eine
> Datenbank haben müsse (wo es doch oft ein Karteikasten täte!),
> andererseits aber bitte nicht die nötige Arbeit investieren will. Die

natürlich ziehe ich eine Datenbank einem Karteikasten vor - das bringt
eine gewisse Technikverliebtheit mit sich. Oder warum beschäftigst du
dich privat noch mit Computern? Natürlich bin ich bereit Arbeit zu
ivestieren und das mache ich ja auch.

> Regulars in der NG haben sich aber genau diese Arbeit gemacht - und Du
> willst davon profitieren.

Natürlich will ich davon profitieren - du nicht wenn du jemanden um Rat
oder Hilfe fragst??

> Mit anderen Worten: Dir ist Deine Zeit deutlich mehr wert als die der
> anderen. Mir geht's ähnlich mit meiner Zeit. Also reagiere ich

DAS ist jetzt deine Meinung und eine SEHR frei interpretierte noch dazu.

> ungehalten, wenn ich den Eindruck habe, dass sich da jemand auf meine
> Kosten Arbeit sparen will. Denn ich empfinde dieses "He, lies mir mal
> das Handbuch vor/zeig mir mal die richtige Stelle, ich hab' keine
> Zeit, das selber zu suchen" als genau so unfreundlich wie Du meine

Ich glaube die wenigsten versuchen es immer erst selber! Und auch tritt
wieder deine - sehr negative Einstellung und Interpretations Methodik
zum Vorschein. NEIN es will dir keiner irgendwas an Zeit stehlen, wir
haben uns alle ganz doll lieb und sind (normalerweise) eine grosse nette
Gemeinschaft

> Antworten auf solche Ansinnen. Mein Unmut verstärkt sich, wenn
> Postings schlampig formuliert sind, sodass man nicht auf Anhieb
> verstehen kann, was der Fragesteller meint oder gar meinen könnte
> (krude Ortografie und Grammatik). Auch das heißt nämlich wieder: Da
> hatte jemand keine Lust, sich ein bisschen anzustrengen, will aber,
> dass ich es tue.

Tja zum Glück sind die Menschen verschieden. Ich weiss das ich mich
teilweise sehr kompliziert ausdrücke - warum das so ist vermag ich nicht
zu sagen - aber das ist mit absoluter Sicherheit kein Ausdruck von
Geringschätzung anderer gegenüber! Wenn mir das alles egal wäre hätte
ich sicherlich auch nicht an diesem Beitrag weiter geschrieben!
Vielleicht änderst du mal etwas an deiner Einstellung anderen gegenüber
um zu erkennen das nicht jeder irgendwas böswillig meint oder sich nicht
ausreichend Mühe gibt. Das ist eine Unsitte in unserem Land geworden,
echt traurig.

>> Die FAQ sind aber
>> auch wesentlich anders aufgebaut als ein Manual, obwohl ich zugeben muss
>> das, dass MySQL Handbuch eines der am flüssigsten zu lesenden Handbücher
>> ist das ich die letzten Jahre in den Händen hatte. Aber der Unterschied
>> zu einer FAQ ist ja nun doch schon ganz gewaltig. Den meisten
>> unterstelle ich einfach mal das sie vorher versucht haben im Handbuch
>> etwas zu finden.
>
> Du irrst Dich. Und zwar m.E. in 95% der Fälle. Kaum jemand liest, und
> kaum jemand benutzt die Suchfunktion. An dem ersten Beispiel von Josef
> (was sich auf einen Teil Deines ersten Postings bezog) konnte man das
> ja gut nachvollziehen: Das AUTO_INCREMENT-Thema wird direkt im
> Tutorial behandelt. Es ist der zweite Treffer bei der Suche nach
> auto_increment. Und trotzdem wird hier immer wieder danach gefragt.
> Weil jeder Fragesteller vorher gründlich gesucht hat?

Ich kann nur sagen wie mir es häufig geht und ich finde häufig nicht die
richtigen Antworten bzw. Ausdrücke über die Suchfunktion. Was meines
erachtens häufig damit zusammenhängt das ich die richtigen Begriffe
nicht kenne. Das ist übrigens auch das grösste Problem der meisten
Anleitungen, sie wurden von Technikern für Techniker geschrieben! Gerade
im OpenSource Umfeld findet man diese Unart, MySQL sticht da aber
relativ positiv hervor. Aber auch die setzen gewisse Kenntnisse von
Begriffen und Methodiken voraus die ich als laie nicht besitze. Ist ja
eigentlich auch nicht weiter schlimm wenn man jemanden hat den man
Fragen kann.

>> Zumeist werden sie sogar google gefragt haben und mit
>> beidem sind sie wahrscheinlich gescheitert - aus welche gründen
>> letzendlich auch immer.
>>
> Falsche Prämisse, flasche Schlussfolgerung. Kaum jemand sucht, die
> meisten fragen lieber gleich hier. Dein erstes Posting in diesem

Das ist wieder eine Unterstellung von dir die ich schlicht nicht teile!

> Thread ist auch ein Beispiel dafür: "Funktioniert ein INSERT überhaupt
> über mehrere Tabellen". Da reicht ein Blick in die Dokumentation.

Auch das hatte ich schon versucht zu erklären - nur weil es nicht in der
Dokumentation steht heisst es nicht das es nicht funktioniert! Wenn du
eine Doku - welcher Art auch immer - für so allumfassend hälst dann gute
Nacht. Mal im ernst, dass glaube ich dir auch nicht, auch du wirst schon
von Funktionen in Anwendungen benutzt haben die niemals irgendwo
dokumentiert waren (zumindest in den original Dokus nicht), oder?

Re: SQL fürDummies?

Carsten Bliessen wrote:

>> Was spricht denn dagegen, erstmal das Handbuch zu einem Produkt von
>> vorne bis hinten zu *lesen*, bevor man mit der Arbeit anfängt? Dann
>> hast Du zumindest eine oberflächliche Vorstellung davon, was es gibt,
>> wie das Ganze funktioniert etc., denn Du hast alles schon einmal
>> gesehen. Wenn Du dann auf ein Problem stößt, gibt es eine gute Chance,
>> dass Du Dich daran erinnern kannst, sowas ähnliches schonmal gesehen
>> zu haben ...
>
> Mhm, zeitmangel spricht als allererstes dagegen. Aber im Prinzip hast du
> recht, da muss ich dir zustimmen. Ich erwische mich häufig dabei das ich
> Anleitungen garnicht oder nur sehr selektiv lese.

Ist ja ok - aber zumindest dann, wenn man gewisse Funktionen benötigt,
sollte das dann nachgeholt werden.


>> Thread ist auch ein Beispiel dafür: "Funktioniert ein INSERT überhaupt
>> über mehrere Tabellen". Da reicht ein Blick in die Dokumentation.
>
> Auch das hatte ich schon versucht zu erklären - nur weil es nicht in der
> Dokumentation steht heisst es nicht das es nicht funktioniert!

So? Woher erfährt man denn dann sonst, wie es funktioniert?


> Wenn du eine Doku - welcher Art auch immer - für so allumfassend hälst
> dann gute Nacht. Mal im ernst, dass glaube ich dir auch nicht, auch du
> wirst schon von Funktionen in Anwendungen benutzt haben die niemals
> irgendwo dokumentiert waren (zumindest in den original Dokus nicht), oder?

Was Christian so getan hat, weiß ich nicht. Aber ich für meinen Teil
versuche Programme so zu gestalten, daß sie möglichst portabel bleiben. Und
dazu gehört in erster Linie, mich nicht auf Dinge zu verlassen, die nicht
irgendwo dokumentiert sind, denn da ist die Wahrscheinlichkeit am größten,
daß sie irgendwann mal wegfallen.

Was Einmal-Codeschnipsel angeht: ja, da hast Du recht. Da greift man schnell
mal zu einem irgendwie hergeleiteten "Das könnte so gehen".

Aber, um zum hier angegebenen Fall zurückzukommen: Die Syntax von INSERT
sieht eben ein Multi-Table-Insert nicht vor. Wie sollte es dann gehen? Vor
allem bei Kollissionen von Spaltennamen? Nee, daß da was
nichtdokumentiertes implementiert wurde, ist IMHO sehr unwahrscheinlich.


Thomas