- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Mikrotik routerek
- Mindenki AI-t akar, már 2025-re is eladták a HBM chipeket
- XPEnology
- Facebook és Messenger
- A legtöbb amerikai szerint a TikTok egy őket befolyásoló eszköz
- Az USA nem akarja visszafogni Kína növekedését
- Crypto Trade
- Adobe Illustrator kérdések
- A pápa egyre jobban tart a romlott AI veszélyeitől
Új hozzászólás Aktív témák
-
cucka
addikt
válasz Sk8erPeter #565 üzenetére
while ($result)
Ebben a sorban a feltétel mindig igazra értékelődik ki, ezért kerül végtelen ciklusba.
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #567 üzenetére
ÓÓÓÓ basszus, csak annyit kellett változtatni, hogy átírtam így:
while ($result = mysql_fetch_assoc($query))
És máris tökéletes.
Mondjuk tök érthető, mivel a ciklus meghívása előtt még nyilván 1-et kapott a $result eredményül. Tehát a while ciklusban folyamatosan 1-et érzékel, annak értéke nem változik meg.Thx!
[ Szerkesztve ]
Sk8erPeter
-
cucka
addikt
válasz Sk8erPeter #567 üzenetére
Válasz a php kérdések topikban, mert ennek semmi köze a mysql-hez.
-
ates71
csendes tag
válasz Sk8erPeter #574 üzenetére
Hali Lementettem az users táblát gondolom abban vannak az adatok,sql mezöbe bemásoltam mire végzett vele ezt irta ki Unknown column 'users.random2' in 'field list'
-
anjani182
őstag
válasz Sk8erPeter #584 üzenetére
Közben sikerült letölteni a fullos verziót, próbáltam export-importot, nem fut végig, hibákat talál
Elsőnek valami duplicate valami, kivettem azt a részt, utána megint hibázott, tehát nem fut le se az export, se az import Ezt nem értem!
Akkor talál hibákat, amikor a "create a temporary table transfer package for.." részt csinálja!
Megpróbálom hogy a régit "export", az újba meg "import"...hátha
[ Szerkesztve ]
Forever and ever, let's make this last forever.
-
anjani182
őstag
válasz Sk8erPeter #586 üzenetére
Egyelőre úgymond, egymáson akartam importálni, exportálni...tehát volt a szűz adatbázis, ami most üres, nincs benne adat, beattacholtam a régit, volt ez a kettő, és akkor az egyiket a másikra akartam importálni, így nem ment!
Most kiexportálom egy új .mdf-be, és onnan majd megpróbálom beimportálni a másikba.
Az exportálás egy új .mdf-be most sikeres!
[ Szerkesztve ]
Forever and ever, let's make this last forever.
-
Speeedfire
nagyúr
válasz Sk8erPeter #613 üzenetére
Köszi mindkettőtöknek.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
martonx
veterán
válasz Sk8erPeter #648 üzenetére
Ez pedig nem tűnik rossznak. Milyen hibát kapsz vissza?
Esetleg nyelvi finomságokkal lehetne javítani pl. where és alselect helyett join, majd megadni, hogy melyik táblát update-eled?Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #650 üzenetére
egy példa, hogy mire gondolok:
UPDATE FROM tblTransaction AS t
LEFT JOIN tblEmployee as e
ON e.emp_id = t.emp_id
SET t.emp_block = e.emp_blockÉn kérek elnézést!
-
shev7
veterán
válasz Sk8erPeter #650 üzenetére
Hali!
Lehet valamit felreertek, de szerintem nem sok ertelme van annak amit csinalni probalsz.
SELECT kutya_id AS kutyuli_id
FROM `tbl_ossze` AS tbl_ossze_2
GROUP BY kutyuli_id
Ennek a lekerdezesnek az eredmenye minden olyan kutya_id ami benne van a tablaban. Ha erre meg mukodne is az update, akkor csak azt erned el, hogy minden sorra beallitanad a 'Y'-t nem csak azokra amikre szeretned.Amit te szeretnel, az valami ilyesmi lenne:
UPDATE `tbl_ossze` SET main_picture = 'Y' WHERE kep_id IN (
SELECT kep_id AS ki_id
FROM `tbl_ossze` AS tbl_ossze_2
GROUP BY kutya_id
)Bar ez nem segit azon a tenyen, ahogy a hibauzenet is mondja, nem select-elheted es update-eleheted ugyanazt tablat ugyanabban a queryben.
Viszont, ha lenne egy inner temporal table-ed mar mukodne. Persze performance szempontjabol hagy kivannivalot maga utan, de ha jol sejtem ez a script egyszer futna le, szoval...
UPDATE `tbl_ossze` SET main_picture = 'Y' WHERE kep_id IN (
SELECT *
FROM (
SELECT kep_id
FROM `tbl_ossze`
GROUP BY kutya_id
) as temptable
)[ Szerkesztve ]
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
shev7
veterán
válasz Sk8erPeter #654 üzenetére
ezzel mas: as temptable
Igy letrehoz a memoriaban egy ideiglenes tablat, es a lekerdezest abban hajtja vegre majd az abbol kapott eredmeny alapjan update-el. Szoval itt az update es a select nem ugyanarra a tablara fut le.
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
martonx
veterán
válasz Sk8erPeter #657 üzenetére
Szia!
Esetleg " " idézőjelek közé téve? Mintha MSSQL-ben, meg PostgreSQL-ben az " " jel lenne erre a megoldás. Bár érdemesebb inkább egybe írni, elvégre minek szivasd magad ilyen apróságokkal, nem?
Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #664 üzenetére
Nem az a baj, hogy ezeket használod, én is használom a hoszting tárhelyeken. Na de ezeket fejlesztésre használni??? A szükség esetén használatával egyetértek, de amikor azt mondja valaki, hogy ezen fejleszt, az a szememben vicc kategória. Jó, mondjuk ki mit ért fejlesztés alatt. Két táblát létrehozni, meg köztük egy join-os selectre, valóban jó tud lenni bármi, még a mysql parancssora is. Ha már itt tartunk minek a phpmyadmin, ha ugyanezt tudja a parancssor is?
A mysqli többet tud, mint a mysql, viszont mysql is jó (ha akarod azt is beágyazhatod egy osztályba, és akkor megvan az objektum orientáltság is), és ott legalább nincsenek ilyen szívások, mint amikor én is pont a héten vettem észre, hogy a mysqli nem hajlandó a legújabb php, mysql, apache verziókkal működni. Egy rakás mysqli-s cuccal a gépemen nem volt felemelő felismerés.
Így magamban el is könyveltem fosként (ettől még nem kezdtem el átírni a régebbi munkáimat, hátha megint kijön majd egy stabil php - mysqli kombó), és egyszerűbb projektekben kerülni is fogom a használatát, mert az végképp nem hiányzik, hogy élesítéskor derüljön ki legközelebb, hogy az éles környezeten éppen nem hajlandó működni. A sima mysql-lel ilyen gonddal még sosem találkoztam.
Egyébként ha már phpmyadmin-t használ valaki fejlesztésre (lásd feljebb kéttáblás select), akkor nem mindegy, hogy mysql, vagy mysqli futtatja a végén a select-et?
Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #666 üzenetére
Nálam php 5.3.5 van, és MySql 5.5. akárhány van (amiket a legújabb xampp tartalmaz). Ha ezekkel megy neked a mysqli, akkor le a kalappal.
Én SQL fejlesztés alatt masszív tárolt eljárás írást értek kurzorokkal, deklarálásokkal, temporary táblákkal. Szeretem amennyire csak lehet adatbázishoz közel tartani a logikát. Aztán az már, hogy az adott tárolt eljárást mysql-lel vagy mysqli-vel hívom meg számomra kb. mindegy.
Mivel innentől kezdve a mysqli-t mellőzöm, a javasolt PDO-t ki fogom próbálni, felkeltetted az érdeklődésemet, köszi!
Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #668 üzenetére
Toad for MySQL-t szoktam használni. Nagy tudású, debug-ot is tud.
MySQL-nek van valami ingyenes menedzsment felülete is, állítólag az se rossz, de még sosem próbáltam.
A Toadban azt szeretem, hogy a felületénél megadható, hogy hasonlítson az MS SQL Mangement Studio-hoz, így nem kell mindent máshol keresnem, mint ahol megszoktam.Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #674 üzenetére
xdebug-ot én is használom, nem is azt mondtam, hogy PHP-t nem lehet debugolni, hanem azt, hogy sokkal nehézkesebb, mint más nyelveket. Egyébként SQL-t is lehet debugolni, legalábbis MS SQL-t 2008 fölött, illetve a MySQL-t 5-ös verzió felett.
Az indokaim, hogy miért jobb SQL szinten tartani az adatlogikát (félre értések elkerülése végett én sem 100%-ban SQL szinten valósítom meg, csak törekszek rá).
1. Az SQL nagyon buta, cserében bődületesen hatékonyan, akárhány szálra, akármennyi memóriára optimalizálva kezeli az adatokat, adatműveleteket. Rengeteg konkurens felhasználó kiszolgálására van optimalizálva, akárhány magot, akármennyi memóriát ki tud használni.
2. SQL szerverek általában jóval erősebb hardverek, mint a webkiszolgálók.
Hozhatnék itt ezeregy példát, ebben a fenti két pontban minden benne van, hogy miért érdemes az SQL szintre törekedni. És hangsúlyozom, nem a Pistike-féle olcsó hosztingokra gondolok, ahol egy Core2-es szerver egymaga a webkiszolgáló, és az adatbázis szerver is (bár kis mértékben, de az 1-es pont miatt itt is kijön az SQL-es megközelítés előnye), hanem a nagyvállalati infrastruktúrákra. Nálunk pl. a webkiszolgálók (igaz több is van belőlük), 1-4 processzormaggal és 2-4 Gb memóriával rendelkeznek. Míg a legkomolyabb SQL szerverünk 128 maggal, és 320 Gb memóriával rendelkezik.
Egy komolyabb programkód logika már néhány tíz konkurens felhasználónál kifekteti a webkiszolgálót, míg ugyanaz SQL szinten megvalósítva, mondjuk kisebb mint 5%-os processzorterhlést jelent az adatbázis szervernek, és emiatt szintén minimális terhet a webkiszolgálónak.
Én kérek elnézést!
-
ArchElf
addikt
válasz Sk8erPeter #714 üzenetére
Teszel köré egy ilyet:
SELECT user_id, Count(*) As count_user_id
FROM ( ... )
GROUP BY user_idAE
[ Szerkesztve ]
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #728 üzenetére
Oké, csak most látom, hogy az SQL-kérdés topicban már oltottátok hasonló okok miatt a srácot.
Sk8erPeter
-
sonar
addikt
válasz Sk8erPeter #731 üzenetére
Sajnos nem igazán jól fejeztem ki magamat.
Amit te irtál az megszámolja, hogy hány van. Nos nekem csak az kellene, hogy van
2755 és van 2756..
Szerintem a Distinct-tel kellene valahogy operálniA tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
sonar
addikt
válasz Sk8erPeter #733 üzenetére
Azért mert ez azt adja vissza, hogy van nekem mondjuk 25 db 2755-ös bejegyzésem.
De én meg azt akarom látni, hogy van 2755 és van 2756 és van 2759 de nincsen 2758.
Talán igy már érthetőbb. Bocs ha keverek, de nem igazán tudom másképp megfogalmazniA tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
martonx
veterán
válasz Sk8erPeter #736 üzenetére
A sima sql-es topikban meg ott van a másik emberünk a "csak admin tudjon módosítani egy mezőt" SQL szinten agymenésével. Hihetetlenek.
Én kérek elnézést!
-
sonar
addikt
válasz Sk8erPeter #736 üzenetére
Elnézést. Nem mindig vagyok a szavak embere
A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
RexpecT
addikt
válasz Sk8erPeter #761 üzenetére
De ezt szeretném, köszönöm a segítséget .
-
vakondka
őstag
válasz Sk8erPeter #770 üzenetére
Szia,
Tökéletes!
Nálam az élő szerveren 0,0021 alatt futott le ami szuperKöszi!
https://toptarget.hu - Online Marketing Ügynökség
-
CSorBA
őstag
válasz Sk8erPeter #804 üzenetére
És ami még jobb, hogy már minden létező telefonszám-tárolós helyen meg is csináltam a 3 oszlopos tárolást
-
_Roy_
tag
válasz Sk8erPeter #812 üzenetére
left joinnal próbáltam, mind a két tábla értékei kellenének, viszont vannak olyan mezők pl password, ami mind a kettőben password
az egyik elsődleges kulcsa (username) a másikban ezek az adatok email mezőbe vannak de nem elsődleges kulcs, ott id az elsődleges kulcs[ Szerkesztve ]
-
Speeedfire
nagyúr
válasz Sk8erPeter #848 üzenetére
Akkor te külön kapcsolótáblát tennél mondjuk a 40 mezőhöz?
Illetve te a lekérdezést, hogy oldanád meg? Nincs kedvem a select selectjének a selectjét lekérdezni, illetve se joinolni ennyi táblát.
Csak, mert én simán arra gondoltam az előzőből kifolyólag hogy lenne egy Masodik_tabla model, amiben lenne mondjuk 2 funkció.$item = 'hajszin';
public function items($tem) {
//innen visszadna egy tömbböt, ahol az item mezőben hajszin van, illetve a hozzá tartozó code-ot is
//itt pl visszadná, hogy 1=>barna, 2=>szőke
}
//a másik funckió
$code = 1;
$item = 'hajszin';
public function item($item, $code) {
//itt pedig visszadná azt ahol az item a hajszin és a code értéke 1
//mondjuk azt, hogy barna
}Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
martonx
veterán
válasz Sk8erPeter #854 üzenetére
Lehet nem voltam elég érthető? Én arra a módszerre értettem a szabályosat, hogy van egy paraméter táblája, és ebből csak az ID-ket tárolja le ténylegesen. Ezért is írtam a normalizálásról, meg a Paraméter tábláról.
Én kérek elnézést!
-
Speeedfire
nagyúr
válasz Sk8erPeter #854 üzenetére
Dehogyis, az hajszin, szemszin csak a fő tábla mezője lenne, illetve a második kereszttáblában is csak amiatt, hogy számomra jól értelmezhető legyen. Lásd "1." hsz-emet.
Pont, hogy tinyint-eket akarok tárolni.
40-50 mezőhöz, ha mondjuk lesz olyan 300-400 sor sor a kereszt táblában. Ahol csak 1 mező a varchar és csak amitt, hogy Én tudjam legalább, hogy mi az.2-3-4 táblát join-olni? He? csak 1 táblát kellene a fő mellé, de az on záradékban lenne egy pár bejegyzés 40-50 mezőnél.
Lényegében egy portál szerű dolog lenne, de csak 500-600 felhasználóról beszélünk!!! Nem 5000-6000.
Gondolkozok rajta, hogy kőműves leszek.
martonx: Köszi, akkor marad a join.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Sk8erPeter #859 üzenetére
Igen, ezt értem én is. Csak az on miatt nagyon sok lekérdezést kellene magamtól megírni.
Az unios kérdésre meg ezt találtam:
select h.id, h.pid, ifnull(k.id, 1000) as sorrend
from tbl_hirdetes h
left join tbl_kiemeles_fizetve k
on (h.pid=k.kuid)
where ((k.k_ido<=1346955990 and k.v_ido>=1346955990) or k.id is null)
order by sorrendFotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Sk8erPeter #871 üzenetére
Adott a 2 tábla. Mindenki hirdethet az oldalon, de ha gondolja akkor ki is emelheti magát, adott hétre, adott helyre*.
*adott hely: 100db kiemelési hely van. Az 1. van legelöl, a 100. van a legvégén.A kiemelés táblában azért van uid, hogy valamivel össze tudjam kapcsolni a 2 táblát.
Tehát, van a lekérdezés, ami már jól megy.
Itt ugye lekérdezi az összes felhasználót a hirdetés táblából, akik adott kategóriában hirdetnek. Ha van az aktuális időpontban lekérdezése, akkor ahhoz az 1-100 közötti értéket hozzárendeli. Ez lesz az order értéke.
Akiknek nincs adott hétre kiemelése, azoknak pedig 1000 lesz ez az order érték, így a lista legvégén lesznek.Én jelenleg ezzel értem el ezt a lekérdezést. Lehet van jobb, egyszerűbb, de nem vagyok egy sql májer.
SELECT t.id, t.cim, (t.nap_2_0) as start_time, (t.nap_2_1) as end_time, t.telszam, t.pid, t.kid, ifnull(k.kid, 1000) as sorrend
FROM `tbl_hirdetes` t
LEFT JOIN (
select kuid, kid from tbl_kiemeles_fizetve where k_ido<=1347353832 and v_ido>=1347353832
) k ON (t.pid=k.kuid)
order by sorrendA másikra meg annyi, hogy én jobbnak találtam inkább varchar-kánt menteni az adatbázisban. Emiatt páran biztos megköveznek majd, meg gányolás...de mindegy. Én ezt találtam most a legjobb megoldásnak. AR-ben nem fogok, mindent join-olni. Illetve nem is vagyok annyira megfizetve, hogy ezzel szenvedjek.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Soak
veterán
válasz Sk8erPeter #868 üzenetére
Kurvajó ez a progi, kicsit probálgattam a trial-t , tök bonyolult queryket elsőre össze kattingattam 1perc alatt.
-
Speeedfire
nagyúr
válasz Sk8erPeter #884 üzenetére
A hirdetes_id is opció lehet, de itt inkább a juzerek vannak előtérben. Jobbnak láttam, inkább a user_id-t használni erre.
Valóban nem kell már a segítség, amilyen infó kellett azt megkaptam.Pont, hogy a teljesítmény miatt (részben) maradtam a varchar mellett. Nagyon sok keresés szerintem nem fog itt lenni. Szinte az összes hirdető az emberek arcába lesz nyomva, így csak görgetnie kell és nézegeti a felhasználókat. Mivel te tudod már milyen tartalmú oldal, ajánlom nézd meg a konkurenciát.
De majd meglátjuk, hogy mit fog majd csinálni az oldal.Eddig is cms-t (drupalt) használtam, de nekem egyedibb megoldásokra, jobban fekszik egy saját kód, mint egy cms.
Minek kell a prefix? Hátha lesznek mással kapcsolatos táblák is az adatbázisban. Nem tudom, ezt így szoktam meg.
Az ext mező a fájl kiterjesztése. Több féle fájl mehet egy bejegyzéshez. Akár kép, akár pdf stb. Képeknél meg jobb szeretem így használni, ha vannak kisebb/nagyobb képek. Könnyebb belinkelni a képeket. valami.tn.jpg/valami.jpg/valami.small.jpgMiért fűzném a tag-eket a fórumhoz? A blogokhoz kell a tag.
User salt. Mégis hol kellene ezt tárolni?Minden egyes bejegyzéshez tartozik egy fórum és a fórumhoz tartozik a comment. A fórum csak a fórum címeket tárolja el. Kicsit úgy, mint itt a PH!-n.
Ez az újabb, javított verzsön.
De, régen is komolyabb volt.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Soak
veterán
válasz Sk8erPeter #888 üzenetére
Nem hash akart lenni vajon?
-
Speeedfire
nagyúr
válasz Sk8erPeter #886 üzenetére
"Ez itt attól még sztem nem szempont, mert a konkrét hirdetést boncolgatod tovább, arra jelölsz meg külön táblában kiemelést, tehát a hirdetés_id szerint lenne értelme összekapcsolni a két táblát."
A hirdetőknek vannak jutalom tallérjaik, egyenlegük stb stb.Ezt kifejtenéd?
Ha tinyint vs. varchar, akkor az utóbbi mellett keresés ideje szempontjából nem túl sok szempont szól.....
Wááá!
Pont ezt írom, hogy ezeken az oldalakon a keresés nem jellemző. Belép valaki az oldalra és előtte van 100+x hirdető az 1. oldalon a második oldalon meg megint 100+x összesen max 500-600 hirdetés. Nagyon keveset fognak az oldalra látogatók keresni hirdetőket.Attól még nem látod, a háttérben hogy oldják meg, az, hogy a frontendre hogyan kerül ki a tartalom, nem befolyásolja azt, hogy hogyan kellene megoldani szépen a háttérben.
Nem, de látom az oldalon működését. Meg belső infókat kapok!A prefix önmagában indokolt lenne, de inkább úgy, hogy egyértelműen jelölsz vele valamit, pl. application id-t vagy hasonlót.
Jogos, de nekem most itt nem ez volt a szempont. Legyen valahogy jelölve, melyek tartoznak az adott oldalhoz. Így később sem kell bajlódni a nevekkel, ha költözik másik szolgáltatóhoz.A tages dolgot meg indokoltam már.
PH! copy!Amúgy csak azért kérdeztem rá, miért nem CMS-t használsz erre a célra, mert mások már eleget szoptak azzal, hogy megfelelő táblastruktúrát kialakítsanak ilyesmire, mint pl. a fórum, ami Drupalnál eleve a core része
Adott dolgokra jó, most is drupal van rajta. Csak ha már konkrét igények vannak, akkor én azt már drupallal nem tudom megoldani.
Meg akkor már teljes mértékben úgy alakítom ki az oldalt, ahogy nekem tettszik.
Athlon64+:
A tbl_forum-hoz nem tartozik status, pedig kellene, illetve szóba jöhet más táblák esetén is még.
Azóta már azt is beleraktam, illetve egy ordert is. A status csak az aktív/inaktív miatt van benne más egyéb miatt még nem gondolkoztam rajta el.sem adatbázisoldalról nem kell keresgetni, hogy az "1"-es állapot mégis mit takar, plusz pl. tárolt eljárások írásánál minden kiegészítőinformáció jól jöhet.
Nem tudom erre mennyire jó megoldás, de én láttam már olyat, hogy felvesznek a model-ben pár constans változót, ami ezeket hivatott megmondani.
plconst STATUS_DRAFT=1;
const STATUS_PUBLISHED=2;
const STATUS_ARCHIVED=3;Következetlen a táblák elnevezése, néhol többes, máshol egyes számban írod.
Hát, ezen még nem agyaltam. Csak írtam, ami eszembe jutott.Ugye lesznek majd index-ek is?
Nyilván lesznek és vannak is.Látom mindenki leragadt a salt mellett.
Ezt a yii-ből vettem.A salt regisztrációkor kerül a táblába ami egy unique kulcs és amikor valakit validál a rendszer akkor ezt is nézi.
public function validatePassword($password)
{
return $this->hashPassword($password,$this->salt)===$this->password;
}
public function hashPassword($password,$salt)
{
return md5($salt.$password);
}Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
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
-
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.
-
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.
-
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!
-
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
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
-
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
-
Speeedfire
nagyúr
válasz Sk8erPeter #954 üzenetére
Bezzeg ha te lennél a munkatársa...
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
lakisoft
veterán
válasz Sk8erPeter #967 üzenetére
És mi a helyzet a MySQL Wordbench-el? Nekem ez tökéletesen bevált, eddig.
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #972 üzenetére
Most látom, itt az 1-es pontban lévőt félreérthetően írtam, az SQL Management Studio-ban azért annyiból is sokkal jobb a dolog, hogy van lehetőség mondjuk az első 1000 sor listázására, nem kell külön rámenni, hogy na akkor ezt a query-t futtasd. Itt meg úgy működik, hogy ráklattyolsz a Use in Query > Selectre, aztán van egy külön gomb a query futtatására. Idegesítő ez a szükséges plusz felesleges kör.
Sk8erPeter
-
lakisoft
veterán
válasz Sk8erPeter #972 üzenetére
Nyugodtan nézd meg szerintem nagyon sokat fejlődött korábbi verzióihoz képest.
Új hozzászólás Aktív témák
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Gumi és felni topik
- Android alkalmazások - szoftver kibeszélő topik
- Episodes from Liberty city
- Azonnali notebookos kérdések órája
- PlayStation 1 / 2
- Nyaralás topik
- Víz- gáz- és fűtésszerelés
- Xbox tulajok OFF topicja
- További aktív témák...