Ik heb een html formulier waar namen worden gekozen vanuit een listbox, daar wordt een array van gemaakt en daarna wordt er met een foreach lus een positienummer aan gehangen.
Het werkt alleen helaas niet voor mensen met een spatie in hun naam. Ik heb dmv een echo gekeken waar het mis gaat en ik zie dat spaties worden vervangen door underscores.
Het probleem is alleen dat ik niet weet waar dit gebeurd en hoe ik dit kan voorkomen. Heeft iemand hier ervaring mee?
Ik kan de underscores niet later weer vervangen voor spaties want er zijn ook mensen met een underscore in hun naam die wel moeten blijven staan.
Ik heb uit eindelijk me database aangepast en in de tweede tabel worden nu de userid's geplaatst en aan de hand daar van lees ik weer de gebruikersnamen uit.
De primary key zou beter gebaseerd kunnen zijn op de inhoud van het record, datgene wat dat record "uniek" maakt, iets als de volledige naam en het adres (precies wat artsen ook doen met je naam en geboortedatum).
Weet je zeker dat artsen dat op die manier doen? Ik vermoed dat artsen je BSN-nummer gebruiken. Dát nummer is namelijk echt uniek. Wat als er op één adres 2 personen genaamd "Jan Jansen" wonen? Een vader en zoon?
Voor een "normale" website (dus niet een overheidsinstantie) is volgens mij het enige wat je uniek kunt laten zijn iemands e-mailadres. Dat is de enige factor die uniek is. Mensen kunnen immers dezelfde naam hebben, op hetzelfde adres wonen en op dezelfde dag geboren zijn. Dat zijn allemaal factoren die niet uniek zijn. Oké, dan blijft het e-mailadres over. Dan zou je dus in alle (koppel)tabellen een verwijzing moeten maken naar iemands e-mailadres. Maar ... wat nu als iemand zijn/haar e-mailadres wijzigt? Dan heb je een behoorlijk probleem lijkt me. Dan zou je alle tabellen af moeten gaan en dat e-mailadres wijzigen. Lijkt me een no-go. Als je het zo allemaal bij elkaar beschouwt, blijft er dan maar 1 conclusie over en dat is dat je wél een ID gebruikt ... maar dat die ID binnen jouw systeem als persoonsgebonden data fungeert, net als een BSN-nummer. Dus Pietje heeft binnen jouw website altijd het ID (of klantnummer) 132. Het getal 132 is zijn persoonskenmerk geworden.
Ik heb uit eindelijk me database aangepast en in de tweede tabel worden nu de userid's geplaatst en aan de hand daar van lees ik weer de gebruikersnamen uit.
Bedankt.
Er komt nu alleen een extra SELECT bij.
Je kunt dit ook in één query doen. Kijk eens naar de mogelijkheden van JOIN :)
Zodra je je id's voor iets anders dan de interne (database) nummering gaat gebruiken zou je sowieso al kunnen stellen dat er iets mis is.
Absoluut, en dan is de volgende vraag: is een dropdown op het scherm van een browser nog "de interne nummering?" of zou je kunnen stellen dat je dan ook al met een exterm systeem te maken hebt, gegevan dat de browser door de gebruiker kan worden gemanipuleerd... Maar, dat wordt filosofisch. Het punt is wel helder denk ik.
Ik vermoed dat artsen je BSN-nummer gebruiken.
Intern maakt het BSN natuurlijk vast wel onderdeel uit van het dossier, omdat andere instanties er ook mee werken, maar in de dagelijkse gang van zaken hebben ze het altijd over "Meneer van Puffelen uit 1940, geboren te Amsterdam". Dat zijn gegevens die vrijwel iedereen over zichzelf weet en ook paraat heeft in momenten van stress, zoals bij een ziekenhuisbezoek. Een BSN staat op een pasje dat vooral ouderen nogal eens vergeten.
Vergelijkbaar met de reden waarom je bij veel websites aanlogt met je email, in plaats van het klantnummer; je email weet je altijd, het klantnr dat een winkel aan je heeft uitgedeeld... geen idee...
Mensen kunnen immers dezelfde naam hebben, op hetzelfde adres wonen en op dezelfde dag geboren zijn.
Het kan, theoretisch, net zoals een UUID theoretisch niet uniek is. Maar zelfs in Amsterdam worden maar dertig babies per dag geboren, waarvan de helf man en de helft vrouw, dus 15 babies die mogelijk verward kunnen worden in Amsterdam. Er zijn zo'n 320.000 verschillende achternamen, 300.000 voornamen (per geslacht) en veel babies krijgen meer dan één voornaam. Dus laten we zeggen 15 keer kiezen uit 320.000x300.000x300.000 voor "Pietje P van Puffelen geboren Amsterdam 2010-01-01" Dat is een pakkans van 1 op 13.8 Triljard (1.38x10^15) En die twee moeten dan ook samen gaan wonen op hetzelfde adres...
Dan zou je alle tabellen af moeten gaan en dat e-mailadres wijzigen
Als je van het email adres de PK maakt dan doet de database dat zelf, via de ON UPDATE CASCADE instelling op de foreign key.
Het getal 132 is zijn persoonskenmerk geworden.
Dan moet je het ook alszodanig opslaan, dus niet in een auto_increment kolom 'id' maar in gewone int kolom 'klant_nr' met een not-null en een unique constraint. Alleen dan kun je garanderen dat je de database er nooit zelf een waarde voor zal verzinnen, wat voor fout je ook maakt.
@war: Humor, maar zo mogelijk nog minder waarschijnlijk; de kans dat twee mensen op dezelfde dag geboren zijn, op hetzelfde adres wonen en op twee letters na dezelfde naam hebben.
Maar alles bij elkaar heeft de TS nog steeds het probleem dat er underscores verschijnen op een plek waar dat niet verwacht wordt. Het id is alleen maar een workaround omdat id's geen spaties bevatten. Vindt niemand het belangrijk dat zijn data op onverklaarde wijze wordt aangepast? Ik zou dat tot op de boden uitzoeken, wie weet wat voor dingen er nog meer met de data gedaan worden.
Maar alles bij elkaar heeft de TS nog steeds het probleem dat er underscores verschijnen op een plek waar dat niet verwacht wordt. Het id is alleen maar een workaround omdat id's geen spaties bevatten. Vindt niemand het belangrijk dat zijn data op onverklaarde wijze wordt aangepast? Ik zou dat tot op de boden uitzoeken, wie weet wat voor dingen er nog meer met de data gedaan worden.
Niks is onverklaarbaar tijdens programmeren. Het gaat hier om een beginnend PHP-er.
Zeer waarschijnlijk zal dit ergens in het script opgenomen zijn, zonder dat hij er zelf van af weet.
Tevens is er hier geen enkel voorbeeld gepost en zo te zien is topic starter al een stuk verder gekomen met de aangegeven tips.
Er zullen heus situaties zijn waarin id's niet altijd de beste optie zijn.
Voor nu blijkt dat het dus prima werkt in deze situatie.
Waarom dan alsnog een hele discussie voeren over het wel/niet gebruik er van?
Tevens is er hier geen enkel voorbeeld gepost en zo te zien is topic starter al een stuk verder gekomen met de aangegeven tips.
Ja, hij heeft op jullie advies gewoon het probleem genegeerd en is een waarde gaan doorgeven die niet wordt aangepast door de bug. Het is een kwestie van tijd tot hij exact hetzelfde probleem krijgt met een waarde die niet vervangen kan worden door een id, en daar komt hij waarschijnlijk pas achter als de helft van zijn data corrupt is. Goed plan hoor!
Deze laksheid is dus wat ik in een eerder topic bedoelde met "de warme douche van de PHP wereld", het hele idee dat je willens en wetens een bug negeert door een oplossing aan te dragen die volstrekt overbodig is en alleen werkt omdat hij ongevoelig is voor de bug en dan nog beweert dat de poster beter af is is zo... zo PHP...
Maargoed, ik hou het hier weer voor gezien, ik trek deze mentaliteit gewoon niet.
" En die twee moeten dan ook samen gaan wonen op hetzelfde adres..."
Zomaar een idee, dat het in het geval van zelfde geboortedatum + zelfde achternaam + zelfde adres
best eens om tweelingen kan gaan.
En ik heb recent nog een gevalletje gezien waarbij de ouders ze een gelijkende voornaam met dezelfde voorletter gaven. Lekker over nagedacht...
Dat hebben wij bewust voor alle kinderen vermeden (geen meerlingen).
