[data] doornummeren zonder dataruimte gereserveerd te hebben

[Nas T]

Ik loop tegen een interessante kwestie aan, ik hoop dat het me lukt het uit te leggen.

Ik gebruik (willekeurige) software waarbij ik iets kan vullen. Alleen kan ik niet oneindig veel karakters invullen.
Bijvoorbeeld productnummering. Vanuit Philips wordt voor productnummers een "12NC" gebruikt (12 nummers als productcode).
Elk product heeft 12 nummers, dus er kunnen een biljoen producten gemaakt worden.
Stel dat documenten ook een 12NC krijgen, en elke documentwijziging een nieuw 12NC. Dan zal er ooit een moment komen dat de getallen op zijn. Dan zal er waarschijnlijk een 13NC of groter bedacht worden.
Wat gaat er dan gebeuren: Alle software zal hiervoor aangepast gaan moeten worden. Alles uit het "oude" 12NC-systeem zal dan herkend moeten worden en een extra getal krijgen waarschijnlijk.

Maar goed: andersom gedacht: als er vanuit gegaan wordt dat een productnummer oneindig lang kan worden, is het dan mogelijk/standaard dat de software hier rekening mee gaat houden, zonder dat de mogelijkheid tot een oneindig lang nummer ook leidt tot allerlei computerspecifieke problemen?

Ik zie namelijk rondom me heen allerlei "kromme" problemen door beperkingen wat getal-lengtes betreft.
Ik wil weten of er al eerder over nagedacht is en of er een algemene oplossing voor is.


Ik kan me voorstellen dat het niet duidelijk is, dus reageer maar raak!

[Orion84]

Ik snap niet helemaal welke kant je op wilt, maar na 999999999999 komt dan toch gewoon 1000000000000

Als er maar 12 positities beschikbaar zijn in de software die de opslag / verwerking doet, dan zal die software inderdaad moeten worden aangepast om een 13de cijfer kwijt te kunnen en eventueel nog wel overweg te kunnen met 12 cijferige codes.

[ Voor 55% gewijzigd door Orion84 op 22-07-2010 15:34 ]

[downtime]

Nas T schreef op donderdag 22 juli 2010 @ 15:27:
Maar goed: andersom gedacht: als er vanuit gegaan wordt dat een productnummer oneindig lang kan worden, is het dan mogelijk/standaard dat de software hier rekening mee gaat houden, zonder dat de mogelijkheid tot een oneindig lang nummer ook leidt tot allerlei computerspecifieke problemen?

Waarom zou een nummer oneindig lang moeten zijn? Wil je soms Pi gaan berekenen?

Voor een productnummer is 12 cijfers met 99% waarschijnlijkheid al meer dan genoeg. Anders pas je de software aan en leer je die dat een 12-cijferig nummer 000.000.000.123 niet hetzelfde is als een 13-cijferig nummers 0.000.000.000.123. Het is namelijk een nummer en geen getal dus bestaande nummers hoeven niet te wijzigen.

[Orion84]

Als je wilt doornummeren is het niet zo handig om nadat de twaalfcijferige codes op zijn verder te gaan met twaalf nullen gevolgd door een 1 etc.

Gewoon nadat je de code bestaande uit 12 negens gehad hebt verder gaan met de code bestaande uit één 1 gevolgd door 12 nullen. En eventueel alle oude 12 cijferige codes omzetten naar (of bij elk gebruik herinterpreteren als) 0<oude-code>.

[Nas T]

Om het probleem technisch weer te geven:
wordt er in het algemeen software gebruikt die hiertussen het verschil kan maken:
1
22
333
4444

en:
0001
0022
0333
4444

Want: 1e manier: zo "lezen" mensen het. Geen extra nullen "opslaan" die geen toegevoegde waarde geven.
2e manier: bit-notering:
1 wordt in 8 bits geschreven als (bijvoorbeeld): 00000001
2: 00000010
3: 00000011
4: 00000100
etc.
Een mens zou zo slim zijn om te zeggen:
1: 1
2: 10
3: 11
4: 100

En waarom zou een computer niet zo slim zijn om on the fly te lezen hoeveel cijfers er zijn en het zodoende juist te interpreteren? Dat scheelt opslag en communicatieproblemen.
Je kunt deze situatie creëren:
nummer 1234 (oud) is nummer 001234 (nieuw). Maar een mens kan 1234 en 001234 gescheiden zien.

Stel je de volgende situatie voor:
Je hebt een fabriek en je gaat alle machines nummeren. Je beslist: Ik gebruik 4 cijfers. Dan gebruik je 2 cijfers voor elke afdeling en 2 voor elke machine.
Stel dat afdeling 5 meer dan 100 apparaten heeft. Dan maakt het systeem een nieuwe nummergroep: 5 cijfers. Dus dan komt na 0599: 05100.
Bij het invoeren leest de software: 5 cijfer, eerste 2 is afdelingnummer, laatste 3 is machinenummer.

Maar dan is afdeling 99 bereikt. Wat nu? afdeling 100? Kan, maar let wel op:
de eerste machine van afdeling 100 kan dan niet 01 genoemd worden, aangezien je dan krijgt:
10001. Computer leest: 5 cijfers. Eerste 2 voor afdeling, laatste drie voor machinenummer.
Dus: 6-cijferig:
100001. Computer leest het nieuwe 6 cijferig nummer en bepaalt: eerste 3 afdeling, laatste 3 machinenummer.

Dan kan de computer de getallen altijd goed beheren, omdat bij elke lengte een bepaalde interpretatie bestaat die vastgelegd wordt en dan is het nog wel belangrijk bij weergeven van een nummer richting gebruiker (scherm, printen) dat deze getallen wel netjes een zichtbare scheiding krijgen.
Want 111011 en 110111 zijn makkelijk te verwarren, 111_011 en 110_111 al minder.

Maar goed...dat zijn geen leuke grappen dus...

Mijn doelvraag is dan:
Is die constructie softwarematig gestandaardiseerd?

Orion84 schreef op donderdag 22 juli 2010 @ 15:31:
Ik snap niet helemaal welke kant je op wilt, maar na 999999999999 komt dan toch gewoon 1000000000000

Als er maar 12 positities beschikbaar zijn in de software die de opslag / verwerking doet, dan zal die software inderdaad moeten worden aangepast om een 13de cijfer kwijt te kunnen en eventueel nog wel overweg te kunnen met 12 cijferige codes.

Ja, precies. Na 999 komt 1000 (of hoe je het ook schrijft). Maar ga software maar eens vertellen dat na 999 1000 komt als deze ingericht is om 3 karakters weer te geven...
Bijvoorbeeld:
Je bent bezig om een database te maken met alle werknemers. Voornaam, achternaam, geboortedatum, etc. Nou kun je per veld bepalen hoeveel karakters je er kwijt kan. Omdat niet gebruikte karakters van een veld ook data innemen, wil je niet dat elk veld oneindig veel karakters heeft. Dus elke voornaam mag maximaal 32 tekens lang zijn. Nou is er één werknemer die, hoe gek ook, 33 tekens als voornaam heeft. Dus je past je database aan, je houdt rekening met namen die nog langer kunnen worden en je maakt daar maximaal 40 karakters van. Daardoor zal bij elk record 8 karakters extra aan data gebruikt worden, ongeacht of die data wel of niet wordt gebruikt.

Daarnaast: inderdaad: de software moet aangepast worden. En ook weer als er 14 cijfers in plaats van 13 gebruikt gaan worden. Om dan alle flauwekul tot in oneindigheid op te lossen: is er iets standaard bedacht, die om kan gaan met elke lengte, zonder de opslagkwestie? Zelfde voorbeeld zijn clusters van een harde schijf: hoe klein je bestandje ook is, het zal altijd een cluster data innemen. Al is je bestandje maar 1 bit.

downtime schreef op donderdag 22 juli 2010 @ 15:38:
[...]

Waarom zou een nummer oneindig lang moeten zijn? Wil je soms Pi gaan berekenen?

Voor een productnummer is 12 cijfers met 99% waarschijnlijkheid al meer dan genoeg. Anders pas je de software aan en leer je die dat een 12-cijferig nummer 000.000.000.123 niet hetzelfde is als een 13-cijferig nummers 0.000.000.000.123. Het is namelijk een nummer en geen getal dus bestaande nummers hoeven niet te wijzigen.

Ik loop tegen de 1% aan. Het specifieke probleem is het volgende:
Leverancier doet bestelling en geeft tekening als 12NC met de bestelling mee. Een tekening wordt hier intern behandeld als 11NC plus een versienummer (dat maakt bij elkaar een 12NC). Na 10 versiewijzigingen zal er een nieuw 11NC gemaakt moeten worden, dat kan technisch gezien niet. Dus wordt er omheen gewerkt: naast de versie bestaan er datumwijzigingen. Dus verschillende producten in een "uniek" 12NC.
Hoe kom je daar van af: oneindig-NC :d
Dan zou elke tekening kunnen beginnen met de 12NC van het product, gevolgd door een versienummer dat oneindig door kan lopen. Dan kan de 12NC nummering bestaan blijven en een nieuw nummeringsmanagement daar mee omgaan.

Orion84 schreef op donderdag 22 juli 2010 @ 15:42:
Als je wilt doornummeren is het niet zo handig om nadat de twaalfcijferige codes op zijn verder te gaan met twaalf nullen gevolgd door een 1 etc.

Gewoon nadat je de code bestaande uit 12 negens gehad hebt verder gaan met de code bestaande uit één 1 gevolgd door 12 nullen. En eventueel alle oude 12 cijferige codes omzetten naar (of bij elk gebruik herinterpreteren als) 0<oude-code>.

Nee, niet gaan omzetten...het punt is dat wij als mensen onderscheid kunnen maken tussen 1234 en 01234 en software moet dit ook gewoon kunnen. Anders zou alles omgezet worden naar 13NC, en dus bij ALLE informatie.
Als de software gewoon 12NC kan scheiden van andere getallen, is dat veel logischer.
Want dan kan 12NC blijven bestaan, want dat is iets van Philips en zit ongelooflijk ver ingebakken.
Want: Stel dat we overschakelen, moeten alle leveranciers overschakelen. En wie gaat dat betalen?
En hoe ver ga je dat doorvoeren? Moeten alle oude documenten gewijzigd worden? Ook van papier om misverstanden te voorkomen?

[downtime]

De fout is dan ook dat nummers bij jullie perse een betekenis moeten hebben. Dan ben je inderdaad beperkt in je mogelijkheden als je codering niet genoeg ruimte geeft.
Geef nummers dan liever niet een betekenis of kies gewoon een beter nummer met meer ruimte per veld. Daar wordt het nummer misschien lang van, maar so what, storage is goedkoop.

[leuk_he]

Computers hebben geen probleem met enorme cijvers t cijfers te werken. Maar jij hebt het dus al niet over cijfers, maar over nummerreeksen, Noem zo'n ding ook in de communicatie ook niet een artikel nummer, maar gebruik artikel-idenitficatie

Als je onderscheid moet maken tussen 001 en 1 dan sla je het in de computer op als een karakter reeks. Moderne database lopen tot een karakter of 2000 niet zo gauw tegen beperkingen aan, en als je weet dat een reeks groter moet worden kan dat makkelijk worden opgerekt.


Het probleem lijkt me eerder in de interfaces te zitten.
-Je moet product identificaties ook door mensen laten invoeren. Alleen scanner is niet voldoende, want dan is het b.v. onmogelijk een serienummer door te bellen over de telefoon. Daar stuit je al gauw op beperkingen.
-Je moet de identificaties dus ook tonen, op de producten zelf, maar ook op schermen. Op computer schermen heb je maar beperkt ruimte, dus reserveer je ook alleen maar ruimte voor de normale ruimte.

Ook is een klassieke fout teveel logica aan te brengen in het nummer. Door b.v. de eerste 3 cijvers van de artikel identificatie te gebruiken als productgroep staan ze op (oude) lijsten mooi op volgorde. Maar je hebt wel in 1x een factor 1000 verbruikt, waar flinke gaten in zullen vallen. Terwijl het geen enkel probleem is te sorteren op het veld artikelgroep. in een database.

Je hebt geen oneindige nummer reeks nodig. Je moet alleen voorkomen dat er gaten vallen in je reeksen doordat met teveel andere functionaliteit wil opnemen in 1 identificatienummer.

Overigens moest ik meteen denken aan EAN-128 barcodes. Eerst dacht ik ook dat dit gewoon een uitbreiding was van EAN-13 codes, maar bij nadere bestudering blijkt een een streepjes code waarin een start en een stop karakter is opgenomen. O die manier kun je heel veel informatie in 1 streepjescode kwijt, de gescande code wordt immers gewoon een enorme karakterstring tot het stop karakter wordt tegengekomen. (Om te voorkomen dat deze te breed wordt zijn er ook andere coderingen uitgevonden met hogere dichtheid, maar dat is nu even niet relevant)

[ Voor 0% gewijzigd door leuk_he op 23-07-2010 14:14 . Reden: cijver -> cijfer ]

[CAPSLOCK2000]

Het is prima mogelijk om de computer met "oneindig lange" getallen om te laten gaan.
Zoals je weet tellen computers binair

0
1
10
11
etc
en die nummers kunnen steeds langer worden.
Nu spreken we af dat je ieder getal afsluit met "00" (een zogenaamde terminator):

000 => 0
100 => 1
11110111101110111100 => 111101111011101111

Dat gaat goed totdat je een getal hebt waar al twee nullen in zitten:
11001100 => 11 of 110011 ?
Dus spreken we af dat als de combinatie "00" tussendoor voorkomt je het 2 keer moet schrijven:
Als je het getal "110011" hebt dan sla je het op als "1100001100".

Zo kun je oneindig lange getallen opslaan.

"Wat dan als er 4 nullen achter elkaar in het getal zitten?" vraag je je af: 4 nullen is 2 x 2 nullen, dus het getal "11000011" zou je opslaan als "11000000001100".
Voor de compleetheid nog even met 3 nullen (2x2 nullen + 1 nul):
1100011 => 11000001100

In praktijk wordt het bijna nooit zo gedaan omdat het veel langzamer is voor de computer om iedere keer te moeten gaan kijken waar de grenzen van een getal zijn. Zorg ervoor dat je code zo lang is dat je zeker weet dat het altijd genoeg zal zijn, gebruik bijvoorbeeld 100NC (om eens lekker extreem te doen).
Je bent dan misschien iets meer geld kwijt aan hardeschijven maar anders was je dat geld (en meer) kwijt aan duurdere processoren.

[zwippie]

leuke_he en CAPSLOCK geven dus al twee voorbeelden van 'oneindige' opslagruimte.\0

Ik geef je er nog eentje. :p\0

[Nas T]

CAPSLOCK2000 schreef op donderdag 22 juli 2010 @ 21:29:
"Wat dan als er 4 nullen achter elkaar in het getal zitten?" vraag je je af: 4 nullen is 2 x 2 nullen, dus het getal "11000011" zou je opslaan als "11000000001100".
Voor de compleetheid nog even met 3 nullen (2x2 nullen + 1 nul):
1100011 => 11000001100

In praktijk wordt het bijna nooit zo gedaan omdat het veel langzamer is voor de computer om iedere keer te moeten gaan kijken waar de grenzen van een getal zijn. Zorg ervoor dat je code zo lang is dat je zeker weet dat het altijd genoeg zal zijn, gebruik bijvoorbeeld 100NC (om eens lekker extreem te doen).
Je bent dan misschien iets meer geld kwijt aan hardeschijven maar anders was je dat geld (en meer) kwijt aan duurdere processoren.

Het zit hem ook in datacommunicatie. Op een gegeven moment ga je aardig wat lege datacommunicatie creëren. Een een 12NC gaan converteren naar een 100NC... das leuk op papier: eerst 88 nullen en dan de 12NC.

Maar computers op zich kunnen wel vrij netjes omgaan met getallen, lijkt me, maar het zit me meer in de software-kant:

leuk_he schreef op donderdag 22 juli 2010 @ 17:33:
Computers hebben geen probleem met enorme cijvers te werken. Maar jij hebt het dus al niet over cijvers, maar over nummerreeksen, Noem zo'n ding ook in de communicatie ook niet een artikel nummer, maar gebruik artikelditenitficatie

Als je onderscheid moet maken tussen 001 en 1 dan sla je het in de computer op als een karakterreeks. Moderne database lopen tot een karakter of 2000 niet zo gauw tegen beperkingen aan, en als je weet dat een reeks groter moet worden kan dat makkelijk worden opgerekt.


Het probleem lijkt me eerder in de interfaces te zitten.
-Je moet product identificaties ook door mensen laten invoeren. Alleen scanner is niet voldoende, want dan is het b.v. onmogelijk een serienummer door te bellen over de telefoon. Daar stuit je al gauw op beperkingen.
-Je moet de identificaties dus ook tonen, op de produckten zelf, maar ook op schermen. Op computer schermen heb je maar beperkt ruimte, dus reserveer je ook alleen maar ruimte voor de normale ruimte.

Ook is een klassieke fout teveel logica aan te brengen in het nummer. Door b.v. de eerste 3 cijvers van de artikel identificatie te gebruiken als produktgroep staan ze op (oude) lijsten mooi op volgorde. Maar je hebt wel in 1x een factor 1000 verbruikt, waar flinke gaten in zullen vallen. Terwijl het geen enkel probleem is te sorteren op het veld arikelgroep. in een database.

Je hebt geen oneindige nummer reeks nodig. Je moet alleen voorkomen dat er gaten vallen in je reeksen doordat met teveel andere functionaliteit wil opnemen in 1 identicatiecijver.

Overigens moest ik meteen denken aan EAN-128 barcodes. Eerst dacht ik ook dat dit gewoon een uitbreiding was van EAN-13 codes, maar bij nadere bestudering blijkt een een streepjes code waarin een start en een stop karakter is opgenomen. O die manier kun je heel veel informatie in 1 streepjescode kwijt, de gescande code wordt immers gewoon een enorme karakterstring tot het stop karakter wordt tegengekomen. (Om te voorkomen dat deze te breed wordt zijn er ook andere coderingen uitgevonden met hogere dichtheid, maar dat is nu even niet relevant)

cijver? Volgens mij raak je aardig het punt wat ik bedoel, al begrijp ik nog niet alles.
Het gaat inderdaad om een nummerreeks en de ruimte die beschikbaar is om nummerreeksen weer te geven.
Die is ingericht op 12NC. Alleen intelligentere software zou theoretisch een 11NC moeten kunnen verwerken of 13NC. Uiteraard is dan op een gegeven moment de scherm/papierruimte op, maar dat valt ook wel softwarematig te reguleren, lijkt me. Kijk eens naar een 2d barcode: daar kun je veel informatie in kwijt op een relatief klein oppervlak.
Het hele ERP systeem (centraal bedrijfsdatamanagement zeg maar) is nu gericht op 12NC. Alleen als er een aanpassing moet komen, is het denk ik slimmer om iets fatsoenlijks en intelligents te gebruiken in plaats van weer een statisch systeem (van 12NC naar 13NC zeg maar). Want dan vraagt de software altijd een 13NC code en moet de gebruiker de vertaalslag maken, terwijl het slimmer is om de software te laten begrijpen om het verschil te herkennen, door middel van (bijvoorbeeld) een start en stop signaal. Bij velden is dat eenvoudig: er staat een bepaalde waarde in en die bestaat uit een aantal karakters.

Ik vroeg me af of dit een probleem was dat algemeen geldt (ik kom dat op erg veel plekken tegen) en of daar bij software standaard rekening mee gehouden kan worden en dat er dus niet veel software opnieuw geschreven hoeft te worden.

[Reptile209]

Je kan het probleem ook wat pragmatischer benaderen: hoe erg is het dat je nummerreeks op een gegeven moment 'omloopt' en weer bij 1 begint? Stel: je hebt een biljoen productnummers. Hoe lang duurt het voordat je die allemaal gebruikt hebt? Zou je na die periode niet eens wat ballast uit je systeem willen lozen, en de eerste 10 miljard nummers weer willen vrijgeven? Zeker als dat pas na X keer de levensduur van een product is, lijkt me dat geen enkel probleem.
Het is een beetje vloeken in de database-kerk, maar onmogelijk lijkt het me zeker niet.

[Croga]

Reptile209 schreef op vrijdag 23 juli 2010 @ 08:53:
Je kan het probleem ook wat pragmatischer benaderen: hoe erg is het dat je nummerreeks op een gegeven moment 'omloopt' en weer bij 1 begint? Stel: je hebt een biljoen productnummers. Hoe lang duurt het voordat je die allemaal gebruikt hebt? Zou je na die periode niet eens wat ballast uit je systeem willen lozen, en de eerste 10 miljard nummers weer willen vrijgeven? Zeker als dat pas na X keer de levensduur van een product is, lijkt me dat geen enkel probleem.
Het is een beetje vloeken in de database-kerk, maar onmogelijk lijkt het me zeker niet.

Let wel dat we het hier hebben over een bedrijf wat rustig nog support levert op producten van 25 jaar geleden. Zeker als je praat over de assembleer machines die ze maken....

Daarnaast weten we allemaal dat er steeds meer producten/documenten gemaakt worden. De snelheid waarmee de nummers op gaan stijgt alleen maar. En voor een bedrijf met meer dan 100'000 werknemers is een biljoen nummers tegenwoordig zo op.

[Nas T]

Reptile209 schreef op vrijdag 23 juli 2010 @ 08:53:
Zou je na die periode niet eens wat ballast uit je systeem willen lozen, en de eerste 10 miljard nummers weer willen vrijgeven? Zeker als dat pas na X keer de levensduur van een product is, lijkt me dat geen enkel probleem.
Het is een beetje vloeken in de database-kerk, maar onmogelijk lijkt het me zeker niet.

Niet onmogelijk, maar dat is zelfs meer dan godslasterij in de database-kerk. Het KAN gewoon niet zo zijn dat verschillende entiteiten in 1 record bestaan. Het stomme is dat de 12NC zelf een biljoen mogelijkheden heeft, maar als volgt is opgebouwd:
4 cijfers voor een bedrijfstak
3 cijfers voor een afdeling
5 cijfers voor een product

Dan heb je dus theoretisch 1 biljoen combinaties, praktisch gezien binnen een afdeling 100.000 (en dat is veel toch?). Ga je de nummers voor allerlei doeleinden gebruiken dan is je poel met getallen zo op. En een 13NC dan invoeren is niet de oplossing, want dan gaan wéér andere dingen gebruik daarvan maken, dan worden alle documenten daarmee beheerd. Gevolg: 14NC. Dan kan elk fysiek product zelfs een eigen nummer krijgen, "ruimte zat". Gevolg: 15NC. Etc.
Elke overstap gaat gepaard met een verandering van software en het vertalen van oude nummers. Maar stel je eens voor dat je dan beslist dat papieren documenten dan niet worden gewijzigd en die papieren documenten worden gescand later. Dan wil je ze misschien weer wel wijzigen en bestaan systemen toch (semi-illegaal) naast elkaar. En wat als andere bedrijven met het 12NC-systeem werken, die moeten dan ook overstappen. En stel je dan voor dat een leverancier die al enkele jaren niet meer levert, maar een tijd na de overstap weer producten levert? Die wil dan een 12NC uit de kast pakken, maar: dat werkt niet/half.

Daarom: De software in 1 keer slim genoeg maken om ##NC te handelen.

[Orion84]

Daarom: De software in 1 keer slim genoeg maken om ##NC te handelen.

Zoals al eerder gezegd: Dat is een kwestie van de boel opslaan als string en speciale karakters introduceren die de verschillende onderdelen van de code markeren. Zodat je dus bijvoorbeeld iets krijgt als 1230-456-78901 (bedrijf-afdeling-product) en zodra je dan aan de duizendste afdeling toekomt wordt dat gewoon 1230-1000-45601.

Om te zorgen dat je systeem nog met de oude codes overweg kan interpreteer je elke 12 cijferige code als een code die geen speciale markers heeft en bestaat uit een blok van 4, een blok van 3 en een blok van 5.

[CAPSLOCK2000]

Nas T schreef op vrijdag 23 juli 2010 @ 09:27:
Elke overstap gaat gepaard met een verandering van software en het vertalen van oude nummers. Maar stel je eens voor dat je dan beslist dat papieren documenten dan niet worden gewijzigd en die papieren documenten worden gescand later. Dan wil je ze misschien weer wel wijzigen en bestaan systemen toch (semi-illegaal) naast elkaar. En wat als andere bedrijven met het 12NC-systeem werken, die moeten dan ook overstappen. En stel je dan voor dat een leverancier die al enkele jaren niet meer levert, maar een tijd na de overstap weer producten levert? Die wil dan een 12NC uit de kast pakken, maar: dat werkt niet/half.

Daarom: De software in 1 keer slim genoeg maken om ##NC te handelen.

Het kan, maar het is over het algemeen weinig efficient.
Proberen rekening te houden met alles wat in de toekomst nog zou kunnen gebeuren is een veel gemaakte programmeerfout. Een beetje vooruit kijken is prima, maar ga niet te ver. Als je denkt dat de nummers ooit opraken, maak ze dan langer. Maak in je eigen applicatie het veld 20 tekens lang en laat de computer de begin-nullen verbergen voor de gebruiker.
Er zijn voldoende oplossingen om met oneindig lange getallen te werken maar die hebben ook allemaal hun nadelen. Slecht programmeerwerk ga je er niet meer voorkomen.

Het zit hem ook in datacommunicatie. Op een gegeven moment ga je aardig wat lege datacommunicatie creëren. Een een 12NC gaan converteren naar een 100NC... das leuk op papier: eerst 88 nullen en dan de 12NC.

Dan gebruik je compressie voor je communicatie. Voor mij gevoel ben je helemaal de verkeerde problemen aan het oplossen. Zijn je vragen theoretisch of ben je iets aan het programmeren?


PS.
Het is cijFer, met een F dus. Normaal zeur ik daar niet over maar mensen beginnen je na te praten.

[Nas T]

CAPSLOCK2000 schreef op vrijdag 23 juli 2010 @ 11:16:
[...]


Het kan, maar het is over het algemeen weinig efficient.
Proberen rekening te houden met alles wat in de toekomst nog zou kunnen gebeuren is een veel gemaakte programmeerfout. Een beetje vooruit kijken is prima, maar ga niet te ver. Als je denkt dat de nummers ooit opraken, maak ze dan langer. Maak in je eigen applicatie het veld 20 tekens lang en laat de computer de begin-nullen verbergen voor de gebruiker.
Er zijn voldoende oplossingen om met oneindig lange getallen te werken maar die hebben ook allemaal hun nadelen. Slecht programmeerwerk ga je er niet meer voorkomen.


[...]

Dan gebruik je compressie voor je communicatie. Voor mij gevoel ben je helemaal de verkeerde problemen aan het oplossen. Zijn je vragen theoretisch of ben je iets aan het programmeren?


PS.
Het is cijFer, met een F dus. Normaal zeur ik daar niet over maar mensen beginnen je na te praten.

Mijn vragen zijn theoretisch. Het 12NC systeem is een systeem wat werkt op een bepaalde manier.
Elke "regel" die het 12NC kent, brengt beperkingen met zich mee.
de 4-3-5 constructie, het maximum aantal van 12 getallen.
Nu willen ze hier het een en ander oplossen door een speciale reeks 12NC te reserveren, waardoor er 20 versies kunnen bestaan. Ik vind dat korte-termijn denken.
Die begin-nullen verbergen is weer om het probleem heen werken. Ja dat kan op zich wel, maar je verplaatst het probleem alleen maar, want je hebt een 12NC en een (stel) 13NC.
Dan krijgt een 12NC een 13NC-equivalent, dus dan is je 13NC een vervanging van je 12NC, dus alles waar ook maar iets van 12NC in zit, moet worden hergeprogrammeerd. Ook bij externe bedrijven, die moeten jouw nieuwe nummeringssysteem wel kunnen doorvoeren.
Op het moment dat je 13NC (en hoger!) een aanvulling is, hoeft er maar 1 keer grondig aangepast te worden.
Slecht programmeerwerk staat los van dit probleem. Ik doel op het systeem erachter. Het programmeerwerk is nu goed, het is gemaakt om met 12NC te dealen. En dat doet het. Het systeem van 12NC is te beperkt voor de praktijk. 13NC dan maar? Nee, kent ook zijn beperkingen. 100NC? Ook beperkt, plus wat doe je met het oude systeem? converteren? En bij externe bedrijven?

Wat bedoel je met rekening houden met alles wat er komt? Dat de tijd die er in gestoken moet worden zijn doel voorbij gaat schieten? Ik denk dat dat in dit geval de tijd wel waard is, aangezien dit iets fundamenteels betreft wat diepgeworteld zit in veel ondernemingen. Dan is het een stuk praktischer een oplossing te bedenken die door veel bedrijven gehanteerd kunnen worden. Dan hoeft het maar 1 keer bedacht te worden.
Ik heb het idee dat er in nederland misschien wel een paar honderd ondernemingen zijn die hier mee werken, dus een goede oplossing is, zacht uitgedrukt, erg praktisch.

Orion84 schreef op vrijdag 23 juli 2010 @ 09:43:
[...]

Zoals al eerder gezegd: Dat is een kwestie van de boel opslaan als string en speciale karakters introduceren die de verschillende onderdelen van de code markeren. Zodat je dus bijvoorbeeld iets krijgt als 1230-456-78901 (bedrijf-afdeling-product) en zodra je dan aan de duizendste afdeling toekomt wordt dat gewoon 1230-1000-45601.

Om te zorgen dat je systeem nog met de oude codes overweg kan interpreteer je elke 12 cijferige code als een code die geen speciale markers heeft en bestaat uit een blok van 4, een blok van 3 en een blok van 5.

Kijk, dat klinkt goed. Zoiets zou inderdaad aardig intelligent zijn. Dus "na" 12NC gebruik je een 4-4-5NC bijvoorbeeld. En dan kan de software simpelweg de 12NC herkennen en noteren als 111-222-33333
Dan zou bij het invoeren dus 3 velden moeten bestaan, maar dan zit je weer: 3 velden.
Waarom geen 4?

[Orion84]

Omdat je maar 3 aspecten wilt coderen in de string? Als je behalve bedrijf, afdeling en product bijvoorbeeld ook nog het land van herkomst wilt toevoegen, ja dan is het niet zo heel gek dat je dan je interface moet aanpassen lijkt me? Immers is de betekenis van de data veranderd. Ruimte scheppen voor grotere aantallen verandert de betekenis van de data niet, een nieuw veld toevoegen wel.

Als je dat ook af wilt vangen, dan moet je één invulveld maken en de persoon die het invult het aantal blokken laten bepalen door -'s te plaatsen. Alleen is dat niet echt heel erg gebruiksvriendelijk en juist door een relatief specifieke interface te gebruiken verklein je ook de kans op invoerfouten. Bovendien zul je in de achterliggende software sowieso wijzigingen hebben om met de nieuwe betekenis van de data om te gaan.

Grote flexibiliteit heeft z'n prijs in performance, gebruiksvriendelijkheid etc. Je zult dus van te voren goed na moeten denken welke mate van flexibiliteit vereist is met zicht op toekomstige veranderingen, zonder daarin door te draven.

Als je echt zulke flexibele vorm van gegevensrepresentatie wilt hebben, dan kan je bijvoorbeeld met XML achtige oplossingen aan de slag. Dan begin je met

XML:

<bedrijf>123</bedrijf>
<afdeling>3456</afdeling>
<product>1234</product>

waarbij je afspreekt welke attributen je gebruikt en wat voor type waarde er tussen de tags staat. Waarbij je voor die waardes een datatype kiest dat flexibel genoeg is voor de aantallen die je verwacht nodig te hebben. Als je dan op een gegeven moment ook het land wilt opslaan spreek je af dat je daar een nieuw attribuut voor gebruikt <land>42</land>. De oude gegevens zijn dan nog prima bruikbaar voor software die geen kennis heeft van het <land> attribuut en alle software die wel het land wil gebruiken kan dat attribuut toevoegen en lezen.

Maar zoals gezegd: dat heeft z'n nadelen. Zo kost het expliciet aangeven van de betekenis van bepaalde stukjes data een boel overhead. Bovendien wil je een gebruiker dit soort dingen niet handmatig laten intypen, dus moet je alsnog een interface bouwen die de juiste velden verzorgt en zo

[ Voor 47% gewijzigd door Orion84 op 23-07-2010 13:37 ]

[leuk_he]

De echte oplossing is dus bij een nieuw identificatie systeem geen attributen in het nummer systeem op te nemen. Die sla je maar in het systeem op, of neem je op in de interfaces als extra velden.

En een 13NC dan invoeren is niet de oplossing, want dan gaan wéér andere dingen gebruik daarvan maken, dan worden alle documenten daarmee beheerd. Gevolg: 14NC. Dan kan elk fysiek product zelfs een eigen nummer krijgen, "ruimte zat". Gevolg: 15NC. Etc.

Dat is dus je probleem. Niet het gebrek aan nummers, maar misbruik van de codes.

Maar om dat bij alle databasebeheerders in hun hoofd te krijgen mag je nog heel veel uren vergaderen. Je systemen hebben (disk) ruimte zat (iets wat niet het geval was toen 25 jaar terug de nummer systemen bedacht werden). Je wil een afdeling meesturen? neem een veld afdelings(nummer) in de interface op. Wil je een sorteer sleutel? neem die op in je applicatie. (niet in je #NR)

Als je dat dus doorvoert: Je systeem heeft het OUDE ID Cijfer nodig? neem dat op in de interface, niet altijd coderen in je nieuwe nummer. (Zal denk ik wel gebeuren, maar je moet dat oude nummer logica zo snel mogelijk los kunnen laten)

offtopic:
PS excuses voor cijver.. mijn spellingscontrole stond op Engels en door de grote hoeveelheid rode steepjes zag ik de fouten niet meer...

[Nas T]

Orion84 schreef op vrijdag 23 juli 2010 @ 13:27:
Omdat je maar 3 aspecten wilt coderen in de string? Als je behalve bedrijf, afdeling en product bijvoorbeeld ook nog het land van herkomst wilt toevoegen, ja dan is het niet zo heel gek dat je dan je interface moet aanpassen lijkt me? Immers is de betekenis van de data veranderd. Ruimte scheppen voor grotere aantallen verandert de betekenis van de data niet, een nieuw veld toevoegen wel.

Als je dat ook af wilt vangen, dan moet je één invulveld maken en de persoon die het invult het aantal blokken laten bepalen door -'s te plaatsen. Alleen is dat niet echt heel erg gebruiksvriendelijk en juist door een relatief specifieke interface te gebruiken verklein je ook de kans op invoerfouten. Bovendien zul je in de achterliggende software sowieso wijzigingen hebben om met de nieuwe betekenis van de data om te gaan.

Grote flexibiliteit heeft z'n prijs in performance, gebruiksvriendelijkheid etc. Je zult dus van te voren goed na moeten denken welke mate van flexibiliteit vereist is met zicht op toekomstige veranderingen, zonder daarin door te draven.

Als je echt zulke flexibele vorm van gegevensrepresentatie wilt hebben, dan kan je bijvoorbeeld met XML achtige oplossingen aan de slag. Dan begin je met

XML:

<bedrijf>123</bedrijf>
<afdeling>3456</afdeling>
<product>1234</product>

waarbij je afspreekt welke attributen je gebruikt en wat voor type waarde er tussen de tags staat. Waarbij je voor die waardes een datatype kiest dat flexibel genoeg is voor de aantallen die je verwacht nodig te hebben. Als je dan op een gegeven moment ook het land wilt opslaan spreek je af dat je daar een nieuw attribuut voor gebruikt <land>42</land>. De oude gegevens zijn dan nog prima bruikbaar voor software die geen kennis heeft van het <land> attribuut en alle software die wel het land wil gebruiken kan dat attribuut toevoegen en lezen.

Maar zoals gezegd: dat heeft z'n nadelen. Zo kost het expliciet aangeven van de betekenis van bepaalde stukjes data een boel overhead. Bovendien wil je een gebruiker dit soort dingen niet handmatig laten intypen, dus moet je alsnog een interface bouwen die de juiste velden verzorgt en zo

Dus met het XML-voorbeeld voeg je "tags" aan reeksen getallen. Ook niet leuk voor opslag.
Dan vind ik het systeem meerdere NC's naast elkaar waar elke NC zijn eigen "opmaak" heeft nuttiger.
bijvoorbeeld in jouw land-voorbeeld zou je dan van een 12NC een 14NC moeten maken. De software zou een 14NC herkennen, dit als 14 karakters wegschrijven en bij lezen moeten "weten" dat de 1e 2 karakters de reeks is voor het land.

Om invoeren eenvoudig te maken en efficiënt: als je een 12NC invoert, gewoon achter elkaar, je drukt enter, dan past hij de weergave aan: 1111 222 33333
Dus:
111122233333 [enter]
1111-222-33333

Wil je dan met landencode 42 (dus een 14NC):
42111122233333 [enter]
42-1111-222-33333

Dan hoeft je niet tussen elk veld de tab te gebruiken, en is het toch te zien voor de gebruiker wat deze typt.
In plaats van na het nummer een enter te geven, kan er ook een time-out plaatsvinden (zeg een halve seconde). Dan wordt als er een halve seconde niet wordt getypt gecheckt hoeveel cijfers er gebruikt worden, de juiste notering toegepast en als wordt doorgetypt valt de notering weg en wordt de cyclus herhaald.

leuk_he schreef op vrijdag 23 juli 2010 @ 14:13:
Dat is dus je probleem. Niet het gebrek aan nummers, maar misbruik van de codes.

Maar om dat bij alle databasebeheerders in hun hoofd te krijgen mag je nog heel veel uren vergaderen. Je systemen hebben (disk) ruimte zat (iets wat niet het geval was toen 25 jaar terug de nummer systemen bedacht werden). Je wil een afdeling meesturen? neem een veld afdelings(nummer) in de interface op. Wil je een sorteer sleutel? neem die op in je applicatie. (niet in je #NR)

Als je dat dus doorvoert: Je systeem heeft het OUDE ID Cijfer nodig? neem dat op in de interface, niet altijd coderen in je nieuwe nummer. (Zal denk ik wel gebeuren, maar je moet dat oude nummer logica zo snel mogelijk los kunnen laten)

Is het probleem dat de codes worden "misbruikt" of dat de codes misbruikt kunnen worden. Het is ook fout om geen misdaad te plegen, en hoe erg de straffen ook zijn, ze vinden al-tijd plaats. Dat is de mens. Dat is al eeuwen/millenia zo, dus ik ga niet naïef daarover discussiëren, ik los het probleem op. Linksom of rechtsom.
Dat doorvoeren kan de nodige jaren/decennia nodig hebben, daar ben ik zeker van. Alle software zal herschreven moeten worden, maar mijn advies: pak dat grondig aan.

Samenvattend:

1 invoerveld, "oneindig" lang.
2 Software kijkt wat er wordt getypt, past de juiste notering toe naar aanleiding van hoeveelNC er is getypt en geeft de ##NC op de juiste manier weer.
3 De manier van weergeven zit dus niet bij de nummerreeks opgeslagen, maar hangt af van welke ##NC er wordt gebruikt.
4 Er kunnen "oneindig" veel ##NC's worden gebruikt, doordat de notering van elke ##NC wordt vastgelegd en er oneindig veel toegevoegd kunnen worden

Op die manier is het gebruiksvriendelijk, oude NC's worden geen nieuwe NC's en oude NC's kunnen blijven bestaan, de opslag vormt geen probleem.


Zie ik nog iets over het hoofd? Zijn er nog nadelen aan dit systeem? Ik ben geen programmeur, ik heb er weinig ervaring mee (Excel VBA is het zwaarste wat ik heb geprogrammeerd), dus het spijt me als ik iets totaal verkeerd beredeneer.

[ Voor 13% gewijzigd door Nas T op 23-07-2010 14:46 ]

[Orion84]

Dan koppel je dus de interpretatie / het formaat aan de lengte van de code. Maar wat nou als je een applicatie hebt die niet met landen aan de slag wil, maar wel twee extra cijfers nodig heeft om producten te kunnen blijven tellen? Dan kan je niet simpelweg een 14NC van 12345671234567 gebruiken, want een 14NC wordt geinterpreteerd als 12-3456-712-34567 met de 12 als landcode en nog steeds maar 5 cijfers voor het product.
En wat als een ander stuk applicatie in plaats van een tweecijferige landcode een tweecijferige kleurcode wil toevoegen (ik noem maar iets). Ga je die kleurcode dan maar in drie cijfers zetten, zodat je een 15NC krijgt die je wel kan herkennen?

Je moet dan voor elke unieke interpretatie van de code een aparte lengte gaan hanteren, ook al is die lengte mogelijk totaal niet nodig voor de betreffende data. Dat lijkt misschien niet zo'n ramp, maar wat als er al duizenden formaten vastgelegd zijn, maar jij werkt nog met 12NC's waar je 1 cijfer aan toe wilt voegen. Dan moet je ineens omschakelen naar 1001NC's. Dat is niet bijster efficient natuurlijk, waarmee we weer terugkomen op het punt dat flexibiliteit een prijskaartje heeft.

Zoals leuk-he al aangeeft kleven er gewoon hele grote nadelen aan het opslaan van allerlei informatie in een numeriek ID. Dat moet je gewoon niet willen, daar moet je gestructureerde datatypes voor gebruiken (al zijn er vast specifieke uitzonderingen te bedenken). En of je die dan opslaat als XML of in een DB, dat is een verhaal apart.

Edit: gestructureerde datatypes worden uiteindelijk in het geheugen ook opgeslagen als rijtjes bits, in zekere zin vergelijkbaar met numerieke codes. Wat jij nu in zekere zin voorstelt is dat gebruikers die numerieke codes met de hand moeten invoeren etc. zodat je niet beperkt wordt door een abstractielaag die een specifieke set datatypes aanbiedt. Dat is misschien leuk met codes van 12 cijfers, maar op een gegeven moment loopt dat totaal uit de hand natuurlijk. Het is echt compleet ondoenlijk. Als het echt zo handig was dan was er nooit iemand op het idee gekomen om die abstractielaag te ontwikkelen, dan zaten we nog steeds in de situatie dat iedere gebruiker gewoon zijn eigen programma's in systeemtaal schreef en samen met een handmatig ingetypte reeks cijfers (de data) aan de computer voerde.

Gelukkig heeft men ingezien dat abstractie wel degelijk nuttig is. Het maakt het programmeren en het gebruik makkelijker, doordat er een duidelijke expliciete structuur aanwezig is, in plaats van allerlei impliciete structuur. Het voorkomt daardoor ook fouten; één typfoutje in jouw voorstel geeft mogelijk een totaal andere interpretatie van de data.

[ Voor 39% gewijzigd door Orion84 op 23-07-2010 15:14 ]

[Nas T]

Orion84 schreef op vrijdag 23 juli 2010 @ 14:53:
Dan koppel je dus de interpretatie / het formaat aan de lengte van de code. Maar wat nou als je een applicatie hebt die niet met landen aan de slag wil, maar wel twee extra cijfers nodig heeft om producten te kunnen blijven tellen? Dan kan je niet simpelweg een 14NC van 12345671234567 gebruiken, want een 14NC wordt geinterpreteerd als 12-3456-712-34567 met de 12 als landcode en nog steeds maar 5 cijfers voor het product.
En wat als een ander stuk applicatie in plaats van een tweecijferige landcode een tweecijferige kleurcode wil toevoegen (ik noem maar iets). Ga je die kleurcode dan maar in drie cijfers zetten, zodat je een 15NC krijgt die je wel kan herkennen?

Je moet dan voor elke unieke interpretatie van de code een aparte lengte gaan hanteren, ook al is die lengte mogelijk totaal niet nodig voor de betreffende data. Dat lijkt misschien niet zo'n ramp, maar wat als er al duizenden formaten vastgelegd zijn, maar jij werkt nog met 12NC's waar je 1 cijfer aan toe wilt voegen. Dan moet je ineens omschakelen naar 1001NC's. Dat is niet bijster efficient natuurlijk, waarmee we weer terugkomen op het punt dat flexibiliteit een prijskaartje heeft.

Zoals leuk-he al aangeeft kleven er gewoon hele grote nadelen aan het opslaan van allerlei informatie in een numeriek ID. Dat moet je gewoon niet willen, daar moet je gestructureerde datatypes voor gebruiken (al zijn er vast specifieke uitzonderingen te bedenken). En of je die dan opslaat als XML of in een DB, dat is een verhaal apart.

Ik had dat zelf ook bedacht net. Toen bedacht ik me: dat zal nu niet voorkomen en als dat is dan kun je daar met een extra nummer of letter wel omheenwerken. Maar goed: dan gebeurt er wat er nu ook gebeurt.

Misschien dan toch met de "tags" werken: Mocht deze situatie voorkomen, dan kun je dus een tag toevoegen aan je 13NC (want je 12 NC was niet voldoende en 13NC t/m 1000NC is in gebruik).
Als er geen tag aan hangt, dan is het een "standaard" 13NC, hangt er wel een tag aan, krijgt deze weer zijn eigen specifieke afhandeling. Dan hoeven de eerste reeks ##NC's geen tag te hebben, en mocht er nog een identieke nieuwe ##NC bedacht gaan worden, krijgt deze een tag ter onderscheid.

Bij het intikken zul je als je 13 cijfers hebt getypt kort een menuutje krijgen waarin je kunt kiezen over welk specifiek 13NC het gaat.

True?

EDIT (n.a.v. edit van de post hiervoor):
Die abstractie zorgt voor extra data, welke nodig is en voor zaken uit het verleden veranderd moet worden.
Dus als er geen extra data is, het systeem de notering "standaard" laten afhandelen, bij een tag: specifieke afhandeling.

En bij het typen dacht ik eraan dat het invoerveld de weergave van het getypte "on the fly" aanpast.
Bijvoorbeeld na een halve seconde inactiviteit te kijken welk ##NC er is getypt en de juiste weergave toe te passen.
Ik typ:
123456789012 (halve seconde wachten) en in het invoerveld verschijnt: "1234-567-89012"
Typfoutjes zijn dan veel sneller te zien.

Op het moment dat er dan een 12NC code is en een 12cijferige code, op de volgende wijze bijvoorbeeld:
12NC: 1234-567-89012
12 cijferige code: 1234-5678-9012
Dan zou je na het typen een menu krijgen met de opties. Heb je de optie gekozen, dan wordt de juiste weergave toegepast.
Als opslag "ziet" dat er zo uit:
12NC is "standaard", dus: 123456789012
de 12cijferige code krijgt een tag, dus zo: <tag>123456789012<tag>

Dan kost de 12cijferige code wel meer data, maar dan hoeft de 12NC niet aangepast te worden.

[ Voor 17% gewijzigd door Nas T op 23-07-2010 15:32 ]

[Orion84]

Als je de abstractielaag op de juiste manier opzet dan kan een nieuwe versie van je datastructuur best backwards compatible zijn.

En de overstap van gegevens als onderdeel van de code, of ergens los is niet eens zo groot. De 12NC's kunnen gewoon blijven bestaan als productcodes waarbij je de gegevens mogelijk ook nog ergens los opslaat, of ze gewoon uit de code blijft halen. Naast die 12NC spreek je dan een toekomstbestendig productID type af waar je geen structuur en gegevens meer in verstopt, maar waarbij je gewoon doornummert en de overige gegevens gewoon ergens apart opslaat op zo'n manier dat je ze aan de hand van het ID kan opvragen zodra je ze nodig hebt.

Het enige wat ik me voor kan stellen dat je aan structuur in een productID wilt hebben is een prefix die het bedrijf of iets dergelijks aangeeft (zoals bij MAC adressen, maar ook bij EAN geloof ik). Anders wordt het wat lastig om door te nummeren, aangezien je dan bij elk nieuw product moet zien uit te vinden wat bij alle betrokken bedrijven het laatste nummer is dat gebruikt is, zonder dat ondertussen iemand anders ook een nieuw product een nummer aan het geven is en zo.

[Reptile209]

Nas T schreef op vrijdag 23 juli 2010 @ 15:22:
[...]

Ik had dat zelf ook bedacht net. Toen bedacht ik me: dat zal nu niet voorkomen en als dat is dan kun je daar met een extra nummer of letter wel omheenwerken. Maar goed: dan gebeurt er wat er nu ook gebeurt.

Misschien dan toch met de "tags" werken: Mocht deze situatie voorkomen, dan kun je dus een tag toevoegen aan je 13NC (want je 12 NC was niet voldoende en 13NC t/m 1000NC is in gebruik).
Als er geen tag aan hangt, dan is het een "standaard" 13NC, hangt er wel een tag aan, krijgt deze weer zijn eigen specifieke afhandeling. Dan hoeven de eerste reeks ##NC's geen tag te hebben, en mocht er nog een identieke nieuwe ##NC bedacht gaan worden, krijgt deze een tag ter onderscheid.

Bij het intikken zul je als je 13 cijfers hebt getypt kort een menuutje krijgen waarin je kunt kiezen over welk specifiek 13NC het gaat.

True?

Nope. Want de identificatie zou je ook in een eerste digit kunnen stoppen, zodat je effectief een 14NC maakt. Maar wat nou als je meer dan 10 typen krijgt... snap je waar ik heen wil? Ook het keuze-menu dat je suggereert gaat beperkingen opleveren. Wat nou als er een nieuwe keuze bij komt? Kan je dan het menu uitbreiden? En de nieuwe functionaliteit aanpassen? En dat allemaal zonder dat de hele app op de schop moet?

[leuk_he]

Nas T schreef op vrijdag 23 juli 2010 @ 14:36:
[...]
Is het probleem dat de codes worden "misbruikt" of dat de codes misbruikt kunnen worden. Het is ook fout om geen misdaad te plegen, en hoe erg de straffen ook zijn, ze vinden al-tijd plaats. Dat is de mens. Dat is al eeuwen/millenia zo, dus ik ga niet naïef daarover discussiëren, ik los het probleem op. Linksom of rechtsom.
Dat doorvoeren kan de nodige jaren/decennia nodig hebben, daar ben ik zeker van. Alle software zal herschreven moeten worden, maar mijn advies: pak dat grondig aan.

Het probleem is dat je (ENORME) gaten in je nummerreeks krijgt als je de nummers gaat misbruiken voor andere doelen.

Je hebt nu aan 10¹³niet genoeg. Weet je hoeveel dat is? Dat is voor elk persoon op aarde 2000 items... Dat is een database van tientallen Terabytes enkel om de nummertjes in op te slaan.

Daarom is het illegaal. De oplossing is niet een moeiijke codering te gebruiken van die velden, maar de logica van de velden los te laten.

Ja, ik werk genoeg met enterprice systemen om te weten dat je nog tientallen jaren vast zit aan de oude nummering en dat je inderdaad bepaalde ranges zult moeten truuken om de gaten te kunnen gebruiken en/of een voorloopcijver moet gebruiken. Maar zolang je dat nummer blijft misbruiken zal je nummerreeks hard groeien. Je gaf zelf al aan dat je niet uitsluit dat de enorme nummerruimte ook wel verbruikt zal worden

En je kunt nu wel definieren dat het nummer 20 posities aan moet kunnen, maar dat is wellicht duurder dan nodig. Wellicht kunnen veel applicaties reeds 14 posities aan, maar moeten wel worden aangepast als je naar (onnodig) 20 posities. En wellicht denk je dat je het op 20 posities hebt gedefineerd, maar als mensen 5 jaar lang 14 positesin een artikel id zien zul je zien dat zodra je een 15 posities introduceerd dat er toch een paar nieuwe applicaties gaan struikelen over 5 jaar.

Dan zul je evengoed aan allerlei interfaces moeten gaan knutselen. (men zal afdeling/bedrijfstak/groep moeten gaan invoeren/tonen op lijsten). Maar je kunt nu wel opeens produkten verplaatsen naar een andere groep omdat hun nummer niet wijzigt, maar enkel de groep, en dat zal correct op rapportages getoond worden.

Tot zover de nummer politie.

[DataGhost]

Het kan aan mij liggen maar ik snap het probleem niet helemaal. Ik ga even uit van een database. Het eerste wat ik daarover leerde was dat je voor ID's zogenaamde atomaire waarden gebruikt, dus geen onzin zoals bedrijf-afdeling-nummer, maar gewoon een *ander* nummer waar vervolgens bedrijf en afdeling (en nummer) aan gekoppeld worden.

Als je nou gewoon van dat niet-atomaire nummersysteem afstapt en een 64-bits integer gebruikt om je ID op te slaan en wat extra velden die de afzonderlijke informatie aangeven is er niet bijster veel aan de hand, toch? Als je de oude nummers ook echt moet houden zou ik zeggen dat je 12NC (en 13NC?) gewoon opslaat as-is en voor de rest begint bij 10.000.000.000.000 ("14NC") en van daaraf verder nummert. Ik snap niet waarom je zo hard op die voorloopnullen lijkt te hameren maar wat mij betreft is dat iets wat je in je presentatie afhandelt. Als je een 64-bits integer gebruikt kan je tot 18.446.744.073.709.551.615 gaan, dus "19NC" voor de zekerheid.

Mochten die extra velden een ontzettend groot obstakel zijn kan je natuurlijk alsnog voor die 64-bits integer kiezen zodat je werkelijk alles op kan slaan en voor mijn part pruts je er dan nog een, twee, drie of vier bytes extra aan vast (resp 256, 65.536, 16.777.216 en 4.294.967.296) om aan te geven *welk* formaat gebruikt wordt, bijvoorbeeld xx-yy-zzzz, xxx-yy-zzz, w-x-y-zzzzzzzz of weet ik veel wat. Dan zit je in totaal alsnog aan de 12 bytes die je nu kwijt bent, terwijl je opeens zowel 12NC, 13NC, XNC (X<=19) als ISBN-13 en nog meer meuk in bijna elk formaat wat je maar kan verzinnen kunt opslaan.

Misschien denk ik te simpel en mis ik iets cruciaals maar ik zit me echt ontzettend te verbazen over hoe gigantisch je een probleem kan maken van (zoals ik het zie dus) niks.

[leuk_he]

DataGhost schreef op vrijdag 23 juli 2010 @ 18:02:
Misschien denk ik te simpel en mis ik iets cruciaals maar ik zit me echt ontzettend te verbazen over hoe gigantisch je een probleem kan maken van (zoals ik het zie dus) niks.

Geloof me, het oprekken van een nummer van 13 naar 14 posities over meerdere applicaties heen is een dure operatie. x tabbellen * uren , y schermen * uren, z interfaces * uren, loopt al gauw in de
papieren.

Niet moeilijk, wel duur.

[DataGhost]

Ja okee maar ik dacht dat we er al over uit waren dat dat in ieder geval nodig ging zijn en als je toch al aan de slag gaat kan je het natuurlijk beter structureel oplossen. Wellicht dat het mogelijk is anders een soort vertaal-laag ertussen te hangen maar dat hangt natuurlijk weer van het ontwerp af. Ik ging er misschien wel iets teveel van uit dat het probleem eigenlijk alleen op de backend sloeg en dat dat de oplossing (daar) makkelijk-ish maakte.

[ Voor 10% gewijzigd door DataGhost op 23-07-2010 21:31 ]

[Nas T]

Ik ben morgen e weken op vakantie, dus ik reageer niet (zo snel).

Tot nu toe zie ik de oplossing als volgt:
intelligente interfaces die 12NC als data herkent doordat het een 12cijferig getal is als opgeslagen.
Er mag nog een ander 12 cijferige code bestaan, deze krijgt bij opslag een tag ter herkenning.

Zo ook bij alle andere codes. De eerste krijgt geen tag, elke evenveel-cijferige code wel bij opslag.
As er al evenveel cijferige codes bestaan, moet worden bepaald welke wel en welke niet een tag krijgt. Dat moet dan toegepast worden op oude data.

De interface zijde is intelligent: tellen hoeveel cijfers er zijn getypt en de juste weergave toepassen.
Bij meerdere mogelijkheden voor weergave via een pop-up menu de juiste weergave kiezen. Dat menu kan oneindig lang in principe. de weergave van het nummer wordt toegepast zodat de gebruiker op juistheid kan controleren.

Al het commentaar hier op is heel erg wenselijk, maar het kan dus lang duren voordat ik reageer.
Alvast heel erg bedankt voor alle zeer nuttige reacties!

[Nas T]

Ik ben weer terug van vakantie, de discussie mag wat mij betreft weer aangewakkerd worden.
Of niemand moet nuttige inbreng hebben, maar daar twijfel ik niet aan.