Hallo allemaal ,
Ik ben bezig met een script waarbij ik dus van vrienden , fammilie etc.. de gegevens wil opslaan in mijn DB,
Alleen hoe netter de DB tabel is hoe beter toch ?
Nu had ik dus de vraag hoe kan ik op z,n net een mooi tabelletje maken ik zelf dacht ongeveer dit ,
ID - Int
Naam - Text
Telnr - Text
Email - Text
Datum - Date {Datum verjaardag}
Opmerking - Text
Ik ben zelf niet zo goed met Mysql dus vandaar deze vraag :-) Iemand nog tips opbouwend kritiek ?
B.v.d Kevin
[quote='Robin de Vries schreef op 23.03.2009 18:38'][quote='Pepijn schreef op 23.03.2009 18:37']Waarom telefoon nummer varchar en niet INT?
omdat er soms nog wel een streepje tussen staat voor duidelijkheid.[/quote]
of een 0 er voor: 06 ... 0032... etc[/quote]
Persoonlijk zou ik kiezen voor een INT, en dan voor de input het streepje of de spatie er uit slopen. Grote voordeel is dat je de nummers dan allemaal gelijk in de db hebt, en desnoods nog eens kunt zoeken/sorteren op netnummer.
Ik zou een telefoonnummer niet in een int steken. Denk er aan: een int is een geheel getal. Je verwacht van een geheel getal dat 5 en 0005 precies het zelfde geheel getal is.
Aangezien een telefoonnummer vaak begint met een 0 begint, lijkt me dat geen goede keuze. 10 karakters vind ik ook wat weinig. Verwacht je geen buitenlanders?
Zorg trouwens ook dat je een functie hebt die onnodige karakters (spaties, punten, /, -, ...) uit dat telefoonnummer haalt. Ik zal eens zien of ik die functie, die ik ooit schreef, nog terug vind.
Robin de Vries schreef op 23.03.2009 18:43
text fields zijn nergens voor nodig, kosten alleen maar ruimte, aan 255 tekens heb je meestal wel genoeg, kies varchar :P
Opay, ik simplifieer het wel wat.
Denk eens aan de manier waarop een db werkt. Wanneer je een uitleg/opmerking/... in een VARCHAR 255 steekt, zullen telkens 255 karakters worden ingenomen, zelfs als de opmerking leeg is.
De DB kan het volgende record vinden gewoon door een aantal karakters verder te zoeken dan het vorige, namelijk de som van het aantal karakters van alle velden. Bij een text veld wordt gewoon een adres mee gegeven naar een tekst die buiten die structuur staat (Dit zal wel verschillend zijn naargelang het soort DB.).
Ik heb me nooit echt verdiept in de interne werking van MySQL, ik hoop dat ik geen onzin verkoop.
Ik zou een telefoonnummer niet in een int steken. Denk er aan: een int is een geheel getal. Je verwacht van een geheel getal dat 5 en 0005 precies het zelfde geheel getal is.
Aangezien een telefoonnummer vaak begint met een 0 begint, lijkt me dat geen goede keuze. 10 karakters vind ik ook wat weinig. Verwacht je geen buitenlanders?
Zorg trouwens ook dat je een functie hebt die onnodige karakters (spaties, punten, /, -, ...) uit dat telefoonnummer haalt. Ik zal eens zien of ik die functie, die ik ooit schreef, nog terug vind.
[quote='Robin de Vries schreef op 23.03.2009 18:43']text fields zijn nergens voor nodig, kosten alleen maar ruimte, aan 255 tekens heb je meestal wel genoeg, kies varchar :P
Opay, ik simplifieer het wel wat.
Denk eens aan de manier waarop een db werkt. Wanneer je een uitleg/opmerking/... in een VARCHAR 255 steekt, zullen telkens 255 karakters worden ingenomen, zelfs als de opmerking leeg is.
De DB kan het volgende record vinden gewoon door een aantal karakters verder te zoeken dan het vorige, namelijk de som van het aantal karakters van alle velden. Bij een text veld wordt gewoon een adres mee gegeven naar een tekst die buiten die structuur staat (Dit zal wel verschillend zijn naargelang het soort DB.).
Ik heb me nooit echt verdiept in de interne werking van MySQL, ik hoop dat ik geen onzin verkoop.
[/quote]
Ik weet er niet enorm veel van, maar CHAR was toch dat altijd die ruimte gebruikt werd, en VARCHAR niet? Een lege CHAR(x) kost dus x ruimte, en een lege VARCHAR(x) niets?
VARCHAR(255) wil zeggen dat je een string wilt opslaan met een constraint (beperking) op de lengte. Dit mag maximaal 255 karakters zijn. Aan geheugen ben je kwijt 1 byte + de lengte van de string. Sla je 10 karakters op, kost je dat 10 byte + 1 byte, bij 100 karakters is het 100 byte + 1 byte. Bij 256 karakters (dus 1 karakter meer dan dat er in past), hoor je een dikke foutmelding te krijgen. Met een niet/nauwelijks geconfigureerde MySQL-server (99% van de gevallen), zal MySQL de data naar de klote helpen door er gewoon een stuk af te knippen. Dat jij vervolgens met een corrupte database zit, dat is jouw probleem en niet het probleem van MySQL. Ga die ellende dus configureren of neem een betrouwbare database.
Een CHAR(10) zal altijd de totale lengte reserveren en kost in dit voorbeeld 10 bytes.
Dit soort dingetjes staan gewoon in de handleiding, een linkje had ik al gegeven.
TEXT wordt in MySQL iets anders behandeld dan een VARCHAR, je moet bij indexen even opletten hoe je die aanmaakt, je moet een maximale lengte opgeven. Met PostgreSQL maakt het niet uit of je nu een VARCHAR of TEXT gebruikt, een VARCHAR zonder constraint is exact hetzelfde als een TEXT. Er zijn geen beperkingen m.b.t. indexen e.d., PostgreSQL kent toch al weinig beperkingen.
Zorg trouwens ook dat je een functie hebt die onnodige karakters (spaties, punten, /, -, ...) uit dat telefoonnummer haalt. Ik zal eens zien of ik die functie, die ik ooit schreef, nog terug vind.
Wat mankeert er aan intval()?
En aangezien je een INT ook een maximale lengte van 10 kan opgeven is er niets aan de hand. En een tekort aan nullen vooraf zou je door PHP gewoon kunnen laten aanvullen.
Denk aan.... CHAR(10) ;). Dat kan ook.
Maar dan gewoon met een unsigned MEDIUMINT (kan tot ...meer.....)
Kost je dan ook maar 3 byte (dus is alweer 7 byte kleiner dan een CHAR() ).
En aangezien je een INT ook een maximale lengte van 10 kan opgeven
Sinds wanneer is dat dan?
INT(10) zoals je in MySQL wel ziet, is geen INT(10) met een constraint van maximaal 10 karakters. Deze notatie slaat helemaal nergens op, het zegt alleen iets over volkomen kansloze voorloopnullen en dus opmaak. En opmaak hoort niet thuis in de database, die is voor opslag van data.
Probeer het eens uit en zet een integer van 11 karakters in de database, geen enkel probleem. Logisch, anders zou het geen integer meer zijn.
Telefoonnummers zou ik opslaan in een CHAR of VARCHAR, de getallen hebben meer betekenis dan alleen als getal. Je kunt tenslotte 2 telefoonnummers niet van elkaar aftrekken, je krijgt er geen nieuw telefoonnummer van. In andere databases zou ik even een domain aanmaken en die defineren als telefoonnnummer. Kun je daar ook direct de validaties op los laten, weet je zeker dat je correcte data in je database hebt staan.
