Gegevens in DB - Hoe netter hoe beter.

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Top Low-Code Developer Gezocht!

Bedrijfsomschrijving Unieke Kansen, Uitstekende Arbeidsvoorwaarden & Inspirerend Team Wij zijn een toonaangevende, internationale organisatie die de toekomst van technologie vormgeeft door het creëren van innovatieve en baanbrekende oplossingen. Ons succes is gebaseerd op een hecht en gepassioneerd team van professionals die altijd streven naar het overtreffen van verwachtingen. Als jij deel wilt uitmaken van een dynamische, vooruitstrevende en inspirerende werkomgeving, dan is dit de perfecte kans voor jou! Functieomschrijving Als Low-Code Developer ben je een cruciaal onderdeel van ons team. Je werkt samen met collega's uit verschillende disciplines om geavanceerde applicaties te ontwikkelen en te optimaliseren met behulp van Low-code

Bekijk vacature »

Kevichill

Kevichill

23/03/2009 18:22:00
Quote Anchor link
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
 
PHP hulp

PHP hulp

29/03/2024 08:26:54
 
Pepijn

Pepijn

23/03/2009 18:28:00
Quote Anchor link
Als je ook families er in stopt is het misschien handig om nog een apparte tabel aan te maken met achternamen. Lees ook deze tutorial,
http://phphulp.nl/php/tutorials/3/426/
 
Robin de Vries

Robin de Vries

23/03/2009 18:28:00
Quote Anchor link
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)
 
Kevichill

Kevichill

23/03/2009 18:31:00
Quote Anchor link
@pepijn bedankt , ik ga die even rustig doornemen.

@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
 
- -

- -

23/03/2009 18:32:00
Quote Anchor link
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)
 
Pepijn

Pepijn

23/03/2009 18:37:00
Quote Anchor link
Waarom telefoon nummer varchar en niet INT?
 
Kevichill

Kevichill

23/03/2009 18:37:00
Quote Anchor link
Even een vraagje ,
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.. ?
 
Robin de Vries

Robin de Vries

23/03/2009 18:38:00
Quote Anchor link
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.
 
Kevichill

Kevichill

23/03/2009 18:40:00
Quote Anchor link
ja dat was ik wel vanplan 2 text fields met eentje voor keuzen uit 06 en een voor 010 bijv.
 
Robin de Vries

Robin de Vries

23/03/2009 18:43:00
Quote Anchor link
text fields zijn nergens voor nodig, kosten alleen maar ruimte, aan 255 tekens heb je meestal wel genoeg, kies varchar :P
 
Jurgen assaasas

Jurgen assaasas

23/03/2009 18:58:00
Quote Anchor link
Robin de Vries schreef op 23.03.2009 18:38:
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
 
Frank -

Frank -

23/03/2009 19:01:00
Quote Anchor link
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
Kies een VARCHAR wanneer je een beperking wilt opleggen. Wanneer er geen beperking is, is (bij MySQL) een VARCHAR een foute keuze.

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
 
Robin de Vries

Robin de Vries

23/03/2009 19:02:00
Quote Anchor link
zou kunnen, maar mijn telefoon nummer bestaat uit
075-642xxxx
 
Mark moes

mark moes

23/03/2009 19:21:00
Quote Anchor link
Jurgen schreef op 23.03.2009 18:58:
Robin de Vries schreef op 23.03.2009 18:38:
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.
 
Emmanuel Delay

Emmanuel Delay

23/03/2009 19:47:00
Quote Anchor link
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.
Gewijzigd op 01/01/1970 01:00:00 door Emmanuel Delay
 
- -

- -

23/03/2009 20:03:00
Quote Anchor link
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.


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 ;-)
 
Frank -

Frank -

23/03/2009 20:16:00
Quote Anchor link
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.
 
Emmanuel Delay

Emmanuel Delay

23/03/2009 20:23:00
Quote Anchor link
thanks
 
Eddy E

Eddy E

23/03/2009 20:24:00
Quote Anchor link
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
 
Frank -

Frank -

23/03/2009 20:42:00
Quote Anchor link
Quote:
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.
 
Emmanuel Delay

Emmanuel Delay

23/03/2009 20:45:00
Quote Anchor link
Ah, gevonden.

Functie om telefoonnummers te valideren.
http://www.phphulp.nl/forum/showtopic.php?cat=1&id=55625&replies=
Je doet er mee wat je wil.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.