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.
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.
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.
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.
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.
Okee mensen bedankt. Ik ga het nog even onderzoeken en als ik er achter kom dan laat ik het weten.
Lukt het me niet dan val ik wel terug op userid's die ik uiteraard bij hou.
Je kunt entiteiten het beste identificeren met een eigenschap waarvan de waarde niet verandert.
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.
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.
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.
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".
Het is een redelijk "moot point" dat het id enkel wijst naar het record (en verder geen echte relatie heeft met de inhoud, als je dat bedoelt). Het vervult een duidelijke en ondubbelzinnige rol.
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.
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.
