Azért, mert gyakorlatilag nem használt (nem feltétlenül szükséges lementeni) adat van az adatbázisban, egyszerűen felesleges.

Attól még lehet a hirdetés_id-hoz kapcsolni.
Persze, meg a juzer_id-hoz is.

Arról beszéltem, hogy ha egyes paraméterekre szűkítenek, akkor nem mindegy a sebesség. varchar-alapú keresés meg lassabb lesz, mint a tinyintre keresés.
Ez igaz (kb 5x írtam már le, hogy igaz...), de nem a keresés fog dominálni az oldalon. Nem tudom máshogy leírni neked.

Miért, a tbl_ prefix csak a saját védjegyed, teljesen egyedi valami?

Pedig ott a Drupal topic, meg a drupal.hu meg még számtalan potenciális segítség.
A drupal.hu-t hanyagoljuk, mert ott a segítség nem erősség. Anno pont emiatt kezdtem el foglalkozni a php-val, mert nem tudtak/akartak segíteni.

Ez tény, de több is a potenciális hibalehetőség
De nagyobb is a biztonság, mert senki sem ismeri a kódot.

Mindenhez van pro és konktra. Én is mérlegeltem mindent, de nekem ezek a dolgok lettek szimpatikusak.

Athlon64+: Már, hogy ne használnám. Még illusztráltam is kóddal.
Illetve ez a salt jól jön még jelszó visszaállításkor is, meg bármire használható, mert ez is unique. Szóval minden felhasználónál egyedi.

Az ORM-nek utána néztem, ha jól értem a yii is ezt használja és tudtomon kívül én is. Csak én nem tudom, hogy ez az ORM...

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

"Persze, meg a juzer_id-hoz is."
Még elmondhatod tizenötször is, akkor sem lesz több értelme. Tervezési kérdés, és eleve nem helytálló olyanhoz kapcsolni a táblát, aminek köze nincs hozzá. A júzer felad egy hirdetést, aztán a hirdetéssel babrál, ezt a babrálást tartalmazza a másik tábla. Akkor mi értelme van a user id-hoz kapcsolni? Honnan a francból tudod, mondjuk a 100 hirdetése közül melyikkel babrált, ha nem tartalmazza a másik táblád a hirdetés id-ját?
Mindegy, nem foglak tovább győzködni, ha nem fogadod el, hogy csak szopatod magad ezzel a megvalósítással, és nehezen lesz lekérdezhető, továbbfejleszthető, akkor ez van.

"Ez igaz (kb 5x írtam már le, hogy igaz...), de nem a keresés fog dominálni az oldalon. Nem tudom máshogy leírni neked. "
Már sokadszor írtam le más formában, de ez nem indokolja az igénytelenebb megvalósítást. Nem tudom máshogy leírni neked.

"A drupal.hu-t hanyagoljuk, mert ott a segítség nem erősség."
Ez sajnos sokszor helytálló (meg van kb. 10 ember, aki aktívan válaszol, és még ért is hozzá, bár néha a stílusuk nem valami simulékony ), de ugyanez már kevésbé igaz a http://drupal.stackexchange.com/-ra. Ott a kérdések többségére tuti kapsz valami választ, hacsak nem túl komplikáltan fogalmazod vagy maga a kérdés nem teljesen egyedi/új problémát érint.
Szerk.: meg most már aktív a PH!-s Drupal topic is.

"De nagyobb is a biztonság, mert senki sem ismeri a kódot."
Hát erről a helyedben azért inkább nem lennék meggyőződve.

[ Szerkesztve ]

Sk8erPeter

Szevasztok !

Most kezdtem el tanulni az SQL-t egy "SQL lekérdezések földi halandóknak" nevű könyvből, amelyhez mellékeltek egy CD-t ami példaadatbázisokat és lekérdezéseket tartalmaz, több formátumban. Én a MySQL mellett tettem le a voksom, mert ez a legelterjedtebb. Telepítettem a wamp servert, és rögtön ki is próbáltam a phpmyadmint, az alap adatbázisok működtek. A könyvhöz kapott mellékletben azt írta hogy a MYSQL DATA könyvtárát kell átirányítanom arra a könyvtárra ahol a példaadatbázisok találhatóak, amit meg is tettem:datadir=c:/AddisonWesley/SQLQFMM2/MySQL/Data -re cseréltem a
datadir=C:/Program Files/wamp/bin/mysql/mysql5.5.16/data
Ezek után kaptam egy olyan hibaüzenetet hogy:
"A MySQL mondta:
#2002 - A szerver nem válaszol (vagy nem megfelelően állították be a helyi MySQL szerver szoftvercsatornáját)"
Nem tudja valaki, hogy ez a semmitmondó üzenet miért jön ki?
Egészen biztosan újabb verziót használok, mit amiben csinálták az adatbázisokat, és elvileg itt is érvényesül a felülről kompatibilitás vagy nem

A példa adatokat restore-olni szokták jobb helyeken, nem pedig a MySQL data könyvtárát átgányolni.
Keress először is egy normális könyvet, utána normális példa adatokat, a phpmyadmin-t meg felejtsd el, de nagyon gyorsan.

Én kérek elnézést!

Nem igazán értem hogy mi a gond a phpmyadmin-nal. Mit használjak akkor?
És hogyan lehet restore-olni az adatokat?

Az a baj vele, hogy veszélyforrás. De nagyon mást nem tudsz használni. Vagy legalábbis én nem tudok róla.

Restore:
Lemented sql formában az adatokat, majd sql-el visszatöltöd.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Szerencsére találtam a példaadatbázisban SQL fájlokat is, először azt hittem hogy azok csak lekérdezések, de importálva létrehozta a megfelelő táblákat. Eredetileg FRM kiterjesztésű fájlok voltak, és ezeket akartam importálni. Amúgy az alap adatbázisokból a MYSQL és az INFORMATION_SCHEMA neműt nem lehet törölni. Ez normális?
Jó lenne ez a phpadmin, csak pl. a táblák közötti kapcsolatok megjelenítése elég pocsék.
Egyébként miért veszélyforrás a phpmyadmin? Ha localhoston fut akkor milyen biztonsági probléma lehet vele?

a MYSQL és az INFORMATION_SCHEMA neműt nem lehet törölni. Ez normális?
Ezt csak az admin tudja szerintem törölni, attól függ milyen jogok vannak ezekre.

Jó lenne ez a phpadmin, csak pl. a táblák közötti kapcsolatok megjelenítése elég pocsék.
Ha localhoston vagy használj msql workbench-et.

Egyébként miért veszélyforrás a phpmyadmin? Ha localhoston fut akkor milyen biztonsági probléma lehet vele?
Localhoston nem sok veszélyforrás van. Élesben viszont könnyen feltörhető.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

A Mysql meg az INFORMATION_SCHEMA részeket még jó, hogy nem lehet törölni, mert ezek a Mysql saját belső működéséhez kellenek. Ezt még DB adminként se lehet törölni, még csak az kellene.
A phpmyadmin lassú és keveset tud és PHP-s webszerver kell hozzá. SQL-t tanulni bármi más jobb a phpmyadmin-nál (na jó az sql konzol ablakban még a PHPmyadmin-nál is reménytelenebb). Én a toad for Mysql-t ajánlom, de van kismillió normális MySQL GUI.

Én kérek elnézést!

Ha localhoston vagy használj msql workbench-et.
Ez egy phpadmin alternatíva akar lenni? És jobb mint phpadmin ?
Én wampservert használok. Nem probléma ha arra rátelepítem a worbench-et?
Mert szerintem a wamp-ban egy kicsontozott myphp verzió van.

Ezt csak az admin tudja szerintem törölni, attól függ milyen jogok vannak ezekre.
Jogom az van hozzá, csak nem engedi kijelölni a phpmyadminban.

A sheama-val kapcsolatban martonx megmondta a tutit.

A mysql workbench egy program, keress rá.
Szép kis diagrammokat lehet vele készíteni. Meg akár egyből lehet az adatbázisban is vele matatni.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

eleve röhejes, hogy wamp-ot telepítesz azért, hogy mysql-t gyakorolj

Én kérek elnézést!

Oké, kipróbálom a worbench-et !
Wamp-ot azért telepítettem, mert egyrészt egyszerű a használata, minden van benne ami az adatbázis kezeléshez kell, és van már tapasztalatom benne, mert a Joomla weboldalam készítésekor is ezt használtam.
Ha meg telepítem szólóban az MySQL-t és mondjuk a Workbech-et, gondolom kell még Apache is hozzá, mert gondolom közvetlenül nem lehet megnyitni fájlként egy adatbázist mind pl a Microsoft Access-ben(most ezzel gyakorlok) , úgy hogy kell Apache is.
De majd megpróbálom a Wamp mellett telepíteni a Workbench-et, hátha működik együtt !
Köszönöm a segítségeteket !

De ha mellette webezik is?
Nem értem, hogy ezen a fórumon miért ilyen lekezelő mindenki....

Bishoop: Apache nem kell a workbench-hez. A workbench-ben csak az sql-hez csatlakozol vele, azon a porton amit az sql is használ.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Miért röhejes? Kezdőknek hasznos lehet, hogy nem kell szarakodni a külön-külön telepítéssel, egyben van minden, elindítod a setupot, next-next-csá. Van még pár ilyen gyorsan használható cuccos, mint az EasyPHP meg társai. Mondjuk Windows-on IIS + a Web Platform Installerrel is klattyolgatós felületen lehet ezeket telepíteni.
Azért egy kezdőt ne oltogass ilyen durván, ne vedd el a kedvét. Te is elkezdted valahogy, azóta a szokásaid nyilván sokat fejlődtek.
A phpMyAdmin lehet, hogy keveset tud, de a legtöbb hosting cégnél akkor is az van, nem árt, ha megtanulja kezelni.
A phpMyAdminban egyébként sztem az a nevetséges, hogy a mai napig framesetek használatára építenek, meg amúgy sem látok benne túl nagy fejlődést, már az is nagy számnak tűnt, hogy a jQuery UI-t kezdték el használni, meg AJAX-ot kezdtek el alkalmazni. Meg tényleg lassú.

(#915) Bishoop :
tényleg "fura" az a tutorial, ahol ahelyett, hogy sql-dumpokat adnának a "kezedbe", inkább azt mondja, irányítsd oda a datadir-t... Lehet, hogy nem a legjobb segédanyag.

(#920) Speeedfire :
tényleg könnyen feltörhető?

Sk8erPeter

Állítólag a php-n keresztül könnyen feltörhető. Nem tudom. Én csak mindig ezt hallom a linux guruktól*.

*webhostingosok

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

"Teljesen érthető, amikor valaki felrak egy wampp-ot (linuxra érthető, windowsra minden esetben felelsleges)."
He? Nem értem a gondolatmenetet.
Ha Linuxban konzolon rámész, hogy mondjuk telepíteni akarod a phpmyadmint, akkor az összes függőséget is behúzza.
Windows-on meg végül is a külön telepítős macerát oldja meg az egyben telepítős módszer, ahogy a XAMPP is.
A WAMPP mozaikszóban az első pedig a Windows-t jelenti, de gondolom ezt nem kell külön mondanom. Akkor hogy érted, hogy Windows-ra ez felesleges?
Mondjuk Windows-on én még mindig IIS+Web Platform Installer-párti vagyok, ott is behúzza a függőségeket, és számomra tisztább megoldás. Meg értem én, hogy live serverhez hasonló környezetet akar valaki felrakni, ami esetek többségében Apache-on lesz, ez elfogadható érv, de én sokszor inkább a tájékozatlanságnak tudom be, hogy nem használnak az emberek PHP-zésre IIS-t Windows-on.

Most kipróbáltam az általad javasolt Toad for MySQL-t, mert eddig nem tettem, de én sok alapvető dolgot nem találtam meg így elsőre, vagy csak nem kézenfekvő helyen van.
Ilyenek, mint az adatbázis egyszerű átnevezése, adatbázis tartalmának egy klikkre történő átmásolása vagy éppen mozgatása másik adatbázisba. Lehet, hogy ezt exportálni kell először egy scriptbe, és aztán behúzni, de nehogy már... ez phpMyAdminban egyből ott van az arcodba tolva, beírod az új db nevét, és megcsinálja, no para. Be lehet állítani, hogy egyből át is váltson arra az adatbázisra. Aztán továbbmenve importálási lehetőség. Ez miért nincs egyből jól látható helyen? Egyáltalán hol van? Biztos csak türelmetlenül futottam át rajta, de ez azért eleve nem tetszik, hogy nincs ott, egyértelmű helyen. Aztán diagramok létrehozásánál pattog, hogy túl sok a tábla, egy beállítás korlátozza. Miért nem kérdezi meg egyből, mennyi táblára akarom korlátozni épp a megjelenítést? A sokat szidott phpMyAdmin "Diagram" opciójára kattintva egyből kirajzolja az összes táblát, még ha rengeteg is van, aztán ezeket ki lehet szedni, és utólag korlátozni, melyek jelenjenek meg, így gyorsan lehet relationt létrehozni táblák közt.

Kezdem átértékelni, hogy mégsem akkora fos ez a phpMyAdmin.

Amúgy nekem a dbForge Studio for MySQL jött be, de arra meg ugye korlátos az ingyen liszensz.

[ Szerkesztve ]

Sk8erPeter

Meglepődve tapasztaltam localhostos tesztelés után, hogy a phpMyAdmin jóval gyorsabban töltődött be az SQL Buddy-nál is, amit pedig elvileg alternatívaként szoktak ajánlani, mondván, hogy gyorsabb, mint a phpMyAdmin.
Most már tényleg kicsit átértékeltem a phpMyAdminnal szemben érzett erős fenntartásaimat.
Épp úgy általában is elég lassan töltődik be nálam a MySQL, de az SQL Buddy-t előbb is indítottam el, de még mindig nem töltött be, a phpMyAdminnal meg már egy query-t is lefuttattam. Elég furcsa, hogy ennyit szarakodik az SQL Buddy.

[ Szerkesztve ]

Sk8erPeter

Ott akkor szerintem valami nem kerek. Nálam az sqlbuddy gyorsabb, win7 64bit/wamp64bit alatt.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Érdekes módon használat közben tényleg gyorsabbnak tűnik, viszont az indulási ideje valamiért iszonyat lassú, nem vágom az okát.
Egyébként a Te géped referenciának számít?

Sk8erPeter

Nem referencia.
Csak leírtam, hogy én hogy teszteltem.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Sziasztok,

Egy kis restore/backup témával fordulnék hozzátok.
Valaki álmosabb volt a kelleténél és Select helyett Delete-vel kicsapott pár recordot.
Nem nagy gond mert van napi Backup. Viszont ha azt állitom vissza akkor a mai napi meló 90%-a elveszik.
Ezért egy másik adatbázisba visszatoltam a backupot és lefutattam a query-t (helyesen), export majd notepad++ szal megszerkesztettem és visszatoltam a helyes adatbázisba.
Szerencsém volt mert csak 50 rekordról volt szó.
Szóval lehet valahogy úgy exportálni egy query-t, hogy azt egyből bele tudjam tölteni a megfelelő táblába?

A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!

Simán lehet, de lehet hogy csak félreértettelek.
Egy select eredményét oda insertálod be, ahova akarod

insert into élestábla (oszlop1, oszlop2)
select oszlop1, oszlop2 from backuptábla

Vagy nem ez volt a kérdés?

Én kérek elnézést!

Így van .

kössz csak nem tudtam, hogy igy is lehet.

A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!

1. Ott valami anomália lehet. Legjobb tudomásom szerint ilyen nincs. Ha rakunk bele értéket, csak akkor nő ez az érték.

2. Hát, pedig a legtöbben a join mellett vannak. 1 nagy lekérdezés, mint több kisebb. Én is inkább erre álltam rá. Kevesebb a generált adat a szerverről.
Szerintem minden esetben célszerű a join.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Ha jól tudom nem minden esetben gyorsabb a nosql. pl ahogy hallom az fb szerű falaknál van igazán nagy haszna.

Gondolom ez lenne az sql-es netbeans. Nem ismerem, meg vagyok elégedve a mysql workbench-el.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

1.
Azt tudom elképzelni, hogy id-val lett beszúrva a 16588-as id-jű sor. Így az increment érték onnan folytatódik.
Magától nem ugrál

2.
Rendes indexelés tábla reláció mellett, 3 tábla összekapcsolása nem szabad, hogy gondot jelentsen.

De alap esetben nézzük mit csinálhatsz.
Legyen product, category, region táblák.

Lekéred az aktív product-okat.
Kapsz mondjuk 5000 rekordot. Ekkor a kategória lekérdezés WHERE IN -be sűríteni 250 id-t, a régió lekérdezésbe 2000 id-t elég fura megoldás.
Teljes kategória és régió táblalekérdezése és szerverkód általi összepárosítása megint csak fura megoldás.

Kis adathalmaznál persze logikusabbnak tűnhet a WHERE IN. Viszont ilyenkor egy indexelt tábla JOIN is gyorsabb.

Speciálisabb esetekben elképzelhető, hogy optimalizálhatóak szétbontva egyes lekérdezések, de ez nem általános szvsz.

- http://pazsitz.hu -

"2. Úgy vettem észre webes gyakorlatban, hogy a JOIN-lást nem nagyon szeretik. Számomra egyetem után meglepő volt, hogy inkább használjunk 3 SELECT-et, amit a szerver oldalon úgy mond összeállítunk és kérdezgetünk le WHERE ID = .... konstrukcióval, ez jobbnak tűnik, mint ha 3 táblát össze JOIN-olnék."
Ki mondta ezt a baromságot? Egyébként nyilván esetfüggő, milyen query-t érdemes használni, nincs erre általános recept.
De az egyszerűen hatalmas hülyeség ebben a formában, hogy jobb 3 különböző select, mint mondjuk egy értelmesen összerakott join.

(#947):
"Lehet már tényleg kellene írnom e kettő adatbázis rendszerről, és megírni a személyes véleményt."
Most mindenféle bántás nélkül, a hozzászólásaidból, kérdéseidből az derül ki, hogy nem igazán vagy még kellően tájékozott ahhoz, hogy cikket írj a témáról, hogy átfogó összehasonlítást tudj ezekről írni. Ehhez komoly háttértudás, tapasztalat kell, és kellő magabiztosság, különben nagyon nagy eséllyel csak téves vagy ingatag információkat fogsz megosztani a publikummal, vagy az állításaid nagy része pusztán spekuláció, saját vélemények, érzésekre hagyatkozás megfogalmazása lenne, aminek meg nem túl sok értelme van szakmailag.
Én személy szerint nem venném a bátorságot ilyen összehasonlító cikk megírására (mostani tudásom egyszerűen nem elég hozzá), főleg, ha olykor láthatóan alapfogalmakkal nem lennék tisztában.

Sk8erPeter

Nem tudom neked mit tanítottak RDBMS-ekkel kapcsolatban egyetemen, de ha érdekel a téma, akkor tényleg érdemesebb lenne előbb jobban utána járni.

Ez a "jobban kedvelik szétbontani több szelektre egy join-t" hát ez rohadt sokmindentől függ. pl attól, hogy abban a rendszerben, amit átvettél fingjuk nem volt mi fán terem az sql, ezért a legegyszerűbb módszerhez folyamodtak, amit még ismertek. Egy megfelelően indexelt, nagy adathalmaznál (értsd: több millió sor) particionált táblákból álló relációs adatbázisban 3 tábla joinja gyorsabb lesz, mint 3 szelekttel lekérdezni. Nem illik okosabbnak lenni az adatbázisnál.

"NoSQL majdnem minden esetben gyorsabb az relációs adatbázisnál" -- ez is hatalmas tévhit. Még elosztott rendszerben is. nézd meg pl az alábbi cikket
Twitter, PayPal reveal database performance

NoSQL-re szeritem áttérni két szélsőséges esetben érdemes:
-- elosztott az alkalmazásod, több szerveren fut, és sokkal több írás történik az adatbázisba, mint lekérdezés (facebook eset)
-- több szerveren fut az alkalmazásod, és ki akarod használni az elosztott "NoSQL" (bár nem ugyanazt jelenti) által alapból nyújtott terheléselosztást anélkül, hogy bajlódni szeretnél egy MySQL clusterezéssel.

Az, hogy mitől lehet lassú egy relációs adatbázis sokmindentől függ: rosszul megtervezett indexek, rosszul megtervezett lekérdezések, rossz particionálás, table lock használata írásnál sok írás mellett (érdemes inkább optimistic locking-ot használni)

Az autoincrement pedig azért is ugorhat, mert tranzakció végén rollback volt, új adat nem került beszúrásra véglegesen, de az auto increment érték nőtt.