Toon posts:

[PHP/MYSQL] Primary key op 2 velden, combi's uniek

Pagina: 1
Acties:

Verwijderd

Topicstarter
Wat ik dus eigenlijk wil hebben is dat ik twee velden in een tabel heb zetten waarvan de combinatie van die twee getallen uniek is.

bijvoorbeeld:
als 1 - 6 er al in zit mag 6 - 1 er niet meer in, moet ik dat gewoon met php afvangen of zit er een mogelijkheid in dat dat met mysql zelf kan?

  • Glimi
  • Registratie: Augustus 2000
  • Niet online

Glimi

Designer Drugs

(overleden)
Geeft eens wat van je model, want dat klopt vast voor geen kant als je zulke constructies nodig hebt
[edit]Ik kan het me iig niet voorstellen

Verwijderd

Topicstarter
haha, nee ik heb niet echt een model opgesteld (weet dat het verkeerd is maar het moet een beetje snel af)

het is de bedoeling dat mensen elkaar berichten kunnen sturen, maar dan iedere keer maar 1, dus het oude bericht van de 1 naar de ander overschrijft het vorige bericht.

tabel dacht ik zo ongeveer:
id1 id2 bericht1naar2 bericht2naar1

met andere fieldnames dan hè...

maar als ik ook id2 id1 erin zet staan de berichten er ook dubbel in en das natuurlijk onnodig, misschien dat ik gewoon even heel erg dom aant denken ben hoor...

  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
topicstarter: d8 niet dat dat in mysql kon....., wel in postgre volgensmij

glimi: stel je voor een voor- en een achternaam. Voornaam mag wel 2x voorkomen, achternaam ook wel, maar combinatie niet....

Verwijderd

Topicstarter
Op maandag 10 juni 2002 20:56 schreef /dev/null het volgende:
topicstarter: d8 niet dat dat in mysql kon....., wel in postgre volgensmij

glimi: stel je voor een voor- en een achternaam. Voornaam mag wel 2x voorkomen, achternaam ook wel, maar combinatie niet....
yep, zoiets ja, alleen als iemand dan zijn achternaam als voornaam invuld en andersom mag ook niet....

  • whoami
  • Registratie: December 2000
  • Laatst online: 16:04
Dat is idd zeer vreemd.

Dat je geen datamodel hebt gemaakt omdat het snel af moet zijn, vind ik maar een flauw excuus. Het kan nu misschien wel snel af zijn, maar in de toekomst zullen de problemen zich opstapelen, en dan ben je ver van huis.

https://fgheysels.github.io/


  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

In postgres/etc kan je dat middels triggers opvangen.
In mysql gaat dat idd niet lukken.

Je zou je inserts zo op kunnen bouwen dat _altijd_ de combinatie 'laagste id, hoogste id' wordt geinsert waardoor je primary key netjes een error afdwingt als je die 2e probeert in te voegen.

  • Glimi
  • Registratie: Augustus 2000
  • Niet online

Glimi

Designer Drugs

(overleden)
Op maandag 10 juni 2002 20:56 schreef /dev/null het volgende:
topicstarter: d8 niet dat dat in mysql kon....., wel in postgre volgensmij

glimi: stel je voor een voor- en een achternaam. Voornaam mag wel 2x voorkomen, achternaam ook wel, maar combinatie niet....
Dat zou een primary key of UNIQUE zijn op beide, da's totaal wat anders omdat in dat geval voornaam-achternaam niet achternaam-voornaam zou moeten matchen!

Verwijderd

Topicstarter
Op maandag 10 juni 2002 20:58 schreef ACM het volgende:
...
Je zou je inserts zo op kunnen bouwen dat _altijd_ de combinatie 'laagste id, hoogste id' wordt geinsert waardoor je primary key netjes een error afdwingt als je die 2e probeert in te voegen.
maar dan is dus niet meer te zien van wie naar wie het berichtje is...

edit:

heb het al opgelost denk ik... ik laat de combinaties wel gewoon allebei toe, maar dan zet ik gewoon maar 1 bericht in een entry, dus bijvoorbeeld:

id1 id2 bericht
id2 id1 bericht

en das dus bericht heen en terug...

toch bedankt iig ennuh, volgende keer maak ik écht eerst een datamodel, dit schiet niet op...

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Op maandag 10 juni 2002 20:59 schreef zellufs het volgende:
maar dan is dus niet meer te zien van wie naar wie het berichtje is...
Je kan niet alles hebben :P

Je zou nog een 'direction' kunnen maken, maar dat is nog veel enger.

Stel eerst voor jezelf de eisen op.
Maakt het ook maar iets uit dat die berichten er op de 6 - 1 manier inkomen?
Etc.

Verwijderd

Topicstarter
Zie mijn edit, sorry for asking ben ook een beetje moe enzo, zo maar eens slapen, gooi deze maar snel dicht :D

  • drm
  • Registratie: Februari 2001
  • Laatst online: 09-06-2025

drm

f0pc0dert

zellufs:
dan zet ik gewoon maar 1 bericht in een entry, dus bijvoorbeeld:

id1 id2 bericht
id2 id1 bericht

en das dus bericht heen en terug...

toch bedankt iig ennuh, volgende keer maak ik écht eerst een datamodel, dit schiet niet op...
Nou heb je uiteindelijk toch nog een goed datamodel ;) :D

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz


Verwijderd

Topicstarter
Ja, maar nu heb ik moeilijkere query's.

Ik wil bijvoorbeeld de berichtjes heen en weer groeperen EN de uitgaande en inkomende berichtjes die nog geen reply hebben daar weer onder. Maar de onderste berichtjes staan er dan dubbel in.

voorbeeld:

id1 id2 bericht1
id2 id1 bericht1reply
id1 id3 bericht2
id3 id1 bericht2reply

maar als ik dan de berichtjes wil hebben die nog geen reply hebben weet ik echt even niet hoe ik die query moet gaan maken, waarschijnlijk iets met een join want subselects worden natuurlijk nog niet ondersteund :D

Het zal waarschijnlijk heel erg simpel zijn maar ik heb al 2 dagen een totale blackout op dat gebied...

  • drm
  • Registratie: Februari 2001
  • Laatst online: 09-06-2025

drm

f0pc0dert

id1 en id2 zijn userID's en vormen tegelijkertijd de (compound) primaire sleutel voor het bericht, toch?

Dan zou je een relatie terug kunnen laten lussen naar de tabel zelf, waarin aangegeven wordt op welk bericht het bericht een reactie is.

Je zou er dan voor kunnen kiezen (zou ik waarschijnlijk doen) om de tabel zo in te richten, dat de (userIDfrom en userIDto) primary key een UNIQUE INDEX wordt, en dat je een "gewone" auto_increment primary key ernaast bijhoudt. Dat maakt het met relaties (en dus queries) een stukje eenvoudiger.

Vervolgens krijg je dus ongeveer zo'n tabelstructuur:
code:
1
2
3
4
5
messageID primary key
fromID \_ compound UNIQUE index
toID   /
message
replyID   "Foreign" Key (relatie terug naar messageID)

maar ik heb het flauwe vermoeden dat ik niet helemaal begrijp welke kant je opwilt :X

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz


Verwijderd

Topicstarter
De bedoeling is dus dat ik alle berichten zie die door en naar een gebruiker gestuurd zijn. De berichten die bij elkaar hoor, dus een soort gesprekje vormen, moeten bij elkaar staan en er mogen natuurlijk geen dubbelen in staan.

Mijn tabelstructuur ziet er op dit moment zo uit:
code:
1
2
3
4
5
6
7
8
  id int(8) NOT NULL auto_increment,
  uid int(8) NOT NULL default '0',
  bid int(8) NOT NULL default '0',
  msg varchar(255) NOT NULL default '',
  date datetime NOT NULL default '0000-00-00 00:00:00',
  PRIMARY KEY (id),
  UNIQUE KEY indexid(uid,bid),
  UNIQUE KEY id(id)

  • dusty
  • Registratie: Mei 2000
  • Laatst online: 21-02 00:06

dusty

Celebrate Life!

Op dinsdag 11 juni 2002 10:57 schreef zellufs het volgende:
De bedoeling is dus dat ik alle berichten zie die door en naar een gebruiker gestuurd zijn. De berichten die bij elkaar hoor, dus een soort gesprekje vormen, moeten bij elkaar staan en er mogen natuurlijk geen dubbelen in staan.
Dan klopt je primary sleutel niet.

Persoon 1 stuurt bericht naar Persoon 2.
Persoon 2 stuurt bericht naar Persoon 1.

Daarna mag persoon 1 geen bericht meer sturen naar persoon 2, immers bestaat er al een bericht van persoon 1 naar persoon 2.

Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR


Verwijderd

Topicstarter
Op dinsdag 11 juni 2002 12:04 schreef dusty het volgende:
Persoon 1 stuurt bericht naar Persoon 2.
Persoon 2 stuurt bericht naar Persoon 1.

Daarna mag persoon 1 geen bericht meer sturen naar persoon 2, immers bestaat er al een bericht van persoon 1 naar persoon 2.
Ja dat klopt, daarna moet dat ene bericht worden geupdate...
Pagina: 1