BRP-API / brp-api-gezag

Het gezag component van Haal Centraal
0 stars 0 forks source link

Hoe willen we omgaan met het ophalen van informatie van personen voor gezagsbepaling #26

Open Patrick-4488 opened 2 months ago

Patrick-4488 commented 2 months ago

TODO: refinen / beslissen

Rationale: De oude gezagmodule haald bij het start van een gezag aanvraag in eerste instantie alleen de persoonslijst op van de bevraagde persoon. Pas wanneer de gezagsmodule informatie nodig heeft van ouder 1, werd de persoonslijst van ouder 1 opgehaald. Wanneer ouder 2 informatie nodig is werd pas de persoonslijst van douder 2 opgehaald enzovoorts.

Dit om het aantal bevraging naar de BRP te verminderen, alleen data op te vragen die daadwerkelijk nodig is en beter performance

Nieuwe situatie: In de nieuwe situatie is gezag direct gekoppeld aan de database. In deze situatie kunnen we hier nog keuzes maken.

Willen we gegevens allemaal direct ophalen? OF: wilen we net als de oude gezag module persoonslijsten ophalen pas op het moment dat die nodig zijn OF: willen we dit verder trekken en verblijfplaats, gezagverhoudingen, historie, ouder 1 etc... alle object pas opvragen wanneer ze daadwerkelijk nodig zijn.

Gerelateerd hieraan: bij de oude gezagmodule is een situatie opgetreden waarin een kind van een bevraagde persoon wilde weten waaom zijn/haar data gebruikt is. Na onderzoek bleek dat de bevraagde persoon niet ingeschreven was in RNI en dus direct uitviel in gezagmodule maar bij het ophalen van de persoonslijst van de persoon waren wel al de data van zijn/haar kinderen verzameld. Eigenlijk onnodig geweest en levert dus echt vragen op. Zie: https://github.com/BRP-API/brp-api-gezag/issues/15

fsamwel commented 2 months ago

ik denk dat er functioneel, of vanuit privacy, geen reden is om niet direct alles op te halen. Bevragen van de database wordt niet geprotocolleerd, dus een burger ziet daar niks van (gegevens verlaten de organisatie niet). Die burger zal dus niet vragen waarom diens gegevens opgevraagd zijn wanneer die voor gezag gebruikt zijn.

Dus ik denk dat het meer de vraag is wat beter performt, beter leesbare code oplevert, beter beheerbaar is, enz.

In productie draait de query draait op een database met meer dan 20 miljoen personen, dus de lo3_pl_persoon database heeft denk ik meer dan 100 miljoen rijen. Dan werkt denk ik een query met veel joins niet noodzakelijk veel sneller dan specifiek benodigde gegevens ophalen

Is dus wat je overweegt op te halen in 1 request is (allemaal uit dezelfde tabel):

En daarnaast uit andere tabellen de inschrijving, verblijfplaats, gezagsverhouding en overlijden van de persoon en inschrijving, gezagsverhouding en overlijden van de ouders

En wanneer de persoon meerderjarig blijkt te zijn de kinderen van persoon en kinderen van de (ex)partner(s) met daarvan al het bovenstaande.

Patrick-4488 commented 2 months ago

@fsamwel duidelijkverhaal, als we niet hoeven te minimaliseren welke gegevens we uit de database halen omdat het de applicatie niet verlaat dan vervalt dit issue en kunnen we technische optimalie keuzes maken hiervoor