hoeveel mailadressen en tel.nrs
Niet een hele spannende vraag, maar vooral uit nieuwsgierigheid.
Ik ben benieuwd hoeveel tel.nrs en e-mailadressen een user kan invoeren op jouw website. Vaak zie je bij het inschrijven 2 velden voor een tel.nr. (een vast en een mobiel nummer). Is dat nog nodig, of is 1 tel.nr. tegenwoordig gebruikelijker? En dezelfde vraag voor een e-mailadres. Bied je de gebruiker de mogelijkheid om 1 e-mailadres in te voeren, of geef je hem de mogelijkheid om nog een extra e-mailadres in te voeren zodat de mail altijd naar 2 adressen wordt verstuurd?
Ikzelf doe altijd maar 1 telefoon nummer vragen. Een 2e word of niet ingevuld of als het verplicht is (huisnummer en mobiel) dan vul ik zelf altijd bullshit in. 1 is ruim voldoende vind ik zelf
Thanks voor je reactie Donny! En hoeveel mailadressen?
Meer nog. Inloggen kan met elk gekozen emailadres
Jan
Voor één site heb ik wel eens een uitzondering gemaakt omdat we voor dat project contactpersonen snel te pakken moeten kunnen krijgen: twee e-mailadressen plus een vast telefoonnummer en een mobiel telefoonnummer, alle vier verplicht.
>> Zowel op telefoon als gsm als email is het bij mij onbeperkt.
Vanuit welke gedachte heb je dat gedaan?
>> Meer nog. Inloggen kan met elk gekozen emailadres
Oké... da's apart. Ook hier weer de vraag... waarom deze aanpak?
@Ward
>> Eén e-mailadres en één telefoonnummer verplicht met optioneel een tweede telefoonnummer.
Oké, en sla je dat optionele mailadres en tel.nr. dan op in de user tabel (dus bij de user zelf) of in een aparte tabel?
In twee extra velden in de usertabel. Dit is een situatie die je in theorie zou moeten normaliseren, maar die in de praktijk leidt tot over-normalisatie. Bij een kleine database merk je er niets van, maar bij een grote database gaat de JOIN in de weg zitten.
Gezien ik soms niet meer weet wat ik waar gebruik :) allemaal toegankelijk. Was wel (voor mij ) een beetje moeilijke sql.
>> In twee extra velden in de usertabel.
Oké. En dan accepteer je dus als ik het goed begrijp het feit dat die 2 velden niet altijd gevuld zijn?
@Jan R
>> Zelf heb ik een 20-tal adressen. Vandaar meerdere ingave.
Gezien ik soms niet meer weet wat ik waar gebruik :)
Oké, bijzonder ;) Ik vraag me wel af of je daarmee niet een potentieel beveiligingsrisico creëert, maar dat terzijde...
Ja, net als bij tussenvoegsels bij achternamen, mocht je die apart willen opslaan.
Oké, helder! Klinkt aannemelijk.
Er bestaat een verschil tussen wat mensen opgeven en wat je in de database opslaat.
Volgens de normalisatie theorieën kan je geen nullable kolommen in een tabel hebben, maar je moet daar praktisch mee omgaan.
Wards voorbeeld met tussenvoegsels is daar een goed voorbeeld voor. (Overigens bestaat er in MySQL een verschil tussen null en ''.
Een andere sitautie is als je een factuuradres en verzendadres hebt, 1 op de mss 30 keer zit daar verschil tussen en dan kies ik ervoor omdat in een aparte table op te slaan.
Gewijzigd op 09/04/2014 21:22:53 door Ger van Steenderen
>> Volgens de normalisatie theorieën kan je geen nullable kolommen in een tabel hebben, maar je moet daar praktisch mee omgaan.
Wat bedoel je precies. Ben je het wel of niet met de methode van Ward eens? Dus 2 mailadres velden en 2 tel.nr. velden, maar accepteren dat vaak 2 velden leeg zijn?
>> Er bestaat een verschil tussen wat mensen opgeven en wat je in de database opslaat.
Wat zou jij dan invullen indien men geen extra tel.nr. / mailadres opgeeft?
Maar ikzelf sla altijd iets op bv:
Voor het extra tel nr. 0 en voor het extra emailadres 'none'
En wat is het voordeel om altijd iets op te slaan? Waarom niet een default null waarde?
Normalistaie gaat over afhankelijkeden en iets wat niet bestaat kan nergens afhankelijk van zijn.
Van wie? Van de normalisatiepolitie? Hehe, grapje hoor ;)
Ik snap alleen niet echt wat je doet. Omdat volgens de theorie een veld niet leeg mag zijn, zet je er toch maar iets in? Is dat waar het dan op neerkomt, of zie ik het helemaal verkeerd? Zou zo maar kunnen hoor?
Volgens sommigen zou je daarvoor het verschil tussen NULL en '' moeten gebruiken.
Stel, iemand meldt zich aan bij een site, maar gebruikte daarvoor het nieuwsbriefformulier. Daarin hoef je alleen voornaam en e-mailadres in te vullen. Van de volledige naam weten we alleen de voornaam, de andere data zijn nooit gecontroleerd of in actie gekomen.
Code (php)
1
2
3
4
5
2
3
4
5
+----------+----------------+------------+
| Voornaam | Tussenvoegsels | Achternaam |
+----------+----------------+------------+
| 'Jan' | NULL | NULL |
+----------+----------------+------------+
| Voornaam | Tussenvoegsels | Achternaam |
+----------+----------------+------------+
| 'Jan' | NULL | NULL |
+----------+----------------+------------+
Later plaatst onze gebruiker een bestelling en leren we zijn volledige naam: Jan Jansen, zonder tussenvoegsels. We kunnen de NULL voor "weet niet" nu vervangen door '' voor "bestaat niet":
Code (php)
1
2
3
4
5
2
3
4
5
+----------+----------------+------------+
| Voornaam | Tussenvoegsels | Achternaam |
+----------+----------------+------------+
| 'Jan' | '' | 'Jansen' |
+----------+----------------+------------+
| Voornaam | Tussenvoegsels | Achternaam |
+----------+----------------+------------+
| 'Jan' | '' | 'Jansen' |
+----------+----------------+------------+
In theorie klinkt dat heel mooi. In de praktijk gaat het fout om verschillende redenen. Niet alle applicatiebouwers houden zich aan het verschil tussen '' en NULL, of weten niet hoe je NULL in een INSERT zet, waardoor onze database in hoog tempo vervuilt. Bovendien handelen MyISAM en InnoDB die NULL ook nog anders af.
Vandaar dat de oplossing van Ger een slim alternatief is: gebruik bijvoorbeeld 0 in de betekenis "we hebben de naam gecontroleerd en er zijn nul tussenvoegsels.
Code (php)
1
2
3
4
5
2
3
4
5
+----------+----------------+------------+
| Voornaam | Tussenvoegsels | Achternaam |
+----------+----------------+------------+
| 'Jan' | 0 | 'Jansen' |
+----------+----------------+------------+
| Voornaam | Tussenvoegsels | Achternaam |
+----------+----------------+------------+
| 'Jan' | 0 | 'Jansen' |
+----------+----------------+------------+
Gewijzigd op 10/04/2014 07:39:32 door Ward van der Put
>> Niet alle applicatiebouwers houden zich aan het verschil tussen '' en NULL, of weten niet hoe je NULL in een INSERT zet
Je kunt de waarde toch ook gewoon niet inserten als ie leeg is en dan defaulten naar null?
Ik snap de insteek enigszins, maar wat maakt het in de praktijk uit of het "weet niet" of "bestaat niet" is. Ik zou gewoon denken "we hebben 'm niet" :) Waarom we 'm niet hebben doet er niet toe.
Ik zou alleen 2 email's gebruiken als je daar van plan bent gebruik van te maken
voor het geval dat iemand niet meer op z'n mail kan kunnen ze een alternatief email adres gebruiken om een nieuw wachtwoord aan te vragen of dat soort dingen
Succes!
>> Niet alle applicatiebouwers houden zich aan het verschil tussen '' en NULL, of weten niet hoe je NULL in een INSERT zet
Je kunt de waarde toch ook gewoon niet inserten als ie leeg is en dan defaulten naar null?
Dat kan ja, maar dan kan het nog steeds voorkomen dat iemand anders het wel doet maar dan met '' in plaats van NULL.
Met een NOT NULL constraint dwing je af dat er iets opgegeven wordt, of je kan met een default value afdwingen dat het niets altijd hetzelfde is.