bd ripper
Normalisatie
Ik wil een "read-only" veld toevoegen op bepaalde tabellen.
Wat zou nu het beste zijn?
Een extra tabel die vermeld wat de status is en bij ontbreken een standaard gebruiken of
gewoon toevoegen als veld waarbij er altijd een status is; veldwaarde.
In andere gevallen zou ik dit niet vragen maar het gaat hier maar over 1 bool waarde per record. De tabel toevoegen gebruikt ook ruimte :)
Jan
Gewijzigd op 17/06/2023 10:02:24 door Jan R
En wat houdt "read-only" in: nooit meer aanpassen (tenzij "read only" weer wordt opgeheven), of alleen niet door bepaalde gebruikers. Op record niveau lijkt het me dan dat je het eerder over een soort status hebt (waarbij "read only" het "gevolg" is van deze status).
Rob Doemaarwat op 17/06/2023 11:02:22:
Je bedoelt een veld dat aangeeft dat het betreffende record "read-only" is? Of een enkel veld (in een record) dat "read-only" is (maar hoe wordt het dan bepaald, of in eerste instantie gevuld)?
En wat houdt "read-only" in: nooit meer aanpassen (tenzij "read only" weer wordt opgeheven), of alleen niet door bepaalde gebruikers. Op record niveau lijkt het me dan dat je het eerder over een soort status hebt (waarbij "read only" het "gevolg" is van deze status).
En wat houdt "read-only" in: nooit meer aanpassen (tenzij "read only" weer wordt opgeheven), of alleen niet door bepaalde gebruikers. Op record niveau lijkt het me dan dat je het eerder over een soort status hebt (waarbij "read only" het "gevolg" is van deze status).
Record is ro nu standaard in dezelfde tabel met standaard false
ro-record kan niet aangepast door geen enkele gebruiker tenzij opgegeven door hoger gebruiksniveau via een formulier.
via query iets zoals update veld="123" where id="852" and readonly=false zelfde principe voor delete.
Jan
https://dev.mysql.com/doc/refman/8.0/en/numeric-type-syntax.html
https://dev.mysql.com/doc/refman/8.0/en/boolean-literals.html
Je kunt daarmee aangeven wat de CRUD-rechten zijn van elke database entiteit.
Als het goed is kan dit sinds een paar jaar ook met MariaDB (in ieder geval voor kolommen)
Mocht je een gecastreerde database moeten gebruiken dan zijn VIEWs met aparte leestoegang een alternatief.
Ik zie geen reden waarom je dit zelf opnieuw zou willen maken, anders dan om te leren.
Voor het geval ik de vraag niet helemaal heb begrepen; databases zijn ook in staat om per rij autorisatie te regelen, via RLS of Row Level Security. Voorwaarde is dat je het eerst per tabel aanzet met ALTER TABLE ... ENABLE ROW LEVEL SECURITY; Daarna kan je policies aanmaken om te bepalen in welke situatie welke rechten van toepassing zijn voor welke rol(len).
Tenzij het over een paar miljoen records gaat, waarvan er maar 1 of 2 "read-only" zijn.
En zoals gezegd zou ik er een "status" veld van maken (tinyint enum). Dan kun je er in de toekomst misschien nog wat extra functionaliteit aan hangen.
Rob Doemaarwat op 17/06/2023 16:06:39:
Nou ... ik heb er niet voor (door)geleerd, maar ...
Ervaring telt ook!
Als het puur om rechten tot gegevens gaat, is niets makkelijker dan te typen GRANT <SELECT, INSERT, UPDATE..> ON tabel (kolom1, kolom2) TO <rol of user>;
Kom je er niet meteen uit dan kan je de linkjes gebruiken in mijn vorige post.
Bij normalisatie wil je elk begrip of ding of een eigen tabel geven. Dat is alles wat je kunt zien als een zelfstandig naamwoord. In de tabellen sla je een of meerdere dingen op die je kunt benoemen met het zelfstandig naamwoord. Bijvoorbeeld in de tabel 'stoel' sla je elke stoel op van de achtbaantrein.
In de meeste gevallen geef je elke rij in de tabel een eigen ID als sleutel, zodat je de relaties kunt vastleggen tussen de verschillende dingen (zelfstandig naamwoorden). In beschrijvende ERD-schema's zie je vaak op de lijntjes van de relaties een verklaring als 'W maakt een X', of 'Y bestaat uit meerdere Z'.
Eigenschappen van begrippen of dingen leg je vast in kolommen van de tabel. Ofwel je legt bijvoeglijke naamwoorden vast. De stoel kan misschien rood zijn, of blauw. Voordat je kolommen aanmaakt, onderga je de lastigste stap van normaliseren. Maak je twee kolommen die je 'rood' of 'blauw' noemt, of moet je eerst de bijvoeglijke naamwoorden categoriseren? Rood en blauw zijn kleuren, dus misschien is een kolom 'kleur' toepasselijker. Dat hangt af van waarvoor je het vastlegt. Wil je van beide kleuren weten of ze voorkomen? Dan is een kolom 'kleur' handiger. Zijn er veel kleuren mogelijk, zijn er andere objecten die een kleur kunnen hebben (bijvoorbeeld de achtbaantrein), of wil je meer dingen vastleggen over de kleur? Dan moet je kleur een eigen tabel geven.
De vuistregel is: zelfstandig naamwoorden een eigen tabel, bijvoeglijk naamwoorden in een kolom. Maar zoals je hierboven al kunt lezen is elke situatie uniek, en ook het categoriseren is meestal niet zo eenvoudig. Tijdens het bedenken van een schema kun je met een veelheid van bijvoeglijk naamwoorden te maken hebben wat het meteen al lastig maakt om te verzinnen wat bij wat hoort.
Vergeet niet het doel van normalisatie. Dat is om niets dubbel op te slaan. Er is op Wikipedia een heel artikel aan gewijd, met onderaan een artikel naar het tegenovergesteld denormalisatie.
Denormalisatie doe je wanneer het de database relatief veel moeite scheelt om gegevens op te vragen. Bijvoorbeeld als het combineren van tabellen lang gaat duren, of als je ingewikkelde queries moet gebruikt om gegevens af te leiden (al kun je daarvoor ook een MATERIALIZED VIEW voor gebruiken).
Ga lekker aan de slag en ontdek wat goed werkt voor jouw situatie. Kom je er niet uit dan helpt het ons om te weten wat je precies waarom wilt vastleggen, en hoe het schema er uitziet. Dan kan je heel gericht commentaar krijgen.
Ad Fundum op 18/06/2023 08:40:52:
Als het puur om rechten tot gegevens gaat, is niets makkelijker dan te typen GRANT <SELECT, INSERT, UPDATE..> ON tabel (kolom1, kolom2) TO <rol of user>;
Kom je er niet meteen uit dan kan je de linkjes gebruiken in mijn vorige post.
Kom je er niet meteen uit dan kan je de linkjes gebruiken in mijn vorige post.
Spijtig genoeg werkt een website altijd met dezelfde gebruiker.
Ozzie PHP op 17/06/2023 17:36:50:
Je kunt in MySQL ook Bit als datatype gebruiken om een boolean op te slaan.
Ward van der Put op 17/06/2023 14:38:55:
In MySQL zijn BOOL en BOOLEAN synoniemen van TINYINT(1), waarbij (int) 1 gelijk is aan TRUE en (int) 0 gelijk is aan FALSE.
ja/nee, waar/onwaar, 0/1 komt allemaal op hetzelfde neer hé :) sommigen gebruiken zelfs tekst. Dat is niet bepaald mijn favoriet.
Rob Doemaarwat op 17/06/2023 16:06:39:
Ik heb wel voor minder een veld toegevoegd dat maar sporadisch wordt gevuld. Als je elk afzonderlijk veld "dat wel eens null kan zijn" af gaat splitsen naar een aparte tabel raak je het overzicht ook kwijt.
Tenzij het over een paar miljoen records gaat, waarvan er maar 1 of 2 "read-only" zijn.
Tenzij het over een paar miljoen records gaat, waarvan er maar 1 of 2 "read-only" zijn.
Om het overzicht niet kwijt te raken wou ik het ook in de tabel houden maar ik wou het toch een vragen.
Het gaat momenteel over 2 tabellen waarbij de grootste nu op 4400 records bevat met een stijging van ±350 per jaar. Ik zal het einde van 1 000 000 niet halen denk ik. 2 800 jaar er nog bij.
Allen bedankt om mee te denken en ideeën door te geven.
Jan
Jan R op 18/06/2023 10:49:32:
Spijtig genoeg werkt een website altijd met dezelfde gebruiker.
Je kunt de gebruiker tijdens een sessie eenvoudig veranderen met SET SESSION AUTHORIZATION, bijvoorbeeld aan het einde van de authenticatieprocedure. Zelfs MySQL heeft iets vergelijkbaars in PHP met mysqli::change_user().
In plaats van bovenstaande kan je een tweede keer een databaseverbinding aanmaken met de andere gebruiker.
Je hebt in ieder geval keuze.
Op mijn nas zou ik er een paar honderd kunnen maken. Op mijn one.com website echter geen BIJmaken.