Új hozzászólás Aktív témák
-
#900
Sk8erPeter
nagyúr
Speeedfire
#890
Sk8erPeter
nagyúr
válasz
Speeedfire
#890
üzenetére
"A hirdetőknek vannak jutalom tallérjaik, egyenlegük stb stb."
Attól még lehet a hirdetés_id-hoz kapcsolni.
"Nagyon keveset fognak az oldalra látogatók keresni hirdetőket."
Már megint kezdünk elbeszélni egymás mellett.
Korábban még júzerek paramétereiről (hajszín, szemszín, csöcsméret, stb.) beszéltünk. 
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.
De nekem mindegy."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."
Miért, a tbl_ prefix csak a saját védjegyed, teljesen egyedi valami?"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."
Pedig ott a Drupal topic, meg a drupal.hu meg még számtalan potenciális segítség.
Rengeteg dolog ráadásul készen van modul formájában.
Persze az tény, hogy a Drupal-modulfejlesztés beletanulásához is bőven kell idő, meg hogy az ember átlássa a dolgokat. De ehhez nagyon jó könyvek vannak az 1. hsz.-ben a belinkelt topicban."Meg akkor már teljes mértékben úgy alakítom ki az oldalt, ahogy nekem tettszik."
Ez tény, de több is a potenciális hibalehetőség (pl. nincs felügyelve egy közösség által, mint a legtöbb Drupal-modul), meg egyes feladatok megvalósítása sokkal szopóbb lehet, ha mindent elölről, saját agyból és erőből kell megoldani. -
#899
Soak
veterán
Speeedfire
#898
Soak
veterán
válasz
Speeedfire
#898
üzenetére
Nem értem ,hogy ezzel mire célzol.
Valószínűleg a kérdés arra irányult, hogy mi értelme van. -
#897
Peter Kiss
őstag
Speeedfire
#895
Peter Kiss
őstag
válasz
Speeedfire
#895
üzenetére
Nem az adatbázist kell lecserélni, hanem az azt kezelő PHP programhalmazt. Google: PHP ORM
Egyébként a salt tárolása ellent mond a relációs adatbázisok "működési elvének", hiszen kvázi redundánsan tárolsz adatot.
-
#896
Soak
veterán
Speeedfire
#895
Soak
veterán
válasz
Speeedfire
#895
üzenetére
Annak nem sok értelme van, ha támadás éri az adatbázisod , e mellé még fölösleges adatbázis terhelést is jelent.
-
#895
Speeedfire
félisten
Peter Kiss
#893
Speeedfire
félisten
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.
-
#894
Soak
veterán
Speeedfire
#892
Soak
veterán
válasz
Speeedfire
#892
üzenetére
Akkor te a saltot és a hash-t is lemented a user táblában?
Szerk : Ez egy elég jó és biztonságos módja a user passok tárolására.
-
#893
Peter Kiss
őstag
Speeedfire
#892
Peter Kiss
őstag
válasz
Speeedfire
#892
üzenetére
Ha az AR active record akar lenni, akkor illene utána nézni valami normális ORM rendszernek.
-
#892
Speeedfire
félisten
Peter Kiss
#891
Speeedfire
félisten
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.
-
#891
Peter Kiss
őstag
Speeedfire
#890
Peter Kiss
őstag
válasz
Speeedfire
#890
üzenetére
A salt-ot nem kell menteni, lehet olyat csinálni, hogy mindenkinek mindig random, működik a jelszóellenőrzés is, én is ilyet csináltam.
Azzal, hogy constansaid vannak, még nem vagy kisegítve SQL oldalon.
-
#890
Speeedfire
félisten
Sk8erPeter
#886
Speeedfire
félisten
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.
![;]](//cdn.rios.hu/dl/s/v1.gif)
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);
} -
#889
Soak
veterán
Sk8erPeter
#888
Soak
veterán
válasz
Sk8erPeter
#888
üzenetére
Nem hash akart lenni vajon?
-
#888
Sk8erPeter
nagyúr
Peter Kiss
#887
Sk8erPeter
nagyúr
válasz
Peter Kiss
#887
üzenetére
"A tbl_user táblában miért van benne a salt?"
Na igen, ezt én is kérdeztem, még mindig nem látom az okát. -
#887
Peter Kiss
őstag
Speeedfire
#885
Peter Kiss
őstag
válasz
Speeedfire
#885
üzenetére
A tbl_forum-hoz nem tartozik status, pedig kellene, illetve szóba jöhet más táblák esetén is még.
Ha pakolsz a rendszerbe állapotokat mutató oszlopokat, akkor ki kellene vezetni a lehetséges értékeket külön táblába, pl. tbl_forum_status. Ezt sokan el szokták felejteni, pedig integritást lehet vele növelni, plusz sem programkód, 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.
A tbl_user táblában miért van benne a salt?
Következetlen a táblák elnevezése, néhol többes, máshol egyes számban írod.
A tbl_ prefix nem rossz ötlet, hasznos tud lenni, mi pl. a táblákat pont nem látjuk el prefix-szel, de a view-ok v-vel, user defined function-ok uf/udf-fel kezdődnek, tárolt eljárások pedig usp-vel, így mindig lehet tudni, hogy miről is van szó, ami pl. több száz soros sp-k esetében nagy előny.
Ugye lesznek majd index-ek is?
-
#886
Sk8erPeter
nagyúr
Speeedfire
#885
Sk8erPeter
nagyúr
válasz
Speeedfire
#885
üzenetére
"A hirdetes_id is opció lehet, de itt inkább a juzerek vannak előtérben."
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."Pont, hogy a teljesítmény miatt (részben) maradtam a varchar mellett."
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....."Nagyon sok keresés szerintem nem fog itt lenni."
Szép, magyaros mondattal jól megaszontad.
"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.
"
Még mindig nem látok semmilyen érvet amellett, hogy varchar legyen a mező. Mi köze ennek ahhoz, hogy néz ki a többi oldal? 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."Minek kell a prefix? Hátha lesznek mással kapcsolatos táblák is az adatbázisban."
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."Miért fűzném a tag-eket a fórumhoz? A blogokhoz kell a tag."
A korábbi struktúrádban TEXT-et jelöltél meg a tagre, ez volt az elsődleges gond, de látom azt már legalább azóta javítottad.
A táblaszerkezet meg nálad közel sem volt egyértelmű, inkább félrevezető: volt forum tábla, volt postokat gyűjtő tábla, meg volt comment tábla. Ebből olyan, mintha a fórumokhoz lehetne postot is írni, meg kommentet is. Erre mondtam, hogy ennek úgy van értelme, ahogy a stackoverflow-n van, de ott mondjuk az is bonyolítja, hogy a postok majdnem ugyanúgy kezelendőek, ahogy az első, nyitópost is, mert mindet lehet pontozni, meg mindet el lehet fogadni, mint megfelelő választ, kivéve az első, nyitópostot.
A tagek meg csak magára a kérdésre kellenek, ami az elnevezéseidből úgy tűnt, magába a forum táblába tartozik, mint gyűjtőtábla. De akkor ezek szerint csak nem voltak egyértelműek az elnevezések.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. Mondjuk ha tanulási céllal akarsz sajátot fejleszteni, akkor oké. De ha a könnyű továbbfejleszthetőség is cél, akkor ezerszer jobban járnál pl. egy Drupallal (persze minimum 7-es verzió), nagyon jól testreszabhatóak a fórumok is, jó modulok készültek hozzá.
-
#885
Speeedfire
félisten
Sk8erPeter
#884
Speeedfire
félisten
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.
-
#884
Sk8erPeter
nagyúr
Speeedfire
#872
Sk8erPeter
nagyúr
válasz
Speeedfire
#872
üzenetére
"A kiemelés táblában azért van uid, hogy valamivel össze tudjam kapcsolni a 2 táblát.
"
Miért nem a hirdetés id-vel kapcsolod össze? A kiemelés a hirdetésre vonatkozik, a hirdetés megvásárlója meg egyértelmű, hogy kicsoda, elég egyszer tárolni. Mivel a hirdetés részleteit boncolgatod tovább, tök értelmetlen a user id-t letárolni a külön táblában. Az összekapcsolás is egyértelműbb lenne.
A kérdéseimre meg nem nagyon válaszoltál, úgyhogy úgy veszem, hogy nem kell neked a segítség."A másikra meg annyi, hogy én jobbnak találtam inkább varchar-kánt menteni az adatbázisban"
Hát felőlem... de ha majd a teljesítmény-szempontok kerülnek majd előtérbe (keresés lassabb lesz, mert szövegalapú keresgélést kell végrehajtani, nem pl. egy tinyintre kell rákeresni, annak mentén összekapcsolni a táblákat), lehet, hogy változtatnod kell majd az adatbázis-struktúrát, és akkor majd szidni fogod magad, hogy miért nem alakítottad ki eleve jól. Mondjuk ha akkor újabb lóvét adnak, akkor nyilván nem.=================
(#873) Soak :
jaja, én is sokszor hasznát vettem már. Főleg akkor jön jól, amikor nincs kedved gondolkozni.=================
(#881) Speeedfire :
most ez ujjgyakorlat? Vagy miért nem használsz tényleg valami CMS-t? (pl. Drupalt, ha már van tapasztalatod vele...)
Miért kezded minden táblád nevét tbl_ prefix-szel? Mivel adatbázisban van, elég egyértelmű, hogy itt táblák lesznek.Amúgy mi az az "ext" mező a tbl_post_items-nél?
Az meg remélem csak egy rossz vicc, hogy a posthoz tartozó tageket TEXT-ként akarod letárolni. A másik, hogy ha már külön táblád van a tbl_forum-nak, akkor ahhoz kéne kapcsolni a tageket, nem a posthoz - vagy minden hozzászólásnak külön taget szeretnél? Gondolom nem.
De az mindenesetre biztos, hogy a tagek összekapcsolását egy teljesen különálló táblában kéne megcsinálni, nem pedig egy TEXT típusú mezőben...
A usernél a saltot miért tárolod külön?
Minél többet nézem a struktúrádat, annál furább dolgokat látok. Miért kell külön tbl_comment és tbl_post tábla a FÓRUMHOZ? Most akkor kommentálni is lehet a fórumot, meg külön hozzászólást is lehet írni? Mi a különbség? Ha kommentálni lehet, akkor már miért nem magát a bejegyzést, ahogy pl. stackoverflow-n van?
Na, most inkább nem nézem tovább.(#883) Speeedfire: miért, régen nem volt komolyabb?
-
#882
martonx
veterán
Speeedfire
#881
martonx
veterán
válasz
Speeedfire
#881
üzenetére
Javaslom a célra a Wordpress-t.
-
#881
Speeedfire
félisten
Apollo17hu
#880
Speeedfire
félisten
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 -
#880
Apollo17hu
őstag
Speeedfire
#879
Apollo17hu
őstag
válasz
Speeedfire
#879
üzenetére
Ahogy a "kiemeles_tabla" tábládban írod, úgy.
Ez a sok kategória meg kétféle kiemelés nekem új, így valószínűleg jobb is, hogy külön táblába szedted őket, de ebben nincs tapasztalatom, hogy melyik az erőforrás-igényesebb megoldás.
-
#879
Speeedfire
félisten
Apollo17hu
#878
Speeedfire
félisten
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. -
#878
Apollo17hu
őstag
Speeedfire
#877
Apollo17hu
őstag
válasz
Speeedfire
#877
üzenetére
id | user_id | (sorrend) | mettol | meddig | hely_erteke | ...
Ez az egy táblád lenne. Lényegében a "hirdetes_tabla" táblád kiegészítve a "mettol", "meddig" és "hely_erteke" mezőkkel a "kiemeles_tabla" tábládból, ami így feleslegessé válik.
Ennél egyszerűbben nem tudom. -
#877
Speeedfire
félisten
Apollo17hu
#876
Speeedfire
félisten
válasz
Apollo17hu
#876
üzenetére
Hát, én ezt mindig nem értem, hogy ez az egyetlen_tabla honnan származtatik.
-
#876
Apollo17hu
őstag
Speeedfire
#875
Apollo17hu
őstag
válasz
Speeedfire
#875
üzenetére
Ebben benne van mindenki. Aki ki van emelve, annál a "mettol", "meddig" és "hely_erteke" töltött, a többinél null. Ha null, akkor 1000-et kap a sorrend felállításakor. Ha ki van emelve, akkor a "hely_erteke" mező értékét kapja.
Nem kell táblákat kötögetni, csak egy elágazást berakni a SELECT utáni felsorolásba.
-
#875
Speeedfire
félisten
Apollo17hu
#874
Speeedfire
félisten
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.
-
#874
Apollo17hu
őstag
Speeedfire
#869
Apollo17hu
őstag
válasz
Speeedfire
#869
üzenetére
Hát, mert most akkor emiatt csináljak még egy táblát?
Egyetlen táblával gondoltam az egészet:
id | user_id | sorrend (Kell egyáltalán ez a mező?) | mettol | meddig | hely_erteke | ...
SELECT id
,user_id
,CASE WHEN mettol <= sysdate AND meddig > sysdate
THEN hely_erteke
ELSE 1000 -- Vagy sorrend mező?
END
,...
FROM egyetlen_tabla
ORDER BY 3 -
#873
Soak
veterán
Sk8erPeter
#868
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.
-
#872
Speeedfire
félisten
Sk8erPeter
#871
Speeedfire
félisten
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.
-
#871
Sk8erPeter
nagyúr
Speeedfire
#869
Sk8erPeter
nagyúr
válasz
Speeedfire
#869
üzenetére
Jó, akkor elmondom a problémámat (egyébként gondolhatod, h ezeket segítő szándékkal mondom
Te is sokszor visszakérdezel, úgyhogy ne szóljá' be ) az itt írtakkal:
ha jól értem, vannak hirdetések "valamikre" az oldalon, amiket le lehet foglalni bizonyos időtartamra. Vagy meg lehet venni. Vagy kiemeltté lehet nyilvánítani egy adott hirdetést. Mittudomén, melyik, ez nem volt egyértelmű, pedig sokat segítene az érdemi megvalósításban. Vegyük mondjuk azt, h van egy kéró, amit bérbe lehet venni, megveszi mondjuk egy júzer az X-től Y-ig tartó időtartam erejéig. VAGY van egy júzer, aki felrak hirdetést, és azt kiemeltté lehet nyilvánítani, és akkor prioritást élvez a többi hirdetéssel szemben. De azt írod, "A kiemeléseknél van egy hely értéke, ami azt mutatja, hogy melyik helyet ki vetette meg mettől meddig." - attól függ a hely értéke, hogy mennyi ideig vette meg valaki? Vagy mennyi ideig számít kiemelt hirdetésnek?
Ez akkor ha jól értettem, változna mondjuk hetenként, mert egy-egy hétre lehet "megvenni" (ki tudja milyen értelemben) ezeket a helyeket. Akkor viszont csak adott időtartamra érdekes egy hely értéke, nem értem, miért akarod ezt nullázni: "Ha a következő hétre nem vett helyet akkor lenullázom az értékét." Adott hétre vonatkozik az érték, akkor a következő hétnél az előző hétre vonatkozó értékkel nem kell foglalkozni, újabb sor kerül a táblába, és annyi. De mondom, mindenféle megvalósítási kérdés a konkrét, jobban specifikált feladattól függene. Lehet, hogy szebben is meg lehetne oldani a feladatodat. Van egyszer user_id a hirdetés táblájában, meg a kiemelés táblában. Feltételezem, ennek az az oka, hogy van egyszer a hirdető, meg van egyszer a vásárló. De akkor ezek szerint nem a hirdetés kiemeltté minősítéséről van szó. Tehát körbe-körbe csavarodik valahogy ez a sztori, ha elsőre elolvasom a hsz.-edet, mert sztem a specifikáció így hiányos, és nehéz rá megmondani a tutit. De ha azóta megoldottad, akkor végül is nekem mindegy.==============
Amúgy erre nem nagyon reagáltál, hogy mi is a gondod vele. -
#870
Speeedfire
félisten
Speeedfire
félisten
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...
-
#869
Speeedfire
félisten
Apollo17hu
#867
Speeedfire
félisten
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. -
#868
Sk8erPeter
nagyúr
Speeedfire
#861
Sk8erPeter
nagyúr
válasz
Speeedfire
#861
üzenetére
A kiegészítő paramétereket nyilván nem kézzel kéne hozzáírnod, hanem mondjuk legenerálni.
Amúgy hány paraméter van?Egyébként próbáld ki a dbForge Studio for MySQL progit, szerintem iszonyat jó, sokkal jobb, mint a MySQL Workbench, nekem komplex query-k összeállításához való segítségként nagyon jól jött már párszor. Van, amikor nem áll össze fejben a query (pl. nagyon összetetteknél már belekavarodsz), és ilyenkor egy ilyen grafikus alapú program elég jól jön.
===
A unionos kérdésre azért nem reagálok, mert ott inkább először visszakérdeznék, de akkor meg jössz azzal, hogy na már megint én vagyok a hülye, mert nem értem a kérdésedet egyből.
-
#867
Apollo17hu
őstag
Speeedfire
#866
Apollo17hu
őstag
válasz
Speeedfire
#866
üzenetére
De miért ne lehetne egy olyan tábla, hogy:
id | user_id | sorrend | mettol | meddig | hely_erteke
...és ebből generálnád a tényleges sorrendet az utolsó 4 mező alapján.
-
#866
Speeedfire
félisten
Apollo17hu
#865
Speeedfire
félisten
válasz
Apollo17hu
#865
üzenetére
2 tábla mindenféleképp kellene, 1 tábla kevés az adatok miatt.
-
#865
Apollo17hu
őstag
Speeedfire
#864
Apollo17hu
őstag
válasz
Speeedfire
#864
üzenetére
Nem lehetne egy táblával megoldani a dolgot? A kiemelés táblából generálnád az egészet úgy, hogy akinél nincs töltve a "mettol", "meddig" és "hely_erteke" mező, azoknak - ahogy írtad - 1000-et adnál, a többieknek pedig a "hely_erteke" mező értékét.
-
#864
Speeedfire
félisten
Speeedfire
#861
Speeedfire
félisten
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á?
-
sonar
addikt
Sziasztok,
Megint meggyült a bajom egy query-vel. Egy intervallumra szeretnék lekérdezni, de mivel a date_time formátuma '%Y%m%d%H%i%s' ezért ez a query nem fut le, azaz nem ad vissza értékelhető eredmény.
Tudnátok segíteni, hogy mit kellene módosítanom?
SELECT * FROM li_mtsn_index where date_time < (DATE_SUB(NOW(), INTERVAL 1 DAY)) order by date_time;
-
#861
Speeedfire
félisten
Sk8erPeter
#859
Speeedfire
félisten
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 sorrend -
#859
Sk8erPeter
nagyúr
Speeedfire
#857
Sk8erPeter
nagyúr
válasz
Speeedfire
#857
üzenetére
"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."
Hát nem tudom, ez neked hogy jön ki.A legegyszerűbb eseteket mondom.
- 1 tábla a paraméter (szemszín, hajszín, stb.) id-jának és ember által olvasható nevének; esetleg lehet machine_name-je is, ami nem tartalmaz ékezeteket, stb., csak olvashatóbb azonosításra szolgál (opcionális). Vegyük azt az esetet, hogy mondjuk nem kívánod lefordítani a paraméterek (szemszín, hajszín, stb.) nevét, VAGY ha lefordítod, akkor ugyanabba a táblába bedobálod külön mezőként a fordításokat nyelvek szerint (bár elvileg szét kéne bontani, és lenne mondjuk egy id-je egy fordítási "csomópontnak", ahogy már említettem). Szóval
id | name
(vagy translation_node_id)
- 1 tábla a paraméterek (szemszín, hajszín, stb.) lehetséges értékeinek (pl. szemszín: barna, zöld; hajszín: ugyanezek, stb.), tehát pl.
param_id | param_value. Ez szebben megint inkább külön id-val lenne tárolva, tehát param_id | param_value_id felosztásban, és a paraméterek lehetséges értékeinek lenne tök általános külön táblája is; ez azért is lehet érdekes, mert a szemszínek és hajszínek közt sok egyező is lehet (pl. barna).
- 1 tábla a felhasználók által beállított paramétereknek; lehet esetleg egy bitmezővel (vagy tinyint 0, 1) jelezni, hogy saját beállított paraméteréről, vagy a kívánt partner paramétereiről van szó; így pl.
user_id | param_id | param_value_id | is_own
felosztás.Ez egy lehetséges megoldás. És igen, a feltételek között az egyezőségek vizsgálatakor elég sok paraméter fog szerepelni, ha OR-ral választod el, akkor még paraméterek egyezőségét is tudod vizsgálni százalékosan, egyetlen lekérdezéssel akár... tehát rengeteg előnye van ennek a felosztásnak (tapasztalat).
"csak 500-600 felhasználóról beszélünk!!! Nem 5000-6000."
500-600 felhasználónál sem mindegy, meddig tart egy lekérdezés eredményeinek megmutatása. Ha jól értem, az oldal legfőbb profilja egyfajta társkeresés lenne, így itt pont ez lehet a szűk keresztmetszet a sebességben a sok keresgélés miatt. -
#858
Speeedfire
félisten
Speeedfire
félisten
Erre van valakinek ötlete, hogy lehetne megoldani union nélkül?
-
#857
Speeedfire
félisten
Sk8erPeter
#854
Speeedfire
félisten
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. -
#856
martonx
veterán
Sk8erPeter
#854
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.
-
#855
martonx
veterán
Speeedfire
#853
martonx
veterán
válasz
Speeedfire
#853
üzenetére
Modellből visszafejtés nagyon nem szép megoldás. Ráadásul simán el tudok olyan helyzetet képzelni, mikor hátulról akarsz adatokat lekérni a DB-dből, és akkor hol van a PHP-s modelled? Szvsz gányolás.
-
#854
Sk8erPeter
nagyúr
Speeedfire
#849
Sk8erPeter
nagyúr
válasz
Speeedfire
#849
üzenetére
"Akkor te külön kapcsolótáblát tennél mondjuk a 40 mezőhöz?
"
Hogy mi van? Te valamit nagyon félreérthettél.
Én azt mondtam, hogy nehogy már ismétlődően stringeket tárolj, hogy sokszor előforduljon, hogy "szemszin", "szemszin", "szemszin", 'hajszin", "hajszin", "hajszin".............. Mi van, ha egyszer meg akarod változtatni az ember által is olvasható, stringesített nevét? Ha lesz mondjuk 5000 felhasználód, akkor 5000 helyen cserélsz majd le egy stringet?
Egy teljesen egyedi azonosítót viszont valószínűleg nem akarnál megváltoztatni, mert tök felesleges.
Ráadásul itt tök feleslegesen stringeket tárolsz, amikor tárolhatnál tiny/smallinteket is mondjuk...A lekérdezéshez meg elég a paraméter nevét tartalmazó táblát hozzákapcsolni, ha név szerint szeretnél lekérdezni...
ha meg "nincs kedved" joinolgatni 2-3-4 táblát - egy szebb megoldást választva -, akkor válassz másik szakmát. (bocs, de ezt muszáj volt )==============
(#850) martonx :
hát az szerintem meg nagyon nem "szabályos menet", hogy mindenhol ismétlődően stringeket tárol, mint a "hajszin", "szemszin", stb. stringek...
Tök jó, hogy megdicséred, de ne akkor tedd, amikor rossz módszert alkalmaz. -
#853
Speeedfire
félisten
martonx
#852
-
#852
martonx
veterán
Speeedfire
#851
martonx
veterán
válasz
Speeedfire
#851
üzenetére
Sok mindent írtál. Az biztos, hogy ebben az esetben lesz egy select-ed, aminek lesz annyi join-ja, ahány mezőben használod a paraméter Id-jait.
Ez így csúnyának fog látszódni, pláne eg egy soros select * from tábla-hoz képest, de hidd el a TSQL-t nem fogja zavarni. Picit teljesítményben persze rosszabb egy select 40 join-nal, de ha abból a 40-ből mind a 40 ugyanannak a táblának ugyanaz a mezője, akkor nem vészes a dolog. Az SQL-ed viszont kevesebb memóriát, tárhelyet fog használni a normalizálásnak hála, ami hoszting cégek esetében előny.
Egy jótanács. Azért ne akarj mindent normalizálni. Pl. kezesség bal - jobb. Ezt egy sima bit mezővel elég megoldani, nem kell, hogy ehhez legyen két paramétered, mint 1 - bal, 2 - jobb.
Még egy jótanács, ha már normalizálunk, és táblát tervezünk. Ne int-ként, hanem tinyint, smallint ilyesmikként kezeld a mezőket. Ezzel további sok byte-ot lehet nyerni mezőnként. És úgy sincs több százezer választható opció egy adott mezőhöz. -
#850
martonx
veterán
Speeedfire
#841
martonx
veterán
válasz
Speeedfire
#841
üzenetére
Amit leírtál az a szabályos menet, és normalizálásnak hívják. Reméléem nem törtelek le, hogy nem találtad fel a spanyolviaszt.
Igen így szokták használni a klasszikus SQL-t, pont ezért is hívják Tranzakciós SQL-nek, nem pedig NoSQL-nek. -
#849
Speeedfire
félisten
Sk8erPeter
#848
Speeedfire
félisten
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
} -
#848
Sk8erPeter
nagyúr
Speeedfire
#841
Sk8erPeter
nagyúr
válasz
Speeedfire
#841
üzenetére
MINDENT id szerint azonosíts. Soak tanácsa szerintem nagyon rossz, hogy inkább mindent varcharral vagy texttel tárolj, kerülendő megoldás, mert nagyon sok partner közti keresésnél észrevehetően lassú lesz a szövegalapú keresgélés.
Az id-khoz tartozó neveket pedig külön tárold. Pl. legyen egy parameters tábla, abban pedig id | name vagy hasonló. De hogy továbbvigyük: gondolj bele, mi van, ha pl. ezeket a neveket fordítani is kell. Akkor még a fordításhoz tartozó "csomópontot" is id szerint érdemes inkább hozzákapcsolni, és a fordítást megint külön táblában tárolni. Tehát akkor meg id | translation_node_id felosztásban lehet. (persze beleerőltetheted azonos táblába az összes fordítást, úgy, hogy minden nyelvhez külön "oszlop" tartozik, de az sem egy túl szép megoldás, nem biztos, hogy mindenre van fordítás, és akkor ott addig NULL van)
Sok ilyen esetben érdemes inkább sok-sok logikailag különálló táblát külön is tárolni, a táblakapcsolások nem fogják nagyon lassítani a lekérdezéseidet, sőt, adott esetben sokkal gyorsabb lehet.Egyébként dolgoztam a tiédhez hasonló feladaton, akkor nem így "oszloponként" tároltam a paramétereket (úgy, hogy
id | hajszin | szemszin | ...
), hanem széjjelbontva,
id | param_id | param_value_id
"csoportosításban" (pl. 1 | 5 | 6, ránézve az adatbázisra persze nem túl beszédes, csak a megfelelő tábla hozzákapcsolásával). -
#846
Soak
veterán
Speeedfire
#845
Soak
veterán
válasz
Speeedfire
#845
üzenetére
Pontosan nem értem, hogy mit szeretnél (a hsz. utolsó bekezdése) , de elég egyszerűen meg tudod mérni.
Csinálsz egy teszt adatbázist . Megcsinálod a vázát. Php-vel random feltöölteszt 500-600 sort, majd pedig pl 50.000szer lekéred és microtimeal megnézed melyik a gyorsabb.
De ha csak nem valami nagyon massziv siteot üzemeltetsz (1.5-2M < pageload/nap ) akkor nem érezhető különbség szvsz.
-
#845
Speeedfire
félisten
Soak
#844
Speeedfire
félisten
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.
-
#844
Soak
veterán
Speeedfire
#843
Soak
veterán
válasz
Speeedfire
#843
üzenetére
Ha jól értem akkor egy sorban 40 oszlop és mindegyikben egy ekkora "cimke" . Úgy sejtem PHP-ban kódolsz szóval én azt mondanám, hogy ha kevesebb cimke lenne (gondolom 40szolophoz van pár választási lehetőség is) akkor egyszerűen le lehetne dokumentálni a Classod elején, hogy mi micsoda.
Viszont ilyen szinten 2 nap alatt elfejtenéd mi-micsoda és mindig keresgetni 10-20 közül a dokumentációdba .
É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)
-
#842
Soak
veterán
Speeedfire
#841
Soak
veterán
válasz
Speeedfire
#841
üzenetére
Nagyon sok text-et vagy nagyonsokszor text-et? A text user input vagy előre definiált (mondjuk kategóriák) ?
-
#841
Speeedfire
félisten
Speeedfire
félisten
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á? -
#840
sonar
addikt
Apollo17hu
#838
sonar
addikt
válasz
Apollo17hu
#838
üzenetére
Zsiir! A group by nem jutott eszembe.
-
#839
sonar
addikt
Speeedfire
#837
sonar
addikt
válasz
Speeedfire
#837
üzenetére
Egy tábla az egész. És tabella kell belőle olyasmi, mint a fociban.
-
sonar
addikt
Sziasztok,
Nézzétek el a hiányos tudásomat. Ismét elakadtam.
Van hat csapat és 10 forduló. És menet közben kellene egy tabellát összerakni.
id_team - csapat
id_fordulo - forduló
score - a csapat mennyi pontot szerzett az adott fordulóban.
Hogyan tudnék ebből egy tabellát összerakni? -
#835
Speeedfire
félisten
Speeedfire
#834
Speeedfire
félisten
válasz
Speeedfire
#834
üzenetére
Kiszúrta a szemem...
-
#834
Speeedfire
félisten
Speeedfire
félisten
Mysql workbench-ben kész adatbázisról nem lehet diagrammot nézni?
-
#828
Apollo17hu
őstag
Soak
#827
Apollo17hu
őstag
select u.id
,u.username
,r.friend_id
,r.typeofrelation
from users u
,relations r
where 1=1
and u.id = r.users_id
and r.friend_id = 5
and r.typeofrelation = 1Ha a két táblában további mezők is szerepelnek, ami miatt duplikálódás fordulhat elő, akkor azokat ne sorold fel a SELECT-ben, hanem használj DISTINCT-et!
-
Soak
veterán
SELECT * FROM users LEFT JOIN relations ON users.id = relations.users_id and relations.friend_id = 65 and relations.typeofrelation = 1 GROUP BY relations.users_id
Ezzel a kóddal már majdnem ott vagyok, de valamiért mindig 1-el több usert kapok vissza és annak nincs is relation oszlopokban semmi csak NULL, mit keres ott?
szerk: Nem LEFT JOIN ,hanem JOIN csak simán. Így müködik.
-
Soak
veterán
Sziasztok !
Van két táblám , Users, Relations. A relations táblában van egy users_id,friend_id,typeofrelation . Azokat a Usereket szeretném lekérni akik a Relations táblában egy bizonyos friend_id mellett szerepelnek és a typeofrelation = 1 .
Magyarul:
Relations táblausers_id friend_id
1 5
2 5A user tábla pedig
id username
1 John
2 Doe
3 Pityuka
stb.Azt szeretném, hogy a lekérésnél az első kettő usert kapnám vissza. Ezzel probáltam, sikerül is kiválasztani a megfelelő sorokat, de mindegyikhez a Users tábla eslő userének adatait illeszti :
SELECT * FROM relations,users WHERE Relations.friend_id = 62 GROUP BY relations.users_username
-
#824
martonx
veterán
Apollo17hu
#822
martonx
veterán
válasz
Apollo17hu
#822
üzenetére
Látod nem is volt nagy cucc beüzemelni. Ezért igazán kár volt a fórumban idétlenkedni. Ráadásul mint annyiszor, most is egy minimális guglizás megoldotta a dolgot.
Egyébként igen azt jelenti, hogy minden win induláskor a MySQL szerver is elindul a háttérben. Ez valamennyi erőforrást lefoglal. Egy régi P4-es celeron kb. használhatatlanná válik tőle, egy core i7-es 8Gb rammal meg észre sem veszi.
-
#822
Apollo17hu
őstag
Apollo17hu
#821
Apollo17hu
őstag
válasz
Apollo17hu
#821
üzenetére
Rágugliztam: ki kellett szedni a Direct mellől a pipát.
Amúgy ez a rendszerrel együtt futva azt jelenti, hogy a Win minden egyes indításakor automatikusan elindul a MySQL szerver is a háttérben? -
#820
martonx
veterán
Apollo17hu
#819
martonx
veterán
válasz
Apollo17hu
#819
üzenetére
amikor telepítetted a mysql-t, és nyomkodtad a next-et, volt egy olyan rész, hogy user, meg jelszó. Ez ha jól rémlik defaultban root és nincs hozzá jelszó. Illetve volt egy olyan rész is, hogy fusson-e szolgáltatásként a rendszerrel együtt a mysql, vagy mindig kézzel akarod indítgatni. Azt hiszem itt is a default, hogy fut a rendszerrel együtt.
A server meglepő módon gondolom localhost. -
#819
Apollo17hu
őstag
Apollo17hu
őstag
Sziasztok!
Telepítettem a MySQL szervert, hozzá pedig a DreamCoder for MySQL eszközt. Utóbbiban próbálnám beállítani a kapcsolatot, de lövésem sincs, hogy kellene:
Nem tudom, mi a Login, a Server-nél pedig semmit sem tudok betallózni. Mi a teendő ilyenkor? -
PazsitZ
addikt
Szimplán fel kell a select után sorolni a mezőket.
Vagy a tábla nevével prefixelve vagy aliassal.
SELECT table1.password, table2.password FROM table1 LEFT JOIN table2 ON table1.id = table2.fkidAkár még a selectált fieldeknek is adhatsz egyedi alias nevet:
SELECT t1.password AS table2_pass, t2.password AS table2_pass FROM table1 t1 LEFT JOIN table2 AS t2 ON t1.id = t2.fkid -
#814
Sk8erPeter
nagyúr
_Roy_
#813
Sk8erPeter
nagyúr
jó, akkor másképp kérdezem:
az egyik táblában lévő id-t tartalmazza a másik, aminek mentén be lehet azonosítani, hogy melyik névhez melyik e-mail tartozik?
Remélem...
Annyit tudtunk meg, hogy van password mindkét táblában (bár nem értem, minek, vagy miről van szó), van username az egyikben, a másikban meg ki tudja mi.
De gondolom mindkettőben van id.
Ne rohanva írd már le, ha neked kéne segítség, hanem írd körül normálisan. Vagy egyszerűen mutass egy SQL dumpot a táblaszerkezetről legalább. -
#813
_Roy_
tag
Sk8erPeter
#812
_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 -
#812
Sk8erPeter
nagyúr
_Roy_
#811
Sk8erPeter
nagyúr
Igen, tudnánk segíteni, ha leírnád, mivel próbálkoztál, meg milyen mező "mentén" kellene összekapcsolni a két táblát.
Az sem mindegy, hogy LEFT JOIN, RIGHT JOIN, INNER JOIN, stb., mert tudni kéne, mely értékek kellenek neked. Csak azok, amelyek mind a két táblában megvannak? -
_Roy_
tag
sziasztok, remélem jó helyre írok
adott két tábla az adatbázisban, amiket szeretnék összefűzni, vannak benne ugyan olyan nevű mezők és különbözőek a lényeg h az új táblában látszódjon mind a 2 tábla mezőinek az értéke LEFT JOIN -al próbáltam megoldani, de ezzel nem jött össze, mert csak az egyik tábla értékeit mutatja, viszont az összes mező benne van mind a 2 táblából
valami ötletetek arra hogy hogyan kellene ennek működnie -
zka67
őstag
Asszem megvan:
SELECT temp.maxdt,temp.user,readers.dir FROM (SELECT MAX(dt) AS maxdt, sid AS user FROM traffic GROUP BY sid) AS temp LEFT JOIN traffic ON traffic.dt=temp.maxdt LEFT JOIN readers ON traffic.reader=readers.id WHERE dir=0 ORDER BY temp.user;
Azért köszi a segítséget
-
zka67
őstag
Sziasztok! Egy olyan lekérdezést szeretnék csinálni, aminek az a lényege, hogy megtudjam, hogy kik tartózkodnak bent egy épületben jelenleg. Az adatbázisban van egy dir nevű mező, ami a mozgás irányát jelzi, 0 ha bement az illető és 1 ha ki. Ehhez természetesen tartozik még pár adat, azonosító, időpont stb.
Ezt vajon meg tudom csinálni 1 db lekérdezéssel? Magyarul az kellene nekem, hogy azokat a rekordokat adja vissza, ahol az adott id-hez (sid a mező neve) tartozó legutolsó időpontnál a dir értéke 0 és minden azonosító csak egyszer szerepeljen a listában természetesen, a legutolsó belépés rekordjával.
A segítségeteket előre is köszönöm.
-
#805
CSorBA
őstag
Sk8erPeter
#804
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
-
#804
Sk8erPeter
nagyúr
CSorBA
#795
Sk8erPeter
nagyúr
No de ezen az alapon az ügyfél akár csillagot vagy akármi mást is írhat a karakterek elválasztásaként kötőjel helyett. Erre a legegyszerűbb, ha a telefonszámot felhasználóbarát módon szétválasztod ország-előhívószámra, körzetszámra, stb., aztán vagy konkatenálva töltöd fel adatbázisba, vagy külön is tárolod ezeket. A validáció meg kliens- és szerveroldalon is elkerülhetetlen, de én a helyedben mindenképp szétbontanám, hogy elkerüljem az ilyen problémákat.
Szerk.: most látom, hogy már hatezer éves (soknapos) kérdés volt, és a (#793)-ban lényegében Te is azokról beszéltél, amiket leírtam.
-
martonx
veterán
hijnye ember te halmozottan hátrányos helyzetű vagy.
1. Ez itt egy MySQL topik
2. A dokumentációban végig MSSQL-ről van szó
3. Ennél betegebb helyre nem tudtad feltölteni a megosztando dokumentumot??? Manapság a felhők világában, egy ilyen elcseszett - döbbenet hogy még létező - fájl megosztó oldalt hogy lehet egyáltalán megtalálni?Mondjuk ez a harmadik pont elég szubjektív, de nekem azért is fizetned kellene, hogy egy ilyen helyről letöltsek egyáltalán bármit. Ennek ellenére letöltöttem, és az 1-2-es pontok ellentmondásánál gurultak el a gyógyszereim. Ha a fenti véleményem ellenére is kell segítség tőlem
, akkor keress meg nyugodtan privátban
Bár erős a gyanúm, hogy távolról amúgy sem fogok tudni segíteni, mert akinek ez a leírás kínai, annak a windows távoli elérésének bekonfigurálása is elérhetetlen messzeségben van, ami viszont az érdemi segítség nyújtáshoz elengedhetetlen.
Korábban még júzerek paramétereiről (hajszín, szemszín, csöcsméret, stb.) beszéltünk. 
Valószínűleg a kérdés arra irányult, hogy mi értelme van.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Windows: mi történik valójában Leállításkor, Alvó módban és Újraindításkor?
- Telekom mobilszolgáltatások
- Jól néz ki a világoskék iPhone 17 Air
- Mini PC
- Magyarországra jött az ultravékony S25 Edge
- Nők, nőügyek (18+)
- Kormányok / autós szimulátorok topikja
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Battlefield 6
- Magga: PLEX: multimédia az egész lakásban
- További aktív témák...
- iKing.Hu - Honor Magic V2 Black Használt, karcmentes állapotban 16 GB RAM / 512 GB tárhely
- Thomson Streaming Box 240 TV okosító / Számla / Garancia /
- Bomba ár! Dell Latitude E5430 - i5-3GEN I 4GB I 128SSD I HDMI I 14" HD I Cam I W10 I Gari!
- Eladó Lenovo ThinkCentre M910q i7 16GB / 12 hó jótállás
- Extra olcsó! HP 230 Vezetéknélküli USB-s Billentyűzet
Állásajánlatok
Cég: FOTC
Város: Budapest