Új hozzászólás Aktív témák
-
#1572
Speeedfire
félisten
_ak_
#1571
Speeedfire
félisten
"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ó?"
De pont az a lényege, megmondod a model relációban, hogyan kapcsolódik össze a 2 model (tábla) és az alapján állítja össze az eredményhalmazt neked.Ha használ idegen kucsot akkor gyorsabb, nem tudom mysql alatt van-e végrehajtási terv, de ott észre lehet venni, hogy hash join alapján a select cost-ja nagyon kicsi lesz. Míg reláció nélkül lassabb a select.
A legjobban úgy tudod ezt kideríteni, hogy megnézed a framework, hogyan használja fel ezeket a relációkat, ha bemegy a db-be és bekérdezi a constraint-eket, akkor bukod, ha nem kérdezi meg, csak használja, amit a user megadott neki akkor nem.
-
#1570
Speeedfire
félisten
_ak_
#1569
-
#1555
Speeedfire
félisten
_ak_
#1554
Speeedfire
félisten
A kutya táblához is lehet kötni a usereket, attól függ mi a cél. A kutya tábla eredményhalmaza, vagy a users tábla.
A with szerintem biztos használható több táblára is. Azt már a model reláció résznél kell megadni, yii-ben ez a through kulcsszóval megy, laravel-re is biztos van hasonló.
Szerintem a Laraveles Eloquent az össze relációt felhozza neked.
-
#1553
Speeedfire
félisten
_ak_
#1552
Speeedfire
félisten
Nem ismerem a laravel-t, de a with opció mondja meg (legalábbis yii-ben így van), hogy mihez legyen kapcsolva és a model-ben írod le a kapcsolatot (inner, left, right stb.).
De egy egyszerű példa sql-ben.
table_a :
id : number
data: varchar2
table_b:
table_a_id : number
data: varchar2
select a.*
from table_a a
left join table_b b
on a.id = b.table_a_id
where a.data like '%valami%' or b.data like '%valami%'Összekötöd az a táblát a b táblával, ahol az a.id értéke megegyezik a b.table_a_id értékével. A feltétel részben pedig az a.data és a b.data mezőkre írsz like-ot. Az eredményhalmazban pedig kilistázza az összeset az a táblából.
Kereshetsz külön is, de akkor kell egy union all.
-
#1384
Speeedfire
félisten
Speeedfire
félisten
Linux alatt, hogy tudok mysql jelszót cserélni parancssorban? Szerintem valami program tegnap felülcsapta amit beállítottam, ma meg már nem megy.
Nem akar beengedni.
-
#963
Speeedfire
félisten
Peter Kiss
#962
Speeedfire
félisten
válasz
Peter Kiss
#962
üzenetére
Oh, hogy az a. Valóban, most esett le, amit PazsitZ írt, hogy a leszűrt halmaz.
Köszi srácok.
Úgy látszik késő van már nekem... -
#961
Speeedfire
félisten
Peter Kiss
#959
Speeedfire
félisten
válasz
Peter Kiss
#959
üzenetére
A 2. képen miért nem jeleníti meg a 18,19-es id-jú sorokat?
Illetve ha a limit 20, 50 akkor pedig a 25. id-val rendelkező az első nála.Ennyire rövid az agyam, hogy nem jól emlékszem a limitre?
Az első paraméter a kezdő érték, a második pedig, hogy az elsőtől kezdve mennyi rekordot jelenítsem meg. Vagy nem?
PazsitZ: Hát akkor marad a where. Bár nekem tényleg úgy rémlik, hogy a limit-tel is lehet így játszani.
-
#958
Speeedfire
félisten
Speeedfire
félisten
Úgy néz ki elfelejtek mindent...
Itt ezt nem értem, hogy mi van vele. Amikor az offsetet átállítom 15-re, akkor a 18,19-es id-jú sorok nincsenek ott. Miért?
Illetve más offset értékekkel is igen furcsa dolgokat ad vissza.
-
#955
Speeedfire
félisten
Sk8erPeter
#954
Speeedfire
félisten
válasz
Sk8erPeter
#954
üzenetére
Bezzeg ha te lennél a munkatársa...
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#944
Speeedfire
félisten
Lacces
#943
Speeedfire
félisten
1. Ott valami anomália lehet. Legjobb tudomásom szerint ilyen nincs. Ha rakunk bele értéket, csak akkor nő ez az érték.
2. Hát, pedig a legtöbben a join mellett vannak. 1 nagy lekérdezés, mint több kisebb. Én is inkább erre álltam rá. Kevesebb a generált adat a szerverről.
Szerintem minden esetben célszerű a join. -
#938
Speeedfire
félisten
Sk8erPeter
#937
Speeedfire
félisten
válasz
Sk8erPeter
#937
üzenetére
Nem referencia.
Csak leírtam, hogy én hogy teszteltem.
-
#936
Speeedfire
félisten
Sk8erPeter
#935
Speeedfire
félisten
válasz
Sk8erPeter
#935
üzenetére
Ott akkor szerintem valami nem kerek. Nálam az sqlbuddy gyorsabb, win7 64bit/wamp64bit alatt.
-
#928
Speeedfire
félisten
Sk8erPeter
#927
Speeedfire
félisten
válasz
Sk8erPeter
#927
üzenetére
Állítólag a php-n keresztül könnyen feltörhető. Nem tudom. Én csak mindig ezt hallom a linux guruktól*.
*webhostingosok
-
#926
Speeedfire
félisten
martonx
#924
-
#920
Speeedfire
félisten
Bishoop
#919
Speeedfire
félisten
a MYSQL és az INFORMATION_SCHEMA neműt nem lehet törölni. Ez normális?
Ezt csak az admin tudja szerintem törölni, attól függ milyen jogok vannak ezekre.Jó lenne ez a phpadmin, csak pl. a táblák közötti kapcsolatok megjelenítése elég pocsék.
Ha localhoston vagy használj msql workbench-et.Egyébként miért veszélyforrás a phpmyadmin? Ha localhoston fut akkor milyen biztonsági probléma lehet vele?
Localhoston nem sok veszélyforrás van. Élesben viszont könnyen feltörhető. -
#913
Speeedfire
félisten
Sk8erPeter
#910
Speeedfire
félisten
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.
-
#908
Speeedfire
félisten
Sk8erPeter
#905
Speeedfire
félisten
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. -
#904
Speeedfire
félisten
Peter Kiss
#903
Speeedfire
félisten
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.
-
#902
Speeedfire
félisten
Sk8erPeter
#900
Speeedfire
félisten
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...
-
#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. -
#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.
-
#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.
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);
} -
#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.
-
#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 -
#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. -
#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.
-
#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.
-
#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.
-
#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. -
#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.
-
#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á?
-
#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 -
#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. -
#853
Speeedfire
félisten
martonx
#852
-
#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
} -
#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.
-
#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á? -
#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?
-
#757
Speeedfire
félisten
Speeedfire
félisten
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.
-
#633
Speeedfire
félisten
Speeedfire
félisten
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
-
#627
Speeedfire
félisten
Frigo
#626
Speeedfire
félisten
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 -
#625
Speeedfire
félisten
Frigo
#624
Speeedfire
félisten
-
#619
Speeedfire
félisten
Speeedfire
félisten
Hogy lehet táblákat átnevezni? Konkrétan van kb 100 táblám, aminek prefixet akarok adni.
-
#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
-
#615
Speeedfire
félisten
Sk8erPeter
#613
Speeedfire
félisten
válasz
Sk8erPeter
#613
üzenetére
Köszi mindkettőtöknek.
-
#612
Speeedfire
félisten
Speeedfire
félisten
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
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Apple MacBook
- Nvidia GPU-k jövője - amit tudni vélünk
- Samsung Galaxy A55 - új év, régi stratégia
- Allegro vélemények - tapasztalatok
- WLAN, WiFi, vezeték nélküli hálózat
- Forradalomi előrelépésként jellemzi az NVIDIA a DLSS 5-öt
- Kerékpárosok, bringások ide!
- Luck Dragon: Asszociációs játék. :)
- Samsung Galaxy Felhasználók OFF topicja
- Horgász topik
- További aktív témák...
- AKCIÓ! ASRock A520M R5 5500 8GB DDR4 250GB SSD GTX 1050 Ti 4GB Sharkoon RGB Slider 400W
- Telefon felvásárlás!! Samsung Galaxy A13/Samsung Galaxy A33/Samsung Galaxy A53
- í kilenc! AKCIÓS PRECÍZIÓS KÉSZÜLÉK! 7560 i9-11950H 32GB RAM 1TB SSD Nvidia RTX A3000 6GB 1 év gar
- Lenovo T14S Thinkpad FHD IPS i5-1135G7 16GB RAM 256GB SSD Intel Iris XE Graphics Win11 Pro Garancia
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7500F 32/64GB RAM RTX 5060 Ti 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest