Új hozzászólás Aktív témák
-
Speeedfire
nagyúr
Adott egy tábla ahol pl 3 azonosító van id, fid, szoveg
Az id ugye autoincrement, a fid az azonosítója a felhasználónak a szövegben meg szöveg van.
Lehet úgy csoportosítani ezeket, hogy melyik felhasználó mennyit küldött be?
Valami ilyesmi:
fid + darabszámaÍgy próbáltam meg, de így mindet kiírja:
select *, SUM(fid) from tabla
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
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
-
Speeedfire
nagyúr
válasz Speeedfire #617 üzenetére
Helyesen:
SELECT fid, count(fid) as mennyi FROM `linkek_tartalom`
group by fid
having count(fid) >= 10Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
Hogy lehet táblákat átnevezni? Konkrétan van kb 100 táblám, aminek prefixet akarok adni.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
A txt fájl tartalmát kellene feltölteni az sql mezőbe majd végrehajtani?
Hogy hívom meg a függvény?
Kicsit kusza nekem ez.
Jelen esetben nekem van ~120 táblám és egy drupal_ prefixet szeretnék oda rakni.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
Nem akar összejönni...
H nem választom ki az adatbázist akkor azt a hiábt mondja, ha kiválasztom akkor:
A MySQL mondta:
#1312 - PROCEDURE 02630_drupal.prefix_all can't return a result set in the given contextÍgy hívtam meg:
CALL prefix_all('02630_drupal','drupal_',1);Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
Ez az, kiválasztottam az adatbázist bele mentem az sql részbe. Beillesztettem a scriptet, utána függvény meghívását és akkor mondta ezt a hibát.
DELIMITER $$
DROP PROCEDURE IF EXISTS `prefix_all` $$
CREATE PROCEDURE `prefix_all` (in_db varchar(20),in_prefix varchar(10),in_add_rem TINYINT(1))
BEGIN
DECLARE done INT default 0;
DECLARE tbl_nm VARCHAR(30);
DECLARE ren VARCHAR(200);
DECLARE table_cur CURSOR FOR select table_name from information_schema.tables where table_schema=in_db;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done=1;
OPEN table_cur;
rename_loop:LOOP
FETCH table_cur INTO tbl_nm;
IF done=1 THEN
LEAVE rename_loop;
END IF;
if in_add_rem=1 then #ADD
SET @ren = concat("rename table ", in_db,'.',tbl_nm ," to ",in_db,'.',in_prefix,tbl_nm,";");
else
set @ren= concat("rename table ", in_db,'.',tbl_nm ," to ",in_db,'.',right(tbl_nm,length(tbl_nm)-length(in_prefix)),';');
end if;
# select @ren;
prepare ren from @ren;
execute ren;
END LOOP;
CLOSE table_cur;
select table_name 'Tables' from information_schema.tables where table_schema=in_db;
END $$
DELIMITER ;
CALL prefix_all('02630_drupal','drupal_',1);Hiba
SQL-lekérdezés:
DELIMITER;
CALL prefix_all(
'02630_drupal', 'drupal_', 1
);
A MySQL mondta:
#1312 - PROCEDURE 02630_drupal.prefix_all can't return a result set in the given context[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
-
Speeedfire
nagyúr
Kérdésem a következő lenne. Ez a lekérdezés miért nem akar menni? Sőt igazából az ilyenek nem nagyon akarnak menni nálam, be kell őket állítanom kézzel...
create table entitascim (
cimazon int not null auto_increment primary_key,
entitasazon int,
scim1 varchar(255),
scim2 varchar(255),
svaros varchar(255),
callam char(2),
sirszam varchar(10),
stipus varchar(50),
contraint kk_entitascim_entitasazon foreign key (enmtitasazon)
references entitasok(entitasazon)
)#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'primary_key, entitasazon int, scim1 varchar(255), scim2 varchar(255), svaros' at line 2
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
Valami miatt nem tudok egy "indexelést" megoldani.
CONSTRAINT fk_hirdetes_id
FOREIGN KEY (hirdetes_id) REFERENCES tbl_hirdetes (id)#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CONSTRAINT fk_hirdetes_id FOREIGN KEY (hirdetes_id) REFERENCES tbl_hirdetes (id)' at line 1
A tbl_hirdetes_extra tábla kiválasztásánal csináltam ezt, az index az él, de ugye nekem a táblák összekötése lenne a fontos.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
Mysql workbench-ben kész adatbázisról nem lehet diagrammot nézni?
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Speeedfire #834 üzenetére
Kiszúrta a szemem...
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
Kis tervezési, kivitelezési kérdésem lenne.
Adott egy tábla mondjuk ahol nagyon sok text-et kellene elmenteni. Helyette ez milyen megoldás?
//elso tabla
id | hajszin | szemszin | hajhossz | testalkat //mind int
1 | 2 | 3 | 2 | 1
//masodik tabla
id | text | code | item
1 | barna | 1 | szemszin
2 | kék | 2 | szemszin
3 | zöld | 3 | szemszin
4 | szőke | 1 | hajszin
5 | rózsaszín | 2 | hajszin
6 | karcsú | 1 | testalkat
7 | telt | 2 | testalkatÍgy az első táblában csak számok vannak és a hozzá tartozó értékek a második táblában van, amit lekérdezésnél visszakeresek sql-el.
Ötlet? Vagy milyen más megoldás van rá?[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
-
Speeedfire
nagyúr
Ha jól értem akkor egy sorban 40 oszlop és mindegyikben egy ekkora "cimke"
Igen, kb így van. Ugye a címke mérete az változik, lehet 5-20 karakter is.akkor egyszerűen le lehetne dokumentálni a Classod elején, hogy mi micsoda.
Így van, én is hasonlóra gondoltam, de ha több controllerből akarom lekérdezni, akkor lehet jobb lenne egy segédtábla.Én azt javaslom, hogy legyen VARCHAR vagy TEXT , mert sokkal gyorsabban programozol ha nem kell felkeresni mindig, hogy melyik kategoria melyik szám, plusz ha esetleg csinálsz keresőt pl, akkor az URL is beszédesebb lehet. (example.com/search.php?haj=szoke&mell=nagy)
Valóban egyszerűbb, gyorsabb, viszont nem tudom, hogy teljesítményben meg mindenben melyik lenne a jobb.
Hely szempontjából lényegtelen szerintem 500-600 bejegyzésnél, viszont ha sokan nézik az oldalt akkor lehet jobb ha csak számok vannak az adatbázisban és csak akkor vannak lekérdezve a tényleges adatok, amikor kell.pl ha a user oldalát nézi valaki:
Seged_tabla::item("szemszin", 1);
//a segéd modell meg visszaadná a hozzá tartozó értéket
//valami ilyesmi lekérdezéssel
select text from seged_tabla where item=szemszin && code=1Viszont ugye itt meg több kisebb lekérdezés lenne. Ugye userenként olyan kb40/tábla. Mert ugye van még egy tábla ahol van kb 50 hasonló mező.
Ezt nem tudom hogy mérlegeljem.Több kisebb lekérdezés, vagy egy az egyben mentsek el mindent az adatbázisba.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
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
-
Speeedfire
nagyúr
Szó sincs spanyol viszról. Nem olvastam még tervezési mintákról, nagyon nem is találtam még.
Köszi az infót. Az adatok lekérésére jó lehet amit utólag írtam? Vagy más megoldás lenne rá a jobb?Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
Igazából a sebesség lenne a fontosabb számomra, inkább nagyobb látogatottság lesz, mint sok adat a táblákban.
Akkor a modellből visszafejtést te el is veted? Csak, mert azt pl még leprogramozni is könnyebb a sok join miatt.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
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
Erre van valakinek ötlete, hogy lehetne megoldani union nélkül?
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 Speeedfire #861 üzenetére
Na, ez az unios helyettesítés mégsem annyira jó. Ugyanis ha már valaki volt kiemelt, akkor az nem jelenik meg a listában, hacsak nem vesz ismét kiemelést. Ötlet rá?
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Apollo17hu #865 üzenetére
2 tábla mindenféleképp kellene, 1 tábla kevés az adatok miatt.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Apollo17hu #867 üzenetére
Hát, mert most akkor emiatt csináljak még egy táblát?
Biztos meglehet oldani, csak kicsit kacifántosan.
Lehet, hogy a left join után kellene tennem még egy select-et, ami csak az aktuális kiemeléseket íratja ki. Utána meg már csak a maradék kell.
Sk8erPeter: Apollo17hu pedig érti.[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
Mondom én, néha jó aludni rá egyet és friss erővel nekiesni megint.
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 sorrendEgyelőre jónak tűnik. Majd kiderül...
Fotó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
-
Speeedfire
nagyúr
válasz Apollo17hu #874 üzenetére
Pont ezt írtam fentebb, hogy a hirdetes táblából nekem mindenki kell. A kiemeles_fizetve táblából pedig megtudom, hogy kik azok akik kivannak emelve.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Apollo17hu #876 üzenetére
Hát, én ezt mindig nem értem, hogy ez az egyetlen_tabla honnan származtatik.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Apollo17hu #878 üzenetére
És ezeket az értékeket, hogy írnám át? Számomra még mindig nem tiszta a kép.
Hirdetésenként van 7 kategória, kiemelésenként van 2. Az 7*2 féle kiemelés.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Apollo17hu #880 üzenetére
Hanyagolom inkább ezt.
Végre van egy kis szabadidőm, elkezdtem tervezni a saját oldalamat.
A postokhoz a hozzászólásokat úgy akarom kezelni, mint itt a PH!-n van. Tehát ha valaki hozzászól egy cikkhez vagy valamihez, akkor az a fórumban fog megjelenni. Ezt nem tudom még, hogy kössem össze post-forum.A forum valahogy így nézne ki:
//itt ha a parent értéke 0 akkor az a fő kategóriában van, ha nem akkor a megadott forum id alá tartozik
//nem jöttem rá, hogy itt mi legyen még, kellene még egy sor aminek postid a neve, ha 0 akkor az nem post. Viszont így hogy kötöm össze a post táblával?
id | Egysoros poszt | 1 | 1201231231 | 3 | 2[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
-
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
-
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 Peter Kiss #891 üzenetére
Lehet úgy is, megy így is. Ez a legszebb az egészben.
SQL-ben nem, de a model tudja és legtöbbször AR-el szoktam a lekérdezéseket megcsinálni.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Peter Kiss #893 üzenetére
Agyalok a monoDb-n, de majd meglátom mi lesz belőle. Vagy másra gondolsz?
Ebben nem vagyok otthon annyira.
Soak: Pontosan.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 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
-
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
-
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
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen