Gegevens in DB - Hoe netter hoe beter.
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
http://phphulp.nl/php/tutorials/3/426/
email varchar(50),
en tenzij je opmerking langer word dan 255 tekens varchar(255)
@Robin , oke dus dan zou het ongeveer zo neer komen ?
ID - int(11)
Naam - Varchar(50)
Tel - Varchar(10) { Dat ik daar niet zelf op kwam .. aangezien een tel nr maar 10 nummers heefd :p}
Opmerking Varchar(255) { Zo ie zo voor de zekerheid 255 }
email - varchar(50)
Gewijzigd op 01/01/1970 01:00:00 door Kevichill
Robin de Vries schreef op 23.03.2009 18:28:
als 1e zou ik naam varchar(50) doen, tel nummer varchar(10),
email varchar(50),
en tenzij je opmerking langer word dan 255 tekens varchar(255)
email varchar(50),
en tenzij je opmerking langer word dan 255 tekens varchar(255)
ik kan toch alles gewoon in 1 tabel doen ?
dus naam id , achternaam , telnr , email , opmerking ?
i.p.v dus 1 tabel te maken voor de naam en dan nieuwe tabel voor de achternaam etc.. ?
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.
Robin de Vries schreef op 23.03.2009 18:38:
omdat er soms nog wel een streepje tussen staat voor duidelijkheid.
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.
of een 0 er voor: 06 ... 0032... etc
Robin de Vries schreef op 23.03.2009 18:43:
Kies een VARCHAR wanneer je een beperking wilt opleggen. Wanneer er geen beperking is, is (bij MySQL) een VARCHAR een foute keuze.text fields zijn nergens voor nodig, kosten alleen maar ruimte, aan 255 tekens heb je meestal wel genoeg, kies varchar :P
En extra ruimte, dat valt reuze mee. Wanneer je maximaal (!!) 1 byte extra al teveel vindt...
http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html
075-642xxxx
Jurgen schreef op 23.03.2009 18:58:
of een 0 er voor: 06 ... 0032... etc
Robin de Vries schreef op 23.03.2009 18:38:
omdat er soms nog wel een streepje tussen staat voor duidelijkheid.
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.
of een 0 er voor: 06 ... 0032... etc
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.
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.
Gewijzigd op 01/01/1970 01:00:00 door Emmanuel Delay
Emmanuel Delay schreef op 23.03.2009 19:47:
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.
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.
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 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?
Of verkoop ik nu onzin?
/PgFrank, kom d'r maar in ;-)
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.
Emmanuel Delay schreef op 23.03.2009 19:47:
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() ).
Gewijzigd op 01/01/1970 01:00:00 door Eddy E
Quote:
Sinds wanneer is dat dan?En aangezien je een INT ook een maximale lengte van 10 kan opgeven
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.
Functie om telefoonnummers te valideren.
http://www.phphulp.nl/forum/showtopic.php?cat=1&id=55625&replies=
Je doet er mee wat je wil.