Προς το περιεχόμενο

Μαζική επεξεργασία με μία φόρμα


L34x88iT

Προτεινόμενες αναρτήσεις

1 ώρα πριν, k33theod είπε

Το 1ο νομίζω που κάνεις λάθος και ξεκίνησε το θέμα και δεν ξέρω αν ακόμη είναι ξεκάθαρο, είναι ότι με λάθος φορμα προσπαθείς να αλλάξεις κάποιον πίνακα στην database

Η φόρμα με τον πίνακα πρέπει να είναι σε αντιστοιχεία. Αν Θέλω να αλλάξω πίνακα που έχει permission_id, permission_title, permission_role, κάνω μια φόρμα που έχει όλα ή κάποια από αυτά τα στοιχεία και τα αλλάζω. Η φόρμα μου δηλαδή πρέπει απλά να έχει επιλογές για permission_title και permission_role. 

Εφόσον λοιπόν όπως λες το σύστημα authorization που έχεις λειτουργεί, και το πρόβλημα είναι να κάνεις edit τον πίνακα με φόρμα, κάνεις την σωστή φόρμα και τέλος.

Αυτά που λέει ο tsofras είναι σωστά  και είναι ένα τυπικό σύστημα. Μόνο αυτό με το κληρονομεί δεν κατάλαβα 😃

 

Η γενική έννοια περί κληρονομικότητας

Έχω τον διαχειριστή που έχει δικαίωμα read , write , delete

Έχω τον χρήστη admin που έχει ρόλο διαχειριστή οπότε "κληρονομεί" τα δικαιώματα read , write , delete.

Απλά με τον τρόπο που λέω εγώ θα μπορούσες να φτιάξεις τον χρήστη superAdmin που θα έχει τον ρόλο του admin (read,write,delete) και να του δώσεις και ένα ξεχωριστό δικαίωμα που δεν το έχει κανένας άλλος ρόλος.

Ελπίζω να έγινα κατανοητός :D

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

  • Απαντ. 32
  • Δημ.
  • Τελ. απάντηση

Συχνή συμμετοχή στο θέμα

8 λεπτά πριν, tsofras είπε

Ελπίζω να έγινα κατανοητός :D

Όχι, αλλά μάλλον είναι θέμα ηλικίας, οπότε δεν μπορούμε να κάνουμε κάτι.

Οι κλάσεις/έννοιες user και role δεν έχουν κάποια σχέση κληρονιμικότητας, είναι σχέση many to many. Μετά λες Ο χρήστης superAdmin θα έχει ρόλο admin. Μα ο admin δεν είναι ρόλος όπως έγραψες παραπάνω είναι χρήστης και αυτός.

 

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δημοσ. (επεξεργασμένο)
1 ώρα πριν, k33theod είπε

Όχι, αλλά μάλλον είναι θέμα ηλικίας, οπότε δεν μπορούμε να κάνουμε κάτι.

Οι κλάσεις/έννοιες user και role δεν έχουν κάποια σχέση κληρονιμικότητας, είναι σχέση many to many. Μετά λες Ο χρήστης superAdmin θα έχει ρόλο admin. Μα ο admin δεν είναι ρόλος όπως έγραψες παραπάνω είναι χρήστης και αυτός.

 

Ένα γρήγορο σχεδιάγραμμα μήπως γίνει πιο κατανοητό (το έφτιαξα στο πόδι οπότε δεν είναι το βέλτιστο απλά για την λογική το βάζω)

Users.png.73be886947d942ab2deb804ee9614f4b.png

 

Επειδή βαρέθηκα να ζωγραφίσω τα υπόλοιπα ας πούμε στα γρήγορα ότι :

 Στον πίνακα authorization έχουμε τις εγγραφές

1) autohID: 1 --> Read

2) autohID: 2 --> Write

3) autohID: 3 --> Delete

4) autohID: 4 --> Do Something Special

Στον πίνακα Role έχουμε τις εξής εγγραφές

1) roleID: 1 -->  autohID:1

2) roleID: 1 --> autohID:2

3) roleID: 1 --> autohID:3

Με το παραπάνω δηλαδή στον ρόλο με id 1 δώσαμε τα δικαιώματα 1,2,3

Σύμφωνα με τον παραπάνω σχεδιασμό μπορείς να φτιάξεις τους χρήστες :

1)Τον χρήστη thomas που να έχει ένα userProfile με μία εγγραφή που δείχνει στο ρόλο roleId 1 (οπότε θα κληρονομεί τα δικαιώματα 1,2,3) και μία εγγραφή με το δικαίωμα 4 (οπότε δίνεις και δικαίωμα κατευθείαν στον χρήστη χωρίς να ανήκει σε κάποιο ρόλο)

2) Τον χρήστη admin που απλά θα έχει ένα userProfile που θα δείχνει στον ρόλο roleID 1 οπότε θα έχει μόνο τα δικαιώματα του ρόλου

3) Τον χρήση mitsos που απλά θα έχει ένα userProfile που θα δείχνει απλά στο δικαίωμα 4 (Do Something Special) και δεν θα έχει κανέναν ρόλο

Οπότε έχουμε :

τον Χρήστη που έχει πολλά προφιλ

το προφιλ που έχει απο 0 έως πολλούς ρόλους , απο 0 εώς πολλά δικαιώματα

τον ρόλο που έχει πολλά δικαιώματα

και έναν κουβά με όλα τα δικαιώματα

Αν σας μπέρδεψα ευχαρίστως αύριο να φτιάξω κανονικά την δομή γιατί τώρα ήταν να φύγω και είδα το σχόλιο και είπα ας κάνω λίγο ζωγραφική :D

Επεξ/σία από tsofras
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

7 ώρες πριν, tsofras είπε

Αν σας μπέρδεψα ευχαρίστως αύριο να φτιάξω κανονικά την δομή γιατί τώρα ήταν να φύγω και είδα το σχόλιο και είπα ας κάνω λίγο ζωγραφική :D

tsofras,

Όσο δεν καταλαβαίναμε την προσέγγισή σου φαινότανε σωστή. Τώρα που μας τη ζωγράφισες, αντί για κληρονομικότητα προέκυψε μια… κυκλικότητα. Πίνακες με διπλότυπα κλειδιά, ρόλοι με δυνατότητα σε ένα μόνο δικαίωμα, αλλού γι’ αλλού τα FKs και πεδία γεμάτα με NULLs.

Σ’ αφήνουμε λοιπόν να φτιάξεις κανονικά τη δομή αύριο γιατί, όχι απλά στο πόδι ήτανε αλλά, στο βρόντο ήτανε – κανονικά. :-D

  • Confused 1
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

6 ώρες πριν, MastroGiannis είπε

tsofras,

Όσο δεν καταλαβαίναμε την προσέγγισή σου φαινότανε σωστή. Τώρα που μας τη ζωγράφισες, αντί για κληρονομικότητα προέκυψε μια… κυκλικότητα. Πίνακες με διπλότυπα κλειδιά, ρόλοι με δυνατότητα σε ένα μόνο δικαίωμα, αλλού γι’ αλλού τα FKs και πεδία γεμάτα με NULLs.

Σ’ αφήνουμε λοιπόν να φτιάξεις κανονικά τη δομή αύριο γιατί, όχι απλά στο πόδι ήτανε αλλά, στο βρόντο ήτανε – κανονικά. :-D

Που είναι η κυκλικότητα και γιατί θεωρείς ότι ήταν στον βρόντο η δομή ?

Μπορείς να μου πείς τα μειονεκτήματα που έχει η δομή αυτή για να το συζητήσουμε ?

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Εγώ το βλέπω αλλιώς άλλη προσέγγιση δηλάδη.

Πίνακας userς  κανένα πεδίο που αφορά το authorization

Πίνακας roles κανένα πεδίο που αφορά το authorization

Πίνακας user_role δύο keys του user και του role. σχέση many to many

Πίνακας Model κανένα πεδίο που αφορά το authorization. Είναι ένα πίνακας που έχει abstract τους πίνακες που θέλω να ελέγχω για authorize π.χ Articles, Autos, Users

Πίνακας Authorizations έχει το model_id και το role_id Το είδος του auth μπορεί να είναι ένα τρίτο key ή τα πεδία read write update kai delete Αν έχουμε μόνο τα standart δικαιώματα

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δημοσ. (επεξεργασμένο)

Επειδή έχω και αρκετή δουλειά σήμερα σας παραθέρω ένα sql fiddle

Τώρα αν δεν είμαι κατανοητός , δεν σας αρέσει η δομή , είναι το design στο βρόντο κτλ. συνεχίζει ο καθένας την ζωή του και είμαστε όλοι ευτυχισμένοι :D

http://sqlfiddle.com/#!9/4c1510/18

-- Schema
CREATE TABLE authorizations (
  authId int NOT NULL AUTO_INCREMENT,
  name varchar(255) NOT NULL,  
  PRIMARY KEY (authId)
);


CREATE TABLE roles (
  roleId int NOT NULL AUTO_INCREMENT,
  name varchar(255) NOT NULL,  
  PRIMARY KEY (roleId)
);

CREATE TABLE roles_authorizations (
  id int NOT NULL AUTO_INCREMENT,
  roleId int NOT NULL,
  authId int NOT NULL,
  PRIMARY KEY (id),
  FOREIGN KEY (roleId) REFERENCES roles(roleId),
  FOREIGN KEY (authId) REFERENCES authorizations(authId)  
);

CREATE TABLE users (
  userId int NOT NULL AUTO_INCREMENT,
  name varchar(255) NOT NULL,  
  PRIMARY KEY (userId)
);

CREATE TABLE user_profiles (
  profileId int NOT NULL AUTO_INCREMENT,
  userId int NOT NULL,  
  isPersonal boolean,  
  roleId int,
  authId int,  
  PRIMARY KEY (profileId),
  FOREIGN KEY (userId) REFERENCES users(userId),
  FOREIGN KEY (roleId) REFERENCES roles(roleId),
  FOREIGN KEY (authId) REFERENCES authorizations(authId)  
);

INSERT INTO authorizations (name) VALUES ('Read');
INSERT INTO authorizations (name) VALUES ('Write');
INSERT INTO authorizations (name) VALUES ('Delete');
INSERT INTO authorizations (name) VALUES ('Special Authorization');

INSERT INTO roles (name) VALUES ('Simple User');
INSERT INTO roles (name) VALUES ('Admin');

INSERT INTO roles_authorizations (roleId,authId) VALUES (1,1);
INSERT INTO roles_authorizations (roleId,authId) VALUES (2,1);
INSERT INTO roles_authorizations (roleId,authId) VALUES (2,2);
INSERT INTO roles_authorizations (roleId,authId) VALUES (2,3);

INSERT INTO users (name) VALUES ('admin');
INSERT INTO users (name) VALUES ('thomas');
INSERT INTO users (name) VALUES ('mitsos');

INSERT INTO user_profiles (userId,isPersonal,roleId,authId) VALUES (1,false,2,null);
INSERT INTO user_profiles (userId,isPersonal,roleId,authId) VALUES (2,true,2,4);
INSERT INTO user_profiles (userId,isPersonal,roleId,authId) VALUES (3,false,1,null);


-- Query for user authorizations
SELECT distinct(a.name) FROM users u
join user_profiles up on (u.userId = up.userId)
join roles r on ( up.roleId is not null and r.roleId = up.roleId )
join roles_authorizations ra on (ra.roleId = r.roleId)
join authorizations a on 
(
  (up.authId is not null and a.authId = up.authId)
  or
  (up.roleId is not null and a.authId = ra.authId)
)
where u.name = 'thomas';

 

Επεξ/σία από tsofras
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

1 ώρα πριν, tsofras είπε

Επειδή έχω και αρκετή δουλειά σήμερα σας παραθέρω ένα sql fiddle

Σήμερα κάπως το συμμάζεψες αλλά, ως προς το προηγούμενο σχήμα, το πιο βροντερό είναι αυτό:

17 ώρες πριν, tsofras είπε

Στον πίνακα Role έχουμε τις εξής εγγραφές

1) roleID: 1 -->  autohID:1

2) roleID: 1 --> autohID:2

3) roleID: 1 --> autohID:3

Με το παραπάνω δηλαδή στον ρόλο με id 1 δώσαμε τα δικαιώματα 1,2,3

ενώ ο πίνακας User έχει διπλότυπο userID και Name για να μπορέσεις να δώσεις δυο profiles στον Thomas. Αντί δηλαδή το userID να εμφανίζεται στον πίνακα UserProfile συμβαίνει το αντίθετο, όπως ακριβώς συμβαίνει και με τον πίνακα role σε σχέση με τον πίνακα Authorization. Με αυτή τη δομή, κάθε roleID μπορεί να έχει μόνο ένα authorization. Με τον όρο κυκλικότητα, αναφερόμουν στη σχέση UserProfile-Role-Authorization, η οποία, ούτως ή άλλως είναι άκυρη και πλέον δεν έχει σημασία.

Μην παρεξηγείς όμως τις προθέσεις μου, η κριτική μου είναι καλοπροαίρετη και οι παρατηρήσεις μου προς βελτίωση (και δικής μου φυσικά).

Επειδή όμως είμαι κι εγώ full busy σήμερα (και όχι με το laptop αλλά με το αλυσοπρίονο), αφήνω μόνο ένα μικρό σχήμα. Μοιάζει αρκετά με την τελευταία σου πρόταση (το έστησα όμως πριν τη δω) αλλά είναι πιο συμπαγές, με την έννοια ότι δεν αφήνει περιθώρια για τιμές NULL. Κάθε χρήστης, μέσω του προφίλ του, "κληρονομεί" τα δικαιώματα του στάνταρ ρόλου του αλλά και ειδικά δικαιώματα μέσω του πίνακα tblSpecialAuths (αν εμφανίζεται εκεί μέσα το προφίλ του). Μπορεί επίσης, ως χρήστης,  να έχει πολλά προφίλ αλλά το "τρέχον" είναι το τελευταίο, έτσι ώστε να τηρείται κι ένα ιστορικό των προφίλ του.

usersModel.jpg.7068e6f9a80e9da64c108d96869ec4d0.jpg

Τα υπόλοιπα αργά το βράδυ.

Καλή συνέχεια!

Υ.Γ. Μοιάζει να κάνουμε έρευνα για τον τροχό αλλά, στην ηλικία μας, ως άσκηση, είναι καλή για το "ακόνισμα" του "πριονιού" μας. :D

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

23 λεπτά πριν, MastroGiannis είπε

Σήμερα κάπως το συμμάζεψες αλλά, ως προς το προηγούμενο σχήμα, το πιο βροντερό είναι αυτό:

ενώ ο πίνακας User έχει διπλότυπο userID και Name για να μπορέσεις να δώσεις δυο profiles στον Thomas. Αντί δηλαδή το userID να εμφανίζεται στον πίνακα UserProfile συμβαίνει το αντίθετο, όπως ακριβώς συμβαίνει και με τον πίνακα role σε σχέση με τον πίνακα Authorization. Με αυτή τη δομή, κάθε roleID μπορεί να έχει μόνο ένα authorization. Με τον όρο κυκλικότητα, αναφερόμουν στη σχέση UserProfile-Role-Authorization, η οποία, ούτως ή άλλως είναι άκυρη και πλέον δεν έχει σημασία.

Μην παρεξηγείς όμως τις προθέσεις μου, η κριτική μου είναι καλοπροαίρετη και οι παρατηρήσεις μου προς βελτίωση (και δικής μου φυσικά).

Επειδή όμως είμαι κι εγώ full busy σήμερα (και όχι με το laptop αλλά με το αλυσοπρίονο), αφήνω μόνο ένα μικρό σχήμα. Μοιάζει αρκετά με την τελευταία σου πρόταση (το έστησα όμως πριν τη δω) αλλά είναι πιο συμπαγές, με την έννοια ότι δεν αφήνει περιθώρια για τιμές NULL. Κάθε χρήστης, μέσω του προφίλ του, "κληρονομεί" τα δικαιώματα του στάνταρ ρόλου του αλλά και ειδικά δικαιώματα μέσω του πίνακα tblSpecialAuths (αν εμφανίζεται εκεί μέσα το προφίλ του). Μπορεί επίσης, ως χρήστης,  να έχει πολλά προφίλ αλλά το "τρέχον" είναι το τελευταίο, έτσι ώστε να τηρείται κι ένα ιστορικό των προφίλ του.

usersModel.jpg.7068e6f9a80e9da64c108d96869ec4d0.jpg

Τα υπόλοιπα αργά το βράδυ.

Καλή συνέχεια!

Υ.Γ. Μοιάζει να κάνουμε έρευνα για τον τροχό αλλά, στην ηλικία μας, ως άσκηση, είναι καλή για το "ακόνισμα" του "πριονιού" μας. :D

Δεν παρεξήγησα συγνώμη αν φάνηκε έτσι για πλάκα το έγραψα , προφανώς και υπάρχουν πολλές λύσεις με τα θετικά και αρνητικά που έχει η κάθε μία , και έχεις δίκιο το πρώτο διάγραμμα το έκανα στο πόδι σε 5 λεπτά αλλά δεν ήταν σωστή αποτύπωση νόμιζα ότι θα πιάνατε το νόημα ως προς τις σχέσεις και όχι ως προς τους πίνακες ήταν περισσότερο entity diagram

null αν καταλαβαίνω καλά μπορεί να έχει και το δικό σου διάγραμμα γιατί μπορεί να φτιάξεις ένα profile που έχει μόνο specialAuth αλλά δεν έχει role , σωστά? Οπότε στο ίδιο καταλήγει περίπου

Τώρα για το ξεσκόνισμα και εγώ έχω να ασχοληθώ πάνω απο 10 χρόνια με χρήστες για αυτό μπήκα και έγραψα σχόλιο , όπως ακριβώς είπες για να ξεσκονίσω λίγο :D

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Εδώ είναι το κομμάτι της db από το σύστημα authorization που έρχεται έτοιμο με το django, για να έχουμε ένα μέτρο σύγκρισης. Δεν είναι το τέλειο είναι όμως αποδεκτό. Οι πίνακες έχουν prefix auth οπότε μπορεί να αφαιρεθεί για να είναι πιο κατανοητό. Επίσης κατά τη γνώμη μου ο πίνακας auth_user_user_permission μπορεί να φύγει τελείως εφόσον δεν απαιτούνται permissions σε μεμονομένους users. Και μία foto από entries στον πίνακα permission που νομίζω είναι ο πιο δυσνόητος. 

 

django_auth_db.png.71729ecd7ce34c1c0d29e1d4facd6140.png

permission.png

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Hi guys!

Sorry για την καθυστέρηση. Είναι βαριά η καλογερική. Γλιτώνεις πολλά ασφάλιστρα αλλά όχι και την ολοήμερη γυμναστική στη φύση. B)

Στις 8/4/2021 στις 2:01 ΜΜ, tsofras είπε

null αν καταλαβαίνω καλά μπορεί να έχει και το δικό σου διάγραμμα γιατί μπορεί να φτιάξεις ένα profile που έχει μόνο specialAuth αλλά δεν έχει role , σωστά? Οπότε στο ίδιο καταλήγει περίπου

 

Σωστή η παρατήρησή σου και, όπως φαίνεται, "κόβει" καλά το "πριόνι". ;)

Υπάρχει όμως μια λεπτή αλλά σημαντική διαφορά: ο κύριος σκοπός του πίνακα tblProfiles είναι η συνένωση των χρηστών με τους ρόλους, και, η ανυπαρξία ρόλου σε κάποια εγγραφή αποτελεί εξαίρεση, η οποία θα μπορούσε να χαρακτηρίσει έναν χρήστη ως «Special user», ή να αποφευχθεί αν το κλειδί του πίνακα ήταν τα δύο σχετικά πεδία, ενώ, το πεδίο auth στον πίνακα UserProfile του πρώτου σου σχήματος, είναι κατά κανόνα Null. Φυσικά, ως «Special user» θα έπρεπε να χαρακτηρίζεται ο χρήστης το id του οποίου εμφανίζεται άμεσα στον πίνακα tblSpecialAuths (αντί για το id του προφίλ του) αλλά, θεώρησα απίθανο ένας χρήστης να μην έχει προφίλ και να έχει δικαιώματα. Μιας και δεν έχω σχετική εμπειρία, υπάρχει όντως τέτοια περίπτωση;

Στις 8/4/2021 στις 4:42 ΜΜ, k33theod είπε

Δεν είναι το τέλειο είναι όμως αποδεκτό.

Είναι αποδεκτό υπολογιζόμενα πεδία του τύπου last_login και is_superuser να ανήκουν σε πίνακα (auth_user) αντί σε ερώτημα (view κτλ);

Στις 8/4/2021 στις 5:44 ΜΜ, tsofras είπε

To έχουμε τερματίσει το ποστ :D

ο TS θα έχει φύγει τρέχοντας χεχε

Καλά, ο TS θα έχει εμπεδώσει ήδη και την αναδρομή και θα τρέχει το πρότζεκτ ιεραρχικά. :-D

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

31 λεπτά πριν, MastroGiannis είπε

Φυσικά, ως «Special user» θα έπρεπε να χαρακτηρίζεται ο χρήστης το id του οποίου εμφανίζεται άμεσα στον πίνακα tblSpecialAuths (αντί για το id του προφίλ του) αλλά, θεώρησα απίθανο ένας χρήστης να μην έχει προφίλ και να έχει δικαιώματα. Μιας και δεν έχω σχετική εμπειρία, υπάρχει όντως τέτοια περίπτωση;

Εγώ με την παραπάνω λογική ξεκίνησα την κουβέντα γιατί και στο δικό μας σύστημα καταλάβαμε ότι υπάρχει η ανάγκη να έχεις και χρήστες που ουσιαστικά δεν έχουν προφιλ και απλά χρειάζονται ένα συγκεκριμένο δικαίωμα. Μην κοιτάς στο παράδειγμα που κάνουμε με 4-5 δικαιώματα , στο σύστημα που δουλεύω εγώ αυτή τη στιγμή έχουμε 980 δικαιώματα και  χρειάζεται αρκετές φορές να φτιάξουμε έναν νέο χρήστη για κάποιες ώρες που να έχει ένα συγκεκριμένο δικαίωμα για να κάνει μία συγκεκριμένη δουλειά .

Σίγουρα δεν είναι η καθημερινότητα αλλά υπάρχει ώς ανάγκη . Αν δεν το είχα δεί στη πράξη δεν θα το σκεφτόμουν ποτέ να το βάλω στη σχεδίαση πάντως

  • Thanks 1
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δημοσ. (επεξεργασμένο)
Στις 13/4/2021 στις 1:16 ΜΜ, MastroGiannis είπε

Είναι αποδεκτό υπολογιζόμενα πεδία του τύπου last_login και is_superuser να ανήκουν σε πίνακα (auth_user) αντί σε ερώτημα (view κτλ);

Αυτό δεν έχει όμως καμμία σχέση με το Authorization. Στο δικό μου user πχ έχω column favorite coffee, γιατί είναι site για καφέ. Πρέπει να κάνεις foυcus στο auth κομμάτι.

 

Επεξ/σία από k33theod
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δημοσ. (επεξεργασμένο)
Στις 16/4/2021 στις 11:12 ΠΜ, k33theod είπε

Αυτό δεν έχει όμως καμμία σχέση με το Authorization. Στο δικό μου user πχ έχω column favorite coffee, γιατί είναι site για καφέ. Πρέπει να κάνεις foυcus στο auth κομμάτι.

 

Sorry, μου έχει μείνει κουσούρι από τη διόφθαλμη σκόπευση.

Η αλήθεια όμως είναι πως δεν έχεις και απόλυτο δίκιο (αποτέλεσμα προφανώς της υπερβολικής εστίασης σε ένα στόχο), αφού, στην πραγματικότητα, το συγκεκριμένο νήμα δεν έχει σχέση αυστηρά με το Authorization αλλά με την κακή δομή ενός σχήματος, το οποίο, πέρα από λειτουργικές δυσκολίες (δυσκολία του TS στο update), είναι και σε θέση να επιστρέψει λάθος πληροφορίες. Όπως για παράδειγμα στην περίπτωσή σου (υπολογιζόμενα πεδία σε πίνακες), αν ο χρήστης δηλώσει ως favorite coffee το frappe και στη συνέχεια οι παραγγελίες του αφορούν όλες τον cappuccino, ποιος πραγματικά είναι ο favorite coffee του χρήστη; Επίσης, στο σχήμα που παραθέτεις, το πεδίο last_login θα πρέπει να ενημερώνεται σε κάθε login του χρήστη, μια διαδικασία επιπρόσθετη και επισφαλής, η οποία σε ένα κανονικοποιημένο σχήμα δεν θα ήταν αναγκαία.

Καλή είναι η εστίαση στο στόχο αλλά δεν πρέπει να χάνουνε τη μεγάλη εικόνα εξαιτίας της.

Επεξ/σία από MastroGiannis
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα

  • Δημιουργία νέου...