Téma: Weboldalkészítés php-oop alapon. 1.rész

hello..
egy két személyes megjegyzés az adatbázis elgondolásokhoz..
legyen egy tábla ahol csak a user azonositoja, jelszava, ipje, session azonositoja, esetlegesen egy statuskod legyen.. ennyi és nem több!
indexelve a nickre!
pw: sha1(md5(string))
igen jol tudod valoban md5 egyiranyu, de ha te lekodolod a jelszo szot md5tel az itt is 'efc847fa5a386a38fcc9d0573bb87272' lesz meg akarhol mashol is.. ezert vannak spéci emberkék akik felállitanak szép nagy táblázatot mindenféle kriksz kraksz karaktersorozatokkal, és megprobálják megtalálni benne a 'efc847fa5a386a38fcc9d0573bb87272' karaktersorozatot.. és már tudja is mi az visszakodolva, de elvileg ..és igen! van rá a gugliban megannyi hiteles oldal egy bizonyos md5 karakterlánc visszafejtésére..és igen a jelszo szó volt az! probald ki!
alapszabály tokéletes biztonsag nincs! nem is lesz soha! ezert soha ne elegedj meg egy titkosito fuggvennyel! minimum a 2, de nem rossz ha 3-4 fuggvenyt raeresztesz..
utolag nem celszeru modositani sem az indexeken sem az adatmezok tipusain, hosszain, mert azok rontják a szerver hatásfokát.. tapasztalat! mindenképpen először át kell gondolni milyen funkciok kellenek milyen adattáblák mik a minimális adattipusok (lasd idhez nem bigintet hasznalsz hanem simán intet!!!), megfogalmazod melyek azok a mezok amik alapjan 90% hogy keresni fogsz, és mentesz!
aztán legyen egy külön tábla ahol a user minden egyéb marhasáéga találhato, szallitasi info, szzuletesi datum, anyja neve 6 peldanyban stb stb.. a lenyeg az a login adat egy kulon tablaban legyen es semmi mas csak ami szigoruan az azonositashoz kell!!.. most ennyi!

bocsi elfelejtettem.. ilyen még csak véletlenül se jusson eszedbe hogy "select * from user where pw=" . $_POST['pw']...
sql injection? mysql_escape_string($_POST['pw']) legalább!!
továbbá nem select * hanem select username, pw, mail, sessid [...] from user...
mert egyszerűbb leirni hogy *, de tobb 100ezer soros soronként legalább 10mezős táblákban másodpercekkel is ronthatja a teljesitményt hogy minden adatot áttol az adatbázisszerver a webszervernek, amikor nekunk pl csak a username vagy a mail kell.. minek tolja át a többit is? felesleges hálozati forgalom!
és célszerű leszokni a nickes azonositasrol.. minden mailhoz 99.99%ban egy ember tartozik, mig tobb ember akarhat egyszerre vicus98 lenni.. mail hatásosabb, és kötöttebb formailag mint egy nick..
és mindjárt itt vagyunk,
$result= "SELECT nick FROM user WHERE mail='". html_entities($_POST['mail']) ."' AND pw='". mysql_escape_string($_POST['pw']) . "' LIMIT 1";
if (mysql_num_rows($result)==1){ //akkor és csak akkor, ha pontosan 1 sor van!!
...
...
..
}
else {
header("Location: index.php");
}
most ennyi..

Ehhez az utóbbihoz hozzátenném azt, hogy igaz, hogy érdemes * helyett kiválasztani a konkrét mezőket, de ha pl tudod, hogy csak 1 rekordot fog találni (pl userhez tartozó password), akkor érdemes betenni a végére egy LIMIT 1-et is, mert akkor nem keresgél az egész táblában, hanem ha megtalálta, amit beírtál, akkor vissza is tér rögtön.

A másik az, hogy érdemes VARCHAR helyett sima CHAR-t használni szerintem, mert így ha minden meződ a táblában fix hosszúságú, akkor az SQL gyorsabban tud benne keresni, mert előre tudja, hogy hol van a következő mező és nem kell számolgatnia. Szerintem az a pár bájt nem éri meg, amennyit ezzel megspórolsz, mert egy merevlemez még mindig olcsóbb, mint egy processzor.

TLoF eredeti hozzászólása

Árny: A fentebb leirt dologhoz annyit, hogy fölöslegesen darabolod fel a user táblát több részre, hiszen igy ha szükséged van az adatra 2 lekérdezést, vagy rosszabb esetben egy join -t kell kiadnod, amivel buktad a fenti esetben jelentkező elenyésző töbletet.

A * helyett akkor éri meg a felsorolást választani ha olyan text vagy blob tipusú mező van a táblában amire az adott lekérdezésnél nincs szükséged. ha csak char, varchar, int, etc.. tipusú meződ van és nincs 200 mező a sorban akkor megéri kikérni az egészet, hiszen egy egyből ki tudja adni az sql szerver nem kell még egy sorba rendezést is lefutattnia.

Azonban ezek a részek már a micro optimalizáció részbe tartoznak, és alap esetben nem éri meg foglalkozni vele, hiszen egy átlagos oldal messze nem fut akkora terheléssel, hogy egy ilyen rendszeroptimalizáció kifizetődő legyen.

Ebben végülis van igazság, de szerintem az egy jó dolog, ha már eleve úgy rögzülnek a dolgok, hogy amikor query-t írsz, akkor ezek rögtön az eszedbe jutnak. Senkinek nem fáj, ha pár plusz karaktert beírsz minden lekérdezésbe.

Vegyünk egy egyszerü esetet.

A tábla felépitése a következő esetet:

id => int(10)
name => varchar(20)
passwd=> varchar(32)
email => varchar(128)
hash => varchar(64)

Ha erre azt mondod, hogy select * from tábla akkor egyszerüen vissza dobja a sort.
Ha azt mondod, hogy select hash, passwd, email, name, id from tabla akkor elősször beolvassa a sort, átrendezi a változók sorrendjét, és vissza adja az eredményt. Tehát nem érte meg a felsorolást. Ha 1-2 mezőt kihagysz, akkor még mindig nem éri meg a dolgot.

Ha hozzá teszel két mezőt

bemutatkozas => text
szuletes => datetime
foto => blob

Akkor * hozza magával a text, blob tipusú mezőket ami már nem jó dolog, hiszen ezek külön területen vannak tárolva, csak be vannak linkelve a táblába, tehát ha ezeket kihagyod akkor többet spórolhatsz.

A dolog konkluziója, hogy erősen a tábla felépitésedtől, és az adatbázisodhoz való csatlakozás sebességétől függ az, hogy milyen formában érdemes ezeket használni. Nincs olyan ököl szabály ami csak az egyik / csak a másik esetet indokolná.

TLoF
igazad van, de:
a 2-ős usertabla azert kell, meert minden egyes belépés és azonositast kovetelo muvelethez elegendo csak a usernam-pass-ip-hashid 4est hasznalni, még id sem kell.. ez szerintem az esetek 80%át fogja kitenni, mig a maradek 20 90-95%át goja kitenni az hogy a user meg akarja nezni neadjisten valtoztatni a profiljat, ahol mar celszeru lekerdezni a reszletes userinfot, ami viszont egy masik tablaban van!
plusz ugy tudom a mysql szeret memoriat eszegetni, igaz nem olyan draga, de ha hagyjuk eléggé bekajál.. ezért célszerű csak azokat a táblákat és velük az adatokat a memóriában tartani és kezelni, amiket muszály! tehat nem teszzunk semmilyen mezot az alapok mellé, azt szigoruan tegyük külön táblába!!! valamint abban Edemnek van igaza, valoban ezekl melyebb dolgok, magam is csak most kezdem kihaszalni ezeket, de ha mar egyszer tanulunk vagy nekiallunk valami nagyot alkotni, mar az elejen legyen meg az az info ami barmikor elonyt jelent.. ne akkro kezdjunk vakarozni amikor mar haldoklik a rendszer, porog a proc zbala a mysql zakatol a vinyo, hiszen megfelelo tervezessel es korultekintessel legalabb 30% eroforras takarithato meg!
szvsz..

TLoF eredeti hozzászólása

Vegyünk egy egyszerü esetet.

A tábla felépitése a következő esetet:

id => int(10)
name => varchar(20)
passwd=> varchar(32)
email => varchar(128)
hash => varchar(64)

Ha erre azt mondod, hogy select * from tábla akkor egyszerüen vissza dobja a sort.
Ha azt mondod, hogy select hash, passwd, email, name, id from tabla akkor elősször beolvassa a sort, átrendezi a változók sorrendjét, és vissza adja az eredményt. Tehát nem érte meg a felsorolást. Ha 1-2 mezőt kihagysz, akkor még mindig nem éri meg a dolgot.

Ha hozzá teszel két mezőt

bemutatkozas => text
szuletes => datetime
foto => blob

Akkor * hozza magával a text, blob tipusú mezőket ami már nem jó dolog, hiszen ezek külön területen vannak tárolva, csak be vannak linkelve a táblába, tehát ha ezeket kihagyod akkor többet spórolhatsz.

A dolog konkluziója, hogy erősen a tábla felépitésedtől, és az adatbázisodhoz való csatlakozás sebességétől függ az, hogy milyen formában érdemes ezeket használni. Nincs olyan ököl szabály ami csak az egyik / csak a másik esetet indokolná.

Aha, így már értem. Jól van, szerintem elraktározom az infot az agyamba, hogy ezt is tudjam. ^^

Apropo, mikor jön a folytatás?