[BC3] Gaten in access autonummering voorkomen?

[Chillout]

Wanneer ik Access autonummering gebruik, en ik een record delete, krijg je dus eigenlijk een gat in de nummering.

Het is namelijk de bedoeling, dat hij de gaten in de nummering opvult.

Voorbeeld:
Nu is het zo:
1
2
3
4
5

als ik 4 verwijder, krijg je dus alsvolgt:
1
2
3
5

Wanneer ik iets nieuws toevoeg, moet dit dus met het unieke nummer 4 beginnen.
Hoe is dit met autonummering te verkrijgen?
Wanneer dit niet met autonummering mogelijk is, hoe kan het dan wel?

Alvast bedankt.

[Verwijderd]

auto increment uitzetten
en uniek aanzetten

zoiets
maar maakt het veel uit dat er wat gaten in je nummering zitten ?

[Chillout]

ja het maakt veel uit. De computers van het betreffende bedrijf hebben namelijk niet al te veel capaciteit, en het is onderdeel van de opdracht dat we voorkomen dat er gaten in de database komen.

ps: waar kan ik die auto increment vinden?

[tomato]

In 99 of zeg maar 100 procent van de gevallen hoor je dit helemaal niet te willen. Ik kan geen goede reden bedenken waarom je dit zou willen. Misschien gebruik je het veld niet als key (wat waarschijnljik wel het geval is), maar dan nog snap ik absoluut niet waarom je dit zou willen.
Maar goed, deze discussie hebben we hier al vaker meegemaakt.

[Chillout]

inderdaad, en het gaat me er niet om, dat we hierover gaan discussieren, maar dat ik een antwoord krijg...

[Bezulba]

mischien is het ook gewoon NETJES om de concistentie (oid) te bewaren? 1 3 5 19 enzovoorts ziet er niet uit. ik kan best begrijpen wrom ie het wil..

[Chillout]

ja dat ook...
hehe, eindelijk iemand die het met me eens is...

Iemand met een antwoord? Ik heb even geen zin in discussie, ik wil gewoon wat hulp.
Alvast bedankt.

[Verwijderd]

Op donderdag 19 april 2001 11:19 schreef Chillout het volgende:
ja dat ook...
hehe, eindelijk iemand die het met me eens is...

Iemand met een antwoord? Ik heb even geen zin in discussie, ik wil gewoon wat hulp.
Alvast bedankt.

Weet je wel dat dit extra rekenkracht kost, en de uitwerking hetzelfde blijft Bovendien zorg je voor een hogere foutgevoeligheid. Als je nl. in tabel1 een id wijzigt, zal deze in een aansluitende tabel tevens moeten worden gewijzigd, aangezien je anders corrupte koppelingen krijgt.

[tomato]

*zucht*
Om het mooi doet er niet toe, bij het gebruik van je applicatie heb je niets te maken met die nummers. Maar ik zal m''n mond wel houden, laat alleen dusty het niet horen...

[Chillout]

nee, ik heb het niet over dat dan alle nummers moeten doorschuiven, ik zeg dat dat gat wat er dan zit, opgevuld moet worden wanneer een klant in de toekomst wordt toegevoegd.

Wanneer 4 dus is verwijderd, zal een volgende keer een nieuwe klant het nummer 4 krijgen.

[Chillout]

Ik heb wel te maken met die nummers, het zijn de unieke klantnummers, die de klant iedere keer als hij een opdracht heeft, aan mij doorgeeft.

En het is voor een schoolproject, en wat er onder onze access-app zit, moet dus WEL mooi zijn...

[Chillout]

en ik benadruk nog een keer: het is een eis van de opdrachtgever (onze leraar)

[Verwijderd]

Je kunt een list maken als volgt. (kan ook een array zijn, dat maakt niet uit).

Je pakt met Max(recordid) de maximale id waarde. Daarna ga je een loop uitvoeren van 0 tot Max(recordid) en voert een ListFind functie uit op de recordset.

Als er op een bepaald moment een gat zit tussen je id''s (ListFind geeft 0 of false op) kun je dit ListItem gebruiken als ID.

Je kunt ook een andere methode gebruiken, en dat is niet het record verwijderen, maar leegmaken en toch laten staan. Met een query pak je het eerste lege record en deze kun je gebruiken om je data in kwijt te raken.

[tomato]

Op donderdag 19 april 2001 11:28 schreef Chillout het volgende:
Ik heb wel te maken met die nummers, het zijn de unieke klantnummers, die de klant iedere keer als hij een opdracht heeft, aan mij doorgeeft.

En het is voor een schoolproject, en wat er onder onze access-app zit, moet dus WEL mooi zijn...

Die klantnummers worden dus ook naar buiten gebruikt. Dan wordt het een ander verhaal, ik zou het klantnummer niet als sleutel gebruiken (weet niet of je dat van plan was).

Tabel Klant
id (pk, uniek, autonummering)
klantnummer (uniek)
verdere velden

Met de waarde van de primary key heb je dan dus NIETS te maken bij het gebruik van je applicatie, en voor mijn part mogen deze ook gevuld zijn met 7, 23, 5, 9999, of zelfs abc als je dat wilt. Niet mooi bestaat hier niet en is dus niet lelijk.
Voor je klantnummer veld is het een ander verhaal. Is het echt zo belangrijk dat elk klantnummer bestaat? Zoja, heb je toch ook een probleem van het moment dat er een klant verwijderd tot het moment dat er weer een toegevoegd wordt, of is het dan toch niet zooo heel erg? Is het eigenlijk meer voor het mooi naar buiten toe? Als het om klantnummers gaat zou ik overigens niet bij 1 beginnen maar bij 10000 ofzo, staat ook al een stuk mooier (ik ben trouwens nog nooit een bedrijf tegengekomen dat aaneensluitende klantnummers belangrijk vond...).

[Chillout]

Hmm, daar zit wat in...
Het bedrijf hanteert nu namelijk codes alsvolgt: A120 voor Akzo, en C340 voor bijvoorbeeld CCV. Ik was al van plan om deze naast elkaar te houden, omdat ze dan hun eigen oude nummering kunnen aanhouden.

In dat geval hebben we dus, net zoals jij zegt: 1 unieke ID en 1 klantnummer.

Helaas was niet iedereen in de projectgroep het daarmee eens, aangezien je dan 2 keer een nummer toewijst, en dat is dubbel...

Maar goed, het blijft nog steeds de opdracht dat je die gaten moet voorkomen...

[BC3 Victim]

Op donderdag 19 april 2001 11:01 schreef Chillout het volgende:
ja het maakt veel uit. De computers van het betreffende bedrijf hebben namelijk niet al te veel capaciteit, en het is onderdeel van de opdracht dat we voorkomen dat er gaten in de database komen.

autoincrement of niet heeft niets te maken met gaten in het bestand of zo. bij MS Access is het zo dat :
1) records niet allemaal even groot hoeven te zijn.
2) een recordnummer niets te maken heeft met de plaats van het record in het bestand.

als je ruimte wilt besparen moet je zo af en toe de database comprimeren of geen Access gebruiken.

keurig oplopende recordnummers hebben helemaal geen nut. dat kan je namelijk gewoon aan de database-engine vragen en het is een verspilling van ruimte die op te slaan.

[BC3 Victim]

eigenlijk mag je helemaal niet deleten uit deze tabel. Stel je hebt een factuur van klantnr 4 met factuurnr inv0003. Je gooit klantnr 4 weg, maakt een nieuwe klant aan onder klantnr 4, want id is vrij.
Als je nu de factuur inv003 linkt met je klantnr tabel (om naw gegevens te krijgen) krijg je wel mooi de foute naw gegevens.

[tomato]

Ja, daar heeft watnou wel gelijk in, eigenlijk mag je een klant nooit verwijderen uit je systeem. Echt oude klanten kun je misschien wel op inactief zetten (voeg een veld ''actief'' met default waarde ''1'' toe) zodat je in je applicatie in staat bent alleen actieve klanten standaard te tonen...

[Verwijderd]

hmm ik wil even een opmerking plaatsen..
de discussie over wat je wel en niet moet doen omdat het "netter" staat gingen we niet voeren maar het zal je database een worst zijn of het id nu 1,2,3,4,5 of 1,5,7,9,10 is hoor..

Maar dat terzijde... ik wou even opmerken dat het misschien verstandig is een naast je applicatie die gewoon auto_increment id geeft en als je delete gewoon een record er tussen uit haalt.

Schrijf een ander stukje code om het eens in de zoveeltijd te defragmenteren als het ware.

Zodat ie dus.... een leeg id zoekt. de laatste record pakt. die daar voor in de plaats zet en alle andere tabellen met dat id weer update.......

Ik weet het het is misschien niet TOP... maarja ik vind het idee van ID''s netjes op laten lopen ook niet echt top... misschien gaat er hierdoor een lampje bij je branden.

Ik denk dat dit namelijk sneller is dan dat je programma code dit bij elke run moet gaan bepalen.

Nogmaals, don''t shoot me... ik wou alleen maar proberen te helpen

[Verwijderd]

*hihi* wat een onzin allemaal.. unieke id''s opvullen, LOL

Maar goed.. wat je ook zou kunnen doen is een tabel maken met de getallen 1 tot 10 miljoen er in en elke keer als je een record aanmaakt trek je daar het laagste getal uit en dan wis je die. Als je een record wist zet je dat getal terug..

Als die 10e6 getallen op zijn laat je je progje gewoon 10e6 nieuwe getallen er in zetten.

[Verwijderd]

Ik heb het helemaal eens met de stelling dat gaten in een ID veld totaal niet erg zijn.

Als je een doorlopend en niet onderbroken nummering wil hebben, maak dan een extra nummerveld aan met die nummerreeks, als een kandidaat sleutel, die dan NIET gebruikt wordt om relaties naar andere records te maken (aangezien je anders met je referentiele integeriteit in de knoop komt.

Om een record te deleten kun je evt. een delete veld maken met daarin true / false, en op basis daarvan wel of niet tonen. Als je echt je klant wil verwijderen, realiseer je dan ook dat je alle gerelateerde data in andere tabellen ook moet verwijderen.

Als je dus persee dat volgnummers probleem wil oplossen, gebruik dan niet een auto increment veld maar gewoon een nummer veld. Maak een extra tabel met daarin een record voor ieder volgnummer dat hoort bij een gedelete record en kleiner is dan het grootste volgnummer.

Als je de oplossing gebruikt met een ''delete'' flag in ieder record hoeft dat niet. Je kunt dan aan de hand van een query alle deleted records opzoeken, deze sorteren op volgnummer, en het eerst beschikbare volgnummer pakken. Bedenk wel dat je op dat moment het volgnummer van dat deleted records moet omzetten in een ''niet-valid'' waarde, aangezien hij anders bij een volgende zoektoch naar het eerst beschikbare volgnummer hetzelfde nummer vindt.

Zoals je ziet heb je bij al deze oplossingen juist MEER overhead dan bij een simpel volgnummer waarin gaten vallen door gedelete records.

Enjoy

[dusty]

Op donderdag 19 april 2001 11:27 schreef tomato het volgende:
*zucht*
Om het mooi doet er niet toe, bij het gebruik van je applicatie heb je niets te maken met die nummers. Maar ik zal m''n mond wel houden, laat alleen dusty het niet horen...

Ik weiger zelfs te antwoorden..

Darn toch gedaan.

Naja dan toch maar:

Voor de load van de database maakt het absoluut niet uit. De ID behoort ook alleen maar een ID te zijn die binnen de database zelf betekenis heeft. Dat deze ID als klantnummer wordt gebruikt is een erg domme fout. Immers laat je ook de oude klanten in je systeem zitten. Immers krijgt elke klant een unieke klantnummer. Je kan moeilijk je klantnummers overnieuw gaan gebruiken want over 2 jaar kan wel eens een klant zeggen hey dit was mijn klantnummer. En ik heb dit probleem.

Als je dus daaraan gaat kloten om het "zo mooi" te maken heb je juist meer kans op consistentie fouten.

Het enigste wat je bereikt is dat je extra cpu tijd gaat genereren.

Dat het een eis is van de opdrachtgever (leraar) is niet goed genoeg. Jij als IT-professional hoort erop te wijzen op problemen die ervan kunnen komen. Ook als ze niet direct met IT te maken hebben. Er zullen meer redenen te bedenken zijn waarvoor je het juist niet moet doen dan wel.

Ik weet het.. sommige dingen zijn al gezegd maar ik loop te reageren en loop dan de reacties naar beneden af zodra ik klaar ben met een gedeelte reageren

wat je ook zou kunnen doen is een tabel maken met de getallen 1 tot 10 miljoen er in en elke keer als je een record aanmaakt trek je daar het laagste getal uit en dan wis je die. Als je een record wist zet je dat getal terug

Wat nog steeds beter zou zijn is dan een "tempnumber" tabel aanmaken. waarin je een waarde gooit zodra je een record verwijderd.
Moet je een nieuwe klant toevoegen pak je de laagste waarde uit die tabel.
Is de tabel leeg neem je de max waarde van je klantnummers en tel je er een bij op.

Uiteindelijke Conclusie: tegen de leraar in gaan en beargumenteren waarom het juist slecht zou zijn om klantnummers als de ID te gebruiken. De klant heeft over het algemeen niets met de database opvulling te maken. Zolang jij netjes een database model maakt en normaliseert is er niets fout aan.

niet slecht voor een persoon die niet wou reageren.

[Crazy D]

Of zeg ''m dat het alleen kan met MS SQL. Wat zo is trouwens. Ik ken geen statement om Access eventjes niet het autonumber veld te laten zetten, om ''m zelf tee kunnen zetten. Access zelf zal die gaten niet opvullen. In SQL kun je _wel_ eventjes het auto-increment veld ''stoppen'', record inserten, en daarna weer ''aanzetten''. Ik zou ff moeten kijken in books online waar ik dat ook alweer heb gelezen.

Maarre ik ben het met 1 van de voorgangers eens, jij als IT professional zou je leraar er op moeten wijzen dat dit nergens over gaat, en dat ie wel met hele goeie argumenten moet komen om een autonumber veld van Access te willen gebruiken, en geen tussenruimtes wil hebben tussen de nummers.

[Chillout]

hmmkay, ik neem het morgen in de vergadering op.

Mijn voorstel wordt dus: geen idnummer als klantnummer, en gewoon een extra kolom in de tabel met een echt klantnummer, wat dan naar de klant gaat.
Hmkay, bedankt allemaal voor de inbreng.