Vastus: Üks võimalus oleks luua soovitatud muudatuste jaoks tabelid.

Soovituse_seisundi_liik(soovituse_seisundi_liik_kood, nimetus)
Primaarvõti (soovituse_seisundi_liik_kood)
Alternatiivvõti (nimetus)

Tabelis Soovituse_seisundi_liik on registreeritud seisundid "esitatud", "vastuvõetud" ja "tühistatud".

Muutmise_soovitus (soovitus_id, skeemi_nimi, tabeli_nimi, veeru_nimi, võti, väärtus, soovituse_aeg, soovitaja, soovituse_seisundi_liik_kood)
Primaarvõti (soovitus_id)
Alternatiivvõti (skeemi_nimi, tabeli_nimi, veeru_nimi, võti, soovituse_aeg, soovitaja)
Välisvõti (soovituse_seisundi_liik_kood) Viitab Soovituse_seisundi_liik(soovituse_seisundi_liik_kood)
Välisvõti (soovitaja) Viitab Kasutaja (kasutaja_id)

• Tabeli Muutmise_soovitus veerul soovituse_seisundi_liik_kood on vaikimisi väärtuseks seisundile "esitatud" vastav kood.
• Tabeli Muutmise_soovitus veerul soovituse_aeg on vaikimisi väärtuseks ajatempli leidmiseks mõeldud funktsiooni poole pöördumine.
• (skeemi_nimi, tabeli_nimi, veeru_nimi) identifitseerivad tabeli+veeru, kus soovitakse muudatust teha ning veerus võti olev väärtus identifitseerib rea tabelis, milles soovitakse muudatust teha.
• Muutmise_soovitus veerg võti võiks näiteks olla massiivitüüpi text[][] ning seal oleks registreeritud võtmeveergude nimede ja nende väärtuste tekstiliste esituste paarid. Alternatiiv oleks see esitada JSON objektina ja siis oleks veerg võti tüüpi JSONB. Variant oleks ka kasutata tüüpi hstore, millesse kuuluvad väärtused on võti-väärtus paaride hulgad.
• Tabeli Muutmise_soovitus veerg väärtus on tekstitüüpi (PostgreSQL puhul tüüpi TEXT), et registreerida soovitatud väärtuse tekstiline esitus. Kas soovituse esitamisel või ülevaatamisel tuleb kontrollida, et see on teisendatav sobivat tüüpi väärtuseks (a'la, keegi soovitab kuupäeva 31. veebruar 2022). Veeru tüübi saab kindlaks teha päringu abil INFORMATION_SCHEMA.columns süsteemikataloogi vaate põhjal, sest soovituse tabelis on skeemi, tabeli ja veeru nimi registreeritud.

Tabel Muutmise_soovitus on mõeldud selleks, et soovitada UPDATE operatsioone. Kui soovitada saaks ka ridade lisamist (INSERT) või kustutamist (DELETE), siis selleks looksin eraldi tabelid (Lisamise_soovitus ja Kustutamise_soovitus). Tabelis Kustutamise_soovitus ei ole vaja veerge veeru_nimi ja väärtus. Tabelis Lisamise_soovitus ei ole vaja veerge veeru_nimi ja võti. Veerus väärtus peab olema lisatava rea esitus (sõltuvalt kasutatavast tüübist kas massiivina, JSON objektina või võti-väärtus paaride hulgana).

Keerukust soovituste ülevaatamisele lisab see, kui samale väljale/reale on tehtud mitu soovitust. Ilmselt peaks ülevaatajale kõiki näitama ja andma talle võimaluse ühe valida või enda poolt mingi kombineeritud väärtus sisestada.

Edasiarenduseks on näiteks võimalus määrata, kas kasutajale või kasutajate rollile (mida võib omada mitu kasutajat) veerud, mille jaoks on tal üldse lubatud muudatusi soovitada.

Kastutaja (kasutaja_id, ....)
Primaarvõti (kasutaja_id)

Kasutaja_roll (kasutaja_roll_kood, nimetus)
Primaarvõti (kasutaja_roll_kood)
Alternatiivvõti (nimetus)

Kasutaja_rolli_omamine (kasutaja_id, kasutaja_roll_kood)
Primaarvõti (kasutaja_id, kasutaja_roll_kood)
Välisvõti (kasutaja_id) Viitab Kasutaja (kasutaja_id)
Välisvõti (kasutaja_roll_kood) Viitab Kasutaja_roll (kasutaja_roll_kood)

Muutmise_soovituse_luba (skeemi_nimi, tabeli_nimi, veeru_nimi, kasutaja_roll_kood)
Primaarvõti (skeemi_nimi, tabeli_nimi, veeru_nimi, kasutaja_roll_kood)

Kui soovitada saab ka ridade lisamist või kustutamist, tuleks luua ka tabelid Lisamise_soovituse_luba ja Kustutamise_soovituse_luba.

Õiguste poolelt soovitaksin lahendust, kus igale rakenduse lõppkasutajale (mille kohta on rida tabelis Kasutaja) vastaks ka eraldi andmebaasi kasutaja (seda on muide tehtud selles näiteprojektis) nii nagu soovitakse  SELLES artiklis andmebaasipõhise turvalisuse tagamise mudeli kohta. See võimaldab teha nii, et rakenduse kasutajatel, kes saavad soovitada muudatusi, on INSERT õigus tabeli Muutmise_soovitus suhtes, kuid ei ole UPDATE õigust tabelite suhtes, mille jaoks muudatusi soovitatakse. Rakenduse kasutajatel, kes saavad ise otse muudatusi teha on UPDATE õigus muudetava tabeli suhtes, kuid ei ole INSERT õigust tabeli Muutmise_soovitus suhtes.

Muudatuste kinnitamiseks võiks luua plpgsql keeles kirjutatud funktsiooni, mis koostab muudatuste soovituse andmete põhjal dünaamiliselt SQL lause, mille abil muudatus ära teha, käivitab selle lause ja muudab ühtlasi soovituse seisundit. Kui funktsioonis kasutada SECURITY DEFINER määrangut, siis saab teha nii, et ülevaatajal on funktsiooni käivitamise õigus, kuid tal ei ole muutmisõiguseid soovituste tabeli ja tegelike andmetega tabeli suhtes.