Wat is een geldig en redelijk alternatief voor een massale opslagaanpak (voor gebruikersautorisatie doeleinden)?

Ik gebruik ruby on Rails 3.2.2 en MySQL. Na mijn vorige vraag over " hoe om te gaan met massale opslag van records in de database voor gebruikersautorisatiedoeleinden ", omdat gerelateerde antwoorden (over hoe het probleem op te lossen of hoe te bereiken waar ik naar op zoek ben) niet voldoende gedetailleerd zijn of te veel resources vereisen (althans voor mij), Ik zou graag willen weten wat valide en redelijke alternatieven zijn voor die aanpak .

In enkele woorden, deze vraag kan een zin zijn als: hoe "complex" (op niveau van SQL-query's) gebruikersautorisaties worden behandeld wanneer u meer dan één "geautoriseerde" records? Dat is bijvoorbeeld omdat ik een readable_by_user? methode in mijn modelklasse, hoe meer dan één record (records kunnen 10 of miljarden miljarden zijn) door zo weinig mogelijk SQL-query's uit te voeren wanneer u code zoals de volgende gebruikt ( notitie : de volgende code wordt meestal gebruikt in index -controlleracties):

Article.readable_by_user(@current_user)
# => Returns all articles readable by the current user.
0
@mda - Het kan zijn dat mijn vraag "een beetje vaag" is, maar ik verwijs helemaal niet naar "login" . Het kan echter (misschien) zijn dat ik niet begrijp waar u precies naar verwijst ... kunt u explicieter zijn over hoe u gebruikersautorisaties naar session_id verwijst, zodat (zoals u zegt ) de laatste "kan nuttig zijn" in mijn geval? en hoe zit het met "[...] ... tenzij je voldoende uitgewerkt om een ​​ontwerpfout te tonen (zoals onnodige beperkingen)"?
toegevoegd de auteur Backo, de bron
@EJP - "Het idee is niet om het aantal SQL-query's te minimaliseren, maar zeker om hun totale tijds- en ruimtekosten te minimaliseren?" Ik denk dat beide "het aantal SQL-query's te minimaliseren" (omdat een kandidaat-oplossing kan een readable_by_user -methode uitvoeren op elk opgehaalde object/record - het is veel minder performant maar werkt) en "minimaliseren hun totale tijd en ruimtekosten "(omdat een andere kandidaat-oplossing veel autorisatierecords/objecten in een databasetabel moet opslaan - deze is om andere redenen minder performant maar werkt).
toegevoegd de auteur Backo, de bron
@KandadaBoggu - Misschien had het "laatste workflow-product waar u bij betrokken was" geen "complexe" autorisatiecontroles nodig zoals in mijn applicatie (met "complex" bedoel ik dat, om de gebruikersautorisatie gerelateerd te maken aan een enkel object om geslaagd of niet, het moet records uit andere databasetabellen "intern" worden opgehaald bij de gebruikersautorisatiemethode zelf).
toegevoegd de auteur Backo, de bron
@mda - Meer, wat bedoel je precies met "AAA-fase" in je eerste reactie?
toegevoegd de auteur Backo, de bron
@mda - Waarom denk je dat mijn vraag een duplicaat is, omdat ik om alternatieven vraag?
toegevoegd de auteur Backo, de bron
Het idee is niet om het aantal van SQL-query's te minimaliseren, maar zeker om hun totale tijds- en ruimtekosten te minimaliseren?
toegevoegd de auteur EJP, de bron
@Backo Ik bezoek deze oude vraag als onderdeel van de "close vote review" opruiming. Ik ben het ermee eens dat deze vraag anders is, maar in de praktijk heeft de gekoppelde vraag veel antwoorden die alternatieven bieden. Om die praktische reden stem ik om deze te sluiten.
toegevoegd de auteur Wayne Conrad, de bron
Laatste workflowproduct waarbij ik betrokken was ( tibco.com/company/news /releases/2003/press588.jsp ) hadden vergelijkbare vereisten. Individuele documenten hadden privileges. Tijdens het berekenen van de wachtrij voor de werknemer moest elk document worden geautoriseerd. Documenten hadden impliciete rechten zoals eigenaar, beheerder en werkstroom eigenaar. Hoewel elk document autorisatie behoeft, hadden de privileges geen enorme tabel nodig.
toegevoegd de auteur Harish Shetty, de bron
De vraag is een beetje vaag. Ben je het wiel aan het uitvinden? Natuurlijk zijn er bibliotheken die de AAA-fase kunnen uitvoeren (inloggen). Als de verbinding wordt gecodeerd, kan een session_id nuttig zijn. De complexiteit van uw SQL Schema moet niet gerelateerd zijn aan login- of toegangsrechten ... tenzij u voldoende uitgewerkt bent om een ​​ontwerpfout te tonen (zoals onnodige beperkingen).
toegevoegd de auteur mda, de bron
Uw beschrijving bevat niet de relevante delen van uw SQL Schema (een entiteit - relatiediagram bijvoorbeeld). Als u een "grote tafel" hebt en u denkt dat u die niet nodig hebt, voeg dan tabel (len) toe waarin de attributen van toestemming (en) zijn opgeslagen waar nodig. Er zal redundantie zijn van uids/unieke sleutels/aanwijzers, maar dat is altijd het evenwicht dat je zoekt tussen tijd en ruimtecomplexiteit. Een productie-db moet niet "volledig genormaliseerd" zijn, maar eerder aangepast om naar dat evenwicht te zoeken.
toegevoegd de auteur mda, de bron
Waarom stel je een dubbele vraag? Deze hele thread moet worden gemarkeerd of weggestemd. Ik ben klaar met deze vraag.
toegevoegd de auteur mda, de bron

Geen antwoorden

0