Komentarze do: Role Based Access Control cz.2

Autor: cojack

cojack — Mon, 25 Jan 2010 08:59:25 +0000

depesz można prosić o przykład?

Autor: depesz

depesz — Mon, 25 Jan 2010 08:55:16 +0000

@Zyx:
właśnie. trzymajmy się faktów, a nie fanatyzmu. Porównanie nie jest szybsze. Jest wolniejsze. W sposób de facto niemierzalny dla normalnego człowieka. Szybsze jest to, że używanie kluczy naturalnych oznacza, że wielokrotnie można zrezygnować z niektórych zapytań, lub z niektórych części zapytań – joinów.

Autor: cojack

cojack — Mon, 25 Jan 2010 08:05:09 +0000

No z tym może być problem, wydaje mi się że to zależy w dużej mierze od logiki aplikacji, jeżeli dobrze rozplanujemy nasze helpery które wrzucamy do aplikacji typu właśnie menu, jakieś dodatkowe bloki wizualne w naszej aplikacji. I sprawdzanie dostępu do nich wszystkich na raz. Albo po prostu nie sprawdzać widoku ich, tylko dostęp do nich. Huh ale pewnie to nikogo nie zadowoli. Więc problem faktycznie istnieje i będzie trzeba to jakoś przemyśleć. Naszło mnie nagle że można by tak jak w Zend ACL zrobić serializację obiektu dostępu do wszystkich części danego usera i cache. Ameno

Autor: Zyx

Zyx — Mon, 25 Jan 2010 07:47:28 +0000

A w jakiż to sposób porównanie np. 4-kolumnowego klucza naturalnego z danymi tekstowymi ma być szybsze od porównywania dwóch liczb? Trzymajmy się rzeczywistości, a nie fanatyzmu. Klucze naturalne stosuję tam, gdzie to jest potrzebne, a nie bo ktoś tam się gdzieś nimi podjarał. Założeniem klucza jest jednoznaczne identyfikowanie bytu bez względu na nic, a to oznacza m.in. niezmienność. Numer PESEL jest niezmienny, ale np. tytuł artykułu już nie i chociaż jest unikalny, wzięcie go jako klucz główny to proszenie się o kłopoty. Wystarczy, że ktoś będzie chciał kiedyś zrobić porządki na stronie, albo zrobi literówkę i już mamy problem. Pod tym kątem powinno się przede wszystkim patrzeć.

Cojack -> co gdy będzie trzeba sprawdzić dostęp więcej niż raz w trakcie żądania? Np. u mnie liczba sprawdzeń raczej nie schodzi poniżej 10, gdy aplikacja jest ukończona – menu, opcje przy listowaniu danych, sam dostęp do akcji, jakieś dodatki…

Autor: depesz

depesz — Tue, 19 Jan 2010 20:21:06 +0000

Sztuczny klucz główny, to zazwyczaj liczba z seriala – np. u ciebie: „idGroup” SERIAL PRIMARY KEY,

klucz główny podstawowy bazuje na danych które są już w tabeli, bez dokładania sztucznych pól.

np. dla rbac_group takim kluczem mógłby być groupname.

np.:

create table rbac_group ( groupname text primary key );

oczywiście tam gdzie teraz masz id_group miałbyś groupname a nie żaden sztuczny „id”.

takie podejście ma sporo zalet. są oczywiście też wady. ogólnie pytanie czy stosować sztuczne czy naturalne klucze główne jest dosyć zapalne – są miłośnicy tego i tego. ja baaaaardzo długo wolałem sztuczne, ale potem się przekonałem do naturalnych. dają *dużo* szybszą bazę, czytelniejsze zapytania i mniej błędów danych.

Autor: cojack

cojack — Tue, 19 Jan 2010 20:14:43 +0000

Mógłbyś rozwinąć swoją wypowiedź i wytłumaczyć o co chodzi? Szczerze to nie rozumiem..

Autor: cojack

cojack — Tue, 19 Jan 2010 20:12:37 +0000

Aha, a ja myślałem że to 14 wierszy muliło… Ale wtopa ;p

Autor: depesz

depesz — Tue, 19 Jan 2010 20:12:01 +0000

a konstruktywna opinia jest taka – gdybyś używał kluczy głównych naturalnych, a nie sztucznych, to zapytania byłyby szybsze, prostsze i dodatkowo czytelniejsze

Autor: depesz

depesz — Tue, 19 Jan 2010 20:09:46 +0000

14 wierszy bo explain analyze ma 14 wierszy.