- Van, ahol már törvényben védik az agyhullámainkat
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Otthoni hálózat és internet megosztás
- WLAN, WiFi, vezeték nélküli hálózat
- Kanada big tech-adót zúdít az amerikai cégek nyakába
- Milyen routert?
- Linux kezdőknek
- Amazon Prime Video
- eBay
- Windows 11
Új hozzászólás Aktív témák
-
válasz Speeedfire #898 üzenetére
Azért, mert gyakorlatilag nem használt (nem feltétlenül szükséges lementeni) adat van az adatbázisban, egyszerűen felesleges.
-
Speeedfire
nagyúr
válasz Sk8erPeter #900 üzenetére
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
-
válasz Speeedfire #902 üzenetére
Az AR-t lehet ORM-nek nevezni, de nem az igazi.
-
Speeedfire
nagyúr
válasz Peter Kiss #903 üzenetére
Nekem ebből az jön le, hogy ORM-es.
And Yii Active Record (AR), implemented as a widely adopted Object-Relational Mapping (ORM) approach, further simplifies database programming. Representing a table in terms of a class and a row an instance, Yii AR eliminates the repetitive task of writing those SQL statements that mainly deal with CRUD (create, read, update and delete) operations.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
válasz Speeedfire #902 üzenetére
"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
-
válasz Speeedfire #904 üzenetére
Az active record-dal az a baj, hogy egy tervezési hiba.
$post=new Post;
$post->title='sample post';
$post->content='post body content';
$post->save();Ez a kód a Yii oldaláról való, látható, hogy van egy objektumunk, ami mindent megcsinál helyben, ilyet nem szabad csinálni. Egy ilyen rendszerben szépen szét kell szedni mindent: unit of work, identity map, meta data, entity, query object, miegymás. Nyilván könnyebb haszálni egy AR megoldást, de igazából ultragáz.
Belepillantottam a CActiveRecord osztályba, itt aztán minden van. Ami még nagyon tud fájni, hogy nincs benne normális object tracking, de van valamiféle meta leírása, ám az, hogy előírnak egy static metódust a dokumentációban, hogy ezt márpadigimplementálodmánazonnal ahelyett, hogy normálisan felépítenék az egészet, mindent visz.Úgy kell elképzelni az AR-t, mintha egy relációs adatbázisban a táblák a sorok és minden leírást tartalmazó cucc egy valamiben lenne (talán még az adatbázismotor is).
-
Sk8erPeter
nagyúr
válasz Peter Kiss #906 üzenetére
Ha már itt tartunk, milyen framework az, ami tapasztalataid meg kódja alapján szted jónak minősül?
Minden frameworknek van valami bakija, de kíváncsi vagyok, szted melyik az, amelyiket lehet jónak nevezni.Sk8erPeter
-
Speeedfire
nagyúr
válasz Sk8erPeter #905 üzenetére
Okcső! Ne is beszélgessünk többet! Nem tudjuk meggyőzni egymást!
Athlon64+: Én eddig pedig csak jókat olvastam a yii-ről. Több nagyobb cég/weblap is ezt használja.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
válasz Sk8erPeter #907 üzenetére
Entity Framework meg az ASP.NET MVC (nem PHP-s, tudom, kapjam be).
Amelyek most mennek nagyobb frameworkok mindegyik bugzik, a Zend Framework 2-t szeretném majd jobban átvizsgálni, illetve a Symfony-t, Doctrine-t.
-
Sk8erPeter
nagyúr
válasz Speeedfire #908 üzenetére
Az a jó, amikor felteszed a kérdéseidet, tanácsokat kérsz, aztán meggyőzöd magad végül a saját magad által kitalált megoldás helyességéről.
Sk8erPeter
-
PazsitZ
addikt
válasz Speeedfire #908 üzenetére
Én meg azt mondom, hogy a yii -annak ellenére, hogy több nagy megrendelő is hajlamos használni/kérni- nem való túl nagy rendszerekhez.
Kisebb szájtokhoz viszont nagyon kényelmes, hasznos, aránylag gyors társ tud lenni. Pl. a crud-os és egyéb generált kódok, extension-ök segítségével.
Egyébként viszont rengeteg static függvénnyel, félig konfigurálható, félig viszont beégetett implentációval rendelkezik.
[ Szerkesztve ]
- http://pazsitz.hu -
-
Sk8erPeter
nagyúr
válasz Peter Kiss #909 üzenetére
Na, ez tök jó, ilyen sem sűrűn volt közöttünk, most mindegyik mondatoddal egyetértek. (Lehet, hogy ez egyszer nem fogunk vitába szállni, pezsgőt bontok ) Kivéve azzal, hogy "nem PHP-s, tudom, kapjam be". Én aztán nagyon nem vagyok PHP-rajongó. Jelenlegi terveim szerint a jövőben webes területen éppen ASP.NET-re szeretnék átállni teljesen, vagy valamelyik Java-s technológiára. Eleve mondjuk az általam kedvelt C#, Java, C++ nyelvek közül bármelyikben sokkal szebben lehet kódolni (kevésbé sarkall gányolásra, vagy engedi azt), mint PHP-ben (tudom, kapjam be ).
Addig is az általad említett PHP-s frameworkök engem is foglalkoztatnak, pont ezek a "menőbbek", amiknek a használatát már sokszor szerettem volna megtanulni.Sk8erPeter
-
Speeedfire
nagyúr
válasz Sk8erPeter #910 üzenetére
Dehogy győzöm...
PazsitZ: Ezt nem is vitatom, hogy kisebb oldalakhoz ajánlott.
Vagy a yii vagy a symfony volt nálam terítéken. De mivel a symfony nekem egy brutális nagy állat, ezért annak nem estem neki. Nem is portálokat "szoktam" fejleszteni, ezért is marad szimpatikus a yii. Illetve közelemben is ezt használják, így segítséget is könnyebb volt az elején kérni.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
válasz Sk8erPeter #912 üzenetére
Igazából ezért hegesztek magamnak keret a .NET framework mentén (nyilván kisebbet, egyszerűbbet), építés közben szoktam néha ledöbbenni, hogy mennyire adják egymást a megoldások, pl. nem egyszer volt, hogy kigondoltam egy megoldást az adott problémára, és pont ugyanazzal a megközelítéssel találkoztam az MSDN-en is.
-
Bishoop
tag
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 -
Bishoop
tag
Nem igazán értem hogy mi a gond a phpmyadmin-nal. Mit használjak akkor?
És hogyan lehet restore-olni az adatokat? -
Speeedfire
nagyúr
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
-
Bishoop
tag
válasz Speeedfire #918 üzenetére
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? -
Speeedfire
nagyúr
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
-
martonx
veterán
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!
-
Bishoop
tag
válasz Speeedfire #920 üzenetére
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. -
Speeedfire
nagyúr
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
-
Bishoop
tag
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 ! -
Speeedfire
nagyúr
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
-
Sk8erPeter
nagyúr
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
-
Speeedfire
nagyúr
válasz Sk8erPeter #927 üzenetére
Á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
-
martonx
veterán
válasz Sk8erPeter #927 üzenetére
Életem első használt adatbázisa a MySQL volt. Anno letöltötem a mysql.com-ról, meg leszedtem mellé a Toad-ot (gugli dobta ki), és next-next telepítettem őket. Akkoriban még fórumok se nagyon voltak, mégis boldogultunk. A Toad varázslóit használtam, közben buzgón elemzve a generált SQL scripteket. Bevallom soha nem olvastam egy SQL-es könyvet sem.
A wampp, xampp dolgokban nem maga a wampp, xampp a gáz, hanem az a röhejes, hogy valaki mysql-t akar tanulni, és ehhez nem az az első logikus lépése, hogy felteszi a mysql-t, meg hozzá egy rendes gui-t, hanem felrak egy komplett keretrendszert, minden felesleges szarral együtt.
Olyan ez mintha autót akarna megtanulni vezetni, és ehhez előbb vesz egy komplett autószalont, miközben csak egy autó kellene.Mondjuk később kiderült, hogy webfejleszt emberünk a gépén, szóval ha értelmesebben fogalmazott volna, és nem azt mondja, hogy a mysql miatt raktam fel wampp-ot, hanem a wampp adott volt, akkor nem is kezdem el fikázni, hanem csak a PHPmyadmin helyett javasoltam volna valami rendes GUI-t.
Én kérek elnézést!
-
Sk8erPeter
nagyúr
Azért nem egészen olyan ez a helyzet, mint a hasonlatod. Ha a WAMPP-ot telepíti, akkor abból sejthető, hogy elkezdte érdekelni a webfejlesztés, és most szétnézelődik, elkezd PHP-zni, nézegeti a MySQL-t, próbálgatja az Apache-ot, stb. Én is így kezdtem, csak én eleinte még szopattam magam azzal, hogy egyenként telepítettem őket, és próbáltam rájönni, hogyan kell őket konfigurálni, összehozni, miközben még lószart sem értettem az egészből. Egy csomó időt megspóroltam volna, ha egyszerűen telepítek egy WAMPP-ot, csak akkor még úgy voltam vele, hogy megpróbálom ezeket megismerni. Így utólag úgy gondolom, tök hülyeség ilyennel kezdeni, csak a tököd tele lesz vele már az elején. Miért ne lenne jó telepíteni egy WAMPP-ot? Egyáltalán nem értelek.
Főleg a gonoszkodó stílusodat vele szemben. Kezdő, Te is voltál az.
Egyébként mi van akkor, ha telepíti a WAMPP-ot, talán megeszi a gépét? Értem én, hogy sok felesleges dolog is felmehet vele, de majd ha akarja, kiszedi utólag, és kész. Úgyis ki akarja majd próbálni élete első PHP-scriptjét, tehát kelleni fog az Apache és a PHP is. Mondjuk Windows-on én még mindig IIS-párti vagyok, de ez már másik kérdés.
Ettől még a kezdőnek ne vegyük el a kedvét, inkább segítsünk neki, nem kérdezett olyan vad dolgokat, nem az volt a kérdése, hogy "nem működik, mit tegyek?", hanem részletezte.Szerk.: mondjuk nem vagyok az ügyvédje, majd megvédi magát, csak ez már nekem is feltűnt. Biztos neked is szarul esett volna, ha az elején jól beoltanak.
[ Szerkesztve ]
Sk8erPeter
-
martonx
veterán
válasz Sk8erPeter #931 üzenetére
Továbbra sem a wampp-al van a gondom. Teljesen érthető, amikor valaki felrak egy wampp-ot (linuxra érthető, windowsra minden esetben felelsleges).
Azon nevettem, hogy mindezt mysql-ezéshez, mert az első hsz-ből más nem derült ki. És igen, tudom bunkó vagyok
Ahogy visszaolvastam az egészet, ismét végig nevettem az első hozzászólás mysql - wampp - könyv javaslatán a data könyvtár átirányításáról. Legközelebb megpróbálom magamban tartani az érzelmeimet.Én kérek elnézést!
-
Sk8erPeter
nagyúr
"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
-
lakisoft
veterán
Sziasztok,
Aki hasonló témában dolgozik várom szeretettel:
MSSQL, SQLSERVER, T-SQL, SYBASE adatbázisfejlesztők, DBA-k, üzemeltetők ide -
Sk8erPeter
nagyúr
válasz Sk8erPeter #933 üzenetére
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
-
Speeedfire
nagyúr
válasz Sk8erPeter #935 üzenetére
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
-
Sk8erPeter
nagyúr
válasz Speeedfire #936 üzenetére
É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
-
Speeedfire
nagyúr
válasz Sk8erPeter #937 üzenetére
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
-
sonar
addikt
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!
-
Lacces
őstag
Sziasztok!
Lenne 2 érdekes téma, amellyel a melóhelyen találkoztam.
1. Mitől lehet, hogy az autoincrement érték megugrik? 16585 után 16588 szerepl, és nem volt törlés az adatbázisban, nincs hozzá admin felület, én meg nem piszkálom meg az éles adatokat... Ha tényleg kizárjuk azt, hogy nem lehet törölni belőle adatot, meg eshet, hogy magától megugrik a számozás? Esetleg szerver leállástól lehet ez?
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.
Ez bevett szokás? Egyébként úgy vettem észre, hgoy 3 SELECT-re szét bontva tényleg van sebesség növelés, bár nem mindig figyeltem. (Bár az is igaz, hogy egyetemen még a LIMIT áldásos hatását sem mutatták meg)
Mikor célszerű egy webes alkalmazásnál össze JOIN-olni esetleg IN - alapú feltétel keresést használni, mint SELECT-ekre szét bontás? -
Speeedfire
nagyúr
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
-
Lacces
őstag
válasz Speeedfire #944 üzenetére
Igen anomália, de milyen lehet.
Igen, igen a JOIN-t szeretem, most legutóbb meg át kellett vennem projektet, ahol hát... mit ne mondjak... elég rosszul megtervezett volt az adatbázis, ott mondjuk a JOIN terhelte, vissza kellett hivatkoznom a táblára...
Meg ahogy olvasgatok a MongoDB után (lehet nyitok egy ilyen topicot) akkor olvastam, hogy ha az RDBMS-ben rendkívül kevés a JOIN művelet, akkor nem kell a dokument alapú nosql-ek felé kacsingatni.Meg ha már itt tartunk, NetBeans meglelted már az SQL kezelőfelületét? Állítólag van benne, de én még nem leltem meg (igaz én csak GUI esetében használom)
-
Speeedfire
nagyúr
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
-
Lacces
őstag
válasz Speeedfire #946 üzenetére
Jah, de az FB más téma, a dinamikusan változó dolgoknál jó ez a mongodb, de amúgy a nosql-nek is rengeteg fajtája van. Mindegyik másban jobb.
Bár láttam példát és FB is ezt csinálja, hogy hibrid adatbázis rendszereket használ . Lehet már tényleg kellene írnom e kettő adatbázis rendszerről, és megírni a személyes véleményt.
Köszi a választ, léptem -
PazsitZ
addikt
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ál2.
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 -
-
Sk8erPeter
nagyúr
"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
-
modder
aktív tag
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 performanceNoSQL-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.
Új hozzászólás Aktív témák
- Iqos cigaretta
- Milyen okostelefont vegyek?
- A fociról könnyedén, egy baráti társaságban
- Van, ahol már törvényben védik az agyhullámainkat
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Havi kétszáz leégett tápcsatlakozó fut át egy Los Angeles-i szervizen
- Otthoni hálózat és internet megosztás
- Politika
- Dying Light 2
- További aktív témák...