Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Prof! - zasada trzymania danych w bazach
Forum PHP.pl > Forum > Bazy danych
pauluZ
Witam

Pytanie nie jest skomplikowane.
Nurtuje mnie tylko to że nie mogłem znaleść jakiś specyfikacji
albo standardów na to:

Jak przechowywać dane w bazie?
Gdzie znajdę jakieś specyfikacje na to? Może jakieś case-study dla systemu np.
bankowego lub sklepowego?

Czy w formie jak najbardziej czystej ?
(oczywiście w akceptowalnej dla samej bazy formie)

Czy poddawać te dane już jakiejś wstępnej obróbce przed INSERTem?

Wiem że można robić tak albo tak. Że zależy to od tego co chce robić z tymi danymi.
Ale taka odpowiedz mnie nie satysfakcjonuje.
Duże systemy jednak na jakiś sposób się decydują więc pytam jaki sposób
jest najczęstrzy i ma generalnie najoptymalniejsze rozwiązanie.


Przykład:
1) nazwy plików w bazie - czy nakładać na nie funkcje urlencode() przed INSERTEM?
2) treści z prostymi znacznikami HTML'a - czy dawać htmlspecialchars()

Co o tym mówią standardy kodowania ?
Pytam praktyków i profesjonalistów.

Pozdrawiam
SongoQ
Odnosnie stuktor baz danych bankowych no niestety nic nie moge powiedziec bo nie mialem stycznosci. Ale najwazniesza zasada jest zabezpieczenie i system uprawnien i autoryzacji uzytkownikow.

Teoretycznie powinno to wygladac tak ze kazdy user w takim systemie ma fizyczne konto w bazie i wszystko zalezy od jego uprawnien w bazie. To jakie ty wyciagasz dane w php to juz zalezy od tego do czego masz uprawnienia.
Dodatkowa rzecza jest to zeby uzytkownik nie mial dostepu bezposrednio do tabel lecz np do funkcji, widokow itd. Zamiast INSERT to funkcja ktora dodaje na poziomie bazy danych (walidacja danych, obsluga wyjatkow itd). Tak to mniej wiecej powinno wygladac ale jak w rzeczywistosci jest to juz nie mam pojecia. Jesli bys natrafil na jakis art. zwiazane z taka tematyka to prosze o wrzucenie na forum.
mhs
Kiedyś przeczytałem (o ile się nie mylę na tym forum), że każda osoba (lub konto) w banku posiada przeznaczoną dla siebie bazę danych. Ile jest w tym prawdy trudno jest mi odpowiedzieć, z racji tego, że nigdy nie miałem styczności z systemami bankowymi.
Kocurro
Ze strony technicznej - każda osoba to inna baza danych posiadająca od groma tabel. Wśród tych tabel znajdują się tabele z informacjami czystymi jak i tabele cache'u zawierające dane nadmiarowe, które powstały z informacji z innych tabel.

Odnośnie zabezpieczenia:

Serwer baz danych jeden centralny zbudowany klastrowo. Do tego interfejsy będące pomostem pomiędzy serwerem bd a resztą systemu. Zabezpieczenia to:
1) na poziomie samej bazy danych odpowiedni system dostępu
2) na poziomie interfejsu - analiza zapytań itp...
3) na poziomie użytkownika końcowego.

Do interfejsu nie są przesyłane zapytanie w formie znanej z baz danych tylko raczej rzeczy typu:

Podaj biling dla Kowalskiego od dnia ... do dnia ...

Dopiero interfejs przetwarza to zapytanie, sprawdza uprawnienia, następnie generuje zapytanie, które jest potrzebne do odczytania informacji a następnie analizuje zapytanie dopiero co stworzone pod kątem uprawnień i/lub wstrzyknięcia czegoś złego. Dopiero potem przesyła to do serwera, który dodatkowo sprawdza.

Najczęsciej serwer sprawdza w cache'u czy już jest odpowiedź na takie pytanie czy też nie. Jeśli nie ma to tworzy. A potem zwraca odpowiedź z cache'u.

Jako serwer bazy danych pracuje duży klaster złożony z mniejszych klastrów bez pojedyńczego punktu awarii zawierający trzy poziomowe RAID (na poziomie dysków/pamięci, stacji pojedyńczej oraz mniejszych klastrów).

Nadmiarowość danych jest więc olbrzymia.

Do tego bardzo rozbudowany system tranzakcji.

Tyle wiem z jednego sympozjum na którym byłem (jako słuchacz a dokłandiej podsłuchiwacz winksmiley.jpg - wstęp był wolny).

Informacje jak wiadomo - mogą być - a niemal na pewno nie są kompletne, bo banki i inne instytucje nie lubią chwalić się swoimi rozwiązaniami.
SongoQ
Dodam tylko tyle do tego co napisal @Prometeus ze takie stosowanie zmniejsza ryzyko bledow lub wlaman ale z 2 strony za tym idzie ogromna praca wielu ludzi.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.