Ankündigung

Einklappen
Keine Ankündigung bisher.

MySQL Datensätze einmalig/unique machen, geht das?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • MySQL Datensätze einmalig/unique machen, geht das?

    Hallo Community


    Ich habe mal eine Frage, eigentlich steht die schon in dem Titel

    Ich habe ein PHP-Skript mit dem ich Daten ermittele und sie in MySQL abspeichere
    Bei meinen Datensätzen kommt es mal vor, dass sie mit einer vorherigen Abfrage gleich sind - und so wiederholt in MySQL auftauchen
    Gibt es eine einfach Möglichkeit (am besten in SQL selbst) dies zu verhindern?
    ID Nachname Vorname Alter Geschlecht
    1 Mustermann Maximilian 45 Männlich
    2 Musterfrau Maxia 39 Weiblich
    3 Mustermann Maximilian 45 Männlich
    4 Musterjunge Max 19 Männlich
    Am besten natürlich das SQL das selbst prüft und verhindert BEVOR überhaupt eine ID gesetzt wird

    EDIT // Die Tabelle ist nur ein klein gestaltetes Beispiel (!)




    das untere ist gelöst

    PS: Noch eine Nachfrage bezüglich Umlauten

    Mein MySQL speichert (pbwohl latin1_general_ci gesetzt) Variablen die einen Umlaut haben in einer falschen weise ab

    z.B. den Wert einer Variabel aus PHP "Session und offene Bühne" (die wird in PHP auch mit echo richtig angezeigt)
    In MySQL als "Session und offene Bühne"




  • #2
    Du hast ja das Stichwort unique schon:

    http://www.mysqltutorial.org/mysql-unique/

    Umlaute:
    utf-8 ist die Codierung Deiner Wahl:
    https://php-de.github.io/jumpto/utf-8/

    Kommentar


    • #3
      Zitat von dustinator Beitrag anzeigen
      z.B. den Wert einer Variabel aus PHP "Session und offene Bühne" (die wird in PHP auch mit echo richtig angezeigt)
      In MySQL als "Session und offene Bühne"
      Die Kollation hat nichts mit der Anzeige zu tun. Diese wird dann relevant, wenn sortiert oder ein Index verwendet wird. Davon abgesehen ist latin1_general_ci tiefstes Mittelalter und nicht zeitgemäß. Warum verwendest du sowas altes?

      Wenn du ein Zeichenkodierungsproblem hast, dann sind grob gesagt folgende 3 Dinge relevant:

      Zeichenkodierung der Datenbankverbindung.
      Zeichenkodierung im HTTP-Header.
      Zeichenkodierung der PHP-Dateie(n).

      Diese sollten alle übereinstimmen und in der Regel UTF-8 sein.

      Kommentar


      • #4
        Hatte latin1_general_ci automatisch genommen (zu schnell geklickt^^)
        Habs umgeändert auf utf16_general_ci
        Problem mit Umlauten besteht in MySQL immer noch ... aber bei der Ausgabe in PHP ist es nun wie gewünscht mit Umlauten ))
        Danke euch ))
        PS: ich habe mich auf utf16 eingestellt, ist das überdimensioniert oder genauso okay?



        Das mit unique werde ich mir jetzt durchlesen ... wäre aber dankbar wenn mir da noch mehr Infos gebt

        Kommentar


        • #5
          Zitat von dustinator Beitrag anzeigen
          Habs umgeändert auf utf16_general_ci
          Problem mit Umlauten besteht in MySQL immer noch ... aber bei der Ausgabe in PHP ist es nun wie gewünscht mit Umlauten ))
          utf8, nicht utf16. Außerdem reicht es nicht den Aufkleber zu ändern, du musst schon dafür sorgen dass die Daten wirklich als utf8-kodiert vorliegen (und auch immer als solche behandelt werden).

          Zitat von dustinator Beitrag anzeigen
          Das mit unique werde ich mir jetzt durchlesen ... wäre aber dankbar wenn mir da noch mehr Infos gebt
          Was brauchst du noch an Infos? Du musst halt einen Key auf die Spalten setzten die zusammen genommen dann eindeutig sein müssen (vmtl. vorname/nachname/alter und ggf. geschlecht) - allerdings ist es nicht wirklich sinnvoll das Alter zu speichern, speicher das Geburtsdatum.

          Kommentar


          • #6
            Zitat von dustinator Beitrag anzeigen
            Das mit unique werde ich mir jetzt durchlesen ... wäre aber dankbar wenn mir da noch mehr Infos gebt
            Code:
             
             ALTER TABLE `namen`  ADD UNIQUE INDEX `unqiue_name` (`Nachname`, `Vorname`);
            Musst du hier den Tabellen Namen sowie Spaltennamen anpassen, danach gibt es beim INSERT eine Feherlmeldung wenn du doppelte Einträge machst
            apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/witalimik

            Kommentar


            • #7
              Danke TK,
              Ja ich hatte gleich die Tabelle neu angelegt - auf utf16 - weil mir da jemand gesagt hat, dass das mehr abspeichern kann und einzig die performence darunter leiden kann (bei sehr vielen Einträgen, an die ich nie rannkommen^^)
              Das mit Alter war nur als Beispiel - in meiner eigentlichen Tabelle ging es um Internetadressen usw die ich auf UNIQUE setzen wollte

              Thx BC,
              Code:
               ALTER TABLE evente ADD UNIQUE INDEX UC_link (linkmehr, linknochmehr);
              Was ist der Unterschied zwischen diesen zwei Varianten?

              Code:
              ALTER TABLE evente ADD CONSTRAINT UC_linkmehr UNIQUE (linkmehr)
              Die untere Variante sperrt mir eine Spalte 'linkmehr' - da wird ein Link abgespeichert den ich nie wieder in einem SQL Eintrag haben will
              Wenn ich jetzt mit INSERT einen Datensatz mit z.b. name, vorname, alter, linkmehr usw übergebe, dann wird der ganze Datensatz nicht angespeichert wenn linkmehr schon vorhanden ist

              Kommentar


              • #8
                Naja du definierst welche Spalten Einzigartig sein sollen.

                Im ersten sagst du dass eben WENN linkmehr UND linknochmehr zusammen doppelt vorkommen, dann darf kein Eintrag stattfinden.

                Beim zweiten guckst du eben NUR auf linkmehr.
                apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/witalimik

                Kommentar


                • #9
                  Ah cool super, da kann ich dann mit sql noch mehr spielen ))

                  Kommentar


                  • #10
                    Zitat von dustinator Beitrag anzeigen
                    Ja ich hatte gleich die Tabelle neu angelegt - auf utf16 - weil mir da jemand gesagt hat, dass das mehr abspeichern kann und einzig die performence darunter leiden kann (bei sehr vielen Einträgen, an die ich nie rannkommen^^)
                    Das ist halt hochgradiger Unfug. Was mehr Speicher verbraucht und was mehr Performance bringt hängt vom Anwendungsfall ab. Aber das wird erst bei richtig großen Datenmengen relevant.

                    Bei Webanwendungen hat sich UTF-8 eingebürgert und man macht sich das leben leichter, wenn man konsequent UTF-8 verwendet und nicht ständig herumkodieren muss.

                    Kommentar


                    • #11
                      Genau genommen utf8mb4 sollte man nehmen, da hab ich schon mehr gelesen dazu, zB

                      https://mathiasbynens.be/notes/mysql-utf8mb4

                      https://medium.com/@adamhooper/in-my...4-11761243e434

                      https://www.eversql.com/mysql-utf8-v...8-and-utf8mb4/


                      MOD: Verschoben von Off-topic zu DB
                      Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                      PHP.de Wissenssammlung | Kein Support per PN

                      Kommentar


                      • #12
                        Ne neue DB ist bei mir schnell angelegt, muss nur drauf achten dasALTER TABLE.. wieder zu benutzen

                        Tja jetzt habe ich 6 Alternativen ... ich brauchen wohl einen Würfel um zu entscheiden welches das beste is

                        1) utf8_general_ci < - das habe ich früher am meisten genommen
                        2) utf8_german2_c2 < - auch das - gibt es da einen signifikanten unterschied zum oberen?

                        3) utf16_general_ci < - das wurde mir empfohlen - obwohl der Programmierer meist mit Java programmiert
                        4) utf16_german2_c2 < - die zwei 16er Varianten werde ich nicht mehr nehmen


                        5) utf8mb4_general_ci <- so, jetzt sind noch mehr Alternativen da
                        6) utf8mb4_german2_c2 <-

                        Was wäre das sinnvollste 1, 2, 3, 4, 5, oder 6 ...

                        Kommentar


                        • #13
                          Je nachdem, was du brauchst. Das solltest du selber wissen.

                          Die Kollation sollte aber zur Zeichenkodierung der Daten passen. Also eine utf16-Kollation ergibt bei einer utf8-Kodierung keinen Sinn.

                          Kommentar


                          • #14
                            https://stackoverflow.com/a/766996/10537201

                            Das mal lesen, den Rest solltest du dann selbst entscheiden können/müssen.

                            EDIT:
                            OK du hast _german_ noch aber im Grunde zieht sich das bei den Kollationen eh irgendwie durch, bzw. kannst alles nachlesen.
                            Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                            PHP.de Wissenssammlung | Kein Support per PN

                            Kommentar


                            • #15
                              Zitat von dustinator
                              Was wäre das sinnvollste 1, 2, 3, 4, 5, oder 6 ...
                              Sinnvollste? Wenn es dir nur um "best practise" geht:

                              Code:
                               CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
                              https://dba.stackexchange.com/a/152383

                              LG
                              Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                              PHP.de Wissenssammlung | Kein Support per PN

                              Kommentar

                              Lädt...
                              X