admin/Database
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FCLT#60015 nieuwe conditiemeting-werkwijze, savepoint alvorens te splitsen

Browse Source 
svn path=/Database/trunk/; revision=45399
This commit is contained in:
Peter Feij
2020-01-09 16:55:17 +00:00
parent 4c9ee72bf0
commit f83d1982e0
1 changed files with 16 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
CND/CND.sql
View File

@@ -4,7 +4,7 @@
-- Script for (re)initializing the "CND-module" for conditiemetingen according to NEN2767-standard
-- It can be run repeatedly after a initial initialisation in an existing Facilitor database
-- to upgrade CND the to the latest version.
-- First time the CND_INI must be run as well, once
-- First time the CND_INI must be run as well, once, first
--
-- If all scores are uptodate, the next statement should have no result
@@ -19,34 +19,30 @@
-- OR ins_deel_mjb_score2 <> cnd.calculate_prio_score (ins_deel_key));
--
-- STATUS: REFACTORING IN HET KADER VAN FCLT#60015 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-- STATUS: REFACTORED IN HET KADER VAN FCLT#60015 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--
-- Hier is vast nog een beetje hulp bij nodig.
--
-- Wat is het verhaal van de Facilitor-conditiemetingen?
-- - Er zijn objectgebonden meldingen met eigenschappen (cnd_ini.sql) die de conditie/prioriteitscore van een object bepalen
-- - Er zijn 2 zienswijzen, nu aangeduid met setting cnd_gebreken_scoremethode
-- - Er zijn objectgebonden meldingen met eigenschappen (cnd_ini.sql) die de conditiescore/prioriteit van een object (of "element") bepalen
-- - Er zijn 2 werkwijzen, nu aangeduid met setting cnd_gebreken_scoremethode
-- - - 1: deze meldingen stellen een meting voor, een inspectie, een opname. Die bepaalt dan de scores en je maakt vervolgmeldingen om te herstellen;
-- - daar telde iedere recente melding mee ongeacht de status (behalve vervallen)
-- - daar telde iedere melding mee ongeacht de status (behalve vervallen of verwerkt(?))
-- - - 2: deze meldingen constateren een gebrek, dat de scores bepaalt maar tegelijkertijd de melding is om het te herstellen. Afgemeld is het gebrek weg.
-- - als zo'n melding geaccepteerd/in behandeling is (status 0,4,7) telt die mee voor de score, anders niet
--
-- Onze berekening van de scores moet stateless zijn, d.w.z. je kunt de huidige score op elk moment herberekenen tot hetzelfde resultaat.
-- Onze berekening van de scores is nu stateless, d.w.z. je kunt de huidige score op elk moment herberekenen tot hetzelfde resultaat.
-- Dat is principieel anders dan het was: je mocht eenmalig berekenen op bepaalde triggermomenten, maar daarbuiten niet meer, berekeningen waren niet reproduceerbaar.
-- Gebrekmeldingen die Verwerkt(6) of Afgewezen(1) zijn beschouwen we totaal niet
-- Gebrekmeldingen die Verwerkt(6) of Afgewezen(1) zijn beschouwen we totaal niet, die halen we direct al weg uit de processing, die bestaan niet.
--
-- - de score van een object kan dus wijzigen indien er een bijbehorende gebrekmelding van/naar die status gaat of anderszins verandert (verwijderd bv)
-- de resterende gebreken bepalen dan de actuele score
-- - als er geen gebreken zijn dan is de score onbekend (nooit gebrek geweest) of nieuwstaat (1)
--
-- - Veranderd: je kunt in principe op elk moment de score van een object bepalen obv de meldingen van dat moment
-- - middels triggers op die gebreken willen we de score actueel houden
-- - Dus: je kunt in principe op elk moment de score van een object bepalen obv de meldingen van dat moment
-- - middels triggers of aanroepen (in ASP of waar nodig) forceren we herberekening. Veranderingen worden getrackt indien de score(s) ook daadwerkelijk veranderen
-- - gebreken kunnen ook in bulk geimporteerd worden
-- - het direct berekenen van de score kan onderdrukt worden door een status _in_bewerking op gebouw/terreinniveau, als dat weer aan gaat wordt het hele gebouw berekend
--
-- TODO: vertaalbare teksten (Plato noemt objecten elementen bv)
-- suspend-veld in GUI bij gebouw
--
DEFINE thisfile = 'CND.SQL'
@@ -1087,7 +1083,7 @@ AS
p_deel_key,
p_user_key,
NULL,
'Conditiescore: ' || TO_CHAR(loldscore1) ||lcl.l('lcl_trackto') || TO_CHAR(lnewscore1));
lcl.l('lcl_ins_deel_mjb_score1')||': ' || TO_CHAR(loldscore1) ||lcl.l('lcl_trackto') || TO_CHAR(lnewscore1));
ELSE
DBMS_OUTPUT.put_line ('Conditiescore ongewijzigd');
END IF;
@@ -1100,13 +1096,13 @@ AS
p_deel_key,
p_user_key,
NULL,
'Prioriteitscore is gewist'); -- PF snap nog niet goed waarom dit kan/bijzonder is
lcl.l('cnd_prioriteitscore_gewist')); -- geen score = ongedefinieerde (geen) prio
ELSE
fac.trackaction ('#INSUPD',
p_deel_key,
p_user_key,
NULL,
'Prioriteitscore: '||TO_CHAR(loldscore2) ||lcl.l('lcl_trackto')|| TO_CHAR(lnewscore2));
lcl.l('lcl_ins_deel_mjb_score2')||': '||TO_CHAR(loldscore2) ||lcl.l('lcl_trackto')|| TO_CHAR(lnewscore2));
END IF;
ELSE
DBMS_OUTPUT.put_line ('Prioriteitscore ongewijzigd');
@@ -1222,16 +1218,14 @@ AS
p_melding_key,
p_user_key,
NULL,
'Wijziging is verwerkt in de conditiescore van het object.');
lcl.l('cnd_conditiescore_verwerkt'));
ELSE
fac.trackaction (
'#MLDUPD',
p_melding_key,
p_user_key,
NULL,
'Wijziging is verwerkt in de conditiescore van de '
|| TO_CHAR (ldeelcnt)
|| ' objecten.');
lcl.l('cnd_conditiescore_verwerkt_m'));
END IF;
END IF;
END;
@@ -1326,7 +1320,7 @@ AS
locatie.alg_locatie_key,
NULL,
NULL,
'Conditiescore: ' || TO_CHAR(l_cond_score_old) ||lcl.l('lcl_trackto') || TO_CHAR(l_cond_score_new));
lcl.l('lcl_ins_deel_mjb_score1')||': ' || TO_CHAR(l_cond_score_old) ||lcl.l('lcl_trackto') || TO_CHAR(l_cond_score_new));
END IF;
END LOOP;
@@ -1350,7 +1344,7 @@ AS
gebouw.alg_gebouw_key,
NULL,
NULL,
'Conditiescore: ' || TO_CHAR(l_cond_score_old) ||lcl.l('lcl_trackto') || TO_CHAR(l_cond_score_new));
lcl.l('lcl_ins_deel_mjb_score1')||': ' || TO_CHAR(l_cond_score_old) ||lcl.l('lcl_trackto') || TO_CHAR(l_cond_score_new));
END IF;
END LOOP;