pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin!


Mal eine Frage: Ihr solltet Schülern PHP (und damit auch HTML) und MySQL
beibringen, wobei das Lernziel hauptsächlich mal die Beherrschung der
Datenbank ist. Ich habe die Reihenfolge
MySQL, erst Kommandozeile, später PHPMyAdmin
HTML, kurz, nur das nötigste
PHP, erst allgemein, dann Datenbankspezifisch
gewählt. Ist das soweit sinnvoll?

Sonst irgendwelche Tipps, was man noch beachten sollte? Ich habe in
meinen bisherigen Ausführungen schon darauf geachtet, nicht die
standard-Fehler zu machen (Sicherheit, etc.).

Noch eine Frage zur Nomenklatur:
Ist der Ausdruck "Befehl" zulässig für ein "SELECT * FROM bla"?
Eigentlich sagt man ja Abfrage, aber Befehl ist etwas allgemeiner, oder?
Ist "DELETE FROM..." oder "CREATE TABLE" auch eine Abfrage?
Und: Man sagr WHERE-Klausel, oder? Und ORDER BY-Klausel?

Details, Details....!

Daniel Fett
--
www.fragcom.de / ICQ 119-700-134

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Daniel Fett:

> Mal eine Frage: Ihr solltet Schülern PHP (und damit auch HTML) und MySQL
> beibringen, wobei das Lernziel hauptsächlich mal die Beherrschung der
> Datenbank ist.

Dann sollte PHP (und HTML) nur als kurzes Anschaungsbeispiel dienen. MySQL
sollte das RDBMS sein, und SQL-$version die Sprache. Ich würde dabei nicht
den Fehler machen und nur MySQLs SQL beibringen, bzw. auch mal andere RDBMS
vorstellen.

> Ich habe die Reihenfolge
> MySQL, erst Kommandozeile, später PHPMyAdmin
> HTML, kurz, nur das nötigste
> PHP, erst allgemein, dann Datenbankspezifisch
> gewählt. Ist das soweit sinnvoll?

PHPMyAdmin würde ich ganz weglassen. Wenn man mit den mysql* tools umgehen
kann, braucht man das Spielzeug nicht mehr. Warum Du HTML bringst ist mir
auch nicht klar. Ich würde mal eher auf Grundsätze eingehen (Komplexität
von linearer Suche und Notwendigkeit effizienter Strukturen...evtl. mit
einem simplen binären Baum veranschaulicht) und dann eben noch
Datenbankdesign (Normalformen), was ja für die Anwendung enorm wichtig ist.
--
- Kontonummerprüfung mit PHP

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Daniel Fett schrieb:

> Noch eine Frage zur Nomenklatur:
> Ist der Ausdruck "Befehl" zulässig für ein "SELECT * FROM bla"?
> Eigentlich sagt man ja Abfrage, aber Befehl ist etwas allgemeiner,
> oder? Ist "DELETE FROM..." oder "CREATE TABLE" auch eine Abfrage?
> Und: Man sagr WHERE-Klausel, oder? Und ORDER BY-Klausel?

Es heißt 'SQL-Anweisung'; die Klauseln (clauses) werden in der
deutschsprachigen Literatur gelegentlich auch als 'Satz' bezeichnet.

HTH
Niels

--
Informatiker haben Humor, allerdings lässt sich der nur schwer
im Quelltext ausdrücken. Ausnahme Microsoft: Dort arbeiten die
Kabarettisten der Informatik, die sogar lustigen Quelltext schreiben
können. [Oliver Schad in dclpm]

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Daniel Fett wrote:

> Mal eine Frage: Ihr solltet Schülern PHP (und damit auch HTML) und MySQL
> beibringen, wobei das Lernziel hauptsächlich mal die Beherrschung der
> Datenbank ist.
Cool. Ich bin selber noch Schüler und fände das echt eine gute Idee.
Leider sind unsere Lehrer zu eingestaubt dafür :-)

> Ich habe die Reihenfolge
> MySQL, erst Kommandozeile, später PHPMyAdmin
> HTML, kurz, nur das nötigste
> PHP, erst allgemein, dann Datenbankspezifisch
> gewählt. Ist das soweit sinnvoll?
Wie einer meiner Vorredner schon gesagt hat, MySql an sich keine
Sprache, sondern ein Datenbankserver. Die "Sprache" ist SQL (Standard
Query Language), auf welche MySql sich stüzt. (Die Übersetzung redet ja
für sich)
IMHO kommt es stark darauf an, was für eine Art Unterricht du gibst. Für
einen Kurs "PHP & MYSQL" würde ich dir andere Vorgehensweise empfelen
als eimem Datenbanken Kurs. Vielleicht unterrichtest du ja auch
Informatik als WPU oder als Kurs, da kannst du dich mit einem Thema
nicht lange aufhalten.
Aber grundsäztlich wäre es sicher nicht schlecht erstmal zu erklären,
wozu Datenbanken da sind, was man mit ihnen machen kann, ein paar
Regeln, Foreign Keys, auto_increment, Normalisieren, etc, etc... Erst
danach, wenn die Schüler das Grundprinzip verstanden haben würde ich mit
SQL anfangen, was interessierte Schüler interessieren wird, ich
spreche aus eingenem erfahren :)

> Sonst irgendwelche Tipps, was man noch beachten sollte? Ich habe in
> meinen bisherigen Ausführungen schon darauf geachtet, nicht die
> standard-Fehler zu machen (Sicherheit, etc.).
>
Die Schüler sollten die verbreitesten Regeln kennenlernen, Tabellen
immer mit einem Feld "id", welches INT und auto_increment ist, etc.
Sozusagen die "Nettiquette" oder die ungeschriebenen Regeln sind.

> Daniel Fett
Gruß, Niklas


--
Fatal Error: Could not find "brain" in Line 2004

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Niklas Schumann, du schriebst:

> Tabellen
> immer mit einem Feld "id", welches INT und auto_increment ist,

Das ist hochgradiger Unsinn.

Sofern man entsprechende Kandidatenschluessel hat, erübrigt
sich das. Bei einer Datenbank mit Buechern braucht es keine
solche ID, da (mindestens) ein Kandidatenschluessel
existiert:: die ISBN.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:

>>Tabellen
>>immer mit einem Feld "id", welches INT und auto_increment ist,
>
>
> Das ist hochgradiger Unsinn.
>
> Sofern man

....sehr viel Erfahrung hat und sich sehr sicher ist kann man
ausnahmsweise auch manchmal drauf verzichten.

*klopf-klopf* Hallo? McHuebenthal? Jemand zu Hause? :-) [*]

Es geht hier um einen *Grundkurs* für *Schüler*. "In jeder Tabelle ein
Primärschlüssel int auto_increment und ein timestamp" ist eine Klasse
Regel, mit der man sich supergut Ärger vom Hals halten kann. Sie ist
einfach zu vermitteln, einfach zu merken, einfach zu realisieren,
meistens richtig und nie richtig falsch - wenn auch nicht immer
unbedingt optimal.

Grüße, Matthias

* Aussage soll nicht Kritik verstärken und angreifen, sondern lediglich
meinem momentan spontan ausbrechendes Faible für "Zurück in die Zukunft"
Ausdruck verleihen.

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal wrote:
>
> Das ist hochgradiger Unsinn.
>
> Sofern man entsprechende Kandidatenschluessel hat, erübrigt
> sich das. Bei einer Datenbank mit Buechern braucht es keine
> solche ID, da (mindestens) ein Kandidatenschluessel
> existiert:: die ISBN.

Tja, wie ich sagte ist es eine ungeschriebene Regel. natürlich gibt es
oftmals eine eindeutige Nummer, troztdem bleibt es so übersichtlich, und
*ich* habe es mir so angeöhnt.
Wie dus machst, ist mir egal, aber es macht ein großteil der
Programmierer so, und du kannst mir glauben, das ich einige
"Datenbank-Profis" kenne, die diese Technik anwenden.

Außerdem wäre es ja nur "hochgradiger Unsinn" wenn die Aussage *nie*
zutreffen würde. Das tut sie aber nicht, also rede nicht so einen
hochgradigen Unsinn.

Danke


--
Fatal Error: Could not find "brain" in Line 2004

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

.oO(Niklas Schumann)

>Wie einer meiner Vorredner schon gesagt hat, MySql an sich keine
>Sprache, sondern ein Datenbankserver. Die "Sprache" ist SQL (Standard
>Query Language), [...]

Je nach Quelle auch "Structured Query Language".

>Die Schüler sollten die verbreitesten Regeln kennenlernen, Tabellen
>immer mit einem Feld "id", welches INT und auto_increment ist, etc.
>Sozusagen die "Nettiquette" oder die ungeschriebenen Regeln sind.

NACK

Zum einen hat auto_increment nur bedingt mit SQL zu tun, es ist eine
MySQL-spezifische Erweiterung (in anderen DBMS muß das bei Bedarf
nachgebaut werden, z.B. mit Triggern). Zum anderen sind künstliche
Schlüssel (IDs) kein Allheilmittel und nicht immer sinnvoll.

Zu vernünftigem Datenbankdesign gehört nicht nur, daß man ein
normalisiertes Schema entwirft, sondern auch der Verzicht auf Unnötiges.
Wenn sich bestimmte Felder der DB als Primärschlüssel eignen (einzeln
oder zusammengesetzt), braucht man oftmals keine IDs mehr. Das soll
nicht heißen, daß IDs trotz Primärschlüssel generell unnötig seien, aber
es kommt immer auf den Zusammenhang an. Als ungeschriebene Regel würde
ich es jedenfalls nicht bezeichnen.

Micha

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Niklas Schumann verfasste am 12.10.2004 16:25 n.Chr.:
> Daniel Fett wrote:
>
>> Mal eine Frage: Ihr solltet Schülern PHP (und damit auch HTML) und
>> MySQL beibringen, wobei das Lernziel hauptsächlich mal die
>> Beherrschung der Datenbank ist.
>
> Cool. Ich bin selber noch Schüler und fände das echt eine gute Idee.
> Leider sind unsere Lehrer zu eingestaubt dafür :-)

Musst du so machen wie ich: Ich bin 13. Klasse, gebe in einer 11.
Unterricht und der Lehrer schaut zu und lernt selbst was dabei :-)

>
>> Ich habe die Reihenfolge
>> MySQL, erst Kommandozeile, später PHPMyAdmin
>> HTML, kurz, nur das nötigste
>> PHP, erst allgemein, dann Datenbankspezifisch
>> gewählt. Ist das soweit sinnvoll?
>
> Wie einer meiner Vorredner schon gesagt hat, MySql an sich keine
> Sprache, sondern ein Datenbankserver. Die "Sprache" ist SQL (Standard
> Query Language), auf welche MySql sich stüzt. (Die Übersetzung redet ja
> für sich)

Schon klar. Am Beispiel von MySQL hier. Ich will, dass die Schüler was
praktisches machen können, auch zu Hause. Da wird es kaum klappen, zu
sagen: Installiert euch XSQL und YSQL und ZSQL...
So können die Schüler sich ein XAMPP oder Derivate draufhauen und gut ist.

> IMHO kommt es stark darauf an, was für eine Art Unterricht du gibst. Für
> einen Kurs "PHP & MYSQL" würde ich dir andere Vorgehensweise empfelen
> als eimem Datenbanken Kurs. Vielleicht unterrichtest du ja auch
> Informatik als WPU oder als Kurs, da kannst du dich mit einem Thema
> nicht lange aufhalten.

Es wird einer 11er Klasse Informatik sein. Da zählt ja noch kaum des
Endergebnis, Abweichungen vom Lehrplan interessieren ja kaum jemanden.

Da ich selbst auch Schüler bin, weiß ich ja, wie das mit theoretischem
Stoff so aussieht... Daher will ich sagen können: "Wenn ihr hiermit
fertig seid, könnt ihr mit SelfHTML (oder Derivate) und dem Skript, was
ich euch austeile, eure eigene datenbankbasiert Website schreiben!"

Dann ist das Interesse gewährleistet und Schüler mit Vorwissen in HTML
(die es wohl geben wird) können dieses gewinnbringend anwenden.

> Aber grundsäztlich wäre es sicher nicht schlecht erstmal zu erklären,
> wozu Datenbanken da sind, was man mit ihnen machen kann, ein paar
> Regeln, Foreign Keys, auto_increment, Normalisieren, etc, etc... Erst
> danach, wenn die Schüler das Grundprinzip verstanden haben würde ich mit
> SQL anfangen, was interessierte Schüler interessieren wird, ich spreche
> aus eingenem erfahren :)

Genau das ist meine Vorgehensweise. Dabei natürlich nur so viel Theorie
wie nötig und mit vielen praktischen Beispielen zum ausprobieren und
nachmachen :-)

>
>> Sonst irgendwelche Tipps, was man noch beachten sollte? Ich habe in
>> meinen bisherigen Ausführungen schon darauf geachtet, nicht die
>> standard-Fehler zu machen (Sicherheit, etc.).
>>
> Die Schüler sollten die verbreitesten Regeln kennenlernen, Tabellen
> immer mit einem Feld "id", welches INT und auto_increment ist, etc.
> Sozusagen die "Nettiquette" oder die ungeschriebenen Regeln sind.

Ob das nun genau so heißen und aussehen muss, will ich mal dahingestellt
lassen (wenns nach mir geht: ja). Aber diese ungeschriebenen Regeln
werde ich auf jeden Fall vermitteln.

>
> > Daniel Fett
> Gruß, Niklas
>
>


--
E-Mail: dfett "bei" fragcom punkt de
www.fragcom.de / ICQ 119-700-134

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Matthias P. Wuerfl verfasste am 12.10.2004 19:08 n.Chr.:
> Rainer Huebenthal schrieb:
>
>>> Tabellen immer mit einem Feld "id", welches INT und auto_increment ist,
>>
>>
>>
>> Das ist hochgradiger Unsinn.
>>
>> Sofern man
>
>
> ...sehr viel Erfahrung hat und sich sehr sicher ist kann man
> ausnahmsweise auch manchmal drauf verzichten.
>
> *klopf-klopf* Hallo? McHuebenthal? Jemand zu Hause? :-) [*]
>
> Es geht hier um einen *Grundkurs* für *Schüler*. "In jeder Tabelle ein
> Primärschlüssel int auto_increment und ein timestamp" ist eine Klasse
> Regel, mit der man sich supergut Ärger vom Hals halten kann. Sie ist
> einfach zu vermitteln, einfach zu merken, einfach zu realisieren,
> meistens richtig und nie richtig falsch - wenn auch nicht immer
> unbedingt optimal.

Full ACK. Hier muss ein Mittelweg gefunden werden; Der geneigte Schüler
wird schon irgendwann die Erleuchtung finden, alle anderen sind so
zufrieden.

Daniel


--
E-Mail: dfett "bei" fragcom punkt de
www.fragcom.de / ICQ 119-700-134

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Markus Malkusch verfasste am 12.10.2004 00:43 n.Chr.:
> Daniel Fett:
>
>
>>Mal eine Frage: Ihr solltet Schülern PHP (und damit auch HTML) und MySQL
>>beibringen, wobei das Lernziel hauptsächlich mal die Beherrschung der
>>Datenbank ist.
>
>
> Dann sollte PHP (und HTML) nur als kurzes Anschaungsbeispiel dienen. MySQL

Ich möchte PHP und HTML vielmehr als praktische Anwendung denn als
Beispiel. Der Schüler soll nachher aus dem Kurs gehen und sagen: "Jap,
jetzt schreib ich mir mal ein Gästebuch!"

> sollte das RDBMS sein, und SQL-$version die Sprache. Ich würde dabei nicht
> den Fehler machen und nur MySQLs SQL beibringen, bzw. auch mal andere RDBMS
> vorstellen.

siehe weiter unten: Ein Blick über den Tellerrand, ja, aber keine
ausführliche Abhandlung.

>
>>Ich habe die Reihenfolge
>>MySQL, erst Kommandozeile, später PHPMyAdmin
>>HTML, kurz, nur das nötigste
>>PHP, erst allgemein, dann Datenbankspezifisch
>>gewählt. Ist das soweit sinnvoll?
>
>
> PHPMyAdmin würde ich ganz weglassen. Wenn man mit den mysql* tools umgehen
> kann, braucht man das Spielzeug nicht mehr.

Der Schüler [tm] soll aber Lust bekommen am Hantieren mit Tabellen und
sich nicht durch diverse Tools kämpfen müssen. Und als "Spielzeug" würde
ich das jetzt auch nicht grad bezeichnen....



> Warum Du HTML bringst ist mir
> auch nicht klar.

Für die praktische Anwendung. Ich will nachher keinen sagen hören (wie
das z.B. in Mathe so oft ist): "Und? Wozu muss ich im späteren Leben
Kurven diskutieren können?.

> Ich würde mal eher auf Grundsätze eingehen (Komplexität
> von linearer Suche und Notwendigkeit effizienter Strukturen...evtl. mit
> einem simplen binären Baum veranschaulicht) und dann eben noch

Neeeeeeee, du, das sprengt den Rahmen. 11. Klasse, Grundkurs, zwei
Stunden pro Woche.

> Datenbankdesign (Normalformen), was ja für die Anwendung enorm wichtig ist.

jap, das wird kommen.

--
E-Mail: dfett "bei" fragcom punkt de
www.fragcom.de / ICQ 119-700-134

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Daniel Fett:
> Markus Malkusch verfasste am 12.10.2004 00:43 n.Chr.:
>
>> PHPMyAdmin würde ich ganz weglassen. Wenn man mit den mysql* tools
>> umgehen kann, braucht man das Spielzeug nicht mehr.
>
> Der Schüler [tm] soll aber Lust bekommen am Hantieren mit Tabellen und
> sich nicht durch diverse Tools kämpfen müssen.

Ich bezweifle, dass er mit PHPMyAdmin dem SQL näher kommt. Wenn er
allerdings seine Tabellen mit SQL erzeugt und pflegt hat das einen gewissen
Lerneffekt und im Endeffekt ist man mit SQL effektiver als mit dem geklicke
im PHPMyAdmin.

>> Warum Du HTML bringst ist mir
>> auch nicht klar.
>
> Für die praktische Anwendung.

[..]

> > Ich würde mal eher auf Grundsätze eingehen (Komplexität
>> von linearer Suche und Notwendigkeit effizienter Strukturen...evtl. mit
>> einem simplen binären Baum veranschaulicht) und dann eben noch
>
> Neeeeeeee, du, das sprengt den Rahmen. 11. Klasse, Grundkurs, zwei
> Stunden pro Woche.

Und HTML sprengt nicht den Rahmen? Ich hoffe Du produzierst keine Klasse mit
Frontpagediletanten.

BTW. die Notwendigkeit eines DBMS ist in weniger als 10 Minuten erklärt. Du
musst ja keinen B-Baum erklären. Mein Dozent hat als Beispiel eine Suche
mit 10^30 Elementen gebracht. Ich fand es sehr beeindruckend, dass die
binäre Suche nur 100 anschauen muss.
--
- Kontonummerprüfung mit PHP

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Matthias P. Wuerfl, du schriebst:

>> Das ist hochgradiger Unsinn.
>>
>> Sofern man
>
> ...sehr viel Erfahrung hat und sich sehr sicher ist kann man
> ausnahmsweise auch manchmal drauf verzichten.
>
> *klopf-klopf* Hallo? McHuebenthal? Jemand zu Hause? :-) [*]
>
> Es geht hier um einen *Grundkurs* für *Schüler*.

Eben drum. Und denen bringe ich gleich Muell bei?


> Primärschlüssel int auto_increment und ein timestamp" ist eine Klasse
> Regel,

Mit der Regel wuerdest du deine Probezeit bei mir nicht
bestehen :)


> einfach zu vermitteln, einfach zu merken, einfach zu realisieren,
> meistens richtig und nie richtig falsch - wenn auch nicht immer
> unbedingt optimal.

Sie erspart einem das Nachdenken. Ist ja aber in heutzutage,
lieber das nachzuaeffen, was alle machen, anstatt Brain 1.0
und Zeit.2.0 zu investieren.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Michael Fesser, du schriebst:

> NACK

Ich dachte schon, ich waere alleine. Aber dieser Unsinn frisst
sich genauso durch wie die Linkgeschichte mit dem Landgericht
in Hamburg.

Aber ich seh schon, es war ein Fehler, sich mal wieder diese
NGs anzutun.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Daniel Fett wrote:
> Niklas Schumann verfasste am 12.10.2004 16:25 n.Chr.:
>
>> Daniel Fett wrote:
>>
>> Cool. Ich bin selber noch Schüler und fände das echt eine gute Idee.
>> Leider sind unsere Lehrer zu eingestaubt dafür :-)
>
>
> Musst du so machen wie ich: Ich bin 13. Klasse, gebe in einer 11.
> Unterricht und der Lehrer schaut zu und lernt selbst was dabei :-)

Bin 10te... Ich glaub kaum, das es sich lohnen würde oder das ich es
überhaupt darf.

Werde ich aber mal vorschlagen oder so...

--
Fatal Error: Could not find "brain" in Line 2004

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal wrote:
>
> Eben drum. Und denen bringe ich gleich Muell bei?
>

Nein.

>
>>Primärschlüssel int auto_increment und ein timestamp" ist eine Klasse
>>Regel,
>
>
> Mit der Regel wuerdest du deine Probezeit bei mir nicht
> bestehen :)
>

was das timestamp soll weiß ich nicht, aber was ist daran *schlecht*?

>
>>einfach zu vermitteln, einfach zu merken, einfach zu realisieren,
>>meistens richtig und nie richtig falsch - wenn auch nicht immer
>>unbedingt optimal.
>
>
> Sie erspart einem das Nachdenken. Ist ja aber in heutzutage,
> lieber das nachzuaeffen, was alle machen, anstatt Brain 1.0
> und Zeit.2.0 zu investieren.
>

*zustimm* - aber diese Regel ist für Anfänger bestens geeignet, und dek
dran, kein Meister ist je vom Himmel gefallen, du warst sicher auch kein
Profi von anfang an, und man lernt in Mathe ja auch nicht in der
Grundschule, warum 1+1=2 ist.

> cu
> Rainer
>
Niklas


--
Fatal Error: Could not find "brain" in Line 2004

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Niklas Schumann, du schriebst:

> Das ist hochgradiger Unsinn.
>>
>> Sofern man entsprechende Kandidatenschluessel hat, erübrigt
>> sich das. Bei einer Datenbank mit Buechern braucht es keine
>> solche ID, da (mindestens) ein Kandidatenschluessel
>> existiert:: die ISBN.
>
> Tja, wie ich sagte ist es eine ungeschriebene Regel. natürlich gibt es
> oftmals eine eindeutige Nummer,

Noch haeufiger gibt es zusammengesetzte Schluessel.

> troztdem bleibt es so übersichtlich, und

Trotzdem bleibt es unsinn, sowas per se einzufuegen.

> Wie dus machst, ist mir egal, aber es macht ein großteil der
> Programmierer so, und du kannst mir glauben, das ich einige
> "Datenbank-Profis" kenne, die diese Technik anwenden.

Dann sind es keine Datenbankprofis.

> Außerdem wäre es ja nur "hochgradiger Unsinn" wenn die Aussage *nie*
> zutreffen würde. Das tut sie aber nicht, also rede nicht so einen
> hochgradigen Unsinn.

Deine pauschale Regel ist Bloedsinn. Nur weil du es dir so
angewoehnt hast, macht es das nicht richtiger. Ansonsten:
Dieter Nuhr.

Ein unsubscribe empfiehlt sich. Selten so viel hanebuechenen
Unsinn gelesen. dclp* scheint sich vom Niveau her noch
verschlechtert zu haben. Fuer ein Gaestebuch mit 15 Eintraegen
mag deine Regel noch angehen.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:
> Aber ich seh schon, es war ein Fehler, sich mal wieder diese
> NGs anzutun.


Bleib doch bitte noch ein wenig hier.
Du musst einfach ein wenig Geduld mit dem Haufen hier haben. Sie werden
schon merken was sie an dir haben. Wenn du nun schon wieder gehst, weiß
die Mehrheit nicht was sie verpasst hat.

Gruß
Christian

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Niklas Schumann:

> was das timestamp soll weiß ich nicht, aber was ist daran *schlecht*?

Wenn Deine Tabelle mit unnötigen Feldern (oder gar Indexen) eine gewisse
Größe erreicht können diese Felder kostbare GB an Platz (und Traffic beim
Backup) kosten, bzw. Indexe kosten erheblichen Verwaltungsaufwand.

> und man lernt in Mathe ja auch nicht in der
> Grundschule, warum 1+1=2 ist.

Pauschal gesehen ist 1+1 nicht zwingend 2 (z.B. kann es auch 0 sein), und
warum das 2 sein kann lernt man auch nicht im Mathe LK. Das musst ich
gerade sagen, weil ich (hoffentlich nicht) demnächst mein Analysis VD habe.
--
- Whoisabfrage

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Niklas Schumann, du schriebst:

>> Eben drum. Und denen bringe ich gleich Muell bei?
>
> Nein.

Warum dann also nicht gleich richtig machen?

>>
>>>Primärschlüssel int auto_increment und ein timestamp" ist eine Klasse
>>>Regel,
>>
>> Mit der Regel wuerdest du deine Probezeit bei mir nicht
>> bestehen :)
>>
>
> was das timestamp soll weiß ich nicht, aber was ist daran *schlecht*?

Was ist daran gut? Und ich rede jetzt vom unix-timestamp, den
auch mysql intern benutzt, Wenn man zeibasierte Daten hat,
dann benutzt man Datum, Uhrzeit, notfalls Mikrosekunden. Und
kann damit Zeiten jenseits vom 1.1.1970 und 2038 problemlos
ablegen. Ohne sich je wieder den Kopf drueber zu zerbrechen.
Ok 9999 wirds eng, aber das ist weit genug hin.

>> Sie erspart einem das Nachdenken. Ist ja aber in heutzutage,
>> lieber das nachzuaeffen, was alle machen, anstatt Brain 1.0
>> und Zeit.2.0 zu investieren.
>>
>
> *zustimm* - aber diese Regel ist für Anfänger bestens geeignet

Sie ist voellig ungeeignet, weil sie wahre Zusammenhaenge und
damit weitere Loesungsmoeglichkeiten nicht aufzeigt. Ich kann
auch jemanden an den PC setzen und ihn mit MAPLE integrieren
lassen. Was er letztlich damit anstellt, weiss er aber immer
noch nicht. Man lernt erst die Grundlagen und wie es richtig
geht, danach kommen die vereinfachungen, die man dann gezielt
einsetzt und man weiss, was man anstellt.

> dran, kein Meister ist je vom Himmel gefallen, du warst sicher auch kein
> Profi von anfang an, und man lernt in Mathe ja auch nicht in der
> Grundschule, warum 1+1=2 ist.

Man lernt aber das es so ist. Und man kann gleich lernen, das
es auch zusammengesetzte Primaerschluessel gibt-
aquto_increment ist was fuer Leute, die nicht wissen, was sie
tun.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Moin Markus Malkusch, du schriebst:

>> und man lernt in Mathe ja auch nicht in der
>> Grundschule, warum 1+1=2 ist.
>
> Pauschal gesehen ist 1+1 nicht zwingend 2

Ich biete 11 und 10 :)

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Christian Hamacher, du schriebst:

> Du musst einfach ein wenig Geduld mit dem Haufen hier haben. Sie werden
> schon merken was sie an dir haben. Wenn du nun schon wieder gehst, weiß
> die Mehrheit nicht was sie verpasst hat.

Einen Suppenkasper meinst du? .) Ah nein, ich hab schon von
dem FAQ-Vorlesedienst dclp* aufgegeben.

Meiner Meinung nach zieht die Masse das Wissen im usenet stark
herunter. mysql gibts an jeder Ecke und mit PHPmyadmin kriegt
man es halbwegs zum funzen und meint, man haette grosse
Ahnung. Zum Glueck gibts noch Webforen, die ein Mindestmass an
Qualitaet bieten. Das usenet tut es groesstenteils nicht mehr.
jaja, das waren nochj zeiten damals....

fup2p wegen ot

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal:

> Moin Markus Malkusch, du schriebst:
>
>> Pauschal gesehen ist 1+1 nicht zwingend 2
>
> Ich biete 11 und 10 :)

Nö, ich habe an den einfachsten Körper F2, bei dem 1+1=0, gedacht. Die 10
könnte ich mir binär erklären, aber wie kommst Du auf 11?
--
- Kontonummerprüfung mit PHP

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Moin Markus Malkusch, du schriebst:

> Nö, ich habe an den einfachsten Körper F2, bei dem 1+1=0, gedacht. Die 10
> könnte ich mir binär erklären, aber wie kommst Du auf 11?

"1" + "1" = "11"

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal:

> aquto_increment ist was fuer Leute, die nicht wissen, was sie
> tun.

Das ist pauschaler Müll. Es gibt durchaus (nicht wenige) Fälle in dem keine
Kombination aus Feldern eindeutige Eigenschaften hat, oder zu groß sind.
--
- Whoisabfrage

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

.oO(Niklas Schumann)

>*zustimm* - aber diese Regel ist für Anfänger bestens geeignet, und dek
>dran, kein Meister ist je vom Himmel gefallen, du warst sicher auch kein
>Profi von anfang an, und man lernt in Mathe ja auch nicht in der
>Grundschule, warum 1+1=2 ist.

Ohnehin falsch, 1+1 ist schließlich 10.

SCNR
Micha

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Markus Malkusch schrieb:
> Daniel Fett:
>> Markus Malkusch verfasste am 12.10.2004 00:43 n.Chr.:
>>
>>> PHPMyAdmin würde ich ganz weglassen. Wenn man mit den mysql* tools
>>> umgehen kann, braucht man das Spielzeug nicht mehr.
>>
>> Der Schüler [tm] soll aber Lust bekommen am Hantieren mit Tabellen
>> und sich nicht durch diverse Tools kämpfen müssen.
>
> Ich bezweifle, dass er mit PHPMyAdmin dem SQL näher kommt. Wenn er
> allerdings seine Tabellen mit SQL erzeugt und pflegt hat das einen
> gewissen Lerneffekt und im Endeffekt ist man mit SQL effektiver als
> mit dem geklicke im PHPMyAdmin.

Aber man lernt, mit MySQL effektiv umzugehen. Das Lernziel ist hier wohl
eher die Fähigkeit, dieses Tool zu verwenden und nicht die Beherrschung
von Datenbankdesign (das gehört nicht in einen Grundkurs). Inhalt sollte
vielmehr Sinn und Zweck von Normalisierung sein ebenso wie die Benutzung
von MySQL mit den mysql_*-Funktionen und korrekter Fehlerbehandlung.
Datenbankklassen wie die aus PEAR sollten nur Erwähnung finden, aber
nicht vertieft werden.

>>> Ich würde mal eher auf Grundsätze eingehen (Komplexität
>>> von linearer Suche und Notwendigkeit effizienter Strukturen...evtl.
>>> mit einem simplen binären Baum veranschaulicht) und dann eben noch
>>
>> Neeeeeeee, du, das sprengt den Rahmen. 11. Klasse, Grundkurs, zwei
>> Stunden pro Woche.
>
> Und HTML sprengt nicht den Rahmen? Ich hoffe Du produzierst keine
> Klasse mit Frontpagediletanten.

Eher nicht. Es ist didaktisch wertvoll, schnelle Resultate zu bringen.
Dazu muss man lange nicht alles zeigen oder lehren; es sollte nur kein
Müll[tm] dabei sein. In diesem Zusammenhang ist sogar ein
HTML-Tabellen-Design akzeptabel, solange darauf hingewiesen und
beispielhaft gezeigt wird, dass CSS die bessere Wahl ist.

MfG
Niels

--
Informatiker haben Humor, allerdings lässt sich der nur schwer
im Quelltext ausdrücken. Ausnahme Microsoft: Dort arbeiten die
Kabarettisten der Informatik, die sogar lustigen Quelltext schreiben
können. [Oliver Schad in dclpm]

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Matthias P. Wuerfl schrieb:

> Es geht hier um einen *Grundkurs* für *Schüler*. "In jeder Tabelle ein
> Primärschlüssel int auto_increment und ein timestamp" ist eine Klasse
> Regel, mit der man sich supergut Ärger vom Hals halten kann. Sie ist
> einfach zu vermitteln, einfach zu merken, einfach zu realisieren,
> meistens richtig und nie richtig falsch - wenn auch nicht immer
> unbedingt optimal.

Es macht schon Sinn, die verschiedenen Arten (Verwendungszwecke) von
Tabellen zu unterscheiden. Daher ist die Formulierung "In *jeder*
Tabelle ..." nicht geeignet. Es gilt hier zu unterscheiden zwischen
Tabellen, die Entities wiederspiegeln (da ist das ok) und denen, die zB
n:m-Relationen darstellen (da ist zumindest eine id unsinnig).

MfG
Niels

--
'Geht nicht' gibt's nicht.
Es gibt nur ein 'Lohnt nicht'.

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:
> Moin Niklas Schumann, du schriebst:
>
>> Tabellen
>> immer mit einem Feld "id", welches INT und auto_increment ist,
>
> Das ist hochgradiger Unsinn.
>
> Sofern man entsprechende Kandidatenschluessel hat, erübrigt
> sich das. Bei einer Datenbank mit Buechern braucht es keine
> solche ID, da (mindestens) ein Kandidatenschluessel
> existiert:: die ISBN.

Blödsinn. Wer erzählt dir, die ISBN sei eindeutig?

MfG
Niels

--
Eigendlich is n Standart in der Rechtschreibung föllig
egal. Hauptsache is, mann ferstet mich! Ich kapier nur
ned, wiso der PHP-Pharser immer mekert?

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Markus Malkusch verfasste am 12.10.2004 21:12 n.Chr.:
> Und HTML sprengt nicht den Rahmen? Ich hoffe Du produzierst keine Klasse mit
> Frontpagediletanten.

Ich fühle mich in meiner Ehre gekränkt! Frontpage.... tststs.

Wie Niels nebenan schon sehr richtig bemerkt hat: Man muss nicht alles
erklären, man sollte nur nix falsches erklären. Wenn man mal einen
Grundstock in HTML gelegt, hat, kann der interessierte Schüler ohne
Probleme in entsprechenden Kompendien nachschauen und schnell Ergebnisse
produzieren. Wenn ich das weglasse, nimmt er doch gar nichts mit!

Daniel Fett


--
E-Mail: dfett "bei" fragcom punkt de
www.fragcom.de / ICQ 119-700-134

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Niklas Schumann verfasste am 12.10.2004 21:50 n.Chr.:
> Daniel Fett wrote:
>
>> Niklas Schumann verfasste am 12.10.2004 16:25 n.Chr.:
>>
>>> Daniel Fett wrote:
>>>
>>> Cool. Ich bin selber noch Schüler und fände das echt eine gute Idee.
>>> Leider sind unsere Lehrer zu eingestaubt dafür :-)
>>
>>
>>
>> Musst du so machen wie ich: Ich bin 13. Klasse, gebe in einer 11.
>> Unterricht und der Lehrer schaut zu und lernt selbst was dabei :-)
>
>
> Bin 10te... Ich glaub kaum, das es sich lohnen würde oder das ich es
> überhaupt darf.
>
> Werde ich aber mal vorschlagen oder so...

Lass dich zum Klassensprecher wählen und setz dich in die
Fachkonferenzen von Mathe, Physik und Info.
Weil: Info ist meistens Teilmenge von Physik ist meistens Teilmenge von
Mathe, was die Lehrer betrifft.
Und dann hast du genug Zeit, mal deine Vorschläge denen zu unterbreiten :-)

Daniel Fett


--
E-Mail: dfett "bei" fragcom punkt de
www.fragcom.de / ICQ 119-700-134

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal verfasste am 12.10.2004 22:06 n.Chr.:
> Moin Niklas Schumann, du schriebst:
>
>
>>>Eben drum. Und denen bringe ich gleich Muell bei?
>>
>>Nein.
>
>
> Warum dann also nicht gleich richtig machen?
>

Nun, ich denke, das hat was mit der maximalen Geschwindigkeit der
Aufnahme von Informationen in das menschliche Hirn und die
Speicherkapazitäten dessen zu tun:
Ich finde, man kann gerade in so einem Fall, _eine_ oder _wenigen_
fortgeschrittenen Anfänger viel eher nachher sagen: "Hey, eigentlich
geht das viel besser so-und-so..." oder: "Lass das mal, besser ist
das-und-das...", als man _vielen_ Anfängern _viel_ Stoff beibringen
kann, den sie später eh nie wieder anwenden.

Will meinen: Ich bringe doch lieber später einen Erfahrenen auf die
bessere, schwerere Spur als dass ich gleich mit Heerscharen von
Anfängern anödenden Stoff durchziehe.

Oder?

Daniel Fett

--
E-Mail: dfett "bei" fragcom punkt de
www.fragcom.de / ICQ 119-700-134

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Moin Markus Malkusch, du schriebst:

> Rainer Huebenthal:
>
>> aquto_increment ist was fuer Leute, die nicht wissen, was sie
>> tun.
>
> Das ist pauschaler Müll

Jo, aus dem Zusammenhang reissen kann jeder.



cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Daniel Fett, du schriebst:

> Will meinen: Ich bringe doch lieber später einen Erfahrenen auf die
> bessere, schwerere Spur als dass ich gleich mit Heerscharen von
> Anfängern anödenden Stoff durchziehe.
>
> Oder?

Nein, denn dieser Prozess wird nie stattfinden. Heute erwartet
man, das die Leute gleich loslegen. Eine gescheite Ausbildung
für ITler gibt es nicht. Daher wird der Muell, den man am
Anfang hineinstopft, erstmal weiter verteilt. Code Inspektion
finden in vielen Firmen nicht statt oder ist ein Fremdwort.
Woher kommt es eigentlich, dass ich noch immer
Datenbankdesigns sehe mit CHAR(6) fuers Datum? Das Geburtstage
im Unix Timestamp abgelegt werden? Das Wiederholgruppen in
Tabellen auftauchen? Das viele gar nicht wissen was ein
Primary Key ist? Was ein Kandidatenschluessel? Boys Codd?
Normalform? Funktionale Abhaengigkeiten?

Unix Timestamp und auto_increment kommen so haeufig fehl am
Platze vor, das Pauschalurteile hier erlaubt sind. Es ist
bequem, man braucht nicht nachzudenken, braucht diverses
Wissen nicht zu haben. Die Schwierigkeiten tauchen auch nicht
im xten Gaestebuch auf, auch nicht auf der privaten DVD
Sammlung. Es gibt durchaus Faelle. in denen man keine
eindeutigen Kandidtaenschluessel finden kann. Aber oft haben
sich bereits andere Leute darueber Gedanken gemacht, wie man
diese Entitaeten unterscheidet. Da gibt es dann ISBNs, ASINS,
EANs, weltweite eindeutige Produktnummen, Zentralbanknummern,
Bankleitzahlen, Kontonummern usw usw. Von daher ist die
Pauschalaussage "Jede Tabelle kriegt ne ID mit auto-increment"
schlicht und ergreifend Müll. Man macht sich erst Gedanken.
Dann erkennt man das man keinen Kandidtaenschluessel hat. Dann
überlegt man, wie dieser zu bewerkstelligen ist.
auto-increment ist ein selten gebrauchtes Werkzeug dazu.

Das uferlose Benutzen dieses unsaeglichen Features führt dann
irgendwo dazu, das immre wieder die Frage nach einer
Lückenlosen Sequenz auftaucht, das man nach einer Garbage
Collection sucht, die die Luecken wieden füllt. Hier zeigt
sich die Ahnungslosigkeit über Schluessel in voller Breite.
Man kann auch meistens nicht mehr dagegen argumentieren, denn
man findet zahllose Beispiele, Tutorials und Howtos und
Newsgroups, wo es auch so gemacht wird. Das kann doch nicht
alles falsch sein, wenn so viele das so machen? Leider
schreibt aber einer nur vom anderen an, und so verbeitet sich
auto-increment genauso Seuchenartig wie der
Landgericht-Hamburg-Disclaimer, der auch nicht hinterfragt
wird, sondern ohne nachzudenken eingebaut wird.

Jeder popelprovider bietet heute mysql und php und phpmyadmin
an, irgendwie stoepselt man was zusammen, syntaktisch macht
man mit phpmyadmin keine Fehler, irgendwie laeuft das auch,
aber dann funktioniert dieses nicht, oder jenes nicht, oder
jene Abfrage läßt sich nur übers Knie brechen. Auf die Aussage
"Dein Design ist kaputt" wird verstaenndlos mit dem kopf
geschuettelt. Statt es richtig zu machen kommt "Das ist nicht
vorgesehen" oder "Das wird so nie passieren". 640k should be
enough for evrybody wird belaechelt, aber nie auf die eigenen
Sachen angewendet.

Aber eigentlich ist mir das alles ganz recht, denn mit dem
reparieren von kaputten Datenbanken kann man gut Geld
verdienen. Schade nur, das soviel Wirtschaftskraft darauf
verschwendet werden muss, die ich-machs-erst-mal-simple
Loesung zu analysieren, zu konvertieren und entsorgen. Die
Augen sind gross, wenn man darlegt, das in der
Realisierungsphase ein richtiges Design grade mal 10% mehr
gekostet haette, jetzt aber 1000% mehr an laufenden Kosten und
Reparaturen kostet. Geiz ist geil regelt.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Niels Braczek, du schriebst:

> Es macht schon Sinn, die verschiedenen Arten (Verwendungszwecke) von
> Tabellen zu unterscheiden. Daher ist die Formulierung "In *jeder*
> Tabelle ..." nicht geeignet. Es gilt hier zu unterscheiden zwischen
> Tabellen, die Entities wiederspiegeln (da ist das ok) und denen, die zB
> n:m-Relationen darstellen (da ist zumindest eine id unsinnig).

Tabellen, die n:m Relationen aufloesen, haben einen PK, der
sich aus den zusammengesetzten FKs ergibt. Tabellen, die
Entities darstellen, brauchen *per se* auch keine auto-ID, die
ist in vielen Faellen unsinnig.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Niels Braczek, du schriebst:

> Blödsinn. Wer erzählt dir, die ISBN sei eindeutig?

Wenn du meinst.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Niels Braczek, du schriebst:

> Eher nicht. Es ist didaktisch wertvoll, schnelle Resultate zu bringen.
> Dazu muss man lange nicht alles zeigen oder lehren; es sollte nur kein
> Müll[tm] dabei sein. In diesem Zusammenhang ist sogar ein
> HTML-Tabellen-Design akzeptabel, solange darauf hingewiesen und
> beispielhaft gezeigt wird, dass CSS die bessere Wahl ist.

CSS und Tabellendesign haben nicht viel miteinander zu tun.
Tabellen design kann durchaus gut sein, Waehrend div-suppen
manchmal noch schlimmer als Frames sind.

Merkwuerdige Ansichten herrschen hier vor. Tabellendesigns
sind richtig angewendet sogar Barrierefrei, während man dies
von vielen "CSS" Designs nicht behaupten kann. Abe CSS ist ja
allheilmittel und Schic, ebenso wie jede Tabelle eine
auto-inc-ID braucht.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Niklas Schumann schrieb:

> was das timestamp soll weiß ich nicht

Du braucht "eine ID" um zu wissen welcher Datensatz und einen Timestamp
um zu wissen "welche Version des Datensatzes". Stichwort Optimistic
Locking. Wenn Du z.B. mit einem Access-Frontend auf MySQL zugreifst
flutscht das dann besser :-)

Grüße, Matthias

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:

> Da gibt es dann ISBNs, ASINS,
> EANs, weltweite eindeutige Produktnummen, Zentralbanknummern,
> Bankleitzahlen, Kontonummern usw usw. Von daher ist die
> Pauschalaussage "Jede Tabelle kriegt ne ID mit auto-increment"
> schlicht und ergreifend Müll. Man macht sich erst Gedanken.
> Dann erkennt man das man keinen Kandidtaenschluessel hat. Dann
> überlegt man, wie dieser zu bewerkstelligen ist.

Dann implementiert man es so. Dann geben die Benutzer Daten ein. Dann
kommt das erste Buch, welches zwar schon eingegeben werden soll, welches
aber noch keine ISBN hat. Dann steht man da. Dann frickelt man rum um
solche Bücher irgendwie in die Datenbank reinzupfuschen. Dann verändern
Banken ihre Bankleitzahl und nix stimmt mehr und die neue Bank bekommt
die Bankleitzahl von der einen alten, die es wegen Fusionierung nicht
mehr gibt, Deine Datenbank soll aber die (historischen) Daten der alten
Bank und die der neuen getrennt voneinander bearbeiten können. Haha. Da
kommt Freude auf.

Ich halte die Aussage - so wie Du sie triffst, mit *den* Beispielen -
für weit-aus-dem-Fenster-gehängt. *Gerade* ISBNs, Bankleitzahlen,
Kontonummern und (allgemein) ominöse Kundennummern aus zweifelhaften
Drittprogrammen sind gefährlich, weil sie oft nur *vorgeben* Kandidaten
zu sein, es in Wirklichkeit oft aber nicht sind - und selbst wenn: Sie
sind es nur bis sie vom Nachfolge-Nummern-System abgelöst werden. Deine
Datenbank soll das Nummernsystem aber vielleicht überleben. Wie dem auch
sei: hat man *so* einen zum PK erkoren, dann sieht man oft geküsst aus.

Des weiteren solltest Du beachten, welche Implikationen die Wahl des PK
auf die Schnittstellen zum Frontend hat. Ich habe schon oft einen
08/15-PK (Object-ID, int mit auto_increment oder wasauchimmer)
nachträglich eingebaut, weil die verwendete Software zur Gestaltung des
Frontends und/oder anderer Schnittstellen anders einfach zu viel
Probleme/Aufwand bereitete (namentlich insbesondere Access)

Versteh' mich nicht falsch: Prinzipiell stimme ich mit Dir überein, aber
ich halte nicht alles für einen Schlüsselkandidat, was auf den ersten
Blick so aussieht oder einfach nur "Nummer" im Namen trägt :-P

Grüße, Matthias

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:

>>Blödsinn. Wer erzählt dir, die ISBN sei eindeutig?
>
>
> Wenn du meinst.

Ich habe hier ein Buch ohne ISBN und ich bin *sicher* es gibt noch ein
zweites. Ich bin ausserdem *sicher*, dass die Fälle für Datenbanken, in
denen ein "Buch" genau *das* ist, was durch *eine* ISBN gekennzeichnet
ist, selten sind: Entweder möchte man zwischen verschiedenen Versionen,
Covern, ... unterscheiden, die *eine* ISBN haben oder man möchte mehrere
ISBNs zusammenfassen. Das kannst Du Dir aussuchen, aber dass ein
"externer" Schlüssel, dessen Vergabe man nicht unter Kontrolle hat, so
gut in eine Applikation passt, dass man deren grundlegende
Funktionalität auf Gedeih und Verderb von ihm abhängig machen möchte ist
selten.

Grüße, Matthias

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:

>>Das ist pauschaler Müll

> aus dem Zusammenhang reissen kann jeder.

:-)

War das jetzt scherzhaft gemeint?

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Matthias P. Wuerfl, du schriebst:

> Dann implementiert man es so. Dann geben die Benutzer Daten ein. Dann
> kommt das erste Buch, welches zwar schon eingegeben werden soll, welches
> aber noch keine ISBN hat.

Wenn es noch keine ISBN hat, kann man es nicht bestellen. Auf
der Biuchmesse eine Messeexemplar geklaut? :)

> solche Bücher irgendwie in die Datenbank reinzupfuschen. Dann verändern
> Banken ihre Bankleitzahl und nix stimmt mehr und die neue Bank bekommt
> die Bankleitzahl von der einen alten, die es wegen Fusionierung nicht
> mehr gibt, Deine Datenbank soll aber die (historischen) Daten der alten
> Bank und die der neuen getrennt voneinander bearbeiten können. Haha. Da
> kommt Freude auf.

Thats life, Wenn aber sowas passiert, dann fliegt mir
wenigstens die Applikation um die Ohren und der angelieferte
Datenmuell wird nicht stillschweigend in die Datenbank
eingepflegt und kann dort unbemerkt wochenlang unheil
anrichten, bevor es einer merkt. *Da* kommt fFeude auf.

> Ich halte die Aussage - so wie Du sie triffst, mit *den* Beispielen -
> für weit-aus-dem-Fenster-gehängt. *Gerade* ISBNs, Bankleitzahlen,
> Kontonummern und (allgemein) ominöse Kundennummern aus zweifelhaften
> Drittprogrammen sind gefährlich,

Eben drum und genau deswegen lasse ich es lieber scheppern
oder eleganter in einen Error-Workflow fliessen als es
stillschweigend in die Tabelle einfliessen zu lassen. Gerade
Kontonummern und Bankleitzahlen sind sensibel und
stillschweigende Fehlerbehandlung ist das uebelste was man
hier tun kann.

> zu sein, es in Wirklichkeit oft aber nicht sind - und selbst wenn: Sie
> sind es nur bis sie vom Nachfolge-Nummern-System abgelöst werden. Deine
> Datenbank soll das Nummernsystem aber vielleicht überleben. Wie dem auch
> sei: hat man *so* einen zum PK erkoren, dann sieht man oft geküsst aus.

Noe. 6 Stellige Wertpapierkennummer auf die 12stellige ISIN
ohne Probleme umgestellt. WPKN war PK, nun ists die ISIN.
Alltaegliches GEschaeft und mit Tool wie Platinum ein
Kinderspel.

> Des weiteren solltest Du beachten, welche Implikationen die Wahl des PK
> auf die Schnittstellen zum Frontend hat. Ich habe schon oft einen
> 08/15-PK (Object-ID, int mit auto_increment oder wasauchimmer)
> nachträglich eingebaut, weil die verwendete Software zur Gestaltung des
> Frontends und/oder anderer Schnittstellen anders einfach zu viel
> Probleme/Aufwand bereitete (namentlich insbesondere Access)

Sensible Daten legt man nicht in Access ab. Das ist ja auch
keine Datenbank.

> Versteh' mich nicht falsch: Prinzipiell stimme ich mit Dir überein, aber
> ich halte nicht alles für einen Schlüsselkandidat, was auf den ersten
> Blick so aussieht oder einfach nur "Nummer" im Namen trägt :-P

Hab ich das gesagt? Hab ich nicht saetzelang schon drueber
philosophiert, das man erst nachdenkt? Und nicht einfach per
se id-auto-inc einfuehrt?

Du darfst mir gerne mal erklaeren, warum du in einer
Waherungsdatenbank eine ID einführen möchtest. Es kommt an:
ISO-Waehrung und Faktor.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Matthias P. Wuerfl, du schriebst:

> Ich habe hier ein Buch ohne ISBN

Ja. Und? Dann erfindest du eine.

> zweites. Ich bin ausserdem *sicher*, dass die Fälle für Datenbanken, in
> denen ein "Buch" genau *das* ist, was durch *eine* ISBN gekennzeichnet
> ist, selten sind: Entweder möchte man zwischen verschiedenen Versionen,
> Covern, ...

Unterschiedliche Cover haben unterschiedliche ISBNs, und man
kann ja die Aauflage noch dazu nehmen. Zaehlen wir jetzt
Erbsen?

> oder man möchte mehrere
> ISBNs zusammenfassen.

Zusammenfassen zu was?

> gut in eine Applikation passt, dass man deren grundlegende
> Funktionalität auf Gedeih und Verderb von ihm abhängig machen möchte ist
> selten.

Gang und gaebe. Und in der Regel problemlos. Und wenn es
Probleme gibt moechte ich die wissen.Und warum man das macht,
habe ich dir auch geschrieben.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:

> Wenn es noch keine ISBN hat, kann man es nicht bestellen. Auf
> der Biuchmesse eine Messeexemplar geklaut? :)

nö, schon bestellt, aber halt "dem Namen nach". Wiki-Reader (Wikipedia).

[PK-Restrukturierung durch Sachzwänge von aussen]

> Thats life, Wenn aber sowas passiert, dann fliegt mir
> wenigstens die Applikation um die Ohren und der angelieferte
> Datenmuell wird nicht stillschweigend in die Datenbank
> eingepflegt und kann dort unbemerkt wochenlang unheil
> anrichten, bevor es einer merkt. *Da* kommt fFeude auf.

Nun, ich hätte dann bei jedem "Konto" neben dem PK zwei Felder:
"KtoNrAlt" und "KtoNrNeu" jedes natürlich Unique. Ausgehend davon dass
es so gemacht ist, dass nichts "kaputt" geht (logisch) hat "meine"
Methode den Vorteil, dass Veraenderungen IMHO einfacher sind.

> stillschweigende Fehlerbehandlung ist das uebelste was man
> hier tun kann.

Natuerlich.

> Noe. 6 Stellige Wertpapierkennummer auf die 12stellige ISIN
> ohne Probleme umgestellt. WPKN war PK, nun ists die ISIN.

Wieviel Tabellen musstest Du anfassen, die die WPKN als FK hatten? Wie
lange stand die Datenbank für die Umstellung still?

> Sensible Daten legt man nicht in Access ab. Das ist ja auch
> keine Datenbank.

Es ging mir um Access als Frontend.

>>Versteh' mich nicht falsch: Prinzipiell stimme ich mit Dir überein, aber
>>ich halte nicht alles für einen Schlüsselkandidat, was auf den ersten
>>Blick so aussieht oder einfach nur "Nummer" im Namen trägt :-P
>
>
> Hab ich das gesagt?

Natürlich nicht, aber ein "Anfänger" könnte es so verstehen. Es geht ja
um eine Grundlagenschulung und ich denke davor kann man nicht genug warnen.

> Du darfst mir gerne mal erklaeren, warum du in einer
> Waherungsdatenbank eine ID einführen möchtest. Es kommt an:
> ISO-Waehrung und Faktor.

Wenn wirklich die Währung, die Währung und nichts als die Währung (also
nicht implizit das Land oder sowas) gemeint ist, dann würde ich
vielleicht auch drauf verzichten.

....wobei...

"ISO"? Waren das nicht die Typen die einen 2-Buchstaben-Code für
irgendein Land zum zweiten mal vergeben haben, weil er für das erste
Land nicht so viel in Gebrauch war? *nachschau* Ja, genau. "cs" gehörte
zuerst der Tschechoslovakei und gehört jetzt Serbien-Montenegro.

Grüße, Matthias

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:

>>Ich habe hier ein Buch ohne ISBN
>
>
> Ja. Und? Dann erfindest du eine.

Na toll.

> Unterschiedliche Cover haben unterschiedliche ISBNs

>>oder man möchte mehrere
>>ISBNs zusammenfassen.
>
>
> Zusammenfassen zu was?

"Büchern" im Sinne von "Wieviele Bücher hat der Schriftsteller geschrieben?"

[Fremd gesteuerte "Nummern" als PK]

> Gang und gaebe. Und in der Regel problemlos. Und wenn es
> Probleme gibt moechte ich die wissen.

Ja klar, aber mit ist es dann lieber ich mache einfach das "Interface"
neu, als dass ich die ganze Datenbank umstricken muss.

Grüße, Matthias

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal wrote:

> Moin Niklas Schumann, du schriebst:
>
>>Tabellen
>>immer mit einem Feld "id", welches INT und auto_increment ist,
>
> Das ist hochgradiger Unsinn.
>
> Sofern man entsprechende Kandidatenschluessel hat, erübrigt
> sich das. Bei einer Datenbank mit Buechern braucht es keine
> solche ID, da (mindestens) ein Kandidatenschluessel
> existiert:: die ISBN.
>

Das ist hochgradiger Unsinn! (SCNR)

Lies bitte: http://www.isbn-international.org/en/userman/chapter4.html

Abgesehen davon, dass ISBN z.Z. nur in 159 Ländern (von 280?) verwendet
wird gibt es auch einige Konventionen bzgl. der ISBN - siehe Link.

Dein Beispiel hinkt also kräftig. Ich persönlich verwende auch sehr
häufig unter MySQL eine autoincrement-Spalte als pk. Selbst wenn man
glaub, dass es einen passenden "Kandidatenschlüssel" (wie o.g. ISBN)
gibt wird man doch oft feststellen, dass dieser nicht so eindeutig sein
muss, wie man dachte. Und ich mag nicht wirklich regelmässig
Tabellenstrukturen ändern - gerade bei grossen Datenbeständen geht das
auch gerne ins Auge (Tabelle muss anschliessend repariert werden) und
dauert natürlich entsprechend.

Gruss, Frank

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal:

> Eine gescheite Ausbildung für ITler gibt es nicht.

[..]

> Das Wiederholgruppen in
> Tabellen auftauchen? Das viele gar nicht wissen was ein
> Primary Key ist? Was ein Kandidatenschluessel? Boys Codd?
> Normalform? Funktionale Abhaengigkeiten?

Lernt man so was nicht in gängigen DBMS-Vorlesungen? Also ich kann mit
meinem Informatikstudium sehr viel anfangen.

> Aber eigentlich ist mir das alles ganz recht, denn mit dem
> reparieren von kaputten Datenbanken kann man gut Geld
> verdienen.

Ich habe selber so ein Projekt gekriegt und es macht wirklich keinen Spaß.
Das schlimme ist, ich muss mit dem kaputten Design arbeiten, weil das
reparieren würde einer Neuimplementierung entsprechen, und das will er
nicht zahlen (obwohl ich ihm erklärt habe dass es im Endeffekt biliger
wird).

> Augen sind gross, wenn man darlegt, das in der
> Realisierungsphase ein richtiges Design grade mal 10% mehr
> gekostet haette, jetzt aber 1000% mehr an laufenden Kosten und
> Reparaturen kostet. Geiz ist geil regelt.

Leider FULL ACK.
--
- Whoisabfrage

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal:
> Moin Markus Malkusch, du schriebst:
>> Rainer Huebenthal:
>>
>>> aquto_increment ist was fuer Leute, die nicht wissen, was sie
>>> tun.
>>
>> Das ist pauschaler Müll
>
> Jo, aus dem Zusammenhang reissen kann jeder.

Dann habe ich es wohl missverstanden. Es klang für mich wie eine
Pauschalaussage, die darüber hinwegsieht, dass ein Schlüssel in einem DBMS
u.U. eine beschränkte Größe hat (insbes. wenn man Heaps nutzt, die in den
Speicher müssen) bzw. dass die Größe auch auf die Performance gehen könnte
oder dass einfach keine eindeutigen Kandidaten vorhanden sind (und man
keine Möglichkeit hat an die interne oid zugelangen).
--
- Kontonummerprüfung mit PHP

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:
> Unterschiedliche Cover haben unterschiedliche ISBNs,

Leider nicht :(
Sogar unterschiedlicher Inhalt kann die gleiche ISBN haben.

> und man kann ja die Aauflage noch dazu nehmen.

Man muß, wie uns ISBN 3141006008 gezeigt hat.

> Zaehlen wir jetzt Erbsen?

Die Schulbuchkosten meiner Tochter sind um 36.95 EUR gestiegen. Ok ist
kein Beinbruch für uns, aber von Erbsen zählen möchte ich da nicht mehr
sprechen.


Gruß
Christian

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Moin Matthias P. Wuerfl, du schriebst:

> Nun, ich hätte dann bei jedem "Konto" neben dem PK zwei Felder:
> "KtoNrAlt" und "KtoNrNeu" jedes natürlich Unique. Ausgehend davon dass
> es so gemacht ist, dass nichts "kaputt" geht (logisch) hat "meine"
> Methode den Vorteil, dass Veraenderungen IMHO einfacher sind.

Eine Historie sieht iegentlich etwas anders aus :) Stichwort:
Zeitliche Abgrenzung.

>> Noe. 6 Stellige Wertpapierkennummer auf die 12stellige ISIN
>> ohne Probleme umgestellt. WPKN war PK, nun ists die ISIN.
>
> Wieviel Tabellen musstest Du anfassen, die die WPKN als FK hatten?

Ich hab sie nicht gezaehlt.

> Wie
> lange stand die Datenbank für die Umstellung still?

0 Tage, 0 Stunden, 0 Minuten, 0 Sekunden.

>> Hab ich das gesagt?
>
> Natürlich nicht, aber ein "Anfänger" könnte es so verstehen. Es geht ja
> um eine Grundlagenschulung und ich denke davor kann man nicht genug warnen.

Grundlagenschulung wuerd ich ueber funktionale Abhaengigkeiten
machen. Das ist fuer kleine Projekte mit bis zu einem Dutzend
Tabellen immer noch uebersichtlich, erklaert wie man einen PK
findet. Das man keine Normalisierung bis zur zur 5.Normalform
schafft ist eh klar. FA aber wären ein besserer Ansatz als
per-se-IDs.

> Wenn wirklich die Währung, die Währung und nichts als die Währung (also
> nicht implizit das Land oder sowas) gemeint ist, dann würde ich
> vielleicht auch drauf verzichten.

ISO Waehrung ist dreistellig und genormt. Wobei der
Hauptaerger bei der Umstellung die Banken waren, die partout
DM statt DEM angedruckt haben wollten und deswegen hunderte
Applikationen eine Uebersetzung brauchten. Und die leidige
Reichsmark und Goldmark, da gibts dann nämlich noch immer
Genussscheine, die in dieser Waehrung "ausbezahlt werden" und
wo noch immer kein Schwein weiss, wie man das nun umrechnet :)

> "ISO"? Waren das nicht die Typen die einen 2-Buchstaben-Code für
> irgendein Land zum zweiten mal vergeben haben, weil er für das erste
> Land nicht so viel in Gebrauch war? *nachschau* Ja, genau. "cs" gehörte
> zuerst der Tschechoslovakei und gehört jetzt Serbien-Montenegro.

ISO Waehrung ist dreistellig. DEM, USD, FRF,....

Die alten Währungen waren zweistellig: DM, US, FR

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Moin Markus Malkusch, du schriebst:

>> Eine gescheite Ausbildung für ITler gibt es nicht.
>
> [..]
>
>> Das Wiederholgruppen in
>> Tabellen auftauchen? Das viele gar nicht wissen was ein
>> Primary Key ist? Was ein Kandidatenschluessel? Boys Codd?
>> Normalform? Funktionale Abhaengigkeiten?
>
> Lernt man so was nicht in gängigen DBMS-Vorlesungen? Also ich kann mit
> meinem Informatikstudium sehr viel anfangen.

Ich habe nicht viel mit Informatikern am Hut, denn im meinem
Umfeld arbeitet so gut wie keiner. Die Handvoll, die ich
kennengelernt habe, konnte man praxisgerecht nicht einsetzen,
entweder zu esoterisch, zu kaufmaennisch oder zu wenig taug.

cu
Rainer

--
http://www.reisetraeume.com

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Markus Malkusch wrote:
> Wenn Deine Tabelle mit unnötigen Feldern (oder gar Indexen) eine gewisse
> Größe erreicht können diese Felder kostbare GB an Platz (und Traffic beim
> Backup) kosten, bzw. Indexe kosten erheblichen Verwaltungsaufwand.
>
Ok, aber ich glaube kaum, das das bei simplen PHP Scripts geschehen
wird. Zumindestens habe ich das Problem noch nie gehabt.

> Pauschal gesehen ist 1+1 nicht zwingend 2 (z.B. kann es auch 0 sein),...
Klar. Binärsystem. Aber ich meinte es als Sinnbild.

> und
> warum das 2 sein kann lernt man auch nicht im Mathe LK. Das musst ich
> gerade sagen, weil ich (hoffentlich nicht) demnächst mein Analysis VD habe.
S.o.


--
Fatal Error: Could not find "brain" in Line 2004

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Daniel Fett wrote:
> Lass dich zum Klassensprecher wählen
Naja. Das zieht auch noch andere Sachen mit sich.

[OT]
> und setz dich in die
> Fachkonferenzen von Mathe, Physik und Info.
> Weil: Info ist meistens Teilmenge von Physik ist meistens Teilmenge von
> Mathe, was die Lehrer betrifft.
> Und dann hast du genug Zeit, mal deine Vorschläge denen zu unterbreiten :-)
Stimmt :)

> Daniel Fett
Niklas
--
Fatal Error: Could not find "brain" in Line 2004

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

.oO(Rainer Huebenthal)

>Das viele gar nicht wissen was ein
>Primary Key ist? Was ein Kandidatenschluessel? Boys Codd?
^^^^
*räusper*

SCwirklichNR
Mi's/s/ce/'cha

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

.oO(Rainer Huebenthal)

>Grundlagenschulung wuerd ich ueber funktionale Abhaengigkeiten
>machen. Das ist fuer kleine Projekte mit bis zu einem Dutzend
>Tabellen immer noch uebersichtlich, erklaert wie man einen PK
>findet. Das man keine Normalisierung bis zur zur 5.Normalform
>schafft ist eh klar. FA aber wären ein besserer Ansatz als
>per-se-IDs.

Passend dazu ein kleines (noch unvollständiges) Projekt, entstanden im
Rahmen meines Studiums als "Praktikum" in Entwurfstheorie:

http://www.mfesser.de/studium/rparse/

Prüft ein Schema von funktionalen Abhängigkeiten bis BCNF, bei
Nichterfüllung der 3NF wird zerlegt. (Das default-Beispiel stammt nicht
von uns, ist aus einem Buch.)

Momentan bauen wir das Ding etwas um (im Rahmen eines zweiten Praktikums
;-), unter anderem werden noch Zerlegungen bei Nichterfüllung der 2NF
bzw. BCNF ergänzt und das Interface gründlich überarbeitet.

Micha

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Niklas Schumann:
> Markus Malkusch wrote:
>
>> Wenn Deine Tabelle mit unnötigen Feldern (oder gar Indexen) eine gewisse
>> Größe erreicht können diese Felder kostbare GB an Platz (und Traffic beim
>> Backup) kosten, bzw. Indexe kosten erheblichen Verwaltungsaufwand.
>
> Ok, aber ich glaube kaum, das das bei simplen PHP Scripts geschehen
> wird.

Doch sogar mit einem sehr simplen:

while(true) {
mysql_query('INSERT INTO table (felder) VALUES("werte")');
}

> Zumindestens habe ich das Problem noch nie gehabt.

Na und, ich schon und was heißt das jetzt? I.d.R. benutzt man genau wegen
einer enorm hohen Anzahl an Daten ein RDBMS (sonst kann man auch linear auf
Dateien arbeiten). Also wird es auch üblich sein, dass dies auftritt.

>> Pauschal gesehen ist 1+1 nicht zwingend 2 (z.B. kann es auch 0 sein),...
> Klar. Binärsystem.

Nein da ist es 10. Ich meinte den Körper F2 (mit der üblichen Definition von
+).

> Aber ich meinte es als Sinnbild.

OK
--
- Kontonummerprüfung mit PHP

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:
> Moin Niels Braczek, du schriebst:
>
>> Eher nicht. Es ist didaktisch wertvoll, schnelle Resultate zu
>> bringen. Dazu muss man lange nicht alles zeigen oder lehren; es
>> sollte nur kein Müll[tm] dabei sein. In diesem Zusammenhang ist
>> sogar ein HTML-Tabellen-Design akzeptabel, solange darauf
>> hingewiesen und beispielhaft gezeigt wird, dass CSS die bessere Wahl
>> ist.
>
> CSS und Tabellendesign haben nicht viel miteinander zu tun.

In dem von mir gemeinten Kontext schon.

> Tabellen design kann durchaus gut sein, Waehrend div-suppen
> manchmal noch schlimmer als Frames sind.

Man kann alles so anwenden, dass das Ergebnis kaum brauchbar ist.

> Merkwuerdige Ansichten herrschen hier vor. Tabellendesigns
> sind richtig angewendet sogar Barrierefrei, während man dies
> von vielen "CSS" Designs nicht behaupten kann.

Tabelle statt CSS kann keine barrierefreien Ergebnisse liefern, da die
Anforderungen nicht Sehender in Bezug auf die Reihenfolge der Elemente
völlig anders sind als die Sehender. Die Bedienung beider lässt sich nur
mit per CSS positionierten Elementen erreichen.

> Abe CSS ist ja
> allheilmittel und Schic, ebenso wie jede Tabelle eine
> auto-inc-ID braucht.

Hast du auch Argumente, oder trainierst du Polemik?

MfG
Niels

--
Bitte senden Sie mir keine Microsoft-Anhänge.
Siehe http://www.gnu.org/philosophy/no-word-attachments.de.html

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:
> Moin Niels Braczek, du schriebst:
>
>> Blödsinn. Wer erzählt dir, die ISBN sei eindeutig?
>
> Wenn du meinst.

Ich *weiß*.

MG
Niels

--
Microsoft is not the answer - Microsoft is the question.
The answer is NO!

Re: pädagogischsinnvoll MySQL und PHP lernen:-)

On Wed, 13 Oct 2004 09:28:53 +0200, Matthias P. Wuerfl wrote:
> Rainer Huebenthal schrieb:
>
>> Da gibt es dann ISBNs, ASINS,

> kommt das erste Buch, welches zwar schon eingegeben werden soll, welches
> aber noch keine ISBN hat. Dann steht man da. Dann frickelt man rum um
> solche Bücher irgendwie in die Datenbank reinzupfuschen. Dann verändern

Gibt es nicht. Bücher die im offiziellen Buchhandel erscheinen
sollen haben bereits vor ihrer Veröffentlichung eine ISBN.
Und Bücher die nicht im offiziellen Buchhandel erscheinen sollen
kann man meinetwegen Druckwerke nennen.

Eine ISBN kann auch jedermann, mit etwas Aufwand, selbst beantragen.
Nicht einzeln, nur im Kännchen. Aus dem Gedächtnis: Börsenverein des
deutschen Buchhandels, FFM.

Gibt mindestens ein Buch, was sonst, wo beschrieben wird, wie man
einen eigenen Verlag aufmacht um sein selbstgeschriebenes Buch an
den MannIn zu bekommen.

Nicht getestet, Google: Selbstverlag.

> Banken ihre Bankleitzahl und nix stimmt mehr und die neue Bank bekommt
> die Bankleitzahl von der einen alten, die es wegen Fusionierung nicht

Kommt auch so häufig vor.
Meine alte Bank hat auch fusioniert, still und heimlich, hat ihren
Namen und ihre BLZ behalten. Nur die Anschriften auf den
Briefumschlägen gehen nun in eine andere Stadt.
Eben weil die Devise wohl heißt: blos nicht anfangen an 30 Jahre
gewachsenen Daten und Programmen groß rumschrauben, kann in Hose
gehen und es geht um Geld.

Nachbestellung von vorbedruckten 12 Umschlägen übrigens 6,60 EUR.
Ist aber eine andere Story und wirklich wert in einem anderem Medium
breiter diskutiert zu werden.

Ich fand den Aufsatz von R. Hübental sehr interessant.

D.

Re: pädagogisch sinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal schrieb:

>>>Noe. 6 Stellige Wertpapierkennummer auf die 12stellige ISIN
>>>ohne Probleme umgestellt. WPKN war PK, nun ists die ISIN.
>>
>>Wieviel Tabellen musstest Du anfassen, die die WPKN als FK hatten?
>
>
> Ich hab sie nicht gezaehlt.
>
>
>>Wie
>>lange stand die Datenbank für die Umstellung still?
>
>
> 0 Tage, 0 Stunden, 0 Minuten, 0 Sekunden.

Wie geht das? Bis zu den "0 Stunden" glaube ich das ja. Wenn man das
ganze gut vorbereitet und automatisiert hat mag das sein, aber sowas
komplett ohne Downtime?

Grüße, Matthias

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Rainer Huebenthal:

>>> Eine gescheite Ausbildung für ITler gibt es nicht.

[..]

> Ich habe nicht viel mit Informatikern am Hut, denn im meinem
> Umfeld arbeitet so gut wie keiner.

Evtl. liegt es an Deinem Umfeld¹. Ich kann mir nicht vorstellen, wie jemand
der mit einer Hand voll Gattern eine CPU baut, sich eine ausreichende
Sprache ausdenkt, einen Übersetzer für seine CPU baut und dann ein OS mit
Scheduler, FS, Speicherverwaltung, usw dazu schreibt,² seinen Unterhalt mit
Scripte verdient.

> Die Handvoll, die ich
> kennengelernt habe, konnte man praxisgerecht nicht einsetzen,

Das ist vermutl. wie mit Lehrern: Ein Mathelehrer ist in Mathe pervers
überqualifiziert, aber pädagogisch meist unerfahren.

> entweder zu esoterisch

Das kommt von den "Theoretische Informatik" Vorlesungen.

> , zu kaufmaennisch

Das sind die Wirtschaftsinformatiker. Nachdem was ich gehört habe sind das
keine ernstzunehmenden Informatiker. *duck*


[1]: Ich leite das mal von dem p in dclp ab.


[2]: Soviel zur Theorie. Ich glaube kaum, dass sich einer hinsetzt und Jahre
seines Lebens damit vergeudet etwas zu produzieren was nicht
annähernd an die Qualität vorhandener (und freier) Implementierungen
reicht. Und ich persönlich würde mir gerade mal ein paar
Basisoperationen einer ALU zutrauen.
--
- Whoisabfrage

Re: pädagogischsinnvoll MySQL und PHP lernen :-)

Markus Malkusch schrieb:

Moin,

>> entweder zu esoterisch
> Das kommt von den "Theoretische Informatik" Vorlesungen.

Ähm nein glaube eher nicht ;-).
Aber ich lass das mal so stehen weil widerlegen kann ich es nicht. *g*

>> , zu kaufmaennisch
>
> Das sind die Wirtschaftsinformatiker. Nachdem was ich gehört habe sind das
> keine ernstzunehmenden Informatiker. *duck*

Ne stimmt. Das sind die Leute die den Informatikern sagen was sie zu tun
haben, weil die zu esoterisch sind und nicht alleine mit den Auftraggebern
klarkommen. ;P

SCNR
Christoph