PhpMyAdmin moet enkel 1 tabel tonen
Binnenkort wil het Ministerie van OCW in mijn database meekijken van lerarentekortisnu.nl, waar ik graag aan mee werk.
Nu staan daar ook veel gegevens die zij helemaal niet hoeven te zien.
Hoe kan ik maken dat ze wel de database kunnen zien, maar dan enkel 1 (of 2) tabellen?
Ik kan uiteraard een andere gebruiker aanmaken met enkel lees-rechten etc, maar dan limiteer ik ze nog steeds niet tot 1 tabel.
Hoe?
Of de rest overhevelen naar een andere database?
Of kan ik ze enkel één view laten zien, maar wel dat zelf allerlei functies als SUM(), COUNT(), JOIN LEFT() etc kunnen gebruiken?
Code (php)
1
2
2
GRANT SELECT ON database.tabel1 TO 'ocw';
GRANT SELECT ON database.tabel2 TO 'ocw';
GRANT SELECT ON database.tabel2 TO 'ocw';
Kwam het hier tegen :
https://serverfault.com/questions/565343/how-to-grant-and-revoke-rights-to-tables-using-phpmyadmin
Op andere plaatsen zal het ook wel te vinden zijn.
Met adminer vul ik velden in.
https://www.adminer.org/
Ik weet niet wat er nog meer in je database staat, maar als dit persoonsgegevens zijn druist dit behoorlijk tegen de AVG-regelgeving aan.
Gewijzigd op 22/07/2019 19:29:17 door - Ariën -
- Ariën - op 22/07/2019 19:27:45:
Waarom stuur je ze geen dump, of aangepast uittreksel?
Potentieel verouderde informatie. Onnodig extra werk.
- Ariën - op 22/07/2019 19:27:45:
Ik weet niet wat er nog meer in je database staat, maar als dit persoonsgegevens zijn druist dit behoorlijk tegen de AVG-regelgeving aan.
Dit kun je, zoals @Adoptive aangeeft, zelf helemaal dichttimmeren. Plus ik neem aan dat er een soort van "code of conduct" wordt afgesproken, waarin staat vastgelegd waarvoor de data wel en niet gebruikt mag worden. En met views zou je de data op voorhand al geanonimiseerd kunnen aanbieden als privacy een heikel punt zou zijn.
Als dat teveel moeite kost, dan kan je het één en ander overhevelen naar een doorspit-database en eventueel anonimiseren. Nadeel: Deze is niet up-to-date, maar je kan met een geautomatiseerd proces dit wel elke dag actualiseren. Ik neem aan dat dit wel voldoende is voor hun onderzoek.
Andere partijen laten spitten in live-database vind ik een dikke no-go, tenzij er echt noodzaak voor is (jusitie o.i.d.). Ook als je alles dichttimmert, waarbij je mag hopen dat je niet teveel dichttimmert zodat je applicatie niet meer goed werkt, om maar wat te zeggen. Of wat als je door een fout iets niet goed dichttimmert en iemand per ongeluk wat verwijderd.
Gewijzigd op 22/07/2019 23:10:51 door - Ariën -
- Ariën - op 22/07/2019 23:10:16:
Ook als je alles dichttimmert, waarbij je mag hopen dat je niet teveel dichttimmert zodat je applicatie niet meer goed werkt, om maar wat te zeggen. Of wat als je door een fout iets niet goed dichttimmert en iemand per ongeluk wat verwijderd.
Zolang je dit alles -wat voor oplossing je ook kiest- ophangt aan een aparte database-user zou dat de normale werking niet moeten belemmeren?
Wat is er mis met een losse doorzoek-database?
- Ariën - op 22/07/2019 23:32:25:
Wat is er mis met een losse doorzoek-database?
Je creëert daarmee zelf een synchronisatieprobleem, het lijkt mij gewoon veel makkelijker om één bron voor je data te hebben?
Gewijzigd op 23/07/2019 01:03:09 door - Ariën -
Toevoeging op 23/07/2019 05:46:27:
Moet dir niet via een rechter gaan?
@Topicstarter: Maar wat voor informatie staat er in deze database? En hoe is deze ingedeeld?
Gewijzigd op 23/07/2019 09:43:27 door - Ariën -
- Ariën - op 22/07/2019 23:10:16:
Ikzelf zou niemand zomaar vrij in een database laten kijken. Dan zou ik liever voor een dynamisch script gaan waarbij ze zelf kunnen zoeken, sorteren etc.
Als dat teveel moeite kost, dan kan je het één en ander overhevelen naar een doorspit-database en eventueel anonimiseren. Nadeel: Deze is niet up-to-date, maar je kan met een geautomatiseerd proces dit wel elke dag actualiseren. Ik neem aan dat dit wel voldoende is voor hun onderzoek
Als dat teveel moeite kost, dan kan je het één en ander overhevelen naar een doorspit-database en eventueel anonimiseren. Nadeel: Deze is niet up-to-date, maar je kan met een geautomatiseerd proces dit wel elke dag actualiseren. Ik neem aan dat dit wel voldoende is voor hun onderzoek
Dit lijkt mij een mooie oplossing.
Al is het maar elk uur dat het geupdated wordt.
Wellicht gewoon een extra sql-user aanmaken met 1 extra database.
En dan daarin enkel wat ze nodig hebben (enige 'persoonsgegeven' is een emailadres).
Voor de rest geen bewaar ik geen emailadressen, wachtwoorden etc.
Maar in andere tabellen (zelfde database) heb ik die wel .Dat mogen zij niet zien.
Over het afspreken wat er gebruikt kan worden: dat is onderwerp van gesprek binnenkort.
Voorheen was alle data (geanonimiseerd uiteraard) vrijelijk downloadbaar.
Toevoeging op 23/07/2019 17:36:33:
Jan R op 23/07/2019 05:46:01:
Ik wist niet dat een ministerie zomaar eigen databases mag opvragen? Is dit dan niet in strijd met de avg?
Toevoeging op 23/07/2019 05:46:27:
Moet dir niet via een rechter gaan?
Toevoeging op 23/07/2019 05:46:27:
Moet dir niet via een rechter gaan?
Gaat, zoals reeds gezegd, om een vrijwillige samenwerking tussen Ministerie en mij.
Dus dit speelt geen rol. De vakbond Aob krijgt ook wekelijks data, maar dan enkel als Excel-bestand.
En de statistieken/conclusie staat al op https://lerarentekortisnu.nl/statistieken-po/?geavanceerd
Toevoeging op 23/07/2019 17:39:23:
- Ariën - op 23/07/2019 09:04:24:
Volgens mij gaat om een verzoek en een samenwerking, en geen juridische procedure.
@Topicstarter: Maar wat voor informatie staat er in deze database? En hoe is deze ingedeeld?
@Topicstarter: Maar wat voor informatie staat er in deze database? En hoe is deze ingedeeld?
Vooral registraties van wanneer school+klas+groep+aantal-leerlingen etc een lerarentekort had. En hoe het is 'opgelost'.
Per datum, per school (op BRIN-nummer), per groep en oplossing is er 1 record. Gaat om iets van 300.000 records inmiddels. Dan is SQL beter dan Excel ;)
Daarnaast nog wat koppeltabellen waarin ik de brin-nummer (soort kenteken voor een school) heb met daarin de naam, plaats, gps-coördinaten, postcode en bestuurnummer.
Want ook daarvoor is weer een koppeltabel.
Ik ga denk een overzicht genereren en die per uur updaten naar een aparte database die enkel lees-rechten heeft.
Dat lijkt mij wel even wat werk, maar is wel waterdicht en voorkomt dat ze fouten kunnen maken.
Of je maakt gewoon een pagina met een overzicht of is dat te simpel?
Met een SQL-database is dat wel het geval, ook voor SUM/COUNT/SORT etc, maar vooral de GROUP BY() en GROUP BY CONCAT() wat handig is.
Daarnaast moet er een referentie komen (zo'n vergelijkingslijst) met een lijst met 6500 brin-nummers.
Momenteel kopieer de data.
Eerst leeg ik de tabel, dan stel ik vanuit 4 andere tabellen 1 nieuwe lijst records samen en die voeg ik in.
Dit duurt zo'n 3 minuten.
Via een cron-job laat ik dit om de 4 uur (0:00, 6:00, 12:00, 18:00) dit uitvoeren.
Kan dat synchroniseren wellicht sneller?
Daar ga ik nog naar kijken.
Toevoeging op 25/07/2019 08:32:52:
Alle direct kopiëren tussen de tabellen, zonder eerst alles in PHP te laden verkorte de tijd van ongeveer 180 seconden naar 4 seconden.
Moest wel even de database-user kopieren naar de nieuwe database (die van OCW) maar dit is een stuk sneller.
Nu openen zij een URL, die verwijdert alle ocw-data, kopieert alle nieuwe ocw-data (in 4 seconden) en stuurt hen automatisch door naar phpMyAdmin.
Hiervoor heb je alsnog inloggegevens nodig, maar die krijgen zij van mij.
Bedankt voor de hulp heren!