Haal verwijderde records terug in een oogwenk
Ik wil het hier hebben over hoe we omgaan met data die overbodig is geworden. Het artikel is FileMaker-specifiek en bevat daarom niet noodzakelijk richtlijnen die overeenkomen met algemeen database beheer. Het gaat hier ook niet over backups en backup-strategieën. We bespreken wel technieken die we zelf actief gebruiken in productie-applicaties. Wat betreft het gebruik van sleutelvelden (primary keys): we veronderstellen dat elke tabel een numeriek veld ‘__id’ bevat met als validatie: ‘Uniek’ en ‘Niet leeg’.
Waarom records verwijderen?
Waarom zou je je druk maken over overbodige data in je database? Hier zijn een paar voorbeelden van wat men vaak veronderstelt:
Geheugenruimte besparen
Met de huidige lage prijzen van opslagmedia zou dit één van de laatste bezwaren mogen zijn. Als je ooit geheugenruimte tekort komt omwille van de groei van je database dan is dat eerder een teken van onderschatte hardware-vereisten. Los het op door je hardware te upgraden en niet door je database te downgraden.
Zoekopdrachten versnellen
Je kan je hierover terecht bezorgd maken. Maar een tabel die op de juiste manier is geïndexeerd, kan gemakkelijk miljoenen records bevatten vooraleer je een snelheidsverlies merkt in zoekopdrachten. In onze ondervinding zijn de meeste applicaties niet van die aard dat het aantal records bepalend is voor de snelheid van het systeem. Tenminste als je je werk goed doet en ervoor zorgt dat zoekvelden geïndexeerd zijn, dat je met grote found sets niet sorteert en evenmin niet-opgeslagen berekeningen toepast. We gaan hier niet in op de diverse technieken om met grote datasets om te gaan.
Nu we dit hebben uitgeklaard blijft er nog één belangrijke reden over: hoe verbergen we overbodig geworden records voor de gebruiker? Hoe zorgen we er bijvoorbeeld voor dat een artikel dat niet langer beschikbaar is ook niet meer kan worden gebruikt in bestellingen en facturen?
Technieken om overbodige records te verbergen
Ik zet een aantal technieken op een rijtje, de minst praktische eerst, om uiteindelijk te komen tot wat me de beste oplossing lijkt en wat ook de reden is van dit blog-artikel.
Verwijder de records
Om kort te zijn: VERWIJDER NOOIT IETS uit een database. Doe je het toch, dan ontdek je vroeg of laat dat er altijd wel iets ontbreekt: externe sleutelvelden (foreign keys) verwijzen niet langer naar een geldig record en wat dan? Het record is weg en de enige manier om het terug te halen is het gaan zoeken in één of andere backup. Er zijn natuurlijk uitzonderingen: log tabellen bevatten vaak data die snel veroudert en die geen groot verlies inhouden als ze weg zijn.
Verplaats de records naar een archief tabel
In de meeste database-systemen is dit een algemene en eenvoudige techniek. FileMaker zorgt hier helaas voor twee hindernissen:
- FileMaker kent in het relatiediagram niet zoiets als het SQL ‘UNION’ statement. Daarmee kan je in een SQL-omgeving de inhoud van twee tabellen samenvoegen als was het één tabel. Dit is ideaal als je data wil scheiden in een actieve en een archief tabel. Via ‘Union’ kan je zonder veel moeite iets terugzoeken in zowel actieve als archief tabel indien nodig. (Je kan in FileMaker wel degelijk ‘Union’ gebruiken in een SQL statement via ‘ExecuteSQL’ maar het resultaat is geen tabel. Om dat te bekomen moet je al een virtual list inschakelen en dan zijn we ver van het standaard-FileMaker verhaal)
- Doordat er niet zoiets als ‘Union’ bestaat in FileMaker wil dat zeggen dat je geen automatisatie kan toepassen op actieve en niet-actieve records tegelijk. Je doet dubbel werk en elke wijziging in de logica op de actieve tabel moet worden toegepast op de archief-tabel.
Markeer overbodige records zonder ze te verwijderen
Dit is een wijd verspreide techniek. Voeg een aankruisvakje toe aan je tabel, bijvoorbeeld ‘IsActief’ en ga ervan uit dat records waar dat veld als ‘Onwaar’ evalueert, overbodig zijn. Dit kan je eenvoudig inbouwen in een toepassing en het werkt ook erg snel. Maar het zadelt je wel op met extra automatisatie: elke gevonden reeks moet worden gemanipuleerd om ervoor te zorgen dat de gebruiker geen overbodige records te zien krijgt. Denk ook aan portals, scripts, keuzelijsten, … Nog een nadeel is dat de FileMaker navigatiebalk steeds het totale aantal records in een tabel toont (actieve en inactieve). Dat kan verwarrend zijn voor gebruikers en je zou moeten overwegen om die navigatiebalk dan maar te verbergen en te herbouwen…
Gebruik een ‘Actieve Records’ tabel
Eindelijk, de meeste elegante oplossing: maak een nieuwe tabel ‘Actieve Records’ en plaats die voor je eigenlijke data tabel. Bewaar in die nieuwe tabel enkel primary keys en link die met de data tabel via een één-op-één relatie. Een voorbeeld met een tabel ‘artikels’ waarbij je niet-actieve artikels wil verbergen:
Bouw je ‘artikels’ tabel zoals gewoonlijk maar activeer de optie ‘serienummer toekennen’ NIET voor het veld artikel ID (‘__id’). Bouw nu een tweede tabel ‘Artikels~Actief’ en voorzie maar één veld, namelijk ‘__id’ met de serienummer optie AAN. Deze tabel zal één record bevatten voor elk actief artikel. Zo moet het relatiediagram eruitzien:
Dit werkt omdat we ook de optie ‘records aanmaken’ hebben aangezet aan de linker kant van de relatie.
Zoals je kan zien hebben we hiermee een robuuste structuur gebouwd die volledig is gebaseerd op ‘native’ FileMaker functionaliteit met een minimum aan scripting.
Stap voor stap
Hier is hoe het werkt: we verwijderen een record op de layout ‘Articles’, gebaseerd op de ‘ARTICLE~Active’ tabel.
