# MySql - phpMyAdmin



## k3nguruh (13. Dezember 2013)

Hallo,

ich habe eigentlich kein richtiges Problem, möchte aber dennoch mal eure Meinung dazu hören.

Vor kurzem (?) muss wohl auf meinem Server die phpMyAdmin Version 4.0.4.1 aufgespielt worden sein. Jedenfalls habe ich heute mitbekommen, dass bei einigen Tabellen folgende Meldung auftaucht.


> Diese Tabelle enthält keine eindeutige ("unique") Spalte. Gitter-Bearbeitungsfunktion, Kontrollkästchen, Bearbeiten, Kopieren und Löschen von Links sind nicht verfügbar.



Bei den Tabellen handelt es sich unter anderem um solch ein Format:

pid (INDEX) | bla (VarChar) | blabla (VarChar)

Dabei werden entwerder bei einer Abfrage alle gleichen "pid" gelöscht, oder für eine pid kommen mehrere Einträge hinzu.

Muss ich diesen Tabellen jetzt eine Unique - Spalte geben, oder nicht? Jedenfalls mein Script braucht diese Eindeutigen Spalte nicht. Ist ja auch (noch) gar nicht vorhanden


----------



## sheel (13. Dezember 2013)

Hi

Also von der Pid kanns mehrere gleichzeitig geben (?), dann ist die schon ungeeignet.

Was man von einen (eindeutigen) Key hat sind
eventuell bestimmte Funktionen der DB, die ohne nicht funktionieren
(kommt drauf an, was man braucht)
und eventuell ein Geschwindigkeitsgewinn
(auch das hängt stark davon ab, was man eigentlich macht)

Wenns bisher funktioniert hat wirds auch weiterhin so sein.
Wenn man so eine Spalte machen will (und die sonst keine Anforderungen hat)
kann man den Inhalt auch durch die DB selbst festlegen lassen
(einfach 1,2,3... automatisch immer die nächste Zahl bei einem Insert.
Selbst gibt man dann keinen Wert für die Spalte an, also SQL unverändert wie bisher)
Siehe AUTO_INCREMENT bei Bedarf.


----------



## k3nguruh (13. Dezember 2013)

Hallo sheel,

erstmal Danke für deine Antwort...



sheel hat gesagt.:


> Hi
> Also von der Pid kanns mehrere gleichzeitig geben (?), dann ist die schon ungeeignet.


warum ein Fragezeichen ?

Mal eine kurze Erklärung:

Es gibt eine Tabelle "memdaten", dort ist die "pid" AUTO_INCREMENT und PRIMARY, also eindeutig.

Die Einträge, bei der die Infoleiste auftaucht, sind eigentlich nur Zusatzdaten die das Mitglied in einem Formular ausfüllen kann. Dabei ist die Anzahl der Einträge pro Mitglied nicht begrenzt, da die Eingabemaske immer um eine Zeile geclont werden kann.

In die Datenbank kommt zum Bsp. dann sowas rein:

pid | fertigkeit                  | nachweis | .....
12 | Rettungsschwimmer | ja
12 | Taucher                    | nein
12 | Sanitätshelfer           | ja

Beim Speichern lösche ich einfach alle gleichen "pid"s und trage dann die neuen Eingaben ein (foreach).
So umgehe ich eigentlich das prüfen, ob der Eintrag schon existiert, dann Update oder halt neu Eingefügt werden muss und das löschen, wenn nicht mehr eingegeben.

Würde ich da jetzt einen Primary Key mit AUTO_INCREMENT vorsetzen, würde der key ja jedesmal hochzählen. Und irgendwann sicherlich zu ende sein. OK, bei mir vll nie  , da diese Eingaben ca. 2x im Jahr durchgeführt wird.

Ist da immer noch was falsch dran? Damit ich es ggf. mal ändern kann.


----------
Mich stört an der neuen Version eigentlich nur das, dass man nicht wie früher die Bearbeiten, Löschen, ... Links hat. Das es nicht geht, kann ja auch nicht sein, denn in den früheren Versionen konnte ich trotz dieser Tabellenanordnung diese Links benutzen.


----------



## sheel (13. Dezember 2013)

Zu dem Problem mit dem Ausgehen der Zahlen:
Wenn mann ein (unsigned) Bigint als Spaltentyp nimmt...
100 neue Einträge pro Sekunde brauchen immer noch 5849424173 Jahre,
bis die Nummern ausgehen.
Also das sollte kein Problem werden.


----------



## k3nguruh (13. Dezember 2013)

sheel hat gesagt.:


> ...
> 100 neue Einträge pro Sekunde brauchen immer noch 5849424173 Jahre,
> bis die Nummern ausgehen.



naja, könnte knapp werden 

Ich habe jetzt erstmal eine AutoID angelegt. Kann ja nicht schaden. Und wenn die doch schneller voll werden sollte, kann ich die immer noch löschen.

Besten Dank für deine Mühen.


----------

