Hirdetés
- Megjött a Cherry legfrissebb, taktilis karakterisztikájú kapcsolója
- 8 bővítőhelyes Jonsbo "akvárium", akár kábeleket rejtő alaplapokhoz is
- 4K felbontású, 240 Hz-es OLED monitorokkal köszönti az őszt a Lenovo
- Ismét egy teljesen friss egérrel gyarapította kínálatát a Pulsar
- Legalább 20 éves lemaradásban vannak a kínai litográfiai cégek?
- Azonnali VGA-s kérdések órája
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Most Kína tiltotta ki a nemrég exportengedélyt kapott AI gyorsítókat?
- 5.1, 7.1 és gamer fejhallgatók
- Milyen billentyűzetet vegyek?
- TCL LCD és LED TV-k
- OLED TV topic
- Epson nyomtatók
- Projektor topic
- Intel találgatós topik
Új hozzászólás Aktív témák
-
#1573
_ak_
addikt
Speeedfire
#1572
_ak_
addikt
válasz
Speeedfire
#1572
üzenetére
Ez így már világosabb akkor, köszi!
Viszont az továbbra is rejtély, hogy miért nem működik az admin ellenőrzés, máshol is van még egy-egy ilyen if, igaz nem a controllerben, de hasonló a funkció és hibátlanul működik:
@if($dog->user_id === Auth::id())
Ránézésre a host és a vagrant box-om közti különbség a MySQL verziója 5.1-5.5 és tároló motor, de hoston az a két if nem igazán működik úgy, ahogy kéne.
-
#1571
_ak_
addikt
Speeedfire
#1570
_ak_
addikt
válasz
Speeedfire
#1570
üzenetére
Na de nem pont az a lényege az ORM használatának, hogy előredefiniált táblarelációk vannak az idegen kulcsokon keresztül? Máskülönben hogyan határozódik meg a reláció?
Ezt félretéve nagyjából értem amit mondasz, amennyiben a úgy érthetem, hogy a relációk az alkalmazáson belül kerülnek beállításra és az InnoDB motornak pedig sebességi előnye lesz, ha megadjuk, hogy melyek az idegen kulcsok egy másik táblából.
Nem akarok hülyeséget kérdezni, nem hogy írni, csak azt hittem, hogy ha nincsen meghatározva az idegen kulcs, akkor az ORM használatát is bukom.
-
#1560
_ak_
addikt
Speeedfire
#1559
_ak_
addikt
válasz
Speeedfire
#1559
üzenetére
Parancsolj:
(SQL:
select count(*) as aggregate from `dogs` where `gender` = szuka
or
(select count(*) from `dog_breeds` where `dogs`.`dog_breed_id` = `dog_breeds`.`id` and `dog_breed` LIKE %szuka%) >= 1
or
(select count(*) from `counties` where `dogs`.`county_id` = `counties`.`id` and `county` LIKE %szuka%) >= 1
or
(select count(*) from `settlements` where `dogs`.`settlement_id` = `settlements`.`id` and `settlement` LIKE %szuka%) >= 1
)martonx: De még mennyire, hogy hasznos. Noha a Laravel dokumentációban nem túl erős, ezt párosítva a tapasztalatlanságommal, sokszor, ha előttem van vmi, akkor sem vagyok benne biztos, hogy az az amit keresek, lásd a fenti helyzetet. Eloquent query alatt ez is ott van, de egyszerűen túlmentem rajta, amíg nem találtam egy könnyen érthető példát a neten.
Ebben szerencsére jók, a hypenak köszönhetően nagyon sok talált van, csak tudjam, hogy mit is akarok pontosan.
-
#1556
_ak_
addikt
Speeedfire
#1555
_ak_
addikt
válasz
Speeedfire
#1555
üzenetére
Úgy tűnik, hogy szépen elakadtam.
Félig meddig sikerült valamit összehoznom, viszont azzal együtt jött vmi tábla ütközés, mert fals értékek jelentek meg. Itt az első postomban leírtam, hogy mi volt az ami látszólagosan működött.
Amúgy a model relációim működnek, szóval le tudom kérdezni a kutya fajtát vagy a hozzátartozó települést egy egyszerű '$dog->dog_breed'-el, ill. a kutyák táblában is tudok keresni 'LIKE'-al, de ilyen keresést nem tudok kiterjeszteni a hozzátartozó táblákra.
Most nekifutok még egyszer joinnak, hátha frissebb fejjel más lesz az eredmény.
És közben most kaptam egy tippet, hogy scope query-t is nézzem meg, ill. az eager loadingot.
-
#1554
_ak_
addikt
Speeedfire
#1553
_ak_
addikt
válasz
Speeedfire
#1553
üzenetére
Valami összejött, de felvetett jó pár kérdést.
Elsőnek engem a sorrendiség zavart meg. Mivel a kutyák táblám tartalmaz minden infót vagy inkább kapcsolódó 'id'-t, ezért azt hittem, hogy a kutya táblához kell hozzákötni a többit, de most a 'users' táblához kötöttem a 'dogs' táblát, méghozzá a 'user.id', '=', 'dogs.user_id'.
Meg is kapom szépen a keresett infókat. Igen ám, de van még 'county, settlements,dog_breeds' táblám is, ezeket már nem tudom, így hozzákötni a 'users' táblámhoz. Szóval nem működhet ez valahogy visszafelé is?
Mindenesetre még túrom a Laravel doc.-ot, mert 2 dolog is feltűnt. A fenti DB queryt használva másképp kapom meg az adatokat, mint a Laraveles Eloquent-tel.
Eloquenttel a kapott eredmény:
Dog:with('county', 'settlement')->get(); eredménye:
id:
breed:
county_id:
settlement_id (és folytatásként külön tömbben a 'county', majd megint különben a 'settlement'
id:
county:
.
.
.Míg a DB query join után egyben volt minden, tehát tényleg, mintha egy táblából olvastam ki volna mindent.
-
#1549
Kommy
veterán
Speeedfire
#1546
Kommy
veterán
válasz
Speeedfire
#1546
üzenetére
Köszi a trigger bejött most már csak egy jelszó emlékeztetőt kell kérni az SLS-ben és máris be tud lépni.
fordfairlane: há ebből a leírásból nem jöttem rá, hogy fognak a felhasználói adatai átkerülni a phpbb-ből az SLS-be.
-
#1385
bpx
őstag
Speeedfire
#1384
bpx
őstag
válasz
Speeedfire
#1384
üzenetére
-
#962
Peter Kiss
őstag
Speeedfire
#961
Peter Kiss
őstag
válasz
Speeedfire
#961
üzenetére
Első kép:
Kihagy 10-et;
Látszik: 11, 12, 13, 18, 19 és fölötte;Második:
Kihagy 15-öt;
Látszik: 20 vagy fölötte; (15-10 => 5 darab, ami:11, 12, 13, 18, 19) -
#960
PazsitZ
addikt
Speeedfire
#958
PazsitZ
addikt
válasz
Speeedfire
#958
üzenetére
A LIMIT a leszűrt, kapott adathalmazra vonatkozik.
Így a 11, 12, 13, 18, 19 id-val ellátott sorok, amíg megjelennek LIMIT 10, 50 -nél, addig az említett 5 sor nem LIMIT 15, 50 -nél. Nem értem mi a probléma.Ha 15-ös id feletti sorokat akarsz megkapni, akkor ugye a WHERE-ben kell megadnod, az id >15 feltételt.
Ígyál egy kávét, tolj egy minesweepert és fuss neki újra
(#961) Speeedfire:
A limittel lehet játszani, csak nem azt, amire itt most szerintem gondolsz.
Egyenletes, "szünetmentes" id sor esetén lenne esetileg igaz, amire gondolsz.De ha bővebben kifejted, mi a cél lehet többet tudunk segíteni.
-
#959
Peter Kiss
őstag
Speeedfire
#958
Peter Kiss
őstag
válasz
Speeedfire
#958
üzenetére
Teljesen jól működik, amennyire látom.
-
#957
Sk8erPeter
nagyúr
Speeedfire
#955
Sk8erPeter
nagyúr
válasz
Speeedfire
#955
üzenetére
-
#947
Lacces
őstag
Speeedfire
#946
Lacces
őstag
válasz
Speeedfire
#946
üzenetére
Jah, de az FB más téma, a dinamikusan változó dolgoknál jó ez a mongodb, de amúgy a nosql-nek is rengeteg fajtája van. Mindegyik másban jobb.
Bár láttam példát és FB is ezt csinálja, hogy hibrid adatbázis rendszereket használ. Lehet már tényleg kellene írnom e kettő adatbázis rendszerről, és megírni a személyes véleményt.
Köszi a választ, léptem
-
#945
Lacces
őstag
Speeedfire
#944
Lacces
őstag
válasz
Speeedfire
#944
üzenetére
Igen anomália, de milyen lehet.
Igen, igen a JOIN-t szeretem, most legutóbb meg át kellett vennem projektet, ahol hát... mit ne mondjak... elég rosszul megtervezett volt az adatbázis, ott mondjuk a JOIN terhelte, vissza kellett hivatkoznom a táblára...
Meg ahogy olvasgatok a MongoDB után (lehet nyitok egy ilyen topicot) akkor olvastam, hogy ha az RDBMS-ben rendkívül kevés a JOIN művelet, akkor nem kell a dokument alapú nosql-ek felé kacsingatni.Meg ha már itt tartunk, NetBeans meglelted már az SQL kezelőfelületét?
Állítólag van benne, de én még nem leltem meg (igaz én csak GUI esetében használom) -
#937
Sk8erPeter
nagyúr
Speeedfire
#936
Sk8erPeter
nagyúr
válasz
Speeedfire
#936
üzenetére
Érdekes módon használat közben tényleg gyorsabbnak tűnik, viszont az indulási ideje valamiért iszonyat lassú, nem vágom az okát.
Egyébként a Te géped referenciának számít?
-
#922
Bishoop
tag
Speeedfire
#920
Bishoop
tag
válasz
Speeedfire
#920
üzenetére
Ha localhoston vagy használj msql workbench-et.
Ez egy phpadmin alternatíva akar lenni? És jobb mint phpadmin ?
Én wampservert használok. Nem probléma ha arra rátelepítem a worbench-et?
Mert szerintem a wamp-ban egy kicsontozott myphp verzió van.Ezt csak az admin tudja szerintem törölni, attól függ milyen jogok vannak ezekre.
Jogom az van hozzá, csak nem engedi kijelölni a phpmyadminban. -
#919
Bishoop
tag
Speeedfire
#918
Bishoop
tag
válasz
Speeedfire
#918
üzenetére
Szerencsére találtam a példaadatbázisban SQL fájlokat is, először azt hittem hogy azok csak lekérdezések, de importálva létrehozta a megfelelő táblákat. Eredetileg FRM kiterjesztésű fájlok voltak, és ezeket akartam importálni. Amúgy az alap adatbázisokból a MYSQL és az INFORMATION_SCHEMA neműt nem lehet törölni. Ez normális?
Jó lenne ez a phpadmin, csak pl. a táblák közötti kapcsolatok megjelenítése elég pocsék.
Egyébként miért veszélyforrás a phpmyadmin? Ha localhoston fut akkor milyen biztonsági probléma lehet vele? -
#911
PazsitZ
addikt
Speeedfire
#908
PazsitZ
addikt
válasz
Speeedfire
#908
üzenetére
Én meg azt mondom, hogy a yii -annak ellenére, hogy több nagy megrendelő is hajlamos használni/kérni- nem való túl nagy rendszerekhez.
Kisebb szájtokhoz viszont nagyon kényelmes, hasznos, aránylag gyors társ tud lenni. Pl. a crud-os és egyéb generált kódok, extension-ök segítségével.
Egyébként viszont rengeteg static függvénnyel, félig konfigurálható, félig viszont beégetett implentációval rendelkezik.
-
#910
Sk8erPeter
nagyúr
Speeedfire
#908
Sk8erPeter
nagyúr
válasz
Speeedfire
#908
üzenetére
Az a jó, amikor felteszed a kérdéseidet, tanácsokat kérsz, aztán meggyőzöd magad végül a saját magad által kitalált megoldás helyességéről.
-
#906
Peter Kiss
őstag
Speeedfire
#904
Peter Kiss
őstag
válasz
Speeedfire
#904
üzenetére
Az active record-dal az a baj, hogy egy tervezési hiba.
$post=new Post;
$post->title='sample post';
$post->content='post body content';
$post->save();Ez a kód a Yii oldaláról való, látható, hogy van egy objektumunk, ami mindent megcsinál helyben, ilyet nem szabad csinálni. Egy ilyen rendszerben szépen szét kell szedni mindent: unit of work, identity map, meta data, entity, query object, miegymás. Nyilván könnyebb haszálni egy AR megoldást, de igazából ultragáz.
Belepillantottam a CActiveRecord osztályba, itt aztán minden van. Ami még nagyon tud fájni, hogy nincs benne normális object tracking, de van valamiféle meta leírása, ám az, hogy előírnak egy static metódust a dokumentációban, hogy ezt márpadigimplementálodmánazonnal ahelyett, hogy normálisan felépítenék az egészet, mindent visz. Úgy kell elképzelni az AR-t, mintha egy relációs adatbázisban a táblák a sorok és minden leírást tartalmazó cucc egy valamiben lenne (talán még az adatbázismotor is).
-
#905
Sk8erPeter
nagyúr
Speeedfire
#902
Sk8erPeter
nagyúr
válasz
Speeedfire
#902
üzenetére
"Persze, meg a juzer_id-hoz is."
Még elmondhatod tizenötször is, akkor sem lesz több értelme. Tervezési kérdés, és eleve nem helytálló olyanhoz kapcsolni a táblát, aminek köze nincs hozzá. A júzer felad egy hirdetést, aztán a hirdetéssel babrál, ezt a babrálást tartalmazza a másik tábla. Akkor mi értelme van a user id-hoz kapcsolni? Honnan a francból tudod, mondjuk a 100 hirdetése közül melyikkel babrált, ha nem tartalmazza a másik táblád a hirdetés id-ját?
Mindegy, nem foglak tovább győzködni, ha nem fogadod el, hogy csak szopatod magad ezzel a megvalósítással, és nehezen lesz lekérdezhető, továbbfejleszthető, akkor ez van."Ez igaz (kb 5x írtam már le, hogy igaz...), de nem a keresés fog dominálni az oldalon. Nem tudom máshogy leírni neked.
"
Már sokadszor írtam le más formában, de ez nem indokolja az igénytelenebb megvalósítást. Nem tudom máshogy leírni neked."A drupal.hu-t hanyagoljuk, mert ott a segítség nem erősség."
Ez sajnos sokszor helytálló (meg van kb. 10 ember, aki aktívan válaszol, és még ért is hozzá, bár néha a stílusuk nem valami simulékony), de ugyanez már kevésbé igaz a http://drupal.stackexchange.com/-ra. Ott a kérdések többségére tuti kapsz valami választ, hacsak nem túl komplikáltan fogalmazod vagy maga a kérdés nem teljesen egyedi/új problémát érint.
Szerk.: meg most már aktív a PH!-s Drupal topic is."De nagyobb is a biztonság, mert senki sem ismeri a kódot."
Hát erről a helyedben azért inkább nem lennék meggyőződve.![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#903
Peter Kiss
őstag
Speeedfire
#902
Peter Kiss
őstag
válasz
Speeedfire
#902
üzenetére
Az AR-t lehet ORM-nek nevezni, de nem az igazi.
-
#901
Peter Kiss
őstag
Speeedfire
#898
Peter Kiss
őstag
válasz
Speeedfire
#898
üzenetére
Azért, mert gyakorlatilag nem használt (nem feltétlenül szükséges lementeni) adat van az adatbázisban, egyszerűen felesleges.
-
#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.
-
#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.
-
#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.
-
#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á.
-
#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.
-
#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.
-
#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. -
#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.
-
#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 -
#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. -
#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.
-
#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á?
-
#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. -
#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. -
#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. -
#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.
-
#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) ?
-
#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.
-
#835
Speeedfire
félisten
Speeedfire
#834
Speeedfire
félisten
válasz
Speeedfire
#834
üzenetére
Kiszúrta a szemem...
-
#758
martonx
veterán
Speeedfire
#757
martonx
veterán
válasz
Speeedfire
#757
üzenetére
Hátha ez segít:
Ebből kimásolva egy példa:
ALTER TABLE tbl_name
ADD [CONSTRAINT [symbol]] FOREIGN KEY
[index_name] (index_col_name, ...)
REFERENCES tbl_name (index_col_name,...)
[ON DELETE reference_option]
[ON UPDATE reference_option] -
#634
Frigo
őstag
Speeedfire
#633
Frigo
őstag
válasz
Speeedfire
#633
üzenetére
primary key-hez nem kell az alsóvonás : PRIMARY KEY
-
#630
Frigo
őstag
Speeedfire
#629
Frigo
őstag
válasz
Speeedfire
#629
üzenetére
Próbáld meg frissíteni a phpmyadmin-t vagy tedd fel a legújabb Mysql workbenchet.
-
#628
Frigo
őstag
Speeedfire
#627
Frigo
őstag
válasz
Speeedfire
#627
üzenetére
Hát megnéztem amit begépeltél phpmyadminban meg mysql workbenchben egy teszt adatbázissal és működött mindegyikben. Biztos ,hogy az adatbázis nevét jól adtad meg ?
-
#626
Frigo
őstag
Speeedfire
#625
Frigo
őstag
válasz
Speeedfire
#625
üzenetére
Ja igen a mind a függvény végrehajtása mind a meghívás előtt válaszd ki a megfelelő adatbázist .Most próbáltam ki nálam működött rendesen.
-
#624
Frigo
őstag
Speeedfire
#623
Frigo
őstag
válasz
Speeedfire
#623
üzenetére
phpmyadminban a konzolnál bemásolod a függvény kódját ,majd ha végrehajtotta utána a :
CALL prefix_all(‘DATABASE-NAME’,'PREFIX’,0); paranccsal meghívod .A 'DATABASE-NAME' az adatbázisod neve ,a 'PREFIX' amit meg szeretnél adni prefixnek .Ha a végén 0-át adsz meg akkor törli a prefixet a táblák neve elől ha 1-et akkor elejére fűzi.De előtte mindenképp készíts mentést az adatbázisról . -
#622
Frigo
őstag
Speeedfire
#621
Frigo
őstag
válasz
Speeedfire
#621
üzenetére
Rosszul sejted
A tárolt eljárások a függvények SQL megfelelője. -
#620
Frigo
őstag
Speeedfire
#619
Frigo
őstag
válasz
Speeedfire
#619
üzenetére
A RENAME TABLE parancsal tudsz táblákat átnevezni csak vigyázz ,hogy mikor használod ne fusson semmilyen progi ami használja az adatbázist.Illetve ha ilyen sok tábláról van szó akkor érdemes hozzá tárolt eljárást írni ,erre ITT egy remek példa.
-
#618
Speeedfire
félisten
Speeedfire
#617
Speeedfire
félisten
válasz
Speeedfire
#617
üzenetére
Helyesen:
SELECT fid, count(fid) as mennyi FROM `linkek_tartalom`
group by fid
having count(fid) >= 10
-
#614
PazsitZ
addikt
Speeedfire
#612
PazsitZ
addikt
válasz
Speeedfire
#612
üzenetére
SELECT fid, COUNT(fid) FROM tabla GROUP BY fid
lassú vagyok -
#613
Sk8erPeter
nagyúr
Speeedfire
#612
Sk8erPeter
nagyúr
válasz
Speeedfire
#612
üzenetére
SELECT `tabla`.`fid` , COUNT(*) AS bejegyzesek_szama
FROM `tabla`
GROUP BY `tabla`.`fid`
Állítólag van benne, de én még nem leltem meg (igaz én csak GUI esetében használom)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Valószínűleg a kérdés arra irányult, hogy mi értelme van.
Új hozzászólás Aktív témák
- Bomba ár! HP ZBook 14 G8 - i7-1165G7 I 16GB I 512SSD I Nvidia 4GB I 14" FHD I Cam I W11 I Gari!
- Bomba ár! HP ProBook 640 G8 - i7-1165G7 I 32GB I 512GB SSD I 14" FULLHD I Cam I W11 I Gari!
- Bomba ár! Lenovo ThinkPad T495 - AMD Ryzen PRO 7 I 16GB I 256GB SSD I 14" FHD I Cam I W11 I Gari!
- Bomba ár! Lenovo ThinkPad T14 G1 - i5-10GEN I 16GB I 256SSD I 14" FHD I Cam I W11 I Garancia!
- Bomba ár! HP EliteBook 840 G7 - i5-10G I 16GB I 256GB SSD I HDMI I 14" FHD I Cam I W11 I Gari!
- GYÖNYÖRŰ iPhone 13 Pro 256GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3358
- Beszámítás! Apple iPad Pro 11 2024 1TB WiFi + Cellular tablet garanciával hibátlan működéssel
- Intel Core i5-9500 / i5-9500T / i7-8700 / i7-9700 CPU, processzor - Számla, garancia
- 123 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 - 4 év garancia (ELKELT)
- LG 27GS60QC-B - 27" Ívelt - 2560x1440 - 180Hz 1ms - AMD FreeSync - Bontatlan - 2 Év Gyári Garancia
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest