Mysql automatisch incrementen fix?

[Verwijderd]

Hey Tweakers,

Ik heb een vraag, ik heb een soort systeem gebouwt (ben niet de beste developer dus please dont blame me). Maar dat systeem maakt regels aan, die krijgen ook automatisch een ID meegegeven vanuit de database gewoon via dat auto increment gebeuren, alleen als ik dan een regel verwijder en weer een nieuwe toevoeg gaat die regel niet op die plek, en dat ziet er een beetje lelijk uit want dan heb je :

Regel 1
Regel 2
Regel 4
Regel 8
zoiets bijvoorbeeld.

En je kan het wel handmatig regelen, maar automatisch is toch het fijnst. Weten jullie hier een fix voor dat ID's automatisch opschuiven naar de juiste plek? Ik hoop dat jullie begrijpen wat ik bedoel op me vorige ticket werd heel veel gereageerd en dat waardeer ik echt! Alvast bedankt

[CyBeR]

Ten eerste hebben we hier geen tickets maar topics, en ten tweede als je dat per se wilt (wat compleet nutteloos is), dan is daarvoor

SQL:

ALTER TABLE tablename AUTO_INCREMENT = 1

waar 1 is het getal waar je verder wilt gaan.

Als je wilt dat dat automatisch gebeurt elke keer dat je iets verwijdert: dat kan niet.

[ Voor 19% gewijzigd door CyBeR op 04-05-2016 02:55 ]

[Cyphax]

Dat automatische ID is een betekenisloze sleutel, waarmee gaten eigenlijk ook geen betekenis hebben. Moet je ook eigenlijk zo laten.

[Tsurany]

Het hele idee van zo'n id is dat het een unieke sleutel is. Dat aanpassen moet je echt niet willen, dan gaat je data door elkaar lopen. Als je nieuwe regels het id van ouderen laat aannemen kan je programma aardig in de war raken of verkeerde data gaan retourneren omdat je queries uitvoert op id's die inmiddels verwijdert zijn en waar later nieuwe voor in de plaats zijn gekomen.

Dit id is namelijk een unieke sleutel, geen rij nummer zoals in bijvoorbeeld Excel. Daar moet je het ook niet voor gaan gebruiken.

[ Voor 14% gewijzigd door Tsurany op 04-05-2016 07:41 ]

[eheijnen]

Verwijderd schreef op woensdag 04 mei 2016 @ 02:10:
Hey Tweakers,

Ik heb een vraag, ik heb een soort systeem gebouwt (ben niet de beste developer dus please dont blame me). Maar dat systeem maakt regels aan, die krijgen ook automatisch een ID meegegeven vanuit de database gewoon via dat auto increment gebeuren, alleen als ik dan een regel verwijder en weer een nieuwe toevoeg gaat die regel niet op die plek, en dat ziet er een beetje lelijk uit want dan heb je :

Regel 1
Regel 2
Regel 4
Regel 8
zoiets bijvoorbeeld.

En je kan het wel handmatig regelen, maar automatisch is toch het fijnst. Weten jullie hier een fix voor dat ID's automatisch opschuiven naar de juiste plek? Ik hoop dat jullie begrijpen wat ik bedoel op me vorige ticket werd heel veel gereageerd en dat waardeer ik echt! Alvast bedankt

Dat is niet mogelijk. Auto Increment is een uniek identificatienummer dat door het systeem wordt toegewezen en uitsluitend wordt opgehoogd bij de volgende insert-opdracht. Dit ID is uitsluitend gedacht om een record uniek te kunnen identificeren / adresseren (aanwijzen, uniek te maken). Alle andere gegevens in een record kunnen identiek zijn daarom dit unieke-ID.

[Tsurany]

Wat je trouwens wel kan doen is je id's via een aparte sequence genereren. Dan kan je bij een delete dat id wegschrijven naar een tussentabel en die bij een nieuwe insert eerst raadplegen voor je het eerst volgende id binnen de sequence opvraagt. Volstrekt zinloos maar het kan wel

[Caelorum]

Doe dat echt absoluut niet. Ik moet met een systeem werken waarbij we zelf de id's moeten genereren. Echt dagelijks moet ik met de hand data lopen fixen, omdat er weer eens een dubbele id is. Ondanks dat we echt alles met transactions doen, soms maakt iemand een fout en dat werkt echt maanden door.

[Gomez12]

Wat me meer intrigeert is dat je zegt : Dat ziet er lelijk uit... Hoe bedoel je dat?

In principe is een id gewoon een dbase-eigen dingetje wat geen meerwaarde heeft om ergens te tonen oid.

Oftewel waar zie jij het terugkomen dat je het lelijk vind? Want je kan bij het tonen van regels wel binnen 2 seconden bepalen welke regel binnen de recordset het is door zelf een tellertje bij te houden en dit elke keer dat je een nieuw resultaat binnenkrijgt dit op te hogen met 1 tijdens het weergeven naar je scherm.

Dan krijg je wel een regelnummer wat iets zegt binnen je representatie

[Tsurany]

Caelorum schreef op woensdag 04 mei 2016 @ 08:14:
Doe dat echt absoluut niet. Ik moet met een systeem werken waarbij we zelf de id's moeten genereren. Echt dagelijks moet ik met de hand data lopen fixen, omdat er weer eens een dubbele id is. Ondanks dat we echt alles met transactions doen, soms maakt iemand een fout en dat werkt echt maanden door.

Zelf id's genereren is natuurlijk wat anders dan een sequence gebruiken binnen de database. En als je je inserts in een transactie stopt en een unieke constraint op het id veld vastlegt kan er niet heel veel mis gaan. Alsnog is hergebruik van verwijderde id's natuurlijk niet aan te raden.

[Onoffon]

Ik zou het dan niet op db laag oplossen maar op de applicatielaag, maak een extra kolom aan met daarin de juiste waarde, je zou dan iets moeten verzinnen waar je checkt op het eerstvolgende vrije nummer, dit vergt dan wel een extra query. Daarna via de de bestaande INSERT dit veld toevoegen.

Dat gezegd hebbende ben ik het eens met wat er bovenstaand ook al gezegd is. Ik vraag me af of je dit veld alleen in de database hebt staan ter unieke herkenning of dat je het ook daadwerkelijk ergens in de GUI laat zien bijvoorbeeld.

[Kettrick]

Caelorum schreef op woensdag 04 mei 2016 @ 08:14:
Doe dat echt absoluut niet. Ik moet met een systeem werken waarbij we zelf de id's moeten genereren. Echt dagelijks moet ik met de hand data lopen fixen, omdat er weer eens een dubbele id is. Ondanks dat we echt alles met transactions doen, soms maakt iemand een fout en dat werkt echt maanden door.

Zelf ID's genereren is prima, maar gebruik dan wel een geldig soort ID zoals een UUID

[Edwin88]

Dit is iets wat je in je user interface moet oplossen. De database kijk je in principe nooit zelf naar!

Als je bijvoorbeeld je gegevens in een loopje neerplempt op de pagina kan je met een $index bijhouden welk nummer ze nodig hebben, ongeacht welk ID dat item zelf heeft.

code:

counter = 0
foreach(element in array) {
  counter++
  print(element + counter)
}

[Caelorum]

Tsurany schreef op woensdag 04 mei 2016 @ 08:17:
[...]
Zelf id's genereren is natuurlijk wat anders dan een sequence gebruiken binnen de database. En als je je inserts in een transactie stopt en een unieke constraint op het id veld vastlegt kan er niet heel veel mis gaan. Alsnog is hergebruik van verwijderde id's natuurlijk niet aan te raden.

Dat gaat gegarandeerd een keer fout. Iemand wijzigt iets met de hand in de database of vergeet een insert in een transactie te stoppen en je bent de sjaak.

Kettrick schreef op woensdag 04 mei 2016 @ 08:59:
[...]
Zelf ID's genereren is prima, maar gebruik dan wel een geldig soort ID zoals een UUID

Ja, ok. Ik las het als een integer bijhouden en met de hand ophogen ofzo. GUID is overigens niet gegarandeerd uniek. Ook daar kan je problemen mee krijgen als je ze op verschillende machines genereerd (al hoop ik dat je de database dat laat afhandelen).

[Merethil]

Caelorum schreef op woensdag 04 mei 2016 @ 10:27:
[...]

Ja, ok. Ik las het als een integer bijhouden en met de hand ophogen ofzo. GUID is overigens niet gegarandeerd uniek. Ook daar kan je problemen mee krijgen als je ze op verschillende machines genereerd (al hoop ik dat je de database dat laat afhandelen).

Hij heeft het over een UUID, wat technisch gezien wel over meerdere machines uniek zou moeten zijn. Of in ieder geval; zo zou je het moeten kunnen maken als je meer doet dan alleen een "createNewUUID()"-achtige-method in je specifieke taal aanroepen.

[Tsurany]

Caelorum schreef op woensdag 04 mei 2016 @ 10:27:
[...]

Dat gaat gegarandeerd een keer fout. Iemand wijzigt iets met de hand in de database of vergeet een insert in een transactie te stoppen en je bent de sjaak.

Als je met een stel incompetente ontwikkelaars en/of beheerder werkt moet dit wel je laatste zorg zijn
Je kan natuurlijk van alles verneuken aan een database maar dat moet geen reden zijn om niet een externe sequence te gebruiken.

Caelorum schreef op woensdag 04 mei 2016 @ 10:27:
Ja, ok. Ik las het als een integer bijhouden en met de hand ophogen ofzo. GUID is overigens niet gegarandeerd uniek. Ook daar kan je problemen mee krijgen als je ze op verschillende machines genereerd (al hoop ik dat je de database dat laat afhandelen).

Kan toch ook prima? Sequence in je database aanmaken en altijd een select next value gebruiken.

[ Voor 31% gewijzigd door Tsurany op 04-05-2016 12:06 ]

[Hydra]

Caelorum schreef op woensdag 04 mei 2016 @ 10:27:
Ja, ok. Ik las het als een integer bijhouden en met de hand ophogen ofzo. GUID is overigens niet gegarandeerd uniek.

Er is ook geen garantie dat ons universum morgen nog bestaat.

[M4RTiN]

Ik heb eens een tabel gehad, waarbij in de primary key geen gaten mochten komen, ik doe dan gewoon een check wat het hoogste id is voordat ik een nieuwe insert doe. Werkt perfect.

[P_de_B]

M4RTiN schreef op woensdag 04 mei 2016 @ 13:17:
Ik heb eens een tabel gehad, waarbij in de primary key geen gaten mochten komen, ik doe dan gewoon een check wat het hoogste id is voordat ik een nieuwe insert doe. Werkt perfect.

Dan moet je dus voor een insert de hele tabel locken. Dat lijkt me nogal slecht voor je performance?

[NMe]

M4RTiN schreef op woensdag 04 mei 2016 @ 13:17:
Ik heb eens een tabel gehad, waarbij in de primary key geen gaten mochten komen, ik doe dan gewoon een check wat het hoogste id is voordat ik een nieuwe insert doe. Werkt perfect.

....tot je een race condition krijgt, tenzij je inderdaad met locking gaat werken. Bovendien kan ik me niet voorstellen waarom je PK geen gaten zou mogen hebben, introduceer dan een tweede kolom voor die nummering en laat je PK altijd met rust.

Nog naast het feit overigens dat je met jouw methode alsnog gaten krijgt als je rijen hebt voor ID's 1 t/m 10 en dan ID 5 verwijdert. Bij de volgende insert is het hoogste ID 10, dus ga je 11 inserten.

[Hydra]

M4RTiN schreef op woensdag 04 mei 2016 @ 13:17:
Ik heb eens een tabel gehad, waarbij in de primary key geen gaten mochten komen

En waarom mocht dat niet dan?

[Cyphax]

M4RTiN schreef op woensdag 04 mei 2016 @ 13:17:
Ik heb eens een tabel gehad, waarbij in de primary key geen gaten mochten komen, ik doe dan gewoon een check wat het hoogste id is voordat ik een nieuwe insert doe. Werkt perfect.

Het klinkt (maar het is een enorme aanname natuurlijk) alsof je een requirement hebt gekregen die je beter kan oplossen op een manier waarmee je de primary key en alles wat daarbij komt kijken met rust laat.

Ik heb weleens een vergelijkbaar verzoek gehad, maar dan andersom. Of we niet bij een vrij hoog getal konden beginnen zodat klanten niet van die lage nummers zagen, want dat gaf de indruk dat het maar een paar gebruikers had in het begin.

[Merethil]

Cyphax schreef op woensdag 04 mei 2016 @ 13:38:
[...]

Het klinkt (maar het is een enorme aanname natuurlijk) alsof je een requirement hebt gekregen die je beter kan oplossen op een manier waarmee je de primary key en alles wat daarbij komt kijken met rust laat.

Ik heb weleens een vergelijkbaar verzoek gehad, maar dan andersom. Of we niet bij een vrij hoog getal konden beginnen zodat klanten niet van die lage nummers zagen, want dat gaf de indruk dat het maar een paar gebruikers had in het begin.

IDENTITY(3924885, 1)?
Het lijkt me op zich dat als je bijvoorbeeld van je ID ook direct een klantnummer wilt maken, je begint met een getal hoger dan "1". Ik heb gewerkt in een bedrijf waar klantnummers op die manier gegenereerd werden ( telefonische helpdesk toentertijd) en het is heel vreemd als een klant zijn klantnummer door wil geven en zegt "ik ben klant nummer 5" terwijl de rest 6+ getallen lang was

[ThomasG]

Het is sowieso een heel slecht idee om een klant nummer overeen te laten komen met een auto_increment/sequence primary key van een database tabel. Als je het klantnummer als primary key wilt, wat in bepaalde gevallen logisch is, zou dit nooit een auto_increment kolom mogen zijn.

[Merethil]

ThomasG schreef op woensdag 04 mei 2016 @ 13:49:
Het is sowieso een heel slecht idee om een klant nummer overeen te laten komen met een auto_increment/sequence primary key van een database tabel. Als je het klantnummer als primary key wilt, wat in bepaalde gevallen logisch is, zou dit nooit een auto_increment kolom mogen zijn.

Want?

[Cyphax]

Merethil schreef op woensdag 04 mei 2016 @ 13:44:
[...]


IDENTITY(3924885, 1)?
Het lijkt me op zich dat als je bijvoorbeeld van je ID ook direct een klantnummer wilt maken

Hoewel ik dat enerzijds begrijp denk ik/ben ik van mening dat het beter is om die koppeling in elk geval niet "hard" te maken.

Dan heb je ook veel meer vrijheid om klantnummers te genereren die iets complexer zijn dan alleen een volgnummer of je begint bij 10.000.000, maar dan kan je de technische implementatie van je DB daar verder buiten laten.

[Merethil]

Cyphax schreef op woensdag 04 mei 2016 @ 13:59:
[...]

Hoewel ik dat enerzijds begrijp denk ik/ben ik van mening dat het beter is om die koppeling in elk geval niet "hard" te maken.

Dan heb je ook veel meer vrijheid om klantnummers te genereren die iets complexer zijn dan alleen een volgnummer of je begint bij 10.000.000, maar dan kan je de technische implementatie van je DB daar verder buiten laten.

Meh, je zou altijd nog een identity insert kunnen doen. Of gewoon een extra kolom hebben waar je klantnummergegevens aan toe kan voegen zodat je iets krijgt als 20184091 ABC, verdeeld over twee kolommen. Als je gewoon een uniek volgnummer voor je klant wilt zie ik weinig foutiefs in het gebruik van een AI-ID kolom.
(Grote systemen als SAP doen dit trouwens ook al duizend jaar, behalve dat je zelf het eerste getal aan kan geven bij initiële opzet van je klantgroep , waardoor je kan zeggen "klantgroep A begint bij 800000 terwijl klantgroep B begint bij 900000. Nodig? Nah. Handig? Meh. Simpel? Zeker.)

[ Voor 15% gewijzigd door Merethil op 04-05-2016 14:02 ]

[Cyphax]

Merethil schreef op woensdag 04 mei 2016 @ 14:01:
[...]


Meh, je zou altijd nog een identity insert kunnen doen. Of gewoon een extra kolom hebben waar je klantnummergegevens aan toe kan voegen zodat je iets krijgt als 20184091 ABC, verdeeld over twee kolommen. Als je gewoon een uniek volgnummer voor je klant wilt zie ik weinig foutiefs in het gebruik van een AI-ID kolom.

Nee, niet zolang je niet van die eisen krijgt als "maar ik wil geen gaten he".

Je klantnummer verdelen over twee kolommen... tja het kan wel, maar ik denk dat je meer voordeel haalt uit een tweede kolom waar je de numerieke waarde van je primary key dan in zet, al was het maar om niet nodeloos je queries ingewikkelder te maken dan nodig.

(Grote systemen als SAP doen dit trouwens ook al duizend jaar, behalve dat je zelf het eerste getal aan kan geven bij initiële opzet van je klantgroep , waardoor je kan zeggen "klantgroep A begint bij 800000 terwijl klantgroep B begint bij 900000. Nodig? Nah. Handig? Meh. Simpel? Zeker.)

Tja, SAP, ik weet niet of je daar je inspiratie vandaan moet halen...

[ Voor 10% gewijzigd door Cyphax op 04-05-2016 14:10 ]

[Merethil]

Cyphax schreef op woensdag 04 mei 2016 @ 14:07:
[...]

Nee, niet zolang je niet van die eisen krijgt als "maar ik wil geen gaten he".

Je klantnummer verdelen over twee kolommen... tja het kan wel, maar ik denk dat je meer voordeel haalt uit een tweede kolom waar je de numerieke waarde van je primary key dan in zet, al was het maar om niet nodeloos je queries ingewikkelder te maken dan nodig.

[...]

Tja, SAP, ik weet niet of je daar je inspiratie vandaan moet halen...

Ik weet niet zeker of MySQL hetzelfde werkt als MSSQL op dit gebied, maar: als je ergens in het midden van je data wil inserten en betrokken pages zitten vol, dan mag je DBMS aan de bak om de boel opnieuw te organiseren en dat is zonde, want dat is nergens voor nodig.

Identity insert is ook geen dingetje wat je graag doet, maar als het écht móet omdat iemand moeilijk loopt te doen is het in ieder geval mogelijk.
Verdelen over twee kolommen maakt je query nou niet zó veel moeilijker natuurlijk. Eventueel kan je een composite key creëeren, maar weet niet of je dan één AI en de ander non-AI kan maken, waarbij je de tweede kolom los moet invullen in je CRM wanneer je een klant "aanmaakt".

Even terzijde: Als je je numerieke waarde in die tweede kolom wilt gaan neerzetten samen met wat andere data heb je dus wel dat je voor elke insert meerdere queries gaat lopen doen: Insert, get ID, update tweede kolom met ID+zelfingevoerdewaarde. Ik denk dat dat een nog slechter idee is

SAP is inderdaad totaal geen goeie bron van inspiratie, maar 't is wel de "goto" voor veel business users die zeggen "ja maar SAP doet het zo en als de nummer 1 het zo doet dan...". Tja.

[ Voor 9% gewijzigd door Merethil op 04-05-2016 14:13 ]

[Cyphax]

Merethil schreef op woensdag 04 mei 2016 @ 14:11:
[...]

Identity insert is ook geen dingetje wat je graag doet, maar als het écht móet omdat iemand moeilijk loopt te doen is het in ieder geval mogelijk.

Verdelen over twee kolommen maakt je query nou niet zó veel moeilijker natuurlijk. Eventueel kan je een composite key creëeren, maar weet niet of je dan één AI en de ander non-AI kan maken, waarbij je de tweede kolom los moet invullen in je CRM wanneer je een klant "aanmaakt".

Even terzijde: Als je je numerieke waarde in die tweede kolom wilt gaan neerzetten samen met wat andere data heb je dus wel dat je voor elke insert meerdere queries gaat lopen doen: Insert, get ID, update tweede kolom met ID+zelfingevoerdewaarde. Ik denk dat dat een nog slechter idee is

Yes, je snapt denk ik wel waarom ik mijn eerste reactie maar kort hield: om dit traject te voorkomen want ik ben er zo vaak geweest ooit.
Ik blijf erbij dat dat het beste is, enige uitzondering is voor ons speculatie, gezien TS na z'n TS niet meer gereageerd heeft

[Merethil]

Cyphax schreef op woensdag 04 mei 2016 @ 14:27:
[...]

Yes, je snapt denk ik wel waarom ik mijn eerste reactie maar kort hield: om dit traject te voorkomen want ik ben er zo vaak geweest ooit.
Ik blijf erbij dat dat het beste is, enige uitzondering is voor ons speculatie, gezien TS na z'n TS niet meer gereageerd heeft

Ik heb het zelf nooit meegemaakt aangezien ik eigenlijk nooit werk doe voor websites/applicaties waar gebruikers in zitten. Het hele systeem waar ik aan werk is volledige middleware magie en dus ziet geen enkele business user er iets van; vandaar vond ik de discussie ook wel even interessant en was mijn "Want?"-post een half uurtje geleden dus een daadwerkelijke vraag: Waarom zou het zo'n probleem zijn?

Maar goed, niet de plaats om die discussie te houden. Ik gok dat TS meer dan genoeg info heeft gehad om te weten dat hij niet moet gaan lopen klooien met AI "fixen" als het echt niet nodig is.

[NMe]

Merethil schreef op woensdag 04 mei 2016 @ 14:34:
Ik gok dat TS meer dan genoeg info heeft gehad om te weten dat hij niet moet gaan lopen klooien met AI "fixen" als het echt niet nodig is.

...en nodig is het nooit.

[MSalters]

Sowieso is het verwijderen van rows in een database verdacht. Een kolom "inactive" is veel beter. Maar met klanten? Je hebt hooguit een "lastOrderDate", en een "ActiveCustomers" view die selecteert op "lastOrderDate > today - 365".

[BCC]

MSalters schreef op woensdag 04 mei 2016 @ 16:47:
Sowieso is het verwijderen van rows in een database verdacht. Een kolom "inactive" is veel beter. Maar met klanten? Je hebt hooguit een "lastOrderDate", en een "ActiveCustomers" view die selecteert op "lastOrderDate > today - 365".

Met de komende privacy wetgeving, gaat binnenkort toch echt heel anders moeten ben ik bang

[Voutloos]

Hoeft niet, je hebt nog altijd de optie om alle identificerende kolommen als voornaam, achternaam etc een anonieme waarde te geven en je DB compleet te houden.

Anyway, het is afhankelijk van de usecase of verwijderen correct en toegestaan is. Als dat niet zo is, weet je dat hopelijk wel en vage subjectieve dingen als 'maar persoon x vindt het niet heel mooi als een nummertje mist' zijn daar hopelijk aan ondergeschikt.

[ Voor 45% gewijzigd door Voutloos op 04-05-2016 17:04 ]

[NMe]

Voutloos schreef op woensdag 04 mei 2016 @ 17:02:
Hoeft niet, je hebt nog altijd de optie om alle identificerende kolommen als voornaam, achternaam etc een anonieme waarde te geven en je DB compleet te houden.

Compleet offtopic hier, maar moet je facturen niet altijd opnieuw kunnen aanbieden in dezelfde vorm als ze in de eerste instantie zijn aangemaakt? Dan kom je toch niet weg met het verwijderen of anonimiseren van die gegevens?

[ThomasG]

NMe schreef op woensdag 04 mei 2016 @ 17:07:
[...]

Compleet offtopic hier, maar moet je facturen niet altijd opnieuw kunnen aanbieden in dezelfde vorm als ze in de eerste instantie zijn aangemaakt? Dan kom je toch niet weg met het verwijderen of anonimiseren van die gegevens?

Je moet ze voor de fiscus in ieder geval een x-aantal jaar bewaren, met daarbij de correcte prijzen, naam, etc. Wanneer je de klantgegevens in de database anonimiseert, zullen de facturen een andere manier bewaard moeten worden. Bijvoorbeeld als PDF.

[Voutloos]

Eigen voorkeur is om uberhaupt direct de PDFs op te slaan. Storage is goedkoop, zeker tov allemaal logica geneuzel en gezeik of je ze op later punt voldoende hetzelfde renderen kan.

[Gomez12]

NMe schreef op woensdag 04 mei 2016 @ 17:07:
[...]

Compleet offtopic hier, maar moet je facturen niet altijd opnieuw kunnen aanbieden in dezelfde vorm als ze in de eerste instantie zijn aangemaakt? Dan kom je toch niet weg met het verwijderen of anonimiseren van die gegevens?

Gewoon voor die reden opslaan als ps/pdf.

Anders ga je overal en alles moeten versioneren en mijn ervaring is dat dat op een heleboel plekken gewoon niet gebeurt.
Ik wil me niet druk hoeven maken of een belastingdienst nou valt over het feit dat het logo veranderd is in die 7 jaar, of we een ander formaat papier zijn gaan gebruiken of niet etc. etc. etc.

Ik wil gewoon tegen de BD kunnen zeggen : Kijk hier, dit is hoe de printer ze aangeboden kreeg veel plezier ermee.

[Verwijderd]

Jullie hebben mij niet zo goed begrepen denk ik, ik weet net hoe ik dingen in een database kan toevoegen en verwijderen maar wat jullie me allemaal zeggen snap ik de pleuris niet van, een uitleg bij een antwoord zou fijn zijn! En vele zeggen dat wat ik wil onzin is, nou dat is het niet omdat ik niet regel 1 wil hebben en dan opeens regel 4 omdat regel 2 en 3 verwijderd zijn. Ik hoop dat jullie me snappen.

[CyBeR]

Verwijderd schreef op dinsdag 17 mei 2016 @ 02:13:
Ik hoop dat jullie me snappen.

Dat snappen we. En we zeggen dat je je daar niet mee bezig moet houden.

Wat zou je bijvoorbeeld doen als je rij 1, 2, 3, 4, en 5 hebt, en rij 2 wordt weggehaald? Rijen 3, 4, en 5 eentje opschuiven? Wat als er, terwijl je dat aan het doen bent, nog een rij wordt toegevoegd? Dan krijg je rijen 1-4 en 6 zonder 't door te hebben. Ondertussen heb je wel je teller aangepast om '5' neer te zetten dus dat gaat 1x goed en dan bij de volgende insert heb je 2x rij 6.

Die id nummers zijn alleen maar om een rij te identificeren. Je moet er geen waarde aan koppelen anders dan dat.

[ Voor 10% gewijzigd door CyBeR op 17-05-2016 02:22 ]

[Radiant]

Als het puur voor de weergave is en je dan echt zo graag een opvolgend regelnummer voor je results wil, waarom print je dat er dan niet voor in je uitvoer en laat je de PK weg?

(geen garantie dat dat een microseconde na het laden van de pagina nog hetzelfde is, maar dat probleem heb je ook als je zo met je PK's gaat klooien)

[Janoz]

Verwijderd schreef op dinsdag 17 mei 2016 @ 02:13:
En vele zeggen dat wat ik wil onzin is, nou dat is het niet omdat ik niet regel 1 wil hebben en dan opeens regel 4 omdat regel 2 en 3 verwijderd zijn. Ik hoop dat jullie me snappen.

En toch is het onzin. Je probleem is echter dat je 'regel' en 'identifier' door elkaar haalt. Het ID (wat middels de autoincrement gegarandeerd uniek is) is bedoeld om altijd hetzelfde record terug te krijgen wanneer je hetzelfde ID opvraagt. Dat zou dus nooit moeten veranderen. Je moet er daarom ook geen andere betekenissen aan geven.

Regelnummers zijn pas relevant wanneer je je resultaten onder elkaar gaat zetten. Het verwijderen van een record veranderd de regelnummers, maar als je anders gaat sorteren of gaat filteren zijn de regelnummers ook anders. Die zul je dus eigenlijk pas weer moeten geven wanneer je de resultaten afdrukt. Dat is namelijk pas het moment waarop je weet wat het regelnummer is.

Om met een ander voorbeeld te komen: Wanneer er iemand dood gaat, dan verandert toch ook niet het BSN van alle mensen die na hem geboren zijn?

[Cyphax]

Verwijderd schreef op dinsdag 17 mei 2016 @ 02:13:
En vele zeggen dat wat ik wil onzin is, nou dat is het niet omdat ik niet regel 1 wil hebben en dan opeens regel 4 omdat regel 2 en 3 verwijderd zijn. Ik hoop dat jullie me snappen.

Hmm, ik twijfel over dat laatste. Gaat het nou alleen maar over het idee dat, wanneer je in de database gaat kijken, je gaten ziet, of geeft dat ook echt problemen ergens? Met andere woorden: is het praktisch gezien een probleem of gaat het alleen om gevoel?

Als het om dat laatste gaat, dan is er maar één goed advies: laat het gaan. Het is de moeite allemaal niet waard (en met moeite bedoel ik dat je je product technisch slechter of langzamer gaat maken terwijl het in de praktijk niets oplost of verbetert). Kijk gewoon niet in de database, die regelt alles voor jou op dat gebied en die ligt er al niet wakker van. We hebben het beste met je voor.

Als het praktisch gezien een probleem is of cosmetisch voor je gebruikers, dan hebben we dat niet goed begrepen, maar dat kan ik niet opmaken uit het topic.

[Verwijderd]

Cyphax schreef op dinsdag 17 mei 2016 @ 10:11:
[...]

Hmm, ik twijfel over dat laatste. Gaat het nou alleen maar over het idee dat, wanneer je in de database gaat kijken, je gaten ziet, of geeft dat ook echt problemen ergens? Met andere woorden: is het praktisch gezien een probleem of gaat het alleen om gevoel?

Als het om dat laatste gaat, dan is er maar één goed advies: laat het gaan. Het is de moeite allemaal niet waard (en met moeite bedoel ik dat je je product technisch slechter of langzamer gaat maken terwijl het in de praktijk niets oplost of verbetert). Kijk gewoon niet in de database, die regelt alles voor jou op dat gebied en die ligt er al niet wakker van. We hebben het beste met je voor.

Als het praktisch gezien een probleem is of cosmetisch voor je gebruikers, dan hebben we dat niet goed begrepen, maar dat kan ik niet opmaken uit het topic.

Het is voor wij als admins want kijk, ik kan wel een counter doen die elke keer een omhoog gaat maar dan kan een admin niet zien welke id nou daadwerkelijk die regel is, en kan je die regel dus niet verwijderen via mijn admin paneel want daar moet je de id van de regel neerzetten en die kan je dan verwijderen. Ook staat het gewoon niet mooi als je op de pagina regel 4 ziet en dan opeens regel 7 omdat regel 5 en 6 dan zijn verwijderd

[Rmg]

code:

SELECT @n := @n + 1 n,
       first_name, 
       last_name
  FROM table1, (SELECT @n := 0) m
 ORDER BY last_name

Je kan zoiets doen, laat je auto increment gewoon met rust, genereer er dynamisch een ID bij.

[Cyphax]

Verwijderd schreef op vrijdag 03 juni 2016 @ 10:19:
[...]


Het is voor wij als admins want kijk,

We gaan kijken.

ik kan wel een counter doen die elke keer een omhoog gaat maar dan kan een admin niet zien welke id nou daadwerkelijk die regel is, en kan je die regel dus niet verwijderen via mijn admin paneel want daar moet je de id van de regel neerzetten en die kan je dan verwijderen.
Ook staat het gewoon niet mooi als je op de pagina regel 4 ziet en dan opeens regel 7 omdat regel 5 en 6 dan zijn verwijderd

Ik heb die primary key eerder eens "betekenisloze sleutel" genoemd omdat het idee erachter is dat je een iets hebt om die rij te identificeren maar dat dat iets verder eigenlijk niets betekent. Ik zou mijzelf kunnen identificeren aan de hand van mijn BSN, maar dat nummer zegt verder helemaal niks over mij (misschien zou je er, net als bij kentekens van auto's, een grove inschatting van mijn leeftijdscategorie mee kunnen maken, maar dat terzijde).
Je wil nu een daadwerkelijke eigenschap toevoegen aan een row met een betekenis. Die zou ik dan toevoegen als kolom en programmatisch (dat kan zijn via een sp of trigger die je gebruikt voor je deletes en je inserts, of in je backend-code, 'k weet niet wat je het liefst doet) bijwerken. Dan reduceer je het werk voor je database denk ik het meest tot het bijwerken van een serie nummers in een reeks rijen vanaf de rij die je verwijderd hebt. In je adminpaneel moet je dan wél kunnen sorteren op een kolom naar jouw keuze, want anders wordt het lastiger. Ik hoop dat je adminpaneel uiteindelijk niet de doorslag gaat geven over de technische implementatie, al begrijp ik je wens goed, want een onbruikbaar adminpaneel, daar zit je toch ook maar mooi mee.

[edit]
Of een computed kolom zoals Rmg voorstelt, dat is ook wel elegant. Misschien kan je dat nog mooi verpakken in een view.

[ Voor 8% gewijzigd door Cyphax op 03-06-2016 10:33 ]

[Radiant]

Verwijderd schreef op vrijdag 03 juni 2016 @ 10:19:
[...]


Het is voor wij als admins want kijk, ik kan wel een counter doen die elke keer een omhoog gaat maar dan kan een admin niet zien welke id nou daadwerkelijk die regel is, en kan je die regel dus niet verwijderen via mijn admin paneel want daar moet je de id van de regel neerzetten en die kan je dan verwijderen. Ook staat het gewoon niet mooi als je op de pagina regel 4 ziet en dan opeens regel 7 omdat regel 5 en 6 dan zijn verwijderd

Je moet een ID handmatig invullen? Is de oplossing dan niet gewoon een linkje naast de regel plaatsen naar een delete-pagina waar je de ID gewoon in de query string meestuurt?

[Merethil]

Radiant schreef op vrijdag 03 juni 2016 @ 10:31:
[...]

Je moet een ID handmatig invullen? Is de oplossing dan niet gewoon een linkje naast de regel plaatsen naar een delete-pagina waar je de ID gewoon in de query string meestuurt?

Dit. En als je echt een lijstje met oplopende nummers wilt hebben kan je toch gewoon dit doen:

HTML:

<a href="/destroy/{idVanDeRijDieIkWilVerwijderen}">{nummertjeInDeTabelDieIkZelfVerzonnenHeb}</a>

?
Dit is hoe de meeste systemen werken, alleen laten ze vaak gewoon het ID zien als representatie in de frontend omdat de meeste mensen niet zo'n problemen hebben met missende getallen.

[DJMaze]

Verwijderd schreef op dinsdag 17 mei 2016 @ 02:13:
Jullie hebben mij niet zo goed begrepen denk ik, ik weet net hoe ik dingen in een database kan toevoegen en verwijderen maar wat jullie me allemaal zeggen snap ik de pleuris niet van, een uitleg bij een antwoord zou fijn zijn! En vele zeggen dat wat ik wil onzin is, nou dat is het niet omdat ik niet regel 1 wil hebben en dan opeens regel 4 omdat regel 2 en 3 verwijderd zijn. Ik hoop dat jullie me snappen.

Goed, snap je dan wel het volgende:


Persoon A ziet de pagina als volgt:

code:

1. Hendrik
2. Pieter

Persoon B ziet de pagina als volgt:

code:

1. Hendrik
2. Pieter

Nu verwijderd Persoon A "1" uit de database, en ziet:

code:

1. Pieter

Nu verwijderd Persoon B "1" uit de database, en ziet:

code:

Persoon B denkt "Ik heb Hendrik verwijderd, iemand anders heeft Pieter verwijderd".
Persoon B vraagt aan Persoon A: "Heb jij Pieter verwijderd? Ik heb die persoon nodig".
Persoon A: "Ik was het niet, ik heb Herman verwijderd"
Persoon B: "Ja ik heb ook Herman verwijderd, weird "


Persoonlijk: ik zou gewoon nooit een nummertje tonen als het niet relevant is.
Factuurnummer is geen ID (wel oplopend, maar hoeft geen ID te zijn)
Klantnummer, ja dat kan een ID zijn, mag je toch nooit aanpassen.
etc. etc.
Bedenk goed wat je met je laatste rolo nummer doet!

[ Voor 45% gewijzigd door DJMaze op 03-06-2016 12:13 ]

[emnich]

Verwijderd schreef op vrijdag 03 juni 2016 @ 10:19:
[...]


Het is voor wij als admins want kijk, ik kan wel een counter doen die elke keer een omhoog gaat maar dan kan een admin niet zien welke id nou daadwerkelijk die regel is, en kan je die regel dus niet verwijderen via mijn admin paneel want daar moet je de id van de regel neerzetten en die kan je dan verwijderen. Ook staat het gewoon niet mooi als je op de pagina regel 4 ziet en dan opeens regel 7 omdat regel 5 en 6 dan zijn verwijderd

Wat hier gezegd wordt is dat je die ID in principe nooit nodig hebt als gebruiker en nooit hoeft te zien. Die ID is er puur en alleen voor de database.

Ik zou sowieso niet iets maken waar je even een ID invult om het te verwijderen. Waarom niet een link/knop/... waar je op kan drukken. Heb je ook geen kans op typos.

[ajakkes]

Persoon A en B openen het paneel.
Persoon A verwijderd regel 2.
Persoon C opent het paneel en vraagt aan B of regel 2 goed is. Persoon B zegt die zou ik verwijderen en persoon C verwijderd regel 2. Persoon B ziet de volgende keer dat hij kijkt dat regel 3 inmiddels ook weg is. Oeps.

Waarvoor wil je het regel nummer weergeven en niet een auto incr ID?

Ik weet, het ziet er de eerste week een beetje vreemd uit. Maar na 3 maanden wil je niks anders meer. En je kan ze ook beide tonen.