[DB] Welk datatype*

[Wooldoor]

Hey ik heb een simpele vraag maar ben er niet uitgekomen via internet.

Ik de volgende kolommen: Kvknummer, telefoonnummer, kvksubdossier

nu is de eerste altijd een 8 cijferig nummer dus een bigint( heb ik daarvoor gekozen.
kvkdossiernummer zijn 4 cijfers meestal allemaal 0 int(4)
telefoonummer kan met of zonder streepje worden geplaats zodat daar geen fouten in komen dus int(15)

Het probleem zit hem nu in kvksubdossier die als waarde 0000 hebben staan. converteer ik van excel waar hij als 0000 instaat naar MySQL dan staat hij in de database als 0. Dit is dus niet de bedoeling. En ik weet niet of Kvk nummers ook met een 0 kunnen beginnen maar daar wordt ook automatisch de eerste 0 afgekapt.

Mijn vraag is dus welk datatype te gebruiken voor deze kvk nummers?

[Koppensneller]

Wooldoor schreef op donderdag 29 november 2007 @ 15:13:
Hey ik heb een simpele vraag maar ben er niet uitgekomen via internet.

Ik de volgende kolommen: Kvknummer, telefoonnummer, kvksubdossier

nu is de eerste altijd een 8 cijferig nummer dus een bigint( heb ik daarvoor gekozen.
kvkdossiernummer zijn 4 cijfers meestal allemaal 0 int(4)
telefoonummer kan met of zonder streepje worden geplaats zodat daar geen fouten in komen dus int(15)

Het probleem zit hem nu in kvksubdossier die als waarde 0000 hebben staan. converteer ik van excel waar hij als 0000 instaat naar MySQL dan staat hij in de database als 0. Dit is dus niet de bedoeling. En ik weet niet of Kvk nummers ook met een 0 kunnen beginnen maar daar wordt ook automatisch de eerste 0 afgekapt.

Mijn vraag is dus welk datatype te gebruiken voor deze kvk nummers?

Ga je er mee rekenen? Zo niet -> varchar

[Verwijderd]

google eens op voorloopnullen, er is vast iets over te vinden

[GX]

Waarom zou je voorloopnullen op willen slaan? Dat dient je presentatielaag op te lossen.

[Wooldoor]

Koppensneller ik hoef er inderdaad niet mee te rekenen dus dan zal ik voor varchar gaan.

X.Excel thanks veel mensen raden inderdaad een string aan.

GX het is een stuk handiger als MYSQL ook de extra 0 op zal slaan ook al kost dit meer geheugen.

[whoami]

Het zijn meestal numerieke gegevens; dat impliceert dus dat het niet altijd numerieke gegevens zijn -> alfanumerieke columns dus.
Zeker als je met codes zit die met nullen moeten beginnen -> alfanumerieke columns.

GX schreef op donderdag 29 november 2007 @ 15:19:
Waarom zou je voorloopnullen op willen slaan? Dat dient je presentatielaag op te lossen.

Niet akkoord.
Als de code '0000' is, dan moet je niet in je DB '0' opslaan. Da's nl. wat anders, en heeft niets met presentatie te maken. De code is 0000 en niet 0. Wat als je codes hebt die bv beginnen van 0 en kunnen lopen tot 9999 ?

[ Voor 50% gewijzigd door whoami op 29-11-2007 15:23 ]

[Erkens]

Wooldoor schreef op donderdag 29 november 2007 @ 15:13:
telefoonummer kan met of zonder streepje worden geplaats zodat daar geen fouten in komen dus int(15)

telefoonnummers zou ik nooit als een int opslaan, maar altijd als (var)char.

[whoami]

Telefoonnr's idd als varchar/char opslaan. Je zit daar nl. ook met mogelijke voorloopnullen.

[Verwijderd]

Erkens schreef op donderdag 29 november 2007 @ 15:24:
[...]

telefoonnummers zou ik nooit als een int opslaan, maar altijd als (var)char.

Ligt eraan hoeveel je er op wilt slaan, wat je ermee wilt etc. en of je 10 cijferige of meer op wilt slaan
Volgens mij is de geheugen reservering van een char (kunnen 256 = 8 bit mogelijkheden zijn ) groter dan een int (kunnen 10 mogelijkheden zijn is 4 bit)
Doe dit maal tighonderduizendheelveel en je hebt toch een hoop geheugen gereserveerd wat niet nodig is.

[ Voor 4% gewijzigd door Verwijderd op 29-11-2007 15:32 ]

[Confusion]

Erkens schreef op donderdag 29 november 2007 @ 15:24:
telefoonnummers zou ik nooit als een int opslaan, maar altijd als (var)char.

Omdat je verwacht dat ze binnekort weleens alfanumeriek zouden kunnen worden?

whoami schreef op donderdag 29 november 2007 @ 15:28:
Telefoonnr's idd als varchar/char opslaan. Je zit daar nl. ook met mogelijke voorloopnullen.

Tjah, rdbms'en hebben toch met reden de mogelijkheid om voorloopnullen aan int kolommen te plakken.

[ Voor 36% gewijzigd door Confusion op 29-11-2007 15:32 ]

[whoami]

Ik vind de stelregel die Koppensneller aanhaalt wel een goede: als je er niet hoeft mee te rekenen, kan je (in de meeste gevallen) wel kiezen om de gegevens alfanumeriek op te slaan.

Confusion schreef op donderdag 29 november 2007 @ 15:31:
[...]

Omdat je verwacht dat ze binnekort weleens alfanumeriek zouden kunnen worden?

Kan toch ? In de VS heb je , als ik me niet vergis, toch dergelijke telnr's ?

[ Voor 44% gewijzigd door whoami op 29-11-2007 15:32 ]

[Voutloos]

whoami schreef op donderdag 29 november 2007 @ 15:22:
Het zijn meestal numerieke gegevens; dat impliceert dus dat het niet altijd numerieke gegevens zijn -> alfanumerieke columns dus.
Zeker als je met codes zit die met nullen moeten beginnen -> alfanumerieke columns.

Dossiernummer is [0-9]{8} en subdossiernummer is [0-9]{4}. En er zijn ook dossiernummers welke met een 0 beginnen.

[whoami]

Confusion schreef op donderdag 29 november 2007 @ 15:31:
[...]

Tjah, rdbms'en hebben toch met reden de mogelijkheid om voorloopnullen aan int kolommen te plakken.

Dan nog, ik vind een telnr geen numeriek gegeven.
Wat als je een telnr niet overgenormaliseerd opslaat (en dus geen onderscheid gaat gaan maken tussen landnr, zone-nr, etc...).
Wat als een gebruiker een telnr als volgt wil bewaren:
(09)288.58.72
of
[phone]
oid ?

[TeeDee]

whoami schreef op donderdag 29 november 2007 @ 15:32:
Kan toch ? In de VS heb je , als ik me niet vergis, toch dergelijke telnr's ?

Niet alleen in de VS. In Nederland heb je toch ook naambellen? (Weliswaar niet helemaal aangeslagen maar toch).

[Voutloos]

Een telefoonnummer is gewoon geen integer. Tekens als +,-, puntjes, haakjes en voorloopnullen kan je niet zomaar negeren. Bovendien ga je er toch niet mee rekenen.

[Tanuki]

Voutloos schreef op donderdag 29 november 2007 @ 15:53:
Een telefoonnummer is gewoon geen integer. Tekens als +,-, puntjes, haakjes en voorloopnullen kan je niet zomaar negeren. Bovendien ga je er toch niet mee rekenen.

Dat is prima mogelijk. Dan zul je echter wel het telefoonnummer altijd inclusief landcode op moeten slaan èn de optie zerofill op die kolom in moeten stellen.

In je applicatie zelf kun je dan die haakjes ervoor zetten, die plusjes, etc.

[Wooldoor]

Ja ik zat ook al te kijken naar de verschillende manieren waarop een simpel telefoonnummer ingevoerd wordt. Omdat de database niet heel erg groot wordt maak ik er dus maar varchar van.

[YopY]

whoami schreef op donderdag 29 november 2007 @ 15:34:
[...]

Dan nog, ik vind een telnr geen numeriek gegeven.
Wat als je een telnr niet overgenormaliseerd opslaat (en dus geen onderscheid gaat gaan maken tussen landnr, zone-nr, etc...).
Wat als een gebruiker een telnr als volgt wil bewaren:
(09)288.58.72
of
[phone]
oid ?

dan geef je hem een schop, met uitzondering misschien van de plus. Ik bedoel, (09)288.58.72 typ je in je telefoon toch ook gewoon in als 092885872? Het zo opslaan van een telefoonnummer kan wel, maar ik zou het niet doen - je wilt geen presentatie (haakjes, punten e.d) opslaan in je database. Hoeft ook niet nodig te zijn - voor eventuele presentatieverschillen tussen landen en telefoonnummertypes kun je beter een extra kolom gebruiken dan om (var)chars te misbruiken.

Voor een eenvoudige (web)app kan het misschien nog, maar dan moet het echt een projectje zijn die in een dag af is, anders zijn de gevolgen op lange termijn gewoon irritant.

[Confusion]

whoami schreef op donderdag 29 november 2007 @ 15:32:
Kan toch ? In de VS heb je , als ik me niet vergis, toch dergelijke telnr's ?

Het was ook een serieuze suggestie; telefoonnummers zijn natuurlijk een redelijk achterhaald systeem. Technisch is het al lang en breed mogelijk om '[e-mail]' te bellen met een mobiele telefoon, dus ik vind dat een goede reden om het veld varchar te maken.

whoami schreef op donderdag 29 november 2007 @ 15:34:
Dan nog, ik vind een telnr geen numeriek gegeven.
Wat als je een telnr niet overgenormaliseerd opslaat (en dus geen onderscheid gaat gaan maken tussen landnr, zone-nr, etc...).

Als je landnummer, netnummer en aansluitnummer niet scheidt, ben je jezelf sowieso al in de problemen aan het brengen.

Wat als een gebruiker een telnr als volgt wil bewaren:

De gebruiker heeft niets te maken met hoe ik besluit het telefoonnummer in de database op te slaan. De opdrachtgever ook niet.

Als ik in de jaren '80 een applicatie zou maken voor telefoonnummers, dan zou ik landnummer, netnummer en aansluitnummer gescheiden opslaan in integer velden. Dat is qua opslaggrootte en ophaalsnelheid het meest efficient. Dat het nu niet meer nodig is om die redenen, betekent niet dat het opeens fout is.

[Xyzar_]

Kan toch ? In de VS heb je , als ik me niet vergis, toch dergelijke telnr's ?

maar is dat dan niet gewoon een normaal nummer waarbij je toevallig een woord kan maken van de letters bij de cijfers? (0800 - COCACOLA is ookmaar gewoon 0800 - 26 22 26 52. nummer van de infolijn btw.)

[Verwijderd]

Integer (in Mysql) gaat ook maar tot 4294967295 erg leuk als iemadn het telefoon nummer 4294967296 heeft

[Erkens]

Verwijderd schreef op donderdag 29 november 2007 @ 18:18:
Integer (in Mysql) gaat ook maar tot 4294967295 erg leuk als iemadn het telefoon nummer 4294967296 heeft

Dan neem je een BIGINT
Punt is gewoon dat het imo gewoon onverstandig is om een string zoals een telefoonnummer op te gaan slaan in een integer field. Anders dan een paar bytes diskspace heeft het geen voordelen om het als een integer op te slaan. Je verliest er alleen maar overzicht mee en je bent niet flexibel genoeg meer. Zo wil je bijvoorbeeld inderdaad 0900-COCACOLA opslaan, en niet 90026222652.

[whoami]

Confusion schreef op donderdag 29 november 2007 @ 16:31:

Als je landnummer, netnummer en aansluitnummer niet scheidt, ben je jezelf sowieso al in de problemen aan het brengen.

Waarom ? Da's gewoon afhankelijk van de eisen.

Als ik in de jaren '80 een applicatie zou maken voor telefoonnummers, dan zou ik landnummer, netnummer en aansluitnummer gescheiden opslaan in integer velden. Dat is qua opslaggrootte en ophaalsnelheid het meest efficient. Dat het nu niet meer nodig is om die redenen, betekent niet dat het opeens fout is.

In de jaren 80 .... ondertussen zijn we 20 jaar verder.
In de jaren 80 zou ik het misschien ook wel doen, dan werden er allerhande rare truken uitgehaald
(Ik ben nu bezig een applicatie die in die periode geschreven werd, om te zetten naar een nieuw systeem, en in die app worden er eigenschappen van een bepaald item in een character-veld van 16 posities lang opgeslagen, waarbij iedere positie een betekenis heeft, en die positie dan ook nog eens een andere betekenis kan hebben afhankelijk van een ander veld in dat record.
Of wordt een bepaalde bit in een double gebruikt om een specifieke extra betekenis aan dat veld te geven, etc... /offtopic).

Zowiezo vind ik, dat een netnummer dat bv begint als '09' als varchar moet opgeslagen worden. Die 0 is niet gewoon een voorloopnul (voorloopnullen hebben imho te maken met presentatie), maar maakt gewoon integraal deel uit van het gegeven.
9 en 09 is gewoon iets heel anders in deze situatie; en als een andere applicatie m'n database ook moet gebruiken, dan moet ik die andere applicatie niet 'ambeteren' met het feit dat zij er moet voor zorgen dat m'n netnummer met een nul moet geprefixed worden; die nul maakt deel uit van het gegeven.

[ Voor 3% gewijzigd door whoami op 29-11-2007 21:46 ]

[Confusion]

Verwijderd schreef op donderdag 29 november 2007 @ 18:18:
Integer (in Mysql) gaat ook maar tot 4294967295 erg leuk als iemadn het telefoon nummer 4294967296 heeft

(unsigned) 32 bits integers hebben wel vaker de neiging tot 2³² - 1 te gaan; daar moet je niet MySQL de schuld van geven

whoami schreef op donderdag 29 november 2007 @ 21:45:
Waarom ? Da's gewoon afhankelijk van de eisen.

Hoe je bepaalde data het beste op kan slaan, zodat je het in ieder gewenst formaat weer kan reproduceren, is niet afhankelijk van eisen van een specifieke gebruiker of opdrachtgever. Hun eisen slaan vrijwel altijd op de presentatie: hoe moet de data straks weer uit het systeem komen? Die eisen zijn onderhevig aan verandering. Vandaag willen ze alles met '+31(20)' eruit, morgen alles met '0030 20'. Als jij het dan niet gescheiden opslaat, parse je jezelf een ongeluk, als er al een unieke oplossing voor is.

Ik kan je uit ervaring zeggen dat een veld met straatnaam en straatnummer ineen je voor onmogelijke opgaven stelt als je gevraagd wordt het uit elkaar te trekken. Straatnummers, met prefixen, suffixen (dingen als 61^b overkant), gecombineerd met straatnamen die beginnen of eindigen met cijfers zijn een hel. Zeker als je moet gaan normaliseren met andere databases, waar het weer net iets anders in is opgeslagen. (Note overigens: straatnummers niet in int veld opslaan )

Zowiezo vind ik, dat een netnummer dat bv begint als '09' als varchar moet opgeslagen worden. Die 0 is niet gewoon een voorloopnul (voorloopnullen hebben imho te maken met presentatie), maar maakt gewoon integraal deel uit van het gegeven.

Over netnummers ben ik het met je eens (dat kan met Nederlandse netnummers ook niet anders, omdat er zowel drie-, als viercijferige netnummers zijn). Maar volgens mij beginnen de aansluitnummers in Nederland nooit met een 0, precies omdat het oorspronkelijk echte nummers waren en dan lijkt het me niet raar die als een numeriek type op te slaan.

[ Voor 73% gewijzigd door Confusion op 29-11-2007 22:05 ]

[Erkens]

Confusion schreef op donderdag 29 november 2007 @ 21:52:
Over netnummers ben ik het met je eens (dat kan met Nederlandse netnummers ook niet anders, omdat er zowel drie-, als viercijferige netnummers zijn). Maar volgens mij beginnen de aansluitnummers in Nederland nooit met een 0, precies omdat het oorspronkelijk echte nummers waren en dan lijkt het me niet raar die als een numeriek type op te slaan.

Als je spreekt over de "normale" telefoonnummers heb je gelijk dat die aansluitnummers niet met 0 beginnen, maar met bijvoorbeeld 0800 of 0900 nummers kan dat wel, en die zou je toch echt op dezelfde manier moeten opslaan.