[php] Id colom of niet?

[Verwijderd]

Hallo,

Ik zit me af te vragen of het echt nodig is om een aparte ID kolom te maken in een tabel die bij voorbeeld een lijst van gebruikers bevat in een MYSQL database.
Is het niet mogelijk om de combinatie van twee kolommen als unieke ID te gebruiken.
Wat zijn de voors en na's van een ID kolom, en wat zijn deze voor het combineren van twee kolommen om een unieke waarde te verkrijgen?

[Cobalt]

De primary key mag natuurlijk van alles zijn. Het is belangrijk om te zorgen dat deze waarde zo klein mogelijk is en snel te vergelijken zodat zoek acties snel resultaat opleveren.

Zoeken op basis van nummers gaat sneller, dan zoeken op basis van tekst.
Het is natuurlijk mogelijk om twee kolommen als unieke ID te gebruiken, maar het kost extra moeite om die combinatie te maken en te indexeren. Een ID zal niet meer geheugen gebruiken dan twee kolommen als unieke ID. Natuurlijk zal rekening moeten houden met het aantal rijen dat in het tabel zal worden opgeslagen, voor de keuze van je datatype voor ID, vaak is een int al voldoende.

[ Voor 81% gewijzigd door Cobalt op 19-06-2009 17:56 ]

[RobIII]

Dit is niet in 2 zinnen uit te leggen, maar je hebt synthetische keys en natural keys waarbij een gebruikersnaam een natural key zou kunnen zijn; die is immers uniek. Of het altijd handig is is een tweede.

Een key op basis van meer dan 1 veld kan ook; dan heb je een compound key en kan in bepaalde gevallen ook van toepassing zijn. Wederom is het teveel om zo even 1,2,3 uit te leggen maar als je je wat verdiept in de materie en wat feeling hebt/krijgt met DB's kom je er vanzelf achter.

offtopic:
Ik ben onlangs een project tegen gekomen met een tabel met daarin een compound key van 13(!!!!!) velden. Die zal zéér waarschijnlijk binnenkort op thedailywtf.com staan En worse; het was een clustered compound key waarbij de gegevens niet-sequentieel waren

Cobalt schreef op vrijdag 19 juni 2009 @ 17:21:
Zoeken op basis van nummers gaat sneller, dan zoeken op basis van tekst.

Dat is wel heel kort door de bocht. Een getal is niets anders dan een stapel bits. Wat denk je dat een tekst is?

Cobalt schreef op vrijdag 19 juni 2009 @ 17:21:
Het is natuurlijk mogelijk om twee kolommen als unieke ID te gebruiken, maar het kost extra moeite om die combinatie te maken en te indexeren.

Microoptimalisaties... Daarbij kan een compound key soms niet anders en vind ik het zwaar onzin om op basis van deze uitspraak niet te kiezen voor een compound key.

Cobalt schreef op vrijdag 19 juni 2009 @ 17:21:
Een ID zal niet meer geheugen gebruiken dan twee kolommen als unieke ID.

Dus een synthetische key hangen aan een toch-al-unieke combinatie van 2 andere keys heeft jouw voorkeur?

[ Voor 45% gewijzigd door RobIII op 19-06-2009 17:40 ]

[TeasingU]

Wanneer je bijvoorbeeld in een webapplicatie gebruik wilt maken van gebruikersaccounts, dan is het gebruik van id's en sommige gevallen veiliger. Je hoeft dan bijvoorbeeld in een sessie niet de gebruikersnaam maar alleen het id op te slaan. Een id zegt minder over een bepaald account dan de gebruikersnaam.

Uiteraard zal dit bovenstaande niet in alle gevallen opgaan.

[RobIII]

TeasingU schreef op vrijdag 19 juni 2009 @ 17:36:
Je hoeft dan bijvoorbeeld in een sessie niet de gebruikersnaam maar alleen het id op te slaan. Een id zegt minder over een bepaald account dan de gebruikersnaam.

Wat boeit dat in een sessie die toch server-side is en waar niemand iets van ziet? En ID 43400 identificeert mij net zo goed/veel als RobIII. What's the difference?

[ Voor 7% gewijzigd door RobIII op 19-06-2009 17:38 ]

[TeasingU]

RobIII schreef op vrijdag 19 juni 2009 @ 17:38:
[...]

Wat boeit dat in een sessie die toch server-side is en waar niemand iets van ziet? En ID 43400 identificeert mij net zo goed/veel als RobIII. What's the difference?

Hoi RobIII,
Mijn gedachte erbij is dat wanneer in het geval je sessie gestolen wordt, je username bekend is en enkel alleen nog het wachtwoord geraden hoeft te worden. Met een id kom je in dat geval niet verder. Maar zoals jij al aangeeft maakt dat niet uit bij een server-side applicatie waar niemand iets van ziet.

[RobIII]

TeasingU schreef op vrijdag 19 juni 2009 @ 17:43:
Hoi RobIII,
Mijn gedachte erbij is dat wanneer in het geval je sessie gestolen wordt, je username bekend is en enkel alleen nog het wachtwoord geraden hoeft te worden. Met een id kom je in dat geval niet verder.

Security By Obscurity
Daarbij: als de sessie gestolen wordt heb je niet eens meer een wachtwoord nodig; je bent voor het systeem dan namelijk al gewoon "ingelogd" en niet te onderscheiden van de originele eigenaar van die sessies (tenzij je sessie aan IP's e.d. koppelt, zoals dat op T.net bijv. mogelijk is).

TeasingU schreef op vrijdag 19 juni 2009 @ 17:43:
Maar zoals jij al aangeeft maakt dat niet uit bij een server-side applicatie waar niemand iets van ziet.

Een sessie-var is altijd server-side Enkel het sessie-id gaat naar de client.

[ Voor 16% gewijzigd door RobIII op 19-06-2009 17:46 ]

[TeasingU]

Ik heb dit weekend even wat leeswerk te doen weer wat geleerd. Thanks.

Ik heb deze manier van werken ooit geleerd via http://phpsecurity.org/ maar dat ga ik maar eens gauw vergeten dan.

[Verwijderd]

Ik ben nu wat aan het schrijven zonder gebruikers naam. Dus alleen voornaam, achternaam (wat naamgeving betreft). Het is ook niet dat ik denk het nodig te hebben, vroeg me alleen af of het mogelijk is en wat de voordelen ervan zijn.
Het lijkt me dat wanneer je met zeer grote hoeveelheden date te maken krijgt het nogal een verschil kan maken wanneer iets een gegeven minder heeft. Niet dat ik ooit aan zulke hoeveelheden data denk te komen hoor
Vroeg het me af omdat ik het hoe en waarom van een database wel iets moois vind

[Gomez12]

Verwijderd schreef op vrijdag 19 juni 2009 @ 19:10:
Ik ben nu wat aan het schrijven zonder gebruikers naam. Dus alleen voornaam, achternaam (wat naamgeving betreft). Het is ook niet dat ik denk het nodig te hebben, vroeg me alleen af of het mogelijk is en wat de voordelen ervan zijn.
Het lijkt me dat wanneer je met zeer grote hoeveelheden date te maken krijgt het nogal een verschil kan maken wanneer iets een gegeven minder heeft. Niet dat ik ooit aan zulke hoeveelheden data denk te komen hoor
Vroeg het me af omdat ik het hoe en waarom van een database wel iets moois vind

Tja, heel simpel gezegd is een id kolom niet nodig.

Maar als de andere kant is een voornaam + achternaam, dan zou ik toch kiezen voor een id-kolom.

In principe maakt het doorzoeken van iets niet echt uit meer met de huidige computers, maar tussen een integer waarde en 2 gecombineerde string waardes zit een wereld van verschil in snelheid.

Plus, een id is altijd uniek ( zolang je er maar geen belang aan hecht ) terwijl een voornaam en een achternaam niet altijd uniek is, nog wel eens wil wijzigen ( trouwen / scheiden etc ) en het kost ook nog eens meer opslagruimte.

Je kan het zonder id-kolom ( en met voornaam achternaam ) doen, maar dan neem je een performance hit, extra opslagruimte en een ramp bij een naamsverandering ( keys wil je niet veranderen over het algemeen ) mee.

[Noork]

Gomez12 schreef op vrijdag 19 juni 2009 @ 19:27:
Maar als de andere kant is een voornaam + achternaam, dan zou ik toch kiezen voor een id-kolom.

Idd, ik denk dat het nog vies tegenvalt hoeveel "Jan de Groot's" en "Piet de Boer's" er rondlopen

[GarBaGe]

Er bestaat in de database altijd een 2-strijd tussen mensen die graag zoveel mogelijk "natural keys" willen gebruiken en mensen die alleen synthetische keys willen gebruiken.
Mijn voorkeur gaat uit naar de synthetische (dus alles MET een"ID" kolom), omdat ik te vaak heb meegemaakt dat een keuze voor "natural keys" na verloop van tijd niet meer uniek waren vanwege gewijzigd gebruik van de applicatie. Dit vereist dan ineens een relatief grondige wijziging in de applicatie.

[T-MOB]

Het verschil wordt vooral boeiend als je iets met je gebruikers gaat doen. Als gebruikers bijvoobeeld berichten mogen posten dan zul je moeten bijhouden welke gebruiker welk bericht heeft geplaatst. Een synthetische key levert dan het voordeel op dat je minder ruimte gebruikt. Een nummer van (bijv) 16bits kost aanzienlijk minder ruimte dan een username.
Daarnaast levert een synthetische key nog het voordeel dat je "goedkoop" wijzigingen kunt doen. Bij het wijzigen van de gebruikersnaam hoef je niet alle berichten te updaten met de gewijzigde naam. De koppeling is immers gelegd met de synthetische key.

[Verwijderd]

Duidelijk Bedankt allemaal voor de reacties