MySql - Feld hochzählen

[Victor]

Hi,

ich bräucht Hilfe bei einem kleinen insert DB Problem.
Ich hab ne mysql-db und dort möchte ich eine Tabelle, die wie folgt aussieht.

Userid - Kategorie ID - Kategorie Name
80 - 1 - Test
7 - 1 - Hallo
80 - 2 - Uhu
908 - 1 - Katze
7 - 2 - Hund
80 - 3 - Fisch

Nun ist mein Problem, dass ich nicht weiss, wie ich die Kategorie ID automatisch um eins hochzählen lasse bei jeden neuen Eintrag mit der selben Userid. Autoincrement ist mir ein Begriff, aber so wie ich es bisher hinbekommen habe, zählt er einfach hoch unabhängid der der Userid, also:

Userid - Kategorie ID - Kategorie Name
80 - 1 - Test
7 - 2 - Hallo
80 - 3 - Uhu
908 - 4 - Katze
7 - 5 - Hund
80 - 6 - Fisch

Was ich aber nicht möchte.

Jemand eine Idee, wie ich das machen könnte?
Danke.

ciao,
Victor

[Vinzenz Mai]

Hallo

Userid - Kategorie ID - Kategorie Name
80 - 1 - Test
7 - 1 - Hallo
80 - 2 - Uhu
908 - 1 - Katze
7 - 2 - Hund
80 - 3 - Fisch

Nun ist mein Problem, dass ich nicht weiss, wie ich die Kategorie ID automatisch um eins hochzählen lasse bei jeden neuen Eintrag mit der selben Userid.

Jemand eine Idee, wie ich das machen könnte?

Verzichte auf die KategorieID. Versehe jeden Eintrag mit einem Zeitstempel. So kannst Du jederzeit die gewünschte Sortierung abfragen. Berechnete "ID-Werte" für die Kategorie kannst Du über Benutzervariablen erhalten, siehe z.B. dieses Archivposting.

Damit erledigst Du in einem Aufwasch die Problematik:
Wie reorganisiere ich die "ID-Werte", wenn ein Datensatz gelöscht wird.

Freundliche Grüße

Vinzenz

[josh]

Hallo,

Gibt einen bestimmten Hintergedanken, dass für den Benutzer die Kategorien mit einer bestimmten ID versehen werden müssen, die pro Benutzer eindeutig und fortlaufend ist? Ich wüsste nicht, welchen Vorteil das hat. Schliesslich sind die Kategorien aus der Sicht des Benutzereintrags gleichwertig.

Vorschlag: Packe alle Kategorien in eine extra Tabelle des Aufbaus id, name. Bei den Benutzern gibt es dann eine Zuordnung benutzer.id -> kategorie.id, evtl. mehrmals pro Benutzer. Schön relational.

Gruß

[Victor]

Hi,

Hallo,

Gibt einen bestimmten Hintergedanken, dass für den Benutzer die Kategorien mit einer bestimmten ID versehen werden müssen, die pro Benutzer eindeutig und fortlaufend ist? Ich wüsste nicht, welchen Vorteil das hat. Schliesslich sind die Kategorien aus der Sicht des Benutzereintrags gleichwertig.

Vorschlag: Packe alle Kategorien in eine extra Tabelle des Aufbaus id, name. Bei den Benutzern gibt es dann eine Zuordnung benutzer.id -> kategorie.id, evtl. mehrmals pro Benutzer. Schön relational.

Gruß

also meine Idee war ..

Tabelle 1
UserId - KategorieId - Vorname - Nachname - Timestamp
Tabelle 2
UserId - KategorieId - Kategoriename

Jeder User soll nur die Kategorien zur Verfügung haben, die er auch selber angelegt hat (also nicht alle vorhandenen).

Wenn ich nun die Idee von dir aufgreife würde das ja so aussehen ...

Tabelle 1
UserId - Vorname - Nachname - Timestamp
Tabelle 2
UserId - Kategoriename

Richtig?
Hm, stimmt eigentlich. Warum wollte ich denn eine ID?

ciao,
Victor

[josh]

Hallo,

Gut, dann habe ich etwas falsch verstanden. Ich dachte, die User sollen in bestimmte Kategorien eingeteilt werden (so etwa wie Moderator, Autor, Standardbenutzer etc.).

In diesem Fall könnte man es so machen:

Tabelle 1 (Benutzer):
so wie von dir angegeben

Tabelle 2 (Kategorien):
ID(Autoincr.) - UserID - Kategoriename
^--- Hiermit hast du deine ID für die Kategorie. Sie ist eindeutig, aber da sie nur zum Referenzieren genutzt wird/werden kann, ist das egal.

So eine ID kann immer nützlich sein, zum Beispiel, wenn man über HTML-Formulare auf die Daten zugreifen will.

Gruß

[Victor]

Hi,

In diesem Fall könnte man es so machen:

Tabelle 1 (Benutzer):
so wie von dir angegeben

Tabelle 2 (Kategorien):
ID(Autoincr.) - UserID - Kategoriename
^--- Hiermit hast du deine ID für die Kategorie. Sie ist eindeutig, aber da sie nur zum Referenzieren genutzt wird/werden kann, ist das egal.

»»

ist schon spät ... aber mir ist wieder eingefallen, dass ich ja auf jeden Fall eine  Kategorie ID brauch, da ich ja in Tabelle 1 wissen muss welcher Eintrag zu welcher Kategorie gehört.

Also nochmal kurz zum rekapitulieren ...
Tabelle 1
UserId - KategorieId - Vorname - Nachname - Timestamp
Tabelle 2
KategorieId (Autoincr.) - UserId -  Kategoriename

Quasi, das was du gesagt hast. Danke für die Hilfe.

ciao,
victor

[josh]

Hallo,

Also nochmal kurz zum rekapitulieren ...
Tabelle 1
UserId - KategorieId - Vorname - Nachname - Timestamp
Tabelle 2
KategorieId (Autoincr.) - UserId -  Kategoriename

Ich muss noch mal kurz nerven ;-) aber mir bleibt der Sinn dahinter verborgen, warum beide Tabellen die Spalten UserId und KategorieId besitzen. Die stehen doch in einer Beziehung zueinander? Bei deinen Angaben kann jeder Benutzer nur eine Kategorie haben.

Naja, vielleicht ist es wirklich schon spät.

Gruß

[Victor]

Hi,

Hallo,

Also nochmal kurz zum rekapitulieren ...
Tabelle 1
UserId - KategorieId - Vorname - Nachname - Timestamp
Tabelle 2
KategorieId (Autoincr.) - UserId -  Kategoriename

Ich muss noch mal kurz nerven ;-) aber mir bleibt der Sinn dahinter verborgen, warum beide Tabellen die Spalten UserId und KategorieId besitzen. Die stehen doch in einer Beziehung zueinander? Bei deinen Angaben kann jeder Benutzer nur eine Kategorie haben.

wenn ich nun folgende Daten habe ...
Tabelle 1
laufende Nummer - UserId - KategorieId - Vorname - Nachname - Timestamp
1 - 1 - 1 - hans - mueller - 123123213
2 - 1 - 1 - horst - mueller - 121231312
3 - 2 - 1 - huhu - haha - 1231231231
4 - 3 - 1 - hihi - hoho - 1213213
5 - 1 - 2 - huhu - jojo - 12321321

Oh, mir fällt auf, dass ich vergessen habe zu erwähnen, dass es mehrere Namen in Tabelle 1 zur Uid gibt.

Idee dahinter ist folgende ...
Ich hab einen unique user in einer anderen Tabelle:
Usertabelle
UID - Vorname - Nachname
0 - x - x
1 - y - z
2 - x - v

Der User mit der UID hat nun in Tabelle 1 alle seine Bekannten, Freunde, Kollege (Kategorien) gespeichert.

Und in Tabelle 2 sollten nun die Kategorien verwaltet werden:
Tabelle 2
KategorieId (Autoincr.) - UserId -  Kategoriename
0 - 0 - Kollege
1 - 0 - Freunde
2 - 1 - Kollege
3 - 0 - Nachbarn
4 - 3 - Freunde

Ich hoffe so ist einigermassen verständlich was ich will und ich hoffe, dass ich nicht mit der Kirche um Dorf renn ;)

ciao,
victor

[josh]

Hallo,

Ich hoffe so ist einigermassen verständlich was ich will und ich hoffe, dass ich nicht mit der Kirche um Dorf renn ;)

Jetzt ist es klar :-)

So ist das in Ordnung.

Gruß

[Ilja]

yo,

So ist das in Ordnung.

bedinkt....welch ein schönes wort.

zum einen muss ich erst mal wieder päbstlicher sein, als der pabst. im kontext von rdbms ist eine "relation" eine tabelle und keine beziehung, wie du in einem beitrag weiter oben es falsch bezeichnet hast. eine beziehung ist relationship. (relation <> relationship)

und zum anderen ist die frage, wie ich die abhängikeiten modellieren will. ich versuche mal ein ER-Modell mit worten zu beschreiben. es gibt drei entitäten:

• user
• friend (dort sind die freunde, bekannte, etc. mir viel gerade kein besserer name ein)
• category

user steht mit der entiät category in einer 1:n beziehung, sprich jede kategorie gehört genau zu einem benutzer, und jeder benutzer kann mehrere kategorien haben. das ist der einfache teil.

nun zu dem schwierigen teil, was die entität friend betrifft. die kann ich so wie ihr es gemacht hab, mit beiden anderen entitäten in beziehung setzen. das würde ich aber nur machen, wenn es den auch freunde und verwandte geben kann, die -> keine <- kategorie haben können, also unabhängig von der kategorie sein können.

ist dies aber nicht der fall, dann würde ich es so modellieren, dass die tabelle(entität) friend nur in beziehung mit der tabelle category steht, sprich ein freund hat immer genau eine kategorie und eine kategorie kann mehrere freunde haben, also auch hier wieder eine 1:n beziehung.

damit wird dann auch das problem mit dem hochzählen klarer, warum es eigentlich gar kein problem ist. es gibt nämlich immer zuerst die kategorie in der tabelle category folglich auch dort immer einen eindeutigen schlüssel (id).

modelliert man es so wie ihr und hat der neue freund, den du anlegen willst, eine kategorie, dann muss zwangsweise zuerst auch die kategorie mit seiner id vorhanden sein. ergo muss man gar nicht erst abhängig von dem user irgendwelche werte hochzählen...

Ilja

[josh]

Hallo,

zum einen muss ich erst mal wieder päbstlicher sein, als der pabst.

Welcher denn? ;-)

im kontext von rdbms ist eine "relation" eine tabelle und keine beziehung, wie du in einem beitrag weiter oben es falsch bezeichnet hast. eine beziehung ist relationship. (relation <> relationship)

Danke für den Hinweis, war mir nicht bewusst!

user steht mit der entiät category in einer 1:n beziehung, sprich jede kategorie gehört genau zu einem benutzer, und jeder benutzer kann mehrere kategorien haben. das ist der einfache teil.

Jo, das ist klar.

ist dies aber nicht der fall, dann würde ich es so modellieren, dass die tabelle(entität) friend nur in beziehung mit der tabelle category steht, sprich ein freund hat immer genau eine kategorie und eine kategorie kann mehrere freunde haben, also auch hier wieder eine 1:n beziehung.

Das verstehe ich so, dass es keine _direkte_ Beziehung von Freund zu Benutzer geben soll, weil eben jeder Freund eine Kategorie hat, und diese wieder zu einem Benutzer gehört. Ansonsten wären redundante Daten vorhanden.

modelliert man es so wie ihr und hat der neue freund, den du anlegen willst, eine kategorie, dann muss zwangsweise zuerst auch die kategorie mit seiner id vorhanden sein. ergo muss man gar nicht erst abhängig von dem user irgendwelche werte hochzählen...

Bevor ich davon wusste, dass es auch Freunde (und nicht nur Kategorien und Benutzer) gibt, habe ich auch einen entsprechenden Vorschlag gemacht. Allerdings bekam ich diesen Antwortpost, der mich etwas verunsichert hat. Vielleicht sollte der OP noch mal erklären, was er damit gemeint hat.

Gruß

[Tom]

Hello,

In diesem Fall könnte man es so machen:

Tabelle 1 (Benutzer):
so wie von dir angegeben

Tabelle 2 (Kategorien):
ID(Autoincr.) - UserID - Kategoriename
^--- Hiermit hast du deine ID für die Kategorie. Sie ist eindeutig, aber da sie nur zum Referenzieren genutzt wird/werden kann, ist das egal.

Das ist aber immer noch falsch, wenn die Zuordnung ID_Kategorie und Kategoriename immer gleich sein soll. Dann benötigt man ohnehin drei Tabellen für die Zusammenhänge.

id_kat     (Auto)
   katname

id_user    (Auto)
   username

id_kat     Fremdschlüssel  |  zusammen mit Unique belegen
   id_user    Fremdschlüssel  |

Es ist eine klassische m:n Beziehung.

Ein harzliches Glückauf

Tom vom Berg

[Ilja]

yo,

Es ist eine klassische m:n Beziehung.

das mag so auf den ersten blick den anschein haben, ist es aber in diesem speziellen fall von ihm nicht. modellierung ist eine trickreiche sache und hier kann man leicht in eine falle tappen.

die kategorien "gehören" den usern und sind somit von ihnen abhängig. stell dir vor, zwei user würden über deine beziehungstabelle auf die gleiche kategorie verweisen. wer ist den dann der besitzer dieser kategorie oder noch viel anschaulicher, ändert der eine den namen seiner katerogie, dann würde sich ja der name für den anderen user automatisch mit ändern. und wenn ich ihn richtig verstanden habe, so sollte genau das nicht passieren.

Ilja

[Tom]

Hello,

die kategorien "gehören" den usern und sind somit von ihnen abhängig. stell dir vor, zwei user würden über deine beziehungstabelle auf die gleiche kategorie verweisen. wer ist den dann der besitzer dieser kategorie oder noch viel anschaulicher, ändert der eine den namen seiner katerogie, dann würde sich ja der name für den anderen user automatisch mit ändern. und wenn ich ihn richtig verstanden habe, so sollte genau das nicht passieren.

Das kann man dann ja wieder zusätzlich vermerken.
Deshalb kann die Kategorie, deren Identität dann ja aus der Paarung "user(id) - katname" besteht, doch trotzdem eine eineindeutige Kennung bekommen.

Es hat dann nur nicht jeder User einen eigenen geschlossenen Nummernkreis für seine Kategorien.

Ich halte das System so auch für krank, da die User keine gemeinsamen Kategorien haben können. Da fehlt also noch eine Stufe.

Ein harzliches Glückauf

Tom vom Berg

[Ilja]

yo,

Ich halte das System so auch für krank, da die User keine gemeinsamen Kategorien haben können. Da fehlt also noch eine Stufe.

hmm, ich halte da wenig für krank, zwischen usern und den kategeorien gibt es eine 1:n beziehung. es soll ja gerade vermieden werden, dass sie gleiche kategorien gekommen, selbst wenn der name der kategorie gleich gewählt ist.

wenn es um daten-design geht, sage ich meinen kollegen von der entwicklung immer, nicht alles was gleich aussieht, das ist auch gleich. eine gute prüfung, ob ein design gut geht sind die drei anomalien. und keine davon würden auftreten.

anders sieht der fall aus, wenn die jeweiligen kategorien nicht an den user gebunden sind, sondern für sich existieren können, sprich es gibt auch ohne user bestimmte kategorien, die man dann als user sich zuteilen kann. dann würde man es als eine von dir angesprochene n:m beziehung modellieren.

Ilja

[Tom]

Hello,

anders sieht der fall aus, wenn die jeweiligen kategorien nicht an den user gebunden sind, sondern für sich existieren können, sprich es gibt auch ohne user bestimmte kategorien, die man dann als user sich zuteilen kann. dann würde man es als eine von dir angesprochene n:m beziehung modellieren.

Dann scheitern wir hier also gerade an der Unkenntnis über die tatsächlichen Randbedingungen.
Schade eigentlich, denn man könnte sowas ja auch mal von Anfang an richtig machen. Spätere Korrekturen sind oft mit enormem Kraftaufwand verbunden.

Ein harzliches Glückauf

Tom vom Berg