[Alg] Methode voor database edit functionaliteit

[Verwijderd]

Bij mijn projecten maak ik steeds gebruik van Delphi en Interbase en de volgende knoppenbalk waarmee de gebruiker nieuwe records kan toevoegen, verwijderen, wijzigen, enz...



Nu doe ik het steeds zo dat een gebruiker eerst op het edit knopje moet drukken, waarna hij pas het record echt kan wijzigen. Hierbij wordt een dummy update uitgevoerd, waardoor het record gelockt wordt voor andere personen. Vanaf nu kan alleen deze persoon dit record wijzigen.

Om nu te voorkomen dat dit record gelockt blijft en niemand anders het record meer kan wijzigen, zit er een controle in die na x minuten het record automatisch unlockt (dus rollbacken).


Een andere mogelijkheid zou zijn om de gebruiker altijd de mogelijkheid te geven om te editten (er wordt geen dummy update uitgevoerd). Bij het starten wordt dan de tijd opgeslagen (de tijd wordt uit de tabel gehaald, is een apart veld). Vervolgens als de gebruiker zijn wijzigingen wil opslaan wordt gekeken of de opgeslagen tijd hetzelfde is als de tijd die nu in de tabel staat. Zo ja dan heeft dus niemand anders in de tussentijd iets gewijzigd en mag deze persoon de wijzigingen opslaan en anders geef je een melding aan de gebruiker dat iemand anders het record heeft gewijzigd en dat zijn wijzigingen niet kunnen worden opgeslagen.


Ik zelf vind de 1e methode het mooist, omdat je dan niet voor niks een tijd gegevens kan editten, omdat je 100% zeker weet dat wanneer je aan het wijzigen bent, jouw gegevens ook daadwerkelijk opgeslagen gaan worden. Bij de 2e methode moet je dat nog maar afwachten en misschien kan je dus voor niks een heleboel gegevens gewijzigd hebben.


Ik zou graag willen weten hoe jullie dit doen en waarom je die methode het beste vind.

[Verwijderd]

Lijkt me niet handig om de database in te richten dat het extra opslag nodig heeft om een veld te wijzigen. Hoe vaak komt het voor dat meerdere gebruikers tegelijkertijd een record wijzigen? Anyway, in sommige situaties kan dit natuurlijk wel.

Wat ik zou doen is een gebruiker altijd de mogelijkheid geven een record te wijzigen. Pas als de wijzigingen moeten worden opgeslagen, start je een transactie en lock je de record. Dan check je of de record is veranderd t.o.v. de gegevens waarmee je begon. Als er iets is gewijzigd in de tussentijd, geef je een melding aan de gebruiker en anders voer je zijn wijzigingen door.

Een wijziging betekent dat een gebruiker eventueel zijn wijziging moet herzien.

[Verwijderd]

optie 1... waarborgd integriteit van je gegevens.... optie 2 lijkt me sowieso niet efficient...je wijzigt wat en dan ist maar afwachten of je het ook mag bewaren....

[Gerco]

Hier op mijn werk gebruiken we de tweede methode (in ietwat gewijzigde vorm). Een gebruiker mag altijd een record editen, op het moment van opslaan worden de waardes van de gewijzigde velden gecontroleerd tegen de database, zijn die gelijk kan er opgeslagen worden. Zo niet, krijgt de gebruiker een error en worden de gewijzigigde database waarden in zijn invoerscherm gezet.

Zo kunnen twee gebruikers toch aan hetzelfde record werken, mits ze dezelfde velden niet muteren. De wijsheid van deze constructie is me niet geheel duidelijk, het kan heel goed werken, maar ook vreselijk fout gaan (als gewijzigde velden met elkaar in verband staan bijv).

Wil je absolute zekerheid hebben, moet je voor methode 1 gaan, alleen kan je record dan wel lang gelockt zijn. En wat doe je als een gebruiker langer dan je timeout koffie gaat halen en dan wat data verandert en opslaat?

[Verwijderd]

Gerco schreef op 01 September 2003 @ 12:30:En wat doe je als een gebruiker langer dan je timeout koffie gaat halen en dan wat data verandert en opslaat?

Zodra de gebruiker in de edit mode komt, wordt dus het record gelockt en gaat er een timer lopen.

Als de gebruiker nu geruime tijd niks doet, zal er een time-out optreden en zal automatisch gerollbackt worden. Hij zal dus de nieuwe gegevens kwijt zijn. Maar goed zoiets komt gewoon in de handleiding te staan en is gewoon de fout van die gebruiker. Wanneer dus die time-out opgetreden is zal het form weer naar de "standaard" mode gaan.

De gebruiker moet dan dus weer op de edit knop drukken en begint het verhaal weer opnieuw (record wordt weer gelockt, enz...)

[Janoz]

En wat nu als de clientapp vast loopt?

Je moet locking nooit laten afhandelen door een client applicatie. Die zijn namelijk nooit te vertrouwen.

Persoonlijk zou ik helemaal niet locken op die manier. Als gegevens veranderd zouden moeten worden dan neem ik aan dat dit goed gebeurt. Zorg desnoods dat alleen de gewijzigde velden worden geupdate ipv alle velden.

Wat ik eventueel zou overwegen is een versiebeheer systeem achtig iets inbouwen. Op die manier is het aangepaste geheel niet verloren, maar zit ergens in d3e CVS history

[Verwijderd]

Om wat voor soort gegevens praten we hier eigenlijk? Je moet namelijk wel rekening met de mutatiegraad (hoe vaak wordt er gemuteerd?). En daarbij het belang van behoud van wijzigingen.

Het is mijns inziens onzinnig een dure app te ontwikkelen die een perfect wijzigingsbeheersysteem omvat als het om het wijzigen van klantgegevens gaat die één keer per jaar veranderen...

[Verwijderd]

Janoz schreef op 01 september 2003 @ 12:46:En wat nu als de clientapp vast loopt?

Ja dat is een goede. Daar had ik nog helemaal niet aan gedacht.

[Verwijderd]

Verwijderd schreef op 01 September 2003 @ 13:11:Het is mijns inziens onzinnig een dure app te ontwikkelen die een perfect wijzigingsbeheersysteem omvat als het om het wijzigen van klantgegevens gaat die één keer per jaar veranderen...

Wat bedoel je precies met dat wijzigingsbeheersysteem. Mijn vraag was gewoon in het algemeen. Dus bij een bepaald project heb je gegevens die vaak veranderen en wat minder.

Maar ik vind dat maakt niet zoveel uit. Wat je maakt moet gewoon 100% goed werken.

[Verwijderd]

Dat maakt wel uit als je software op maat maakt. Dan kan je best code hergebruiken en dus één algemeen componentje gebruiken om records te wijzigen, maar wanneer heb je als gebruiker een DB-tabel op je scherm die je wilt aanpassen? Ik nooit.

Ik heb altijd een scherm met bijvoorbeeld klantgegevens die aangepast moeten worden. Dan ga ik geen moeite doen om ervoor te zorgen dat niet twee personen tegelijk deze data aan kunnen passen. Als beide personen RECHTEN hebben om dit te doen, dan zoeken ze zelf maar uit wie dit doet. Want dit betekent namelijk ook dat A eerst de gegevens aan kan passen en daarna B het alsnog wijzigt. Wat is dan het verschil met een superoplossing die jij in gedachten hebt?

Het tegelijkertijd aanpassen van gegevens blijft altijd een probleem als twee personen allebei rechten hebben om dit te doen.
In geval van het boeken van een reis, zou een reisadviseur op zijn scherm kunnen zien dat er nog één plaats vrij is. Als hij dan vijf minuten laten de reis wil bevestigen en er is ondertussen iemand anders geweest die deze plaats al heeft besproken, dan moet er simpelweg een melding komen dat hij te laat is. In dit geval kan je hem ook tijdelijk locken, wat vaak als oplossing gebruikt wordt. Wel wordt dit dan expliciet aan de gebruiker gemeld!

[ Voor 6% gewijzigd door Verwijderd op 01-09-2003 13:22 ]

[Verwijderd]

Verwijderd schreef op 01 September 2003 @ 13:21:
Want dit betekent namelijk ook dat A eerst de gegevens aan kan passen en daarna B het alsnog wijzigt. Wat is dan het verschil met een superoplossing die jij in gedachten hebt?

Je zou die 2e mogelijkheid van mij met die tijd controle kunnen gebruiken of controleren welke velden intussen aangepast zijn. Dit voorkomt dat alle wijzigingen van A teniet gedaan worden door B als ze gelijktijdig bezig zijn met editten.

Maar jij zou dus geen enkele controle inbouwen en gewoon steeds wanneer iemand de wijzigingen wil opslaan die klakkeloos overschrijven?

[Gerco]

Verwijderd schreef op 01 september 2003 @ 13:43:
Maar jij zou dus geen enkele controle inbouwen en gewoon steeds wanneer iemand de wijzigingen wil opslaan die klakkeloos overschrijven?

Op zijn minst toch even een "deze gegevens zijn door een andere gebruiker gewijzigd" melding geven en dan een optie geven om de gewijzigde gegevens in te laden in zijn invoerscherm of om zijn hele update maar op te geven.

[Verwijderd]

Maar jij zou dus geen enkele controle inbouwen en gewoon steeds wanneer iemand de wijzigingen wil opslaan die klakkeloos overschrijven?

Wijzigen = bestaande gegevens aanpassen

Welke logica is voor jouw app van toepassing? als ik nu het adres van een klant aanpas en collega X past dat adres 10 minuten later weer aan, dan is dat vreemd! Maar als ik de koers van de Aegon-aandelen nu aanpas en mijn collega doet dat over 10 minuten ook, dan is hij misschien wel een beetje traag... Hoe dan ook, dat ligt helemaal aan je applicatie.

Belangrijker is, denk ik, je rechtenstructuur. Als twee personen allebei rechten hebben om iets aan te passen, dan hebben zij ook de verantwoordelijkheid dat dit juist gebeurt.

Ik wil meteen benadrukken dat er absoluut situaties zijn waarin extra controle nodig is, maar dit is toch echt afhankelijk van het soort informatie dat gewijzigd wordt. Meestal zal dit niet nodig zijn.

[Verwijderd]

Gerco schreef op 01 September 2003 @ 13:52:
Op zijn minst toch even een "deze gegevens zijn door een andere gebruiker gewijzigd" melding geven en dan een optie geven om de gewijzigde gegevens in te laden in zijn invoerscherm of om zijn hele update maar op te geven.

Nogmaals: dat ligt volgens mij helemaal aan het soort gegevens...

[Varienaja]

Verwijderd schreef op 01 September 2003 @ 12:04:
Nu doe ik het steeds zo dat een gebruiker eerst op het edit knopje moet drukken, waarna hij pas het record echt kan wijzigen. Hierbij wordt een dummy update uitgevoerd, waardoor het record gelockt wordt voor andere personen. Vanaf nu kan alleen deze persoon dit record wijzigen.

Hier heb je niet veel aan:

Wanneer gebruiker1 op het edit knopje duwt, en gebruiker2 op ongeveer hetzelfde moment hangt het er maar vanaf welk van de twee als eerste de dummy-update kon doen. De tweede krijgt dan nog steeds net zo'n nare fout als wanneer je niet alle moeite had gedaan om dit te programmeren.

Databases hebben niet voor niets al die locking-mechanismen al in zich.. :-)

[Gerco]

Verwijderd schreef op 01 september 2003 @ 13:58:
Nogmaals: dat ligt volgens mij helemaal aan het soort gegevens...

Volgens mij niet. Die melding komt natuurlijk alleen op als de gevens die ik op mijn scherm had staan toen ik op "edit" drukte niet meer hetzelfde zijn als de gegevens die in de database staan. maw:

1. A: Zoek record op
2. B: Zoek record op
3. A: Open record
4. A: Wijzig gegevens
5. A: Sla op
6. B: Open record
7. B: Wijzig gegevens
8. B: Sla op

Nu kun je ervoor kiezen om de melding te geven op punt 6 of op punt 8, ik verkies punt 8 omdat A ook zou kunnen opslaan als B het record al geopend heeft. Dit heeft niets met het soort gegevens te maken, dat is gewoon standaard gedrag (in mijn ogen).

[Verwijderd]

Toegevoegde vragen:

- Gebruik je een realtime connectie naar een database of een disconnected dataset?
- Wat voor soort app heb je het over?
- Wat voor GUI wordt er gebruikt?

Ik blijf erbij dat het updaten van gegevens van bovenstaande afhangt. En daarvoor zijn genoeg voorbeelden te verzinnen.

[Verwijderd]

Varienaja schreef op 01 September 2003 @ 14:14:
Hier heb je niet veel aan:

Wanneer gebruiker1 op het edit knopje duwt, en gebruiker2 op ongeveer hetzelfde moment hangt het er maar vanaf welk van de twee als eerste de dummy-update kon doen. De tweede krijgt dan nog steeds net zo'n nare fout als wanneer je niet alle moeite had gedaan om dit te programmeren.

Databases hebben niet voor niets al die locking-mechanismen al in zich.. :-)

Nee deze methode werkte perfect. Bij allebei gaan ze dummy update proberen uit te voeren. Alleen bij 1'tje lukt het maar en die mag dan het record gaan wijzigen.

De andere komt niet eens in edit mode. Dit kan nooit verkeerd gaan.