VNC stopt er mee :(
Spatie wordt underscore
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.
Iemand ideeën of bekend hiermee?
Dan zou ik user id bij moeten gaan voegen maar ik heb liever dit probleem getackeld.
Quote:
Ik heb dmv een echo gekeken waar het mis gaat en ik zie dat spaties worden vervangen door underscores.
Gebruik je toevallig een library voor het maken van de listbox?
Je zult sowieso moeten backtracken en met echo moeten kijken op welke plek in het proces de underscore verschijnt; vanaf het moment dat je de data uit de database haalt tot het moment dat je de gesubmitte data verwerkt.
PHP doet het niet vanzelf en HTML al helemala niet, dus ofwel heb je zelf iets gemaakt of je gebruikt een library van derden die niet weet dat spaties gewoon toegestaan zijn.
Quote:
Gebruik user id's.
Dat is een optie maar alleen omdat er geen spaties in getallen zitten, het probleem blijft bestaan en de eerstvolgende keer dat er een spatie moet worden doorgegeven wordt dat gewoon weer een underscore en moet je alsnog zoeken naar de oorzaak.
Pg Vincent op 10/11/2015 12:00:05:
Dat is een optie maar alleen omdat er geen spaties in getallen zitten, het probleem blijft bestaan en de eerstvolgende keer dat er een spatie moet worden doorgegeven wordt dat gewoon weer een underscore en moet je alsnog zoeken naar de oorzaak.
Quote:
Gebruik user id's.
Dat is een optie maar alleen omdat er geen spaties in getallen zitten, het probleem blijft bestaan en de eerstvolgende keer dat er een spatie moet worden doorgegeven wordt dat gewoon weer een underscore en moet je alsnog zoeken naar de oorzaak.
En toch is dit de netste manier om alles te verwerken.
Als het goed is heb je een tabel met user_id, voornaam, achternaam (of iets dergelijks)
Je post vervolgens gewoon alleen het ID. Tijdens het verwerken kun je dan weer voornaam,achternaam ophalen.
Lukt het me niet dan val ik wel terug op userid's die ik uiteraard bij hou.
Als ik zou moeten kiezen tussen een (gebruikers)naam of een intern nummer (die al als DOEL heeft een entiteit uniek te identificeren en waarvan het eigenlijk uitgesloten is dat dit nummer ooit gaat veranderen) dan weet ik wel wat mijn keuze zou zijn.
Te meer omdat namen/nicknames nog wel eens willen veranderen.
Quote:
Dat gaat niet want hij haalt de users op in een tabel en maakt deze aan in een andere tabel en daar worden gegevens geupdate.
Dan zou ik user id bij moeten gaan voegen maar ik heb liever dit probleem getackeld.
Dan zou ik user id bij moeten gaan voegen maar ik heb liever dit probleem getackeld.
Als ik dit zo hoor zou ik nog eens kritisch kijken naar je database-opzet. Er valt iets voor te zeggen om alle tabellen (behalve koppeltabellen wellicht, behalve koppeltabellen waar extra metadata aan zit die je wellicht in afzondering wilt aanspreken) te voorzien van een auto-increment id. Dat werkt vaak gewoon een stuk praktischer.
Wanneer je tabellen aan elkaar knoopt d.m.v. tekstuele kolommen, dat is om meerdere redenenen en slecht idee.
Gewijzigd op 10/11/2015 16:21:55 door Thomas van den Heuvel
Quote:
En toch is dit de netste manier om alles te verwerken.
Het is een makkelijke manier en voor velen ook volkomen vanzelfsprekend want "iedereen doet het zo", maar het verschilt voor de database in geen enkel opzicht van het doorgeven elke willekeurige kolom, zolang de waarden in de tabel uniek zijn.
De database-guru Joe Celko (die een aantal zeerleerzame boeken heeft geschreven) heeft hele epistels gewijd aan de gevaren van zo'n surrogaat primary key en het is verstandig om het kern-argument daarvan altijd in je achterhoofd te houden: het "id" van een record verwijst naar een record, niet naar de data in dat record. 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).
Het id is makkelijk, en in alledaagse toepassingen is er niet echt iets op tegen, maar het is niet "de netste manier".
Dat neemt niet weg dat er andere elementen in je data zitten die een record ook uniek kunnen identificeren, maar dan op voorhand te besluiten dat je dan per definitie geen id nodig hebt/zou hebben is nogal onpraktisch. Ze kunnen best naast elkaar bestaan, en het is een default fallback wanneer er geen combinatie van kolommen is die uniek kan zijn.
Een id is een syntactische oplossing, andere keys zijn meer semantisch van aard.
Wat jij als "netter" beschouwt lijkt mij toch meer een esthetische kwestie.
Quote:
Wat jij als "netter" beschouwt lijkt mij toch meer een esthetische kwestie.
Ja en nee, een id "doet het ook" en het zal in veel gevallen ook geen enkel probleem zijn, maar de dag dat er iets mis gaat met de id's heb je een serieus problem. Ik heb dat helaas zien gebeuren met een API voor producten van een groothandel. Wij (een webshop destijds) kregen een mailtje van een leverancier dat we alle prijzen van de producten opnieuw moesten synchroniseren want meneer had een dump/import gedaan vanuit een CSV en de ID kolom overgeslagen want "die wordt automatisch gegenereerd door de database". Gelukkig synchroniseerden wij op een combinatie van SKU en de EAN code dus wij hebben er niets van gemerkt.
Afijn, opzich werkt het id dus best, maar houd in geachten dat het een verzonnen stukje informatie is dat los staat van de data die je wilt aanwijzen.
Bedankt.
Er komt nu alleen een extra SELECT bij.
Het is een beetje lastig, mn glazen bol is een beetje mistig
Als t lastig is om je database aan te passen
kun je eventueel een quick&dirty oplossing gebruiken met str_replace
vervang je de _ toch weer terug naar spatie? :)
nevermind!
Gewijzigd op 10/11/2015 23:02:09 door Dennis WhoCares
Pg Vincent op 10/11/2015 16:29:51:
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.
Danny von Gaal op 10/11/2015 23:00:39:
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.
Bedankt.
Er komt nu alleen een extra SELECT bij.
Je kunt dit ook in één query doen. Kijk eens naar de mogelijkheden van JOIN :)
@Peter K: Thanks, dit kon ik nog niet en ga ik even bekijken.
Quote:
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.
Quote:
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...
Quote:
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...
Quote:
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.
Quote:
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.
Pg Vincent op 11/11/2015 10:20:30:
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?
Quote:
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.
Salut!
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).