Engin: DB Normalisieren und eine ID in 3 Tabellen speichern

0 46

DB Normalisieren und eine ID in 3 Tabellen speichern

Engin
  • datenbank
  1. 0
    Ilja
    1. 0

      DB Normalisieren Ok. 3 INSERT INTO ausführen Problem

      Engin
      1. 0
        Struppi
        1. 0
          Engin
          1. 0
            ChrisB
            1. 0

              3 INSERT INTO ausführen Problem auch OK.

              Engin
              1. 0
                ChrisB
                1. 0

                  LAST_INSERT_ID() bzw. mysql_insert_id() wie richtig verwenden?

                  Engin
                  1. 0
                    ChrisB
                    1. 0
                      Engin
                    2. 0
                      EKKi
                      1. 0
                        Sven Rautenberg
                        1. 0
                          EKKi
                          1. 0
                            Sven Rautenberg
                            1. 0
                              EKKi
                  2. 0
                    Struppi
                    1. 0
                      Engin
                      1. 0
                        ChrisB
                        1. 0
                          Engin
                          1. 0
                            ChrisB
                            1. 0

                              Danke!

                              Engin
                      2. 0
                        Struppi
  2. 0

    Noch eine frage zur DB normailiserung

    Engin
    1. 0
      ChrisB
      1. 0
        Engin
        1. 0
          EKKi
          1. 0
            Engin
            1. 0
              EKKi
              1. 0
                Engin
                1. 0
                  EKKi
                  1. 0
                    Engin
                    1. 0
                      EKKi
                      1. 0
                        Engin
                        1. 0
                          EKKi
                          1. 0
                            Engin
                  2. 0
                    ChrisB
                    1. 0

                      Danke! DB normailiserung schreitet voran

                      Engin
  3. 0

    PHP $_GET und sonderzeichen <>\

    Engin
    • php
    1. 0
      dedlfix
      1. 0
        Engin
        1. 0
          dedlfix
          1. 0
            Engin
            1. 0
              EKKi
              1. 0

                PHP $_GET auch gelöst

                Engin
    2. 0
      EKKi

Hi,

nach dem ich mehrmals auf eine normalisierung meiner DB hingewiesen wurde, lese ich mich seit Tagen
durchs Netz, bleib aber irgendwie an einer Sache hängen.

Ich hab in meiner DB 3 Tabellen

Tabellen               -  Spalten

  
"song_interpret        -  (interpret_id, name)" 'PRIMARY KEY(`interpret_id`)'  
  
"song_interpret_album  -  interpret_album"  
  
"song_titel_text       -  song_titel"  

Jetzt wird ja 'PRIMARY KEY  (interpret\_id)' wom Server vergeben, wie kann ich diesen
key in die anderen Tabellen übernehmen?
Ich könnte ja den Key auch Manuell beim Eintrag in die DB erstellen, das wäre aber wohl keine Saubere lösung.

Wie es Manuell geht habe ich schon in mehrfacher Form gefunden, bei mir soll es automatisiert sein, da ich ja nicht
weiss, wieviel Einträge in die DB kommen.

Oder ist der Ansatz hier schon falsch?

MySQL5.0 - 1&1

Grüße aus H im R,
Engin

  1. yo,

    Jetzt wird ja 'PRIMARY KEY  (interpret\_id)' wom Server vergeben, wie kann ich diesen
    key in die anderen Tabellen übernehmen?

    mein tipp ist, jede tabelle hat ihren eigenen künstlichen schlüssel, es liegt also keine fachlickeit im schlüssel, sondern dient nur "technischen" zwecken. und dbms bieten immer eine funktionalität, dir die zuletzt benutzte id zu geben, die das system verwendet hat. ich muss bei mysql raten (zu faul selbst nachzuschauen), sollte eine funktion wie last_insert_id sein.

    diese funktion ist auch session abhängig, dass heisst wenn mehrere benutzer gleichzeitig neue datensätze einfügen, bekommst du nur den von dir benutzte letzte id zurück und nicht die eines anderen users.

    kurz noch ein wort zu deinem design, wenn ich das auf den ersten blick richtig verstanden habe, dann solltes du folgende entitäten haben:

    • Interpreter
    • Song
    • Album

    für diese drei entitäten musst du noch die richtgen attribute hinzufügen, zum beispiel titel und text in der song-tabelle, vorname und nachname in der interpreter tabelle, albumname in der album tabelle, etc. achter aber darauf, dass du jeweils einen kunstlichen pk benutzt.

    dann bringst du die drei entitäten in beziehung miteinander. zum beispiel könnte man es so modellieren, dass jeder song nur einen interpreter hat, aber ein interpreter kann mehrere songs haben. das wäre dann 1:n und du kannst den interpreter-fremdschlüssel direkt in die tabelle song ziehen.

    oder aber ein song kann auch mehrere interpreter haben, zum beispiel weil zwei oder drei interpreter gemeinsam einen song aufnehmen, dann hast du eine n:m beziehung zwischen den beiden entitäten, die du mit einer beziehungstabelle auflösen musst, wo jeweils der fremdschlüssel von der entität interpreter drinne ist und von song-entität. diese überlegung der art der beziehung machst du für alle entitäten.

    Ilja

    1. Hi Ilja,

      und dbms bieten immer eine funktionalität, dir die zuletzt benutzte id zu geben, die das system verwendet hat. ich muss bei mysql raten (zu faul selbst nachzuschauen), sollte eine funktion wie last_insert_id sein.

      Tatsächlich, jetzt habe ich zig Stunden damit verbracht, um "eine ID in 3 Tabellen speichern", mist...

      mysql_insert_id() klingt logisch, das auch nirgends auf so eine Funktion
      hingewiesen wird ist echt ärgerlich.

      Habe ich Heute Abend wieder viel zutun.  :)

      • Interpreter
      • Song
      • Album

      für diese drei entitäten musst du noch die richtgen attribute hinzufügen, zum beispiel titel und text in der song-tabelle, vorname und nachname in der interpreter tabelle, albumname in der album tabelle, etc. achter aber darauf, dass du jeweils einen kunstlichen pk benutzt.

      Das ist nur ein kleines bsp. für mich, ich hab erst vor kurzem angefangen, mich damit
      zu beschäftigen, ich versuche erstmal die Logik von dem ganzen zu verstehen.

      Ich wollte das Posting auch nicht unnötig aufblähen und hatte daher schon 1-2 sachen, die du erwähnt hast vor dem Post gelöscht.

      Dank dir für die Info.

      Da hätte ich noch ne folge frage zu INSERT, was ist an dem unteren Code falsch? Der trägt mir nichts in
      die Datenbank ein, bzw. nur das erste INSERT wird ausgeführt.

        
       $eintrag = sprintf(  
        
      "INSERT INTO song_interpret (name) VALUES ('%s')",  
              mysql_real_escape_string($name),  
        
      "INSERT INTO song_interpret_album (interpret_album) VALUES ('%s')",  
              mysql_real_escape_string($interpret_album),  
        
      "INSERT INTO song_titel_text (song_titel, song_text) VALUES ('%s', '%s')",  
              mysql_real_escape_string($song_titel),  
              mysql_real_escape_string($song_text)  
        
       );  
              $eintragen = mysql_query($eintrag);  
      
      

      Grüße aus H im R,
      Engin

      1. Da hätte ich noch ne folge frage zu INSERT, was ist an dem unteren Code falsch? Der trägt mir nichts in
        die Datenbank ein, bzw. nur das erste INSERT wird ausgeführt.

        Das liegt nicht am Insert, sondern an deine Verwendung von sprintf.
        Laß dir mal anzeigen was in $eintrag steht.

        $eintragen = mysql_query($eintrag);

        und hier würde ich einen evtl. Fehler abfangen, das müßte mit PHP auch gehen.

        Struppi.

        1. Hi Struppi,

          Das liegt nicht am Insert, sondern an deine Verwendung von sprintf.
          Laß dir mal anzeigen was in $eintrag steht.

          $eintragen = mysql_query($eintrag);

          und hier würde ich einen evtl. Fehler abfangen, das müßte mit PHP auch gehen.

          Danke für die Hilfe aber ich komm nicht weiter, jetzt krieg ich nur noch fehlermeldungen ausgespuckt.

          Grüße aus H im R,
          Engin

          1. Hi,

            Das liegt nicht am Insert, sondern an deine Verwendung von sprintf.

            Danke für die Hilfe aber ich komm nicht weiter, jetzt krieg ich nur noch fehlermeldungen ausgespuckt.

            Dann lies noch mal im Handbuch nach, wie man sprinft verwendet.

            Und btw: Mehrere Queries auf einmal kannst du mit mysql_query nicht absetzen, sondern immer nur eine nach der anderen.

            MfG ChrisB

            1. Hi ChrisB,

              Dann lies noch mal im Handbuch nach, wie man sprinft verwendet.

              Den habe ich nicht so ganz verstanden, dafür geht es jetzt mit den Einträgen wieder.

              Und btw: Mehrere Queries auf einmal kannst du mit mysql_query nicht absetzen, sondern immer nur eine nach der anderen.

              Ja, habe jetzt jede query einzeln notiert, funktioniert auch wieder.

              Danke für die Info.

              Grüße aus H im R,
              Engin

              1. Hi,

                Dann lies noch mal im Handbuch nach, wie man sprinft verwendet.

                Den habe ich nicht so ganz verstanden

                Woran hapert's denn?

                Als ersten Parameter erwartet sprintf einen String, in dem Platzhalter enthalten sind.
                Und danach als weitere Parameter dann Ausdruecke, durch deren Wert diese Platzhalter ersetzt werden sollen. Diese Ausdruecke koennten bspw. Zahlen oder Textliterale sein (idR. weniger sinnvoll), oder Variablen, deren Wert dann eingesetzt werden soll - oder auch die Rueckgaben von Funktionsaufrufen (hier, wo es um die dynamische Erstellung einer MySQL-Query geht, bspw. die Rueckgabe von mysql_real_escape_string an den Stellen, wo Werte passend zu behandeln sind).

                MfG ChrisB

                1. Hi ChrisB,

                  (hier, wo es um die dynamische Erstellung einer MySQL-Query geht, bspw. die Rueckgabe von mysql_real_escape_string an den Stellen, wo Werte passend zu behandeln sind).

                  Danke für die erklärung, das habe ich soweit verstanden, womit ich aber irgendwie
                  überhaupt nicht zurecht komm ist diese LAST_INSERT_ID() bzw. mysql_insert_id.
                  Da steht,

                  "Falls Sie den Wert zur späteren Verwendung speichern möchten, stellen Sie sicher, dass Sie mysql_insert_id() direkt nach der Abfrage aufrufen, die einen Wert erzeugt hat."

                  wie darf ich das verstehen? <"meineLogik">Ich führe den ersten INSERT aus, lese das Frisch gespeicherte INSERT wieder aus,
                  speichere die ID im nächsten query, bevor ich diese in die Tabelle schreibe.</"meineLogik">
                  Ist diese Logik richtig? Gibt es eine einfachere methode?

                  meine querys sehen derzeit so aus, mysql_real_escape_string() sind natürlich auch drin,

                    
                   $eintrag = sprintf(  
                   "INSERT INTO song_interpret (name) VALUES ('%s')");  
                   $eintragen = mysql_query($eintrag);  
                    
                   $eintrag1 = sprintf(  
                   "INSERT INTO song_interpret_album (interpret_album, spec_id) VALUES ('%s','LAST_INSERT_ID')");  
                   $eintragen1 = mysql_query($eintrag1);  
                    
                   $eintrag2 = sprintf(  
                   "INSERT INTO song_titel_text (song_titel, song_text, spec_id) VALUES ('%s', '%s','LAST_INSERT_ID')");  
                   $eintragen2 = mysql_query($eintrag2);  
                  
                  

                  Kann mir mal Bitte jemand _Idioten_ sicher erklären, wie ich die ID vom ersten query in die anderen 2 querys bekomme.

                  Grüße aus H im R,
                  Engin

                  1. Hi,

                    "Falls Sie den Wert zur späteren Verwendung speichern möchten, stellen Sie sicher, dass Sie mysql_insert_id() direkt nach der Abfrage aufrufen, die einen Wert erzeugt hat."

                    wie darf ich das verstehen?

                    Du musst die Insert-ID a) direkt nach der betreffenden Abfrage ausfuehren (wenn du danach erst weitere andere Abfragen ausfuehrst, funktioniert es nicht mehr zuverlaessig), und b) noch innerhalb der selben Verbindung (auf Seite 1 das INSERT zu machen, und auf Seite 2 dann die ID abzufragen, ist auch nicht moeglich).

                    <"meineLogik">Ich führe den ersten INSERT aus, lese das Frisch gespeicherte INSERT wieder aus,
                    speichere die ID im nächsten query, bevor ich diese in die Tabelle schreibe.</"meineLogik">
                    Ist diese Logik richtig?

                    Jepp.

                    Gibt es eine einfachere methode?

                    Eigentlich nicht.

                    Kann mir mal Bitte jemand _Idioten_ sicher erklären, wie ich die ID vom ersten query in die anderen 2 querys bekomme.

                    INSERT machen, dabei automatisch vergebene ID direkt von der DB wieder abfragen, Ergebniswert in folgende Queries dynamisch einsetzen.

                    MfG ChrisB

                    1. Hi ChrisB,

                      <"meineLogik">Ich führe den ersten INSERT aus, lese das Frisch gespeicherte INSERT wieder aus,
                      speichere die ID im nächsten query, bevor ich diese in die Tabelle schreibe.</"meineLogik">
                      Ist diese Logik richtig?
                      Jepp.
                      INSERT machen, dabei automatisch vergebene ID direkt von der DB wieder abfragen, Ergebniswert in folgende Queries dynamisch einsetzen.

                      Danke für die Info, so weiss ich wenigstens, das ich auf dem richtigen Pfad bin, bevor sich

                      Tatsächlich, jetzt habe ich zig Stunden damit verbracht, um "eine ID in 3 Tabellen speichern", mist...

                      sowas wiederholt.

                      Grüße aus H im R,
                      Engin

                    2. Mahlzeit,

                      Du musst die Insert-ID a) direkt nach der betreffenden Abfrage ausfuehren (wenn du danach erst weitere andere Abfragen ausfuehrst, funktioniert es nicht mehr zuverlaessig), und b) noch innerhalb der selben Verbindung (auf Seite 1 das INSERT zu machen, und auf Seite 2 dann die ID abzufragen, ist auch nicht moeglich).

                      Das ist zwar alles richtig - ich würde aber generell von der Verwendung von LAST_INSERT_ID() abraten. Wenn parallel mehrere Verbindungen zur Datenbank bestehen und von unterschiedlichen Benutzern gleichzeitig Datensätze angelegt werden, dann kann es schon mal vorkommen (zumindest hatten wir mal das Problem), dass sich die einzelnen INSERT-Statements und die jeweiligen LAST_INSERT_ID()-Abfragen ins Gehege kamen ... und dann bekam eine Datenbankverbindung nicht die ID, die sie selbst in die Tabelle eingefügt hatte, sondern die ID eines Datensatzes, der zwischenzeitlich (d.h. einige Millisekungen später) von einer anderen Datenbankverbindung angelegt wurde. Unschön, sowas.

                      MfG,
                      EKKi

                      --
                      sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
                      1. Moin!

                        Das ist zwar alles richtig - ich würde aber generell von der Verwendung von LAST_INSERT_ID() abraten. Wenn parallel mehrere Verbindungen zur Datenbank bestehen und von unterschiedlichen Benutzern gleichzeitig Datensätze angelegt werden, dann kann es schon mal vorkommen (zumindest hatten wir mal das Problem), dass sich die einzelnen INSERT-Statements und die jeweiligen LAST_INSERT_ID()-Abfragen ins Gehege kamen ... und dann bekam eine Datenbankverbindung nicht die ID, die sie selbst in die Tabelle eingefügt hatte, sondern die ID eines Datensatzes, der zwischenzeitlich (d.h. einige Millisekungen später) von einer anderen Datenbankverbindung angelegt wurde. Unschön, sowas.

                        Wenn das so wäre. wäre es ein heftiger Bug in der DB. MySQL garantiert, dass ein Query auf der gleichen DB-Verbindung immer nur die letzte eingefügte ID dieser Verbindung zurückliefert, unabhängig von beliebigen parallelen Connections. Und mir sind noch keine gegenteiligen Berichte zu Ohren gekommen, dass das nicht funktioniert.

                        Ich vermute eher einen Bug in der DB-Applikation, die dir das beschert hat.

                        - Sven Rautenberg

                        --
                        "Love your nation - respect the others."
                        1. Mahlzeit,

                          Wenn das so wäre. wäre es ein heftiger Bug in der DB. MySQL garantiert, dass ein Query auf der gleichen DB-Verbindung immer nur die letzte eingefügte ID dieser Verbindung zurückliefert, unabhängig von beliebigen parallelen Connections. Und mir sind noch keine gegenteiligen Berichte zu Ohren gekommen, dass das nicht funktioniert.

                          Seit wann garantieren sie das? :-)

                          Ist schon etliche Jahre her - irgendwann 1999/2000 war das, mit der damals aktuellen MySQL-Version (ich glaub 3.23.x) und PHP 3.x ... hat uns ziemlich viele Nerven gekostet.

                          MfG,
                          EKKi

                          --
                          sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
                          1. Moin!

                            Wenn das so wäre. wäre es ein heftiger Bug in der DB. MySQL garantiert, dass ein Query auf der gleichen DB-Verbindung immer nur die letzte eingefügte ID dieser Verbindung zurückliefert, unabhängig von beliebigen parallelen Connections. Und mir sind noch keine gegenteiligen Berichte zu Ohren gekommen, dass das nicht funktioniert.

                            Seit wann garantieren sie das? :-)

                            Ist schon etliche Jahre her - irgendwann 1999/2000 war das, mit der damals aktuellen MySQL-Version (ich glaub 3.23.x) und PHP 3.x ... hat uns ziemlich viele Nerven gekostet.

                            Ok, du weißt, wie lange das her ist? Acht Jahre. Damals gab's noch den Netscape 4, der hat auf dem Gebiet CSS auch sehr viele Nerven gekostet. Und wie relevant ist der heute noch? Genauso relevant, wie deine Erfahrung mit MySQL Version 2.23.anno und PHP 3. Wer weiß, was da wirklich die Ursache war.

                            - Sven Rautenberg

                            --
                            "Love your nation - respect the others."
                            1. Mahlzeit,

                              Wer weiß, was da wirklich die Ursache war.

                              Tja, wer weiß das schon - aber kennst das ja: gebranntes Kind und Feuer und so ...

                              MfG,
                              EKKi

                              --
                              sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
                  2. $eintrag1 = sprintf(
                    "INSERT INTO song_interpret_album (interpret_album, spec_id) VALUES ('%s','LAST_INSERT_ID')");

                    LAST_INSERT_ID() ist eine Funktion, der Aufruf müßte so aussehen:

                      
                    "INSERT INTO song_interpret_album (interpret_album, spec_id) VALUES ('%s',LAST_INSERT_ID())");
                    

                    Struppi.

                    1. Hi Struppi,

                      Danke für den hinweis.

                      LAST_INSERT_ID() ist eine Funktion, der Aufruf müßte so aussehen:

                      "INSERT INTO song_interpret_album (interpret_album, spec_id) VALUES ('%s',LAST_INSERT_ID())");

                        
                      :-)  
                        
                      Kommst genau richtig, hatte das Problem grade mit `mysql_insert_id`{:.language-sql} gelöst gehabt. :)  
                        
                      Wobei `LAST_INSERT_ID`{:.language-sql} würde ich bevorzugen, nur da gibt es ein problem, die erste  
                      `LAST_INSERT_ID`{:.language-sql} ist richtig, nur beim dritten query gibt `LAST_INSERT_ID`{:.language-sql} mir die ID vom 2ten query.  
                        
                      Jetzt weiss ich nicht, wie ich da vorgehen soll.  
                        
                      Meine DB ist ja....keine Ahnung ob die richtig gegliedert ist,  
                      ~~~sql
                        
                      1 Tabelle           Spalten  
                      `song_interpret` (  
                        `interpret_id` int(11) NOT NULL auto_increment,  
                        `name` varchar(255) NOT NULL,  
                        PRIMARY KEY  (`interpret_id`)  
                        
                        
                      2 Tabelle           Spalten  
                      `song_interpret_album` (  
                        `id` smallint(5) unsigned NOT NULL auto_increment,  
                        `interpret_album` varchar(255) NOT NULL,  
                        `spec_id` smallint(5) unsigned NOT NULL,  
                        PRIMARY KEY  (`id`)  
                        
                        
                      3 Tabelle  
                      `song_titel_text` (  
                        `id` smallint(5) unsigned NOT NULL auto_increment,  
                        `song_titel` varchar(255) NOT NULL,  
                        `song_text` longtext NOT NULL,  
                        `spec_id` smallint(5) unsigned NOT NULL,  
                        PRIMARY KEY  (`id`),  
                        FULLTEXT KEY `song_text` (`song_text`)
                      

                      Mein erzieltes/funktionierendes Ergebnis mit mysql_insert_id sieht wie folgt aus,

                        
                       $eintrag = sprintf(  
                       "INSERT INTO song_interpret (name) VALUES ('%s')"  
                       );  
                       $eintragen = mysql_query($eintrag);  
                                    $last_id = mysql_insert_id();  
                        
                       $eintrag1 = sprintf(  
                       "INSERT INTO song_interpret_album (interpret_album, spec_id) VALUES ('%s', $last_id)"  
                       );  
                       $eintragen1 = mysql_query($eintrag1);
                      

                      Werd erst mal den Tag drüber schlafen und schau mir das Heute Abend nochmal an.

                      Gute Nacht?Tag und Grüße aus H im R,
                      Engin

                      P.s: Dieser [code lang= für sql sieht ja schrecklich aus *g

                      1. Hi,

                        Wobei LAST_INSERT_ID würde ich bevorzugen, nur da gibt es ein problem, die erste
                        LAST_INSERT_ID ist richtig, nur beim dritten query gibt LAST_INSERT_ID mir die ID vom 2ten query.

                        Nun ja, diese ist ja dann auch wirklich die zuletzt erzeugte Insert-ID.

                        Jetzt weiss ich nicht, wie ich da vorgehen soll.

                        Entweder belaesst du es bei deiner bisherigen Loesung - dass du dir die ID aus der ersten INSERT-Query erst mal nach PHP "importierst", und dann den Wert direkt in die weiteren Queries einfuehrst - oder du schaust dir an, wie man auch in (My)SQL Variablen Werte zuweisen kann, die man dann in spaeteren Abfragen (wiederum natuerlich nur innerhalb der selben Verbindung) weiternutzen kann.

                        http://dev.mysql.com/doc/refman/4.1/en/user-variables.html

                        MfG ChrisB

                        1. Hi ChrisB, Hi Struppi,

                          welche Unterschiede gibt es zwischen LAST_INSERT_ID() und mysql_insert_id() ?

                          ~~~php $eintrag = sprintf(
                           "INSERT INTO song_interpret (name) VALUES ('%s')"
                           );
                           $eintragen = mysql_query($eintrag);

                          $last_id = mysql_insert_id();

                          "INSERT INTO song_interpret_album (interpret_album, spec_id) VALUES ('%s', $last_id)"

                            
                          Dieser Code funktioniert einwandfrei, bzw. soweit ich das selbst einschätzen kann.  
                            
                          Wenn ich jetzt an stelle von  
                            
                           `$last_id = mysql_insert_id();`{:.language-php}  
                            
                           `$last_id = LAST_INSERT_ID();`{:.language-php}  
                            
                          verwende, bekomme ich  
                            
                          "Call to undefined function: last\_insert\_id()"  
                            
                          Ist das beides nicht das selbe?  
                            
                          
                          > oder du schaust dir an, wie man auch in (My)SQL Variablen Werte zuweisen kann, die man dann in spaeteren Abfragen (wiederum natuerlich nur innerhalb der selben Verbindung) weiternutzen kann.  
                          > <http://dev.mysql.com/doc/refman/4.1/en/user-variables.html>  
                            
                          Das werde ich beherzigen und mich in diese Richtung reinlesen, nur würde mich obige frage interessieren.  
                            
                          Grüße aus H im R,  
                          Engin  
                          
                          -- 
                          ["ich bin ein Insekt, ich bin ein Insekt"](http://nimmet.de/nimmet-dateien/banjo.shtml)  
                            
                          ![](http://nimmet.de/nimmet-bilder/valigator.gif)[Der Valligator](http://old.atomic-eggs.com/old_forum/messages/237.html#a1)  
                            
                          ["I would like to buy a hamburger"](http://www.youtube.com/watch?v=x8S7x_z1w1s)
                          
                          1. Hi,

                            welche Unterschiede gibt es zwischen LAST_INSERT_ID() und mysql_insert_id() ?

                            Ersteres ist eine MySQL-Funktion, letzteres eine PHP-Funktion.

                            MfG ChrisB

                            1. Hi ChrisB,

                              welche Unterschiede gibt es zwischen LAST_INSERT_ID() und mysql_insert_id() ?

                              Ersteres ist eine MySQL-Funktion, letzteres eine PHP-Funktion.

                              Danke an alle für die hilfe, soweit habe ich dann erstmal alle benötigten
                              informationen, mal sehen, in wie weit ich jetzt alles ordentlich zusammen gefriemelt bekomm.

                              Grüße aus H im R,
                              Engin

                      2. Kommst genau richtig, hatte das Problem grade mit mysql_insert_id gelöst gehabt. :)

                        Wobei LAST_INSERT_ID würde ich bevorzugen, nur da gibt es ein problem, die erste
                        LAST_INSERT_ID ist richtig, nur beim dritten query gibt LAST_INSERT_ID mir die ID vom 2ten query.

                        Logisch, jeder insert erzeugt eine neue LAST_INSERT_ID() da jede Tabelle eine eigene ID hat, du benötigst aber nur die vom ersten.

                        Struppi.

  2. Hi,

    jetzt hab ich meine DB zwar normailisert, nur frag ich mich, ob´s richtig ist.

    Ich hab 3 Tabellen,

      
    1\. - interpret_id, name             (primary key - interpret_id)  
      
    2\. - id, interpret_album, spec_id   (spec_id bekommt interpret_id von 1. zugewiesen)  
      
    3\. - id, song_titel, song_text, spec_id   (auch hier ist spec_id die interpret_id von Tabelle 1.)
    

    Jetzt wird es so sein, das Tabelle 1, also interpret - name mehrmals vorkommen wird, auch
    wird bsp. weise Tabelle 2, interpret_album unter gleichem Albumnamen viele einträge haben.

    Soll ich interpreten - name und interpret_album bei jedem neuen Eintrag Doppelt speichern und mit neuen IDs versehen?

    Auf dieses problem bin ich grade bei der DB abfrage gestossen, wenn ich nach
    einem interpreten abfrage,
    wird mir 3 mal der gleiche Name angezeigt, er soll aber nur einmal gezeigt werden.
    Für interpret_album gilt das gleiche problem.

    Wie sollte ich das Handhaben?

    Grüße aus H im R,
    Engin

    1. Hi,

      Jetzt wird es so sein, das Tabelle 1, also interpret - name mehrmals vorkommen wird, auch
      wird bsp. weise Tabelle 2, interpret_album unter gleichem Albumnamen viele einträge haben.

      Nein, so sollte es nicht sein. Dann waere die Normalisierung ja weitgehend fuer die Katz, weil sie kein bisschen zur Reduzierung von Redundanz beitraegt.

      Soll ich interpreten - name und interpret_album bei jedem neuen Eintrag Doppelt speichern und mit neuen IDs versehen?

      Nein.
      Aber bevor du ein neues Album fuer Interpret XY speicherst, fragst du erst mal deine Datenbank, ob es schon einen Eintrag fuer XY in der Interpreten-Tabelle gibt.
      Wenn ja - dann nimmst du dessen ID, und benutzt sie weiter.
      Wenn nein - *dann* legst du einen Datensatz fuer Interpret XY an, holst dir anschliessend dessen automatisch generierte ID - und benutzt diese dann weiter.

      Und beim Speichern eines neuen Songtitels natuerlich vorher genau das gleiche Spielchen fuer den Albumnamen.

      MfG ChrisB

      1. Hi ChrisB,

        Aber bevor du ein neues Album fuer Interpret XY speicherst, fragst du erst mal deine Datenbank, ob es schon einen Eintrag fuer XY in der Interpreten-Tabelle gibt.

        Das hatte ich mir auch schon überlegt, über eine art Live suche wie bei Google Suggest.

        Wenn ja - dann nimmst du dessen ID, und benutzt sie weiter.
        Wenn nein - *dann* legst du einen Datensatz fuer Interpret XY an, holst dir anschliessend dessen automatisch generierte ID - und benutzt diese dann weiter.

        Danke für die Info, was mich noch interessiert, ich hab auch bei der ID vergabe wohl einiges falsch gemacht,

        1. - interpret_id, name             (primary key - interpret_id)  
          
        2\. - id, interpret_album, spec_id   (spec_id bekommt interpret_id von 1. zugewiesen)  
          
        3\. - id, song_titel, song_text, spec_id   (auch hier ist spec_id die interpret_id von Tabelle 1.)
        

        Kann ich bei den Tabellen 2 und 3 auf die 'id' verzichten und stattdessen alle Tabellen mit der interpret_id versehen?
        Wäre das Sinnvoll?

        Oder noch besser, kann ich in diesem Fall nicht direkt die Namen als eindeutige IDs benutzen?

        Ich stell mir das in etwa so vor

          
        1\. - interpret_id, name             (primary key - interpret_id)  
          
        2\. - interpret_id, interpret_album  
          
        3\. - interpret_id, song_titel, song_text
        

        Das wäre aber denke ich mal komplett falsch.

        Oder so

          
        1\. - interpret_id, name             (primary key - interpret_id)  
          
        2\. - interpret_id, interpret_album, album_id  
          
        3\. - interpret_id, song_titel, song_text, album_id
        

        Ich dachte, umso mehr ich mich damit beschäftige, umso leichter wird es...

        Grüße aus H im R,
        Engin

        1. Mahlzeit,

          Danke für die Info, was mich noch interessiert, ich hab auch bei der ID vergabe wohl einiges falsch gemacht,

            • interpret_id, name             (primary key - interpret_id)
            • id, interpret_album, spec_id   (spec_id bekommt interpret_id von 1. zugewiesen)
            • id, song_titel, song_text, spec_id   (auch hier ist spec_id die interpret_id von Tabelle 1.)
          
          >   
          >   
          > Kann ich bei den Tabellen 2 und 3 auf die 'id' verzichten und stattdessen alle Tabellen mit der interpret\_id versehen?  
          > Wäre das Sinnvoll?  
            
          NEIN! JEDE Tabelle hat eine ID (als Primary Key) zu haben - damit JEDER Datensatz in JEDER Tabelle eindeutig identifizierbar ist. DAFÜR und NUR DAFÜR ist eine ID da. Für NICHTS anderes. Auch nicht, um in irgendwelchen anderen Tabellen als Name oder sonstwas missbraucht zu werden. Es geht NUR darum, Datensätze eindeutig identifizieren und mit anderen Datensätzen verknüpfen zu können.  
            
          Und bitte benenne die Spalten sinnvoll. "spec\_id" ist ziemlicher Schwachsinn, wenn Du keine Tabelle "spec" hast - was soll diese ID bedeuten, auf was soll sie verweisen?  
            
            
          
          > Oder noch besser, kann ich in diesem Fall nicht direkt die Namen als eindeutige IDs benutzen?  
            
          NEIN. Name != ID. Eine ID ist sinnvollerweise ein rein numerisches Feld mit einem UNIQUE Constraint und entsprechenden Indizes, so dass man bei einer Abfrage nach einem Datensatz mittels dieser ID auch schnell an ein Ergebnis kommt. Ein Name ist normalerweise ein Textfeld (VARCHAR o.ä.), dessen Indizierung weitaus ressourcenfressender ist, so dass eine Suche nach einem bestimmten Datensatz mittels eines Namens länger dauert und die Datenbank mehr belastet. Des weiteren sind Namen im Prinzip "Schall und Rauch" - theoretisch könnten sie mehrfach vorkommen (außer es gibt Gründe, die dagegensprechen), sie könnten geändert werden usw. ALLEIN eine ID identifiziert einen Datensatz eindeutig.  
            
            
          
          > Ich stell mir das in etwa so vor  
            
          Bitte, tu Dir selbst einen Gefallen: stell Dir nicht so viel vor. Halte Dich einfach an klassisch-bewährte Schemata zur Normalisierung von Tabellen und experimentiere nicht so viel herum. Es hat schon alles einen Sinn und Hand und Fuß, was wir Dir vorschlagen.  
            
          Nochmal mein Vorschlag:  
            
          Tabelle "interpret":  
          ID | Name  
          \---+-----  
            
          Tabelle "album":  
          ID | interpret\_ID | Name  
          \---+--------------+-----  
            
          Tabelle "titel":  
          ID | Name | Songtext  
          \---+------+---------  
            
          Tabelle "album\_titel":  
          ID | album\_ID | titel\_ID  
          \---+----------+---------  
            
          So kannst Du jedem Album einen eindeutigen Interpreten zuweisen und Du kannst für jeden Titel zu jedem Album, auf dem er vorkommt, eine Verknüpung anlegen.  
            
          Wenn Du ein neues Album anlegst, prüfst Du natürlich ERST, ob der entsprechende Interpret schon vorhanden ist. Wenn ja, nutzt Du dessen ID als "interpret\_ID", ansonsten musst Du auch einen neuen Datensatz in der Tabelle "interpret" anlegen und dessen ID nutzen.  
            
          Wenn Du einen neuen Titel anlegst, prüfst Du natürlich ERST, ob das Album, auf dem dieser Titel vorhanden ist, schon vorhanden ist. Wenn jan,utzt Du dessen ID als "album\_ID" beim Anlegen des Datensatzes in "album\_titel", ansonsten musst Du auch einen neuen Datensatz in der Tabelle "album" (und ggf. in der Tabelle "interpret", s.o.) anlegen und dessen ID für den Eintrag in "album\_titel" nutzen.  
            
            
          MfG,  
          EKKi  
          
          -- 
          sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
          
          1. Hi EKKi,

            NEIN! JEDE Tabelle hat eine ID (als Primary Key) zu haben - damit JEDER Datensatz in JEDER Tabelle eindeutig identifizierbar ist. DAFÜR und NUR DAFÜR ist eine ID da.

            Da sprach grad die verzweiflung aus mir, hatte Gestern nacht probleme beim Joinen, wollte das irgendwie umgehen.
            War wohl der falsche ansatz.

            Und bitte benenne die Spalten sinnvoll. "spec_id" ist ziemlicher Schwachsinn, wenn Du keine Tabelle "spec" hast - was soll diese ID bedeuten, auf was soll sie verweisen?

            Ich wusste nicht, ob ich den Namen interpret_id aus der 1 Tabelle auch an die anderen Tabellen geben kann,
            so kam spec_id (special_id) ins Spiel, die spec_id bekommt den Wert von interpret_id.

            Ein Name ist normalerweise ein Textfeld (VARCHAR o.ä.), dessen Indizierung weitaus ressourcenfressender ist, so dass eine Suche nach einem bestimmten Datensatz mittels eines Namens länger dauert und die Datenbank mehr belastet....ALLEIN eine ID identifiziert einen Datensatz eindeutig.

            Ok, dieser Gedanke ist jetzt auch aus meinem Kopf gestrichen.

            Ich stell mir das in etwa so vor

            Bitte, tu Dir selbst einen Gefallen: stell Dir nicht so viel vor. Halte Dich einfach an klassisch-bewährte Schemata zur Normalisierung von Tabellen und experimentiere nicht so viel herum. Es hat schon alles einen Sinn und Hand und Fuß, was wir Dir vorschlagen.

            Ok, mit Fantasieren ist jetzt auch schluss. :) Hast schon Recht.
            Eure vorschläge sind ja auch unbezahlbar, ich hatte die ganze zeit das Problem,
            das ich unbedingt dieses Formular zur user Eingabe verwenden wollte,
            das lässt sich aber auf die von mir benötigten anforderungen nicht anpassen.

            Jetzt werde ich mir selbst so ein Formular basteln.

            Nochmal mein Vorschlag:

            Tabelle "interpret":
            ID | Name
            ---+-----

            Tabelle "album":
            ID | interpret_ID | Name
            ---+--------------+-----

            Tabelle "titel":
            ID | Name | Songtext
            ---+------+---------

            Tabelle "album_titel":
            ID | album_ID | titel_ID
            ---+----------+---------

            Danke für deinen Vorschlag, das sieht schon besser aus, als mein derzeitiges
            Konzept.

            Werde das ganze jetzt nochmal von vorne beginnen.

            Grüße aus H im R,
            Engin

            1. Mahlzeit,

              Ich wusste nicht, ob ich den Namen interpret_id aus der 1 Tabelle auch an die anderen Tabellen geben kann,

              Ich würde den Primary Key einer jeweiligen Tabelle immer nur "ID" nennen - es gibt schließlich in jeder Tabelle nur eine eindeutige ID. Beim Auslesen muss man dann halt sowas wie "interpret.ID" verwenden, aber das ist ja auch sinnvoll (sonst weiß man irgendwann nicht mehr, welche ID man nun eigentlich genau ausliest). Als Foreign Key würde ich dann immer den Namen der Tabelle, auf die verwiesen wird + "_ID" (also z.B. "interpret_ID") verwenden - so ist klar, mit welcher ID ich verknüpfe.

              Das ist aber mein persönlicher Ansatz - andere haben andere und meiner muss nicht zwangsläufig der beste oder sinnvollste sein. Du solltest Dir nur eben einen logischen aneignen oder selbst ausdenken, damit Du mit den ganzen IDs nicht durcheinanderkommst.

              Und zurück zu Deiner "Frage": natürlich kannst Du verschiedene Spalten in verschiedenen Tabellen gleich benennen. MUSST Du sogar, wenn Du einen ähnlichen Benennungsansatz wie meinen oben skizzierten verwendest. Ist aber auch sinnvoll, weil man sofort weiß, was sich auf was bezieht.

              so kam spec_id (special_id) ins Spiel, die spec_id bekommt den Wert von interpret_id.

              Ein Feld sollte immer so heißen, dass sein Inhalt klar ist. Wäre in diesem Fall nicht. "spec_id" könnte mal diesen, mal jenen Wert haben. Spätestens ein halbes Jahr nach der letzten programmierten Code-Zeile weißt Du nicht mehr, was wo drin steht - und dann ärgerst Du Dich bei Wartungs- oder Erweiterungsarbeiten schwarz.

              Eure vorschläge sind ja auch unbezahlbar, ich hatte die ganze zeit das Problem,
              das ich unbedingt dieses Formular zur user Eingabe verwenden wollte,
              das lässt sich aber auf die von mir benötigten anforderungen nicht anpassen.

              Wie das Eingabeformular aussieht, hat absolut NICHTS mit der Datenstruktur zu tun. Diese solltest Du vollkommen losgelöst von dem, was der Benutzer sieht, allein auf Basis der logischen Verknüpfung der einzelnen Objekte untereinander (Interpret-Album-Titel) entwickeln.

              Wie man dem Benutzer dann bequeme Eingabemöglichkeiten bietet, ist allerhöchstens zweitrangig.

              Jetzt werde ich mir selbst so ein Formular basteln.

              Tu das. Gerade bei Foreign-Key-Geschichten bieten sich z.B. Selectboxen (mit der ID als Wert und dem jeweiligen Namen als Anzeigetext) an - so kann der Benutzer nichts falsches eingeben und alles immer richtig zuordnen (wobei Du Dich natürlich auch dabei auf Eingaben nicht verlassen darfst - "ALL INPUT IS EVIL").

              Tabelle "interpret":
              ID | Name
              ---+-----

              Tabelle "album":
              ID | interpret_ID | Name
              ---+--------------+-----

              Tabelle "titel":
              ID | Name | Songtext
              ---+------+---------

              Tabelle "album_titel":
              ID | album_ID | titel_ID
              ---+----------+---------

              Danke für deinen Vorschlag, das sieht schon besser aus, als mein derzeitiges
              Konzept.

              Das funktioniert im Übrigen nur, wenn jedes Album genau einen Interpreten haben kann. Wenn Du auch Alben von mehreren Interpreten abbilden willst, musst Du es natürlich folgendermaßen machen:

              Tabelle "album":
              ID | Name
              ---+-----

              Tabelle "interpret_album":
              ID | interpret_ID | album_ID
              ---+--------------+---------

              Werde das ganze jetzt nochmal von vorne beginnen.

              Viel Erfolg!

              MfG,
              EKKi

              --
              sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
              1. Hi EKKi,

                Als Foreign Key würde ich dann immer den Namen der Tabelle, auf die verwiesen wird + "_ID" (also z.B. "interpret_ID") verwenden - so ist klar, mit welcher ID ich verknüpfe.

                Bei mir schlichen sich die ganze Zeit denkfehler ein, so langsam begreife ich das ganze.
                interpret_id, spec_id waren einfache denkfehler, wo ich mir nicht anders zu helfen wusste.
                die erleuchtung kam übrigens jetzt. :)

                Wie das Eingabeformular aussieht, hat absolut NICHTS mit der Datenstruktur zu tun.
                Wie man dem Benutzer dann bequeme Eingabemöglichkeiten bietet, ist allerhöchstens zweitrangig.

                Das stimmt, nur habe ich Angst, mir zu grosse sicherheitslücken mit ein zu programmieren,
                daher wollte ich unbedingt das verlinkte Script benutzen.
                Aber besser ist es eh, das mal selber zu machen, habe mich mit dem fertigen Script 2 Wochen lang
                genug geärgert.

                Tu das. Gerade bei Foreign-Key-Geschichten bieten sich z.B. Selectboxen (mit der ID als Wert und dem jeweiligen Namen als Anzeigetext) an

                Dann müsste ich vor dem eigentlichen Eintrag einen aufruf aus der DB machen und die Eingaben
                vergleichen, also schon in der Vorschau die DB Einträge mit den User eingaben vergleichen,
                wenn´s MATCH´ed, dann in die Select Box eintragen, sehe ich richtig, oder?

                Tabelle "interpret":
                ID | Name
                ---+-----

                Tabelle "album":
                ID | interpret_ID | Name
                ---+--------------+-----

                Tabelle "titel":
                ID | Name | Songtext
                ---+------+---------

                Tabelle "album_titel":
                ID | album_ID | titel_ID
                ---+----------+---------

                Das funktioniert im Übrigen nur, wenn jedes Album genau einen Interpreten haben kann. Wenn Du auch Alben von mehreren Interpreten abbilden willst, musst Du es natürlich folgendermaßen machen:

                Tabelle "album":
                ID | Name
                ---+-----

                Tabelle "interpret_album":
                ID | interpret_ID | album_ID
                ---+--------------+---------

                Das werde ich mir noch überlegen müssen, ob ich es wirklich so genau haben will, zumal
                sowas ja nicht oft vorkommt, das auf einem Album mehrere Interpreten sind, bzw. wenn, dann als
                geschlossene Gruppe, die ja dann auch einen Namen hat. Z.b. Wu-Tang-Clan oder No Angels.

                Viel Erfolg!

                Danke.

                Grüße aus H im R,
                Engin

                1. Mahlzeit,

                  Tu das. Gerade bei Foreign-Key-Geschichten bieten sich z.B. Selectboxen (mit der ID als Wert und dem jeweiligen Namen als Anzeigetext) an

                  Dann müsste ich vor dem eigentlichen Eintrag einen aufruf aus der DB machen und die Eingaben
                  vergleichen, also schon in der Vorschau die DB Einträge mit den User eingaben vergleichen,
                  wenn´s MATCH´ed, dann in die Select Box eintragen, sehe ich richtig, oder?

                  Öööhm - hä?

                  Vor dem Aufbau des Formulars liest Du einfach alle gültigen Werte aus der Datenbank aus, z.B. für das Hinzufügen von Alben:

                  SELECT ID, Name FROM interpret

                  Alle Datensätze fügst Du als <option>-Tags in eine <select>-Box und schreibst ein <input type="text"> darunter, wo der Benutzer den Namen des Albums eingeben muss.

                  Bei der Verarbeitung des Formulars prüfst Du, ob die von der <select>-Box übergebene "interpret_ID" gültig ist - wenn ja, fügst Du einen neuen Datensatz in die Tabelle "album" ein ... "interpret_ID" und "Name" hast Du dann ja.

                  Für die anderen Tabellen entsprechend.

                  Das werde ich mir noch überlegen müssen, ob ich es wirklich so genau haben will, zumal
                  sowas ja nicht oft vorkommt, das auf einem Album mehrere Interpreten sind, bzw. wenn, dann als
                  geschlossene Gruppe, die ja dann auch einen Namen hat. Z.b. Wu-Tang-Clan oder No Angels.

                  Das ist richtig. Gruppen würde ich auch als EIN Interpret behandeln. Ggf. könntest Du natürlich noch zwischen verschiedenen Interpret-Typen unterscheiden:

                  Tabelle "interpret":
                  ID | interpret_typ_ID | Name
                  ---+------------------+--------------
                  ...
                   8 | 1                | Thomas Anders
                  11 | 2                | Modern Talking
                  15 | 2                | No Angels
                  47 | 1                | Dieter Bohlen
                  ...

                  Tabelle "interpret_typ":
                  ID | Name
                  ---+-----
                   1 | Einzel
                   2 | Gruppe

                  Dann könntest Du für die Interpreten, die eine "Gruppe" sind (also die "interpret_typ_ID" = 2 haben), die einzelnen Bandmitglieder in einer separaten Tabelle erfassen:

                  Tabelle "interpret_gruppe":
                  ID | gruppe_ID | interpret_ID
                  ---+-----------+-------------
                  ...
                  62 | 11        | 8
                  72 | 11        | 47
                  ...

                  In diesem speziellen Fall ist es angebracht, dass ein Feld nicht so heißt, wie der Primary Key, auf den es verweist. Wie Du siehst, besteht die Zuordnung zu einer Gruppe einerseits aus der "interpret_ID" der Gruppe (in diesem Fall heißt die Spalte "gruppe_ID") und andererseits aus den "interpret_ID" der einzelnen Interpreten. So kann einerseits jede Person als Einzelinpret auftreten, andererseits lassen sich aber auch Gruppen samt all ihrer Mitglieder darstellen.

                  Der andere Fall wäre aber, wenn ein Album tatsächlich von verschiedenen Interpreten, die NICHT einer Gruppe angehören, stammt. Sowas wie "Wildecker Herzbuben feat. Marylin Manson". Dann müsstest Du einerseits den Interpreten "Wildecker Herzbuben" (der natürlich als Gruppe wieder aus den beiden Einzelinterpreten besteht), andererseits den Interpreten "Marylin Manson" zuordnen. Insofern wäre auch hier eine n:m-Beziehung angebracht.

                  MfG,
                  EKKi

                  --
                  sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
                  1. Hi EKKi,

                    wenn´s MATCH´ed, dann in die Select Box eintragen, sehe ich richtig, oder?

                    Öööhm - hä?

                    Sorry, hab wieder Fantasiert. :)

                    Alle Datensätze fügst Du als <option>-Tags in eine <select>-Box und schreibst ein <input type="text"> darunter, wo der Benutzer den Namen des Albums eingeben muss.

                    Bei der Verarbeitung des Formulars prüfst Du, ob die von der <select>-Box übergebene "interpret_ID" gültig ist - wenn ja, fügst Du einen neuen Datensatz in die Tabelle "album" ein ... "interpret_ID" und "Name" hast Du dann ja.

                    Darüber mache ich mir auch schon seit ein Paar Tagen gedanken,

                    http://de.selfhtml.org/html/formulare/auswahl.htm#listen_absendewert

                    Das umzusetzen dürfte kein problem sein, problematisch wird es, wenn es mehrere Tausend Datensätze gibt.
                    Dann müsste ich schon vor dem Aufbau des eigentlichen Formulars abfragen, wessen "Text" in die DB eingetragen wird.

                    Wobei das auch nicht schlecht wäre, User gibt auf der ersten Seite ein, um welchen Interpret es sich Handelt,
                    kommt auf die zweite Seite wo er dann alle Alben dieses Interpret vorgesetzt bekommt (wenn vorhanden),
                    kommt dann auf die dritte Seite, wo dann, wenn vorhanden, alle Songtexte zu diesem Interpreten/Album angezeigt werden.
                    Wie steht es da um die Usability? Ist das noch Konform, wenn ein Eintrag über 3 Seiten hinweg geht.
                    Und sind DB abfragen Case sensitive, Gross/Klein schreibung.

                    Dann könnte ich ja auf der dritten Seite den query auf´s nötigste kürzen, und die vorhandenen ID´s in die
                    Values schreiben. Ich schreib meine Ideen hier mit auf, das erleichtert irgendwie den Denkprozess.

                    Das ist richtig. Gruppen würde ich auch als EIN Interpret behandeln. Ggf. könntest Du natürlich noch zwischen verschiedenen Interpret-Typen unterscheiden:

                    Danke für deinen Vorschlag, wäre auch ein Nettes feature, aber ich bin mit den derzeit eigentlich
                    wenigen schritten maßlos überfordert. :)
                    Lass mich erstmal das eine versuchen hinzu kriegen, so gesehen hätte ich noch dutzende Ideen,
                    die meine Seiten aufwerten würden, z.b. eintrag von Fanseiten, wenn vorhanden - Video von Youtube einbinden,
                    das ist aber zum jetzigen Zeitpunkt zuviel für mich.

                    Grüße aus H im R,
                    Engin

                    1. Mahlzeit,

                      Das umzusetzen dürfte kein problem sein, problematisch wird es, wenn es mehrere Tausend Datensätze gibt.

                      Öhm, nein!? Wieso sollte es? Was GENAU wird ein Problem - Deiner Meinung nach?

                      Dann müsste ich schon vor dem Aufbau des eigentlichen Formulars abfragen, wessen "Text" in die DB eingetragen wird.

                      Sprich verständlicher - es hilft ungemein, wenn Du nicht nur halbe aus dem Zusammenhang gerissene Gedanken äußerst, sondern GENAU sagst, was Du meinst. Welches Formular? Bei welchem Workflow? Welcher Text?

                      Wobei das auch nicht schlecht wäre, User gibt auf der ersten Seite ein, um welchen Interpret es sich Handelt,
                      kommt auf die zweite Seite wo er dann alle Alben dieses Interpret vorgesetzt bekommt (wenn vorhanden),
                      kommt dann auf die dritte Seite, wo dann, wenn vorhanden, alle Songtexte zu diesem Interpreten/Album angezeigt werden.
                      Wie steht es da um die Usability? Ist das noch Konform, wenn ein Eintrag über 3 Seiten hinweg geht.

                      Worum geht's? Um das Abfragen von Songtexten? Biete dem Benutzer ein Texteingabefeld an, in das er einen beliebigen Suchtext eingeben kann und zeige ihm anschließend alle Titel (geordnet nach Interpret und Album), in deren Songtext, Albumtitel oder Interpretname der Suchbegriff auftaucht - nichts leichter als das.

                      Was ich meinte, war die EINGABE von Daten. Dort ist es wichtig, dass IMMER die RICHTIGEN IDs zugeordnet werden.

                      Und sind DB abfragen Case sensitive, Gross/Klein schreibung.

                      Kommt auf das DBMS, die Datenbank, die Tabelle und das Feld an. Was benutzt Du? Informiere Dich.

                      Das ist richtig. Gruppen würde ich auch als EIN Interpret behandeln. Ggf. könntest Du natürlich noch zwischen verschiedenen Interpret-Typen unterscheiden:

                      Danke für deinen Vorschlag, wäre auch ein Nettes feature, aber ich bin mit den derzeit eigentlich
                      wenigen schritten maßlos überfordert. :)
                      Lass mich erstmal das eine versuchen hinzu kriegen, so gesehen hätte ich noch dutzende Ideen,
                      die meine Seiten aufwerten würden, z.b. eintrag von Fanseiten, wenn vorhanden - Video von Youtube einbinden,
                      das ist aber zum jetzigen Zeitpunkt zuviel für mich.

                      Jein. Über gewisse, grundlegende strukturelle Dinge solltest Du Dir Gedanken machen, BEVOR Du anfängst, Oberflächen zu gestalten. Mach Dir klar, WAS genau Du überhaupt speichern willst, WIE die einzelnen Objekte zueinander in Beziehung stehen usw. Bedenke dabei auch eventuelle spätere Erweiterungen ... wobei da zusätzliche Eigenschaften eines Objektes (wie z.B. in der Titeltabelle "Link zu Video") eine eher untergeordnete Rolle spielen: zusätzliche Spalten in einer Tabelle, die NUR Inhalt darstellen, kann man jederzeit einfügen - die Struktur später grundsätzlich zu ändern, erfordert Schrauben an mehreren Stellen, wenn man Pech hat.

                      MfG,
                      EKKi

                      --
                      sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
                      1. Hi EKKi,

                        Das umzusetzen dürfte kein problem sein, problematisch wird es, wenn es mehrere Tausend Datensätze gibt.

                        Öhm, nein!? Wieso sollte es? Was GENAU wird ein Problem - Deiner Meinung nach?

                        Ich bezog mich auf die <select> Felder, wenn man ein Songtext eintragen will.
                        Ich hab aber wieder zu kompliziert gedacht.

                        Sprich verständlicher - es hilft ungemein, wenn Du nicht nur halbe aus dem Zusammenhang gerissene Gedanken äußerst, sondern GENAU sagst, was Du meinst. Welches Formular? Bei welchem Workflow? Welcher Text?

                        Ich meinte das Formular, in dem man neue Songtexte einträgt.
                        Ich dachte mir das so:
                        Auf der ersten Seite, in der man Songtexte einträgt kommt ein <input text="interpret_name">

                        Wenn der user jetzt dieter eingibt, bekommt der User auf der folgenden Seite(2)
                        alle treffer die zu dieter gehören und ggf. alle Alben, wenn kein dieter in der DB, kann er einen dieter erstellen, wenn´s dieter gibt
                        wählt der user diesen aus und gelangt auf Seite(3)

                        Dann hätte ich auf Seite 3 schon alle relevante Daten des Interpreten, wenn diese in der DB vorhanden sind und könnte alle
                        in der DB vorhanden Texte dieses Interpreten auflisten.
                        Wenn der Text, den der User gerade eingeben will vorhanden ist, kann der User das sofort sehen.

                        Worum geht's? Um das Abfragen von Songtexten? Biete dem Benutzer ein Texteingabefeld an,
                        Was ich meinte, war die EINGABE von Daten. Dort ist es wichtig, dass IMMER die RICHTIGEN IDs zugeordnet werden.

                        Genau das meinte ich auch, also die EINGABE von Daten/Songtexten, hab mich unklar ausgedrückt. Mein fehler.

                        Kommt auf das DBMS, die Datenbank, die Tabelle und das Feld an. Was benutzt Du? Informiere Dich.

                        1&1 MySQL5.0, Tabellen und Felder kann ich ja selbst auswählen.

                        wobei da zusätzliche Eigenschaften eines Objektes (wie z.B. in der Titeltabelle "Link zu Video") eine eher untergeordnete Rolle spielen: zusätzliche Spalten in einer Tabelle, die NUR Inhalt darstellen, kann man jederzeit einfügen - die Struktur später grundsätzlich zu ändern, erfordert Schrauben an mehreren Stellen, wenn man Pech hat.

                        Stimmt, für Link zum Video könnte ich schon vorbereitungen treffen, wobei ich eher daran gedacht hab, das video direkt
                        mit den embed Geschichten der Video Portale einzubinden.

                        Mit radio Button

                        MyVideo - <object type='application/x-shockwave-flash' data='http://www.myvideo.de/movie/2079993'> <param name='movie' value='http://www.myvideo.de/movie/2079993'/> <param value='true' /> </object>

                        Youtube - <object><param name="movie" value=".."></param><param name="wmode"></param><embed src="http://www.youtube.com/v/RLyOJyaj0zc&rel=1" type=".."></embed></object>

                        Wobei ich hier nicht weiss, wie ich das anstellen soll, wie ich diese eingabe validieren soll.

                        Von der DB Struktur her ist ja soweit ich das jetzt sehe alles erforderliche drin, zumal
                        es ja keine Riesige Applikation ist. Nur ich mach aus ner Mücke nen Elefant. :-)

                        Grüße aus H im R,
                        Engin

                        1. Mahlzeit,

                          Dann hätte ich auf Seite 3 schon alle relevante Daten des Interpreten, wenn diese in der DB vorhanden sind und könnte alle
                          in der DB vorhanden Texte dieses Interpreten auflisten.
                          Wenn der Text, den der User gerade eingeben will vorhanden ist, kann der User das sofort sehen.

                          Genau so.

                          Kommt auf das DBMS, die Datenbank, die Tabelle und das Feld an. Was benutzt Du? Informiere Dich.

                          1&1 MySQL5.0, Tabellen und Felder kann ich ja selbst auswählen.

                          Ja. Und Du kannst beim Anlegen derselben auch angeben, ob sie case-sensitiv sein sollen oder nicht.

                          Stimmt, für Link zum Video könnte ich schon vorbereitungen treffen, wobei ich eher daran gedacht hab, das video direkt
                          mit den embed Geschichten der Video Portale einzubinden.

                          Mit radio Button

                          MyVideo - <object type='application/x-shockwave-flash' data='http://www.myvideo.de/movie/2079993'> <param name='movie' value='http://www.myvideo.de/movie/2079993'/> <param value='true' /> </object>

                          Youtube - <object><param name="movie" value=".."></param><param name="wmode"></param><embed src="http://www.youtube.com/v/RLyOJyaj0zc&rel=1" type=".."></embed></object>

                          Wobei ich hier nicht weiss, wie ich das anstellen soll, wie ich diese eingabe validieren soll.

                          Hm. Falls Du vorhast, immer diesen ganzen HTML-Klumpatsch in ein VARCHAR-Feld der Datenbank zu schreiben: gaaaaanz schlechte Idee. Wenn die Dienste die Art und Weise der Einbindung ändern, musst Du ALLE Einträge entsprechend ändern. Außerdem hättest Du dann Unmengen redundanter Daten bei Dir gespeichert.

                          Ich würde folgendes empfehlen:

                          Tabelle "titel":
                          ID | Name | Songtext
                          ---+------+---------
                          ...
                          21 | foo  | bla blubb
                          93 | bar  | fasel laber
                          ...

                          Tabelle "link":
                          ID | titel_ID | linktyp_ID | Code
                          ---+----------+------------+-----
                          ...
                          32 | 21       | 14         | 2079993
                          72 | 93       | 82         | RLyOJyaj0zc
                          ...

                          Tabelle "linktyp":
                          ID | Name    | HTML
                          ---+---------+-----
                          ...
                          14 | MyVideo | <object type='application/x-shockwave-flash' data='http://www.myvideo.de/movie/@CODE@'> <param name='movie' value='http://www.myvideo.de/movie/@CODE@'/> <param value='true' /></object>
                          82 | Youtube | <object><param name="movie" value=".."></param><param name="wmode"></param><embed src="http://www.youtube.com/v/@CODE@&rel=1" type=".."></embed></object>
                          ...

                          Warum? Es können für jeden Titel evtl. mehrere Links mit verschiedenen Linktypen vorkommen - deswegen wieder eine n:m-Beziehung. Zusätzlich dazu besitzt jeder Link einen eindeutigen "Code", der dem jeweiligen Linkanbieter übergeben werden muss. Die jeweiligen Linktypen musst Du dann nur genau EINMAL in Deiner Datenbank speichern, kannst sie jederzeit an ggf. geänderte Anforderungen anpassen und hast dann immer gleich ALLE Links auf dem neuesten Stand. Das einzige, was zu tun wäre: beim Auslesen den beliebigen Platzhalter (der EINDEUTIG zu finden sein muss, egal wie der HTML-Code aussieht - ich hab ihn mal "@CODE@" genannt) durch den jeweiligen Code des Links zu ersetzen.

                          MfG,
                          EKKi

                          --
                          sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
                          1. Hi EKKi,

                            Wenn der Text, den der User gerade eingeben will vorhanden ist, kann der User das sofort sehen.

                            Genau so.

                            Da hat das fantasieren ja doch mal was gebracht. :)

                            Ja. Und Du kannst beim Anlegen derselben auch angeben, ob sie case-sensitiv sein sollen oder nicht.

                            Das wusste ich nicht, das ist auch gut zu wissen.

                            Hm. Falls Du vorhast, immer diesen ganzen HTML-Klumpatsch in ein VARCHAR-Feld der Datenbank zu schreiben: gaaaaanz schlechte Idee. Wenn die Dienste die Art und Weise der Einbindung ändern, musst Du ALLE Einträge entsprechend ändern. Außerdem hättest Du dann Unmengen redundanter Daten bei Dir gespeichert.

                            Ich hatte mir müberlegt, nur den Link bzw. die URI zum Video zu speichern, den ganzen HTML-Klumpatsch
                            würde ich dann einfach mittels Include in die Seite Laden, den Link für das Video dann als Variable in die src laden.

                            vereinfacht: if (isset($_GET...{<embed...src="<? echo $user_eingabe"...
                            und das auch nur, wenn eine Variable vorhanden ist, ansonsten ignorieren.

                            Ich würde folgendes empfehlen:

                            Tabelle "titel":
                            ID | Name | Songtext
                            ---+------+---------
                            ...
                            21 | foo  | bla blubb
                            93 | bar  | fasel laber
                            ...

                            Tabelle "link":
                            ID | titel_ID | linktyp_ID | Code
                            ---+----------+------------+-----
                            ...
                            32 | 21       | 14         | 2079993
                            72 | 93       | 82         | RLyOJyaj0zc
                            ...

                            Tabelle "linktyp":
                            ID | Name    | HTML
                            ---+---------+-----
                            ...

                            Warum? Es können für jeden Titel evtl. mehrere Links mit verschiedenen Linktypen vorkommen - deswegen wieder eine n:m-Beziehung. Zusätzlich dazu besitzt jeder Link einen eindeutigen "Code", der dem jeweiligen Linkanbieter übergeben werden muss. Die jeweiligen Linktypen musst Du dann nur genau EINMAL in Deiner Datenbank speichern, kannst sie jederzeit an ggf. geänderte Anforderungen anpassen und hast dann immer gleich ALLE Links auf dem neuesten Stand. Das einzige, was zu tun wäre: beim Auslesen den beliebigen Platzhalter (der EINDEUTIG zu finden sein muss, egal wie der HTML-Code aussieht - ich hab ihn mal "@CODE@" genannt) durch den jeweiligen Code des Links zu ersetzen.

                            Das ist auch eine gute Idee, ich werde es mir aber vereinfachen, da ich ja die Videos direkt einbinde möchte
                            würde ein Link schon reichen, das werde ich dann so einbinden, das bei TRUE
                            der benötigte HTML Code aus einer Datei geladen wird
                            und in die SRC wird dann der gespeicherte URI geladen.

                            Mein Problem bei dieser Sache war, das ich nicht wusste, wie ich die URI speichern soll,
                            die komplette URI speichern und einfach einbinden wäre Selbstmord, jetzt hast du mich auf die richtige Idee gebracht, einfach
                            die letzten Zahlen aus der URI extrahieren und einbinden.

                            Grüße aus H im R,
                            Engin

                  2. Hi,

                    Dann könntest Du für die Interpreten, die eine "Gruppe" sind (also die "interpret_typ_ID" = 2 haben), die einzelnen Bandmitglieder in einer separaten Tabelle erfassen

                    Das *koennte* man machen - aber ich wuerde doch empfehlen, bei Engins derzeitigem Kenntnisstand und der Denkarbeit, die er bisher ins Datenmodell gesteckt hat und mit unserer Hilfe noch steckt, das ganze erst mal nicht *zu* kompliziert zu machen.

                    Gruppen-/Bandmitglieder haben naemlich die unangenehme Eigenschaft, auch mal zu wechseln - die beruehmten "musikalischen Differenzen" gibt's in vielen Bands mal, und dann steigt Mitmusiker X aus, und wird durch Y ersetzt. Dann haben also X und Y beide in Band A mal die Position B bekleidet - nur zu unterschiedlichen Zeitpunkten. Wenn man das sauber abbilden wollte, muesste man die Zeitpunkte also auch noch in der DB hinterlegen ...

                    Und hier geht's ja wohl eher darum, eine Verwaltung fuer Alben/CDs zu schreiben - wer da jetzt wann in der bewegten Geschichte von Band A mal die Axt geschwungen (Gitarre gespielt) oder das Schlagzeug verdroschen hat, ist an der Stelle eher nebensaechlich. Diese Information darf der geneigte Musikliebhaber sich dann bei Bedarf aus einer Zweitquelle, wie bspw. der Wikipedia, heraussuchen.

                    MfG ChrisB

                    1. Hi ChrisB,

                      Das *koennte* man machen - aber ich wuerde doch empfehlen, bei Engins derzeitigem Kenntnisstand und der Denkarbeit, die er bisher ins Datenmodell gesteckt hat und mit unserer Hilfe noch steckt, das ganze erst mal nicht *zu* kompliziert zu machen.

                      Du verstehst mich :-)

                      Danke euch allen für die Hilfe, hab in den letzten Wochen ne ganze Menge gelernt.

                      Mal sehen, ob ich es _jetzt_ endlich hinkriege. Jeder Versuch, neu anzufangen brachte plötzlich ein neues Problem.

                      Grüße aus H im R,
                      Engin

  3. Hi,

    bastel gerade an meinem ersten eigenen Formular, hab eine art Vorschau die ich mit $_GET aufrufe,
    wenn ich jetzt < oder > eingebe und vorschau klicke, steht im <input type="text"> &lt bzw. &gt, backslashes ()
    bekomme ich in doppelter Form ausgegeben.

    Diese Ausgabe erreiche ich mit (htmlspecialchars($buchstabe)), ist doch richtig oder?

    Sorry wegen der blöden frage, sitz jetzt seit 3 Stunden am ersten aufruf und kann nicht mehr klar denken.

    Das bisherige stück Code sieht nun so aus - (bis auf´s nötigste gekürzt)

      
      if (isset($_GET['PREVIEWBUTTON'])) {  
      
      $buchstabe = (htmlspecialchars($_GET['interpreten_name']));  
      
      echo '<form action="'.$_SERVER['PHP_SELF'].'" method="GET">  
      <input type="text" name="interpreten_name" value="'.(htmlspecialchars($buchstabe)).'" />  
      Interpret<br />';  
      
      $resultat = mysql_query("SELECT interpret_id, name FROM song_interpret");  
      $num_rows = mysql_num_rows($resultat);  
      
      echo '<select name="Interpret" size="'.$num_rows.'">'."\n";  
      
      $sql = "SELECT interpret_id, name FROM song_interpret WHERE name LIKE '$buchstabe%' ORDER BY name";  
     $ergebnis = mysql_query($sql);  
      
      while($row = mysql_fetch_object($ergebnis))  
        {  
        echo '<option value="'.(htmlspecialchars($row->interpret_id)).'">';  
        echo (htmlspecialchars($row->name))."</option>\n";  
        }  
          echo  '</select><br /><input type="submit" name="PREVIEWBUTTON" value="Vorschau" />  
         <input type="submit" name="WEITERBUTTON" value="WEITER" />  
     </form>';  
    }
    

    Gibt es an diesem Code was auszusetzen oder kann ich auf diesem Prinzip weiter aufbauen?

    Grüße aus H im R,
    Engin

    1. echo $begrüßung;

      wenn ich jetzt < oder > eingebe und vorschau klicke, steht im <input type="text"> &lt bzw. &gt, backslashes ()
      bekomme ich in doppelter Form ausgegeben.
      Diese Ausgabe erreiche ich mit htmlspecialchars($buchstabe), ist doch richtig oder?

      Ja, wenn man es einmal macht, dann schon.

      $buchstabe = (htmlspecialchars($_GET['interpreten_name']));

      Die äußeren Klammern sind überflüssig. Ebenso in der nachfolgenden Zeile.

      <input type="text" name="interpreten_name" value="'.(htmlspecialchars($buchstabe)).'" />

      Hier fügst du den Inhalt von $buchstabe in einen HTML-Kontext ein und behandelst ihn noch ein zweites Mal. Daher deine Verdopplung. Behandle Werte niemals im Voraus, immer erst dann, wenn du sie in einen anderen Kontext bringst. Es geht nämlich noch weiter.

      $sql = "SELECT interpret_id, name FROM song_interpret WHERE name LIKE '$buchstabe%' ORDER BY name";

      Das oben bereits HTML-behandelte $buchstabe fügst du nun in einen SQL-Kontext ein. Hier haben die HTML-Umschreibungsn &gt; usw. keinerlei nützlichen Wert. Wenn du nach einem in der Datenbank stehenden > suchen möchtest, stattdessen aber nach &gt; suchst, wirst du nicht fündig. (Höchstens pfündig vom Frustessen.)

      Arbeite stets mit der Rohform der Daten. Befreie sie bei der Übernahme gegebenenfalls von der Transportsicherung, aber bereite sie erst direkt beim Einfügen in einen Ausgabekontext für diesen auf, nicht vorher. Ändere dabei nicht den Inhalt einer Variablen, die du dann einfügst, sondern wende die Aufbereitungsfunktion direkt an, so wie du es in der <input>-Zeile machst.

      $num_rows = mysql_num_rows($resultat);
        echo '<select name="Interpret" size="'.$num_rows.'">'."\n";

      Das Ergebnis von mysql_num_rows($resultat) ist eine triviale Zahl und du brauchst es an genau einer Stelle. Es dafür zunächst in einer Variablen abzulegen, ist nicht notwendig. (Bei $sql=... ist der einmalige Variablengebrauch hingegen nützlich, um sich für Debug-Zwecke das Statement ausgeben zu lassen.)

      Bist du sicher, dass du auf jeden Fall das select-Element so lang haben möchtest wie Datensätze vorhanden sind? Manchmal ist es sinnvoller, eine Obergrenze zu verwenden, so dass vielleicht 15 gleichzeitig angezeigt werden und der Rest erscrollbar ist. Das ließe sich mit der Funktion min() bewerkstelligen: min(15, mysql_num_rows($resultat)). Wenn num_rows größer als 15 ist, holt die 15 es auf ebendiese Anzahl zurück.

      echo "$verabschiedung $name";

      1. Hi dedlfix,

        <input type="text" name="interpreten_name" value="'.(htmlspecialchars($buchstabe)).'" />

        Hier fügst du den Inhalt von $buchstabe in einen HTML-Kontext ein und behandelst ihn noch ein zweites Mal. Daher deine Verdopplung. Behandle Werte niemals im Voraus, immer erst dann, wenn du sie in einen anderen Kontext bringst. Es geht nämlich noch weiter.

        Wenn ich $buchstabe nur 'einmal' behandel werden Zeichen wie < oder > so wie sie sind ausgegeben,
        statt als &lt oder &gt.
        Da stoss ich noch auf verständnis fragen.

        Was muss nach der abfrage im <input type="text"> stehen, '< oder &lt' ?

          
          if (isset($_GET['PREVIEWBUTTON'])) {  
         $buchstabe = $_GET['interpreten_name'];  
          
          echo '<form action="'.$_SERVER['PHP_SELF'].'" method="GET">  
          <input type="text" name="interpreten_name" value="'.htmlspecialchars($buchstabe).'" />  
         Interpret<br />'."\n";  
          
         $resultat = mysql_query("SELECT interpret_id, name FROM song_interpret");  
          $num_rows = min(15, mysql_num_rows($resultat));  # auch hier gibt es noch verständnis probleme  
         echo '<select name="Interpret" size="'.$num_rows.'">'."\n";  
          
         $sql = "SELECT interpret_id, name FROM song_interpret WHERE name LIKE '$buchstabe%' ORDER BY name";  
         $ergebnis = mysql_query($sql);  
          
         while($row = mysql_fetch_object($ergebnis))  
         {  
         echo '<option value="'.(htmlspecialchars($row->interpret_id)).'">'; # ist an dieser stelle eine bearbeitung nötig?  
         echo (htmlspecialchars($row->name))."</option>\n";  
               }  
         echo  '</select><br /><input type="submit" name="PREVIEWBUTTON" value="Vorschau" />  
         <input type="submit" name="WEITERBUTTON" value="WEITER" />  
         </form>';  
               }  
        else {  
        }
        

        Das Ergebnis von mysql_num_rows($resultat) ist eine triviale Zahl und du brauchst es an genau einer Stelle. Es dafür zunächst in einer Variablen abzulegen, ist nicht notwendig.

        Anders kriege ich kein Resultat bzw. zahl ausgegeben, wie kann ich das denn ohne Variablen lösen?

        Bist du sicher, dass du auf jeden Fall das select-Element so lang haben möchtest wie Datensätze vorhanden sind? Manchmal ist es sinnvoller, eine Obergrenze zu verwenden, so dass vielleicht 15 gleichzeitig angezeigt werden und der Rest erscrollbar ist. Das ließe sich mit der Funktion min() bewerkstelligen: min(15, mysql_num_rows($resultat)). Wenn num_rows größer als 15 ist, holt die 15 es auf ebendiese Anzahl zurück.

        Das wäre ein schönes Feature, nur diese funktion verstehe ich nicht, oder wende es falsch an.

         $resultat = mysql_query("SELECT interpret_id, name FROM song_interpret");  
          $num_rows = min(15, mysql_num_rows($resultat));  
         echo '<select name="Interpret" size="'.$num_rows.'">'."\n";
        

        Ich bekomme an stelle von '.$num_rows.' immer 15, egal ob das resultat 15 sind oder weniger.
        Ich hätte jetzt gedacht, das wenn das ergebnis weniger als 15 die entsprechende Zahl ausgibt,
        und über 15 immer 15 ausgibt.
        Oder habe ich es falsch angewendet?

        Grüße aus H im R,
        Engin

        1. echo $begrüßung;

          Wenn ich $buchstabe nur 'einmal' behandel werden Zeichen wie < oder > so wie sie sind ausgegeben, statt als &lt oder &gt.
          Da stoss ich noch auf verständnis fragen.

          Beobachte bitte genauer. Wo werden sie wie ausgegeben? Diese Umschreibung ist nur für den HTML-Code notwendig, denn hier muss du zwischen einem < als Tag-Eröffner und einem < als Datenbestandteil unterscheiden. Der Anwender will ein < sehen. Und auch die Datenbank will ein < haben, denn &lt; sind für sie einfach nur 4 Zeichen ohne Bedeutung.

          Was muss nach der abfrage im <input type="text"> stehen, '< oder &lt' ?

          Im HTML-Code steht &lt;, der Benutzer sieht <.

          echo '<option value="'.(htmlspecialchars($row->interpret_id)).'">'; # ist an dieser stelle eine bearbeitung nötig?

          Ja, so ist das gut (die äußeren ()-Klammern können entfallen). Selbst wenn du annimst, dass die Interpreter-ID immer numerisch ist, schadet es nicht, sie durch htmlspecialchars() zu jagen.

          Das Ergebnis von mysql_num_rows($resultat) ist eine triviale Zahl und du brauchst es an genau einer Stelle. Es dafür zunächst in einer Variablen abzulegen, ist nicht notwendig.
          Anders kriege ich kein Resultat bzw. zahl ausgegeben, wie kann ich das denn ohne Variablen lösen?

          Das Funktionsergebnis weist du einer Variablen zu. Du kannst es genauso gut als Argument für eine weitere Funktion verwenden oder es einem echo übergeben.

          Bist du sicher, dass du auf jeden Fall das select-Element so lang haben möchtest wie Datensätze vorhanden sind? Manchmal ist es sinnvoller, eine Obergrenze zu verwenden, so dass vielleicht 15 gleichzeitig angezeigt werden und der Rest erscrollbar ist. Das ließe sich mit der Funktion min() bewerkstelligen: min(15, mysql_num_rows($resultat)). Wenn num_rows größer als 15 ist, holt die 15 es auf ebendiese Anzahl zurück.
          Das wäre ein schönes Feature, nur diese funktion verstehe ich nicht, oder wende es falsch an.

          Ja, das ist vielleicht verwirrend, wenn du, um das Maximum zu begrenzen, eine Funktion für das Minimum anwenden sollst.

          $resultat = mysql_query("SELECT interpret_id, name FROM song_interpret");

          $num_rows = min(15, mysql_num_rows($resultat));
          echo '<select name="Interpret" size="'.$num_rows.'">'."\n";

            
          Das müsste eigentlich so passen, abgesehen von der fehlenden Reaktion auf Fehler, die dir mysql\_query() per false zu sagen versuchen könnte.  
            
          
          > Ich bekomme an stelle von '.$num\_rows.' immer 15, egal ob das resultat 15 sind oder weniger.  
            
          Was genau ist das Ergebnis von mysql\_num\_rows($resultat) in dem Fall? Füge eine Kontrollausgabe var\_dump(mysql\_num\_rows($resultat)); vor das echo ein.  
            
          
          > Ich hätte jetzt gedacht, das wenn das ergebnis weniger als 15 die entsprechende Zahl ausgibt, und über 15 immer 15 ausgibt.  
            
          So soll es ein. Das klärt sich sicher durch die Kontrollausgabe auf.  
            
            
          echo "$verabschiedung $name";
          
          1. Hi dedlfix, hallo Ekki,

            Beobachte bitte genauer. Wo werden sie wie ausgegeben?

            Im HTML-Code steht &lt;, der Benutzer sieht <.

            ja stimmt, vor lauter Bäumen habe ich den Quelltext übersehen, da steht tatsächlich &lt, wenn ich das ganze 'einmal' bearbeite.
            Ich hatte angenommen, <input type="text"> stellt alles so wie im Quelltext dar.

            Das Funktionsergebnis weist du einer Variablen zu. Du kannst es genauso gut als Argument für eine weitere Funktion verwenden oder es einem echo übergeben.

            Das ist doch verrückt, als ich das Gestern vesucht hatte bekam ich eine fehlermeldung,
            jetzt geht es.  *gg

            Was genau ist das Ergebnis von mysql_num_rows($resultat) in dem Fall? Füge eine Kontrollausgabe var_dump(mysql_num_rows($resultat)); vor das echo ein.
            So soll es ein. Das klärt sich sicher durch die Kontrollausgabe auf.

            Ich hatte die Ergebnisse aus der query fälschlicher weise nicht begrenzt, daher kam der Fehler,
            jetzt funzt[tm] alles PicoBello. *g

            (unwichtige HTML Tags entfernt)

              
              if (isset($_GET['PREVIEWBUTTON'])) {  
             $buchstabe = $_GET['interpreten_name'];  
              
                     echo '<form action="'.$_SERVER['PHP_SELF'].'" method="GET">  
             <input type="text" name="interpreten_name" value="'.htmlspecialchars($buchstabe).'" />  
             Interpret'."\n";  
              
             $resultat = mysql_query("SELECT interpret_id, name FROM song_interpret WHERE name LIKE '$buchstabe%'");  
              
             echo '<select name="Interpret" size="'.min(15, mysql_num_rows($resultat)).'">';  
              
             $sql = "SELECT interpret_id, name FROM song_interpret WHERE name LIKE '$buchstabe%' ORDER BY name";  
             $ergebnis = mysql_query($sql);  
              
             while($row = mysql_fetch_object($ergebnis))  
                   {  
             echo '<option value="'.htmlspecialchars($row->interpret_id).'">';  
             echo htmlspecialchars($row->name)."</option>\n";  
                   }  
             echo  '</select><input type="submit" name="PREVIEWBUTTON" value="Vorschau" />  
             <input type="submit" name="WEITERBUTTON" value="WEITER" />  
             </form>';  
                   }
            

            Ist dieser Code jetzt in dieser Form "Sicher" und verwendbar?

            Grüße aus H im R,
            Engin

            1. Mahlzeit,

              Ist dieser Code jetzt in dieser Form "Sicher" und verwendbar?

              IMHO: nein ... wie gesagt: EVA-Prinzip.

              MfG,
              EKKi

              --
              sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
              1. Hi EKKi,

                Ist dieser Code jetzt in dieser Form "Sicher" und verwendbar?

                IMHO: nein ... wie gesagt: EVA-Prinzip.

                Den Link habe ich mittlerweile 3 mal durch gelesen, weiss aber nicht, wie ich da was machen soll.

                Ich habe es jetzt ganz anders gelöst, ich hab jemanden angagiert, mir das zu programmieren, zusammen mit
                einem Login Script, ich mach das HTML/CSS, er den rest. (zu einem recht fairen Preis)

                Bin leider ein wenig in Stress, hab in den nächsten 2 Wochen einen Termin mit einem
                Türkischen Musik/Fernseh Guru, wenn alles gut verläuft, kann ich demnächst neben Songtexten
                Legal Türkische Musik zum Download anbieten.

                Danke euch allen für eure mühen, ich werde natürlich weiterhin am Ball bleiben und üben.

                Grüße aus H im R,
                Engin

    2. Mahlzeit,

      Gibt es an diesem Code was auszusetzen oder kann ich auf diesem Prinzip weiter aufbauen?

      Ja und jein. Versuche, Dich ans EVA-Prinzip zu halten, vermische niemals Eingabe(-überprüfung), Verarbeitung und Ausgabe!

      Beispiel: Wenn Du gleich zu Anfang irgendeinen Seitenkopf ausgibst und weiter unten irgendwelche Werte auf Validität prüfst, kannst Du dort im Fehlerfall nicht mehr auf eine entsprechende Hinweis-Seite weiterleiten (per "header()""), da schon Ausgaben getätigt wurden.

      Oder - wie in Deinem Fall: Du gibst 1. einen Formularkopf aus, machst 2. eine SQL-Abfrage, gibst 3. den Beginn einer <select>-Box aus und gehst 4. in einer Schleife durch die Ergebnismenge einer Abfrage, um die <option>-Tags auszugeben. Was passiert, wenn in Deinen SQL-Abfragen irgendwo ein Fehler auftritt? Richtig: dann wird Schrott ausgegeben.

      1. Überprüfe ALLE GET- und POST-Parameter auf Validität.

      2. Verarbeite die Werte, mache Deine Abfragen usw. und schreibe das, was du SPÄTER ausgeben willst, in entsprechende Variablen.

      3. Wenn die Verarbeitung abgeschlossen ist, gib das, was Du ausgeben willst, in einem Stück aus (ohne viel PHP-Code dazwischen, nur das Notwendigste).

      So sorgst Du auch für Übersichtlichkeit in Deinem Code - ansonsten suchst Du teilweise ewig nach genau der Stelle, wo nun eigentlich dieses komische Bröckchen HTML direkt per echo rausgeblasen wird.

      MfG,
      EKKi

      --
      sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|