- iPhone topik
- Xiaomi Smart Band 10 - a hetedik napon megpihen
- Megjött a jubileumi Pixel széria
- Milyen okostelefont vegyek?
- Poco F7 Pro - jó, de az amatőr sem rossz
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Hitelesítették az S26 Ultra csalódást keltő telepét
- Huawei Mate 10 Pro - mestersége az intelligencia
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Samsung Galaxy Ring - gyűrű-kúra
Új hozzászólás Aktív témák
-
#1000
Sk8erPeter
nagyúr
laracroft
#998
Sk8erPeter
nagyúr
válasz
laracroft
#998
üzenetére
Szerintem ezzel van a para:
....
(select ......, LEIRAS
from NAPLO
where a.LEIRAS like '%Helyszínen%') as a
union
(select ...., LEIRAS
from NAPLO
where b.LEIRAS like '%Leellenõrizve%') as b
....az a.LEIRAS és b.LEIRAS mezőkre gondolok, így nem hivatkozhatsz rájuk, mert az alquery-ben nem ismeri a MySQL, hogy mi az az "a" meg mi az a "b".
Az alquery-n, a zárójeles részben belül szerintem nem is kell az alias, vagy ha mégis, akkor jó helyre írd az aliast, például:(select ......, LEIRAS
from NAPLO n1
where n1.LEIRAS like '%Helyszínen%') as aRemélem nagyjából érthető, mire gondolok.
Ja, bocs, most néztem tovább, tényleg, tuti, hogy az IF is szar.
De mondjuk sokat segített volna, ha bemásolod a konkrét hibaüzenetet, hogy mire hivatkozik.
Szerintem CASE-t kéne használnod:
http://dev.mysql.com/doc/refman/5.0/en/case.htmlNa, ha nem sikerül, megnézem normálisabban is, most ennyire tellett.
-
laracroft
senior tag
Sziasztok!
Előre is bocs, ha nem egyértelmű mit szeretnék, de próbálok világosan fogalmazni
Van egy NAPLO táblám, aminek a LEIRAS mezőjében szeretném megszámolni hányszor szerepel ez a 2 szó: Helyszínen és Leellenõrizve.
A ügyfelet egyértelműen az ACCOUNT és a LINE mező azonosítja. Az IDO mező datetime típusú.
1 bejegyzésben csak az egyik szó szerepelhet, de előfordulhat, hogy egymás utáni bejegyzésekben szerepel a 2 szó ugyanannál az ügyfélnél.Feltétel:
Ha mindkét szó szerepel egy ügyfélnél, akkor nézze meg, hogy a két bejegyzés között eltelt idő több-e mint 15 perc.
Ha igen számolja 2-nek,
ha nem -tehát a 2 bejegyzés között kevesebb mint 15 perc van- akkor csak 1-nek.Ezzel próbálkoztam, de syntax error-okba futok
select ACCOUNT, LINE, IDO, LEIRAS
from (
(select ACCOUNT, LINE, IDO, LEIRAS
from NAPLO
where a.LEIRAS like '%Helyszínen%') as a
union
(select ACCOUNT, LINE, IDO, LEIRAS
from NAPLO
where b.LEIRAS like '%Leellenõrizve%') as b
)
where if(a.ACCOUNT = b.ACCOUNT and a.LINE = b.LINE) then timestampdiff(minute, a.IDO, b.IDO) > 15
group by ACCOUNTelőre is köszi!
-
#997
laracroft
senior tag
Apollo17hu
#995
laracroft
senior tag
válasz
Apollo17hu
#995
üzenetére
Köszi a válaszokat és a helyesírási tanácsot is
-
#996
Sk8erPeter
nagyúr
Apollo17hu
#995
Sk8erPeter
nagyúr
válasz
Apollo17hu
#995
üzenetére
"aposztróf kell, nem?"
Alapértelmezésben tök mindegy, ez MySQL.
http://dev.mysql.com/doc/refman/5.0/en/string-literals.html(#992) laracroft :
"egyenlőre" ----> "egyelőre"
-
#995
Apollo17hu
őstag
laracroft
#992
Apollo17hu
őstag
válasz
laracroft
#992
üzenetére
Nem tudom leellenőrizni a szintaktikáját, de én így csinálnám (aposztróf kell, nem?):
SELECT t.leiras
,COUNT(*) || ' db'
FROM naplo AS t
WHERE
t.ido BETWEEN '2012-11-01' AND '2012-11-25'
AND t.leiras LIKE '%0-_s%'
GROUP BY t.leirasvagy így, ha 100 felett még menne akár millióig, de azokra nincs szükséged:
SELECT t.leiras
,COUNT(*) || ' db'
FROM naplo AS t
WHERE
t.ido BETWEEN '2012-11-01' AND '2012-11-25'
AND (t.leiras LIKE '%10-es%'
OR t.leiras LIKE '%20-as%'
OR t.leiras LIKE '%30-as%'
OR t.leiras LIKE '%40-es%'
OR t.leiras LIKE '%50-es%'
OR t.leiras LIKE '%60-as%'
OR t.leiras LIKE '%70-es%'
OR t.leiras LIKE '%80-as%'
OR t.leiras LIKE '%90-es%'
OR t.leiras LIKE '%100-as%')
GROUP BY t.leiras -
laracroft
senior tag
Sziasztok!
Van egy lekérdezésem, amit bizonyos időközönként le kell futtatnom:
select * from NAPLO where LEIRAS like "%10-es%" and IDO between "2012-11-01" and "2012-11-25"
select * from NAPLO where LEIRAS like "%20-as%" and IDO between "2012-11-01" and "2012-11-25"... és így tovább 100-ig.
Igazából arra vagyok kíváncsi, hogy a megadott időintervallumban hány darab ilyen esemény volt.
Ezt egyenlőre csak 10 különálló lekérdezéssel tudom megoldani.Valahogy egyszerre szeretném lefuttatni a lekérdezést úgy, hogy ehhez hasonló eredményt kapjak:
10-es eset : 500 db
20-as eset: 4002 db
30-as eset: 102 db
...előre is köszi!
-
#991
Sk8erPeter
nagyúr
MadarasTESCO
#990
Sk8erPeter
nagyúr
válasz
MadarasTESCO
#990
üzenetére
És milyen megoldást választottatok?
Amúgy üzenem a tanárnak, hogy elég rosszak a pedagógiai módszerei.![;]](//cdn.rios.hu/dl/s/v1.gif)
Szerintem ez rohadtul nem kezdőknek való feladat, és messze áll attól, ami a gyakori adatbázis-kezeléshez kell. Ezerszer értelmesebb lenne táblák megtervezésével, összekapcsolásával kapcsolatos feladatot adni...
Nagyon tud irritálni, amikor egy tanár a diákok kedvét még idejekorán elveszi az informatikától. -
#990
MadarasTESCO
csendes tag
Sk8erPeter
#989
MadarasTESCO
csendes tag
válasz
Sk8erPeter
#989
üzenetére
kösz, kiagyaltuk már.
-
#989
Sk8erPeter
nagyúr
MadarasTESCO
#985
Sk8erPeter
nagyúr
válasz
MadarasTESCO
#985
üzenetére
A legprimitívebb, legegyszerűbb megoldás talán ez lehet egy random rendszám kidobálására:
SELECT CONCAT(
CHAR(65+MOD(ROUND(RAND()*100),26)),
CHAR(65+MOD(ROUND(RAND()*100),26)),
CHAR(65+MOD(ROUND(RAND()*100),26)),
'-',
FLOOR(100 + RAND() * (900))
) AS 'rendszam' -
#987
Sk8erPeter
nagyúr
MadarasTESCO
#985
Sk8erPeter
nagyúr
válasz
MadarasTESCO
#985
üzenetére
Most csak rohanva írok, úgyhogy csak részsegítség, de a háromjegyű szám generálása (a magyar rendszám második feléhez) elég egyszerű, lásd [link]:
"To obtain a random integer R in the range i <= R < j, use the expression FLOOR(i + RAND() * (j – i)). For example, to obtain a random integer in the range the range 7 <= R < 12, you could use the following statement:
SELECT FLOOR(7 + (RAND() * 5));
"Szóval például:
SELECT FLOOR(100 + RAND() * (900)) AS szamok
Ezt persze még konkatenálni kéne a háromjegyű, angol ábécéből generált random stringgel, meg a kötőjellel (mármint ezek a szám elé mennek), meg 15 ezer db-ot mindebből ledarálni. Biztos a tanár meg akarta oldani, de nem sikerült neki, ezért rátok bízza a piszkos munkát. -
#986
lakisoft
veterán
MadarasTESCO
#985
lakisoft
veterán
válasz
MadarasTESCO
#985
üzenetére
Ha valamiben elakadsz és forráskódot kell nézni abban szivesen segítek. De nem oldom meg helyetted a feladatod.
-
#985
MadarasTESCO
csendes tag
MadarasTESCO
csendes tag
szevasztok
kaptam egy feladatot, mert berágott a tanár amiért a csoport f@szbúkozott órán, és ennek én is megszívom a levét. ha nincs kész, vagy legalább valami próbálkozás akkor meghúz engem is mert én is a scoport tagja vok. nem értek sokat az SQL-hez, kb egy-két hete kezdtünk el foglalkozni vele. a feladat az hogy sql paranccsal mySQL-ben ki kell iratni 15000 random generált magyar típusú rendszámot, úgy hogy ne legyen két ugyanolyan. aki tudja a megoldást kérem írja le a parancsot. és magyarázza el mi micsoda. aki nem tudja a kérdésre a választ csak bele akar szólni a dologba, pl hogy miért fb-ztek órán miért nem figyeltek oda, az kérem ezeket tartsa meg magának. holnapra kéne a dolog. pls HELP. előre is köszönöm.
-
PazsitZ
addikt
Jobban megnézve tévedtem. A TYPE helyett ENGINE kell, ez volt a hiba.
Azt meg nem is tudtam, hogy így lehet auto increment-et inicializálni.
CREATE TABLE `members` (
`id` INT( 4 ) NOT NULL AUTO_INCREMENT ,
`username` VARCHAR( 65 ) NOT NULL DEFAULT '',
`password` VARCHAR( 65 ) NOT NULL DEFAULT '',
PRIMARY KEY ( `id` )
) ENGINE = MYISAM AUTO_INCREMENT = 2; -
wmati
addikt
Ezzel mit tudok kezdeni ?
SQL-lekérdezés:
CREATE TABLE `members` (
`id` INT( 4 ) NOT NULL AUTO_INCREMENT ,
`username` VARCHAR( 65 ) NOT NULL DEFAULT '',
`password` VARCHAR( 65 ) NOT NULL DEFAULT '',
PRIMARY KEY ( `id` )
) TYPE = MYISAM AUTO_INCREMENT =2;A MySQL mondta:
#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 'TYPE=MyISAM AUTO_INCREMENT=2' at line 6
-
#979
lakisoft
veterán
Sk8erPeter
#978
lakisoft
veterán
válasz
Sk8erPeter
#978
üzenetére
Meg kell írni a hiányosságokat a fejlesztőcsapatnak hátha ráharapnak és megcsinálják.
-
#978
Sk8erPeter
nagyúr
PazsitZ
#976
Sk8erPeter
nagyúr
"user letrehozas, komplett elore konfiguralt jogosultsag szintekkel van. "
Hol?
Csak gyorsan végigkattintgattam, simán lehet, hogy elkerülte a figyelmemet, de én nem találtam."Tomoritett fajl import nem tudom van-e alapbol, de nem tudom miert akkora gond ez."
Nem értem a kérdést. Hogyhogy miért gond? Ha egy tömörített dumpot akarok importálni, akkor már hogyne lenne gond?
Ha phpMyAdminban meg tudták oldani, nem igazán értem, itt miért nem. De már a felvetésedet sem igazán látom be, hogy miért ne lenne gond."A grafikus query osszeallitot meg hagyjuk mar, elhiszen, h lehet vele jot jatszani, de azon tul..."
Azontúl is nagyon hasznos, sokszor jóval gyorsabb, mint kézzel megírni egy rohadt komplex query-t. A gyakorlatban is vettem már hasznát pl. dbForge-nál, amikor tényleg nagyon sok táblát kellett összekapcsolni egy számtalan paramétert, beállítást összekapcsoló query-hez.
Gondolom azért mondod, hogy csak játékra jó, mert nem volt még olyan igény, amire hasznát vehetted volna. Ettől még nem kell ilyen szélsőséges kijelentést tenni, mert számolhatnál azzal is, hogy nincs igazad. Még mindig jobb egy elég jól összepakolt, rohadt nagy query-t átírni pár helyen, mint kézzel, hibákkal lepötyögni a teljeset mindenféle segítség nélkül.
Talán ha kipróbálnád egyszer...(#977) lakisoft : OK.
-
#977
lakisoft
veterán
Sk8erPeter
#975
lakisoft
veterán
válasz
Sk8erPeter
#975
üzenetére
Nem azt mondtam rá hogy tökéletes hanem hogy jól használható.
-
#976
PazsitZ
addikt
Sk8erPeter
#975
PazsitZ
addikt
válasz
Sk8erPeter
#975
üzenetére
user letrehozas, komplett elore konfiguralt jogosultsag szintekkel van. Szerintem korabban is volt.
Tomoritett fajl import nem tudom van-e alapbol, de nem tudom miert akkora gond ez.
A grafikus query osszeallitot meg hagyjuk mar, elhiszen, h lehet vele jot jatszani, de azon tul... -
#975
Sk8erPeter
nagyúr
lakisoft
#974
Sk8erPeter
nagyúr
válasz
lakisoft
#974
üzenetére
Na, megnéztem.
Nagyon kíváncsi lennék: szerinted konkrétan miben fejlődött "nagyon sokat"?
Nagyjából semmi különbséget nem láttam ahhoz képest, mint amikor legutóbb próbáltam.
Még új júzert sem lehet hozzáadni, jogait menedzselni, pedig azt még a korábban mutatott, böngészőben kezelhető DBNinjával is lehet, persze nem is beszélve a phpMyAdminról, ahol elég normálisan van ez is megoldva.
Mondjuk az tetszik, hogy ott van a táblákra jobb klikkelve a "Select Rows - Limit 1000", tehát hogy nem kell külön rányomni a query futtatására, mint a DBNinjában, de asszem ez elég alapvető elvárás. Meg a phpMyAdminban azt is be lehet állítani, hogy egy átlagos selectnél defaultból hány rekordot kérdezzen le (tök hülye számokat is be lehet állítani, pl. 37).
A rekordok szerkesztése viszont tényleg kényelmes.
Az is tetszik, ahogy pl. egy UPDATE vagy INSERT query összeállításában segít, hogy mutatja a default értékeket is: http://i.imgur.com/32k8O.png.
De mondjuk elvileg még ez is alapvető elvárás lehet egy ilyen proginál (még ha ingyenes is).
Az is jó, hogy a szintaktikai hibákat egyből jelzi az editorban - ez sem egy hű de nagy valami.
DE ami kifejezetten hiányzik, hogy én nem találtam grafikus alapú query-összeállítót, ami van a dbForge Studio for MySQL-ben - persze utóbbi nyilván többek közt ezért sem ingyenes. Habár most ugrik be, az Microsoft SQL Server 2012 Express-ben található SQL Management Studio is tök ingyenes, mégis tudja ezt... (lehet, hogy most jön a hivatkozási alap, hogy a Microsoftnak több a tőkéje)Ami viszont szerintem alapvető elvárás, az a korábban említett user-létrehozás, meg az, hogy importálni lehessen normálisan a MySQL dumpokat, a tömörített változatokat is (.gz), mint ahogy phpMyAdminban tök egyszerűen lehet is, kb. három klikk. De itt csak olyat találtam, hogy meg lehet nyitni egy .sql-fájlt, és azt le is lehet futtatni (OK, végül is így importálhatom a rekordokat), DE a tömörített állományokat (.gz) már el sem fogadja. Hát ez mi?
Szóval én ezek miatt nem vagyok túlságosan elragadtatva a MySQL Workbench-től, mert a böngészőalapú phpMyAdmin az alapvető, elvárható funkciókból (lásd utóbbi kettő) még mindig többet tud, még ha lassabb is.
-
#974
lakisoft
veterán
Sk8erPeter
#972
lakisoft
veterán
válasz
Sk8erPeter
#972
üzenetére
Nyugodtan nézd meg szerintem nagyon sokat fejlődött korábbi verzióihoz képest.
-
#973
Sk8erPeter
nagyúr
Sk8erPeter
#972
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#972
üzenetére
Most látom, itt az 1-es pontban lévőt félreérthetően írtam, az SQL Management Studio-ban azért annyiból is sokkal jobb a dolog, hogy van lehetőség mondjuk az első 1000 sor listázására, nem kell külön rámenni, hogy na akkor ezt a query-t futtasd. Itt meg úgy működik, hogy ráklattyolsz a Use in Query > Selectre, aztán van egy külön gomb a query futtatására. Idegesítő ez a szükséges plusz felesleges kör.
-
#972
Sk8erPeter
nagyúr
Peter Kiss
#968
Sk8erPeter
nagyúr
válasz
Peter Kiss
#968
üzenetére
Köszi az ajánlást, ezt kipróbáltam, és tényleg meglepően gyors! Ráadásul elég modern a felülete (ahogy a cikkben is kiemelik), egész kényelmes és intuitív a kezelése.
Ami engem zavar, és elég gyorsan feltűnt, az első pár perc tesztelgetés után:
1.) táblákra kétszer rákattintva először a struktúráját mutatja, ami még önmagában nem lenne gáz, de magához a tartalmához viszont kénytelen vagyok az SQL Management Studio-hoz hasonlóan rákattintani jobb gombbal, majd Use in Query menüben kiválasztani a Selectet. Pedig tesztelésnél van, hogy inkább azt szeretném megnézni, hogy mi a táblák tartalma, a struktúráját meg alapvetően elég kevésszer módosítom.
2.) amikor az előbb említett Use in Query > Select menüpontot kiválasztom, akkor a hosszú, legörgetett táblalistában felugrik magának az adatbázisnak a nevére, igazából itt a bal oldali hasáb görgetési állapota nem tudom, miért nem tud független lenni a jobb oldalitól, miközben úgyis AJAX-szal töltődik be a tartalom, miért kell, hogy felugorjon a fókusz az adatbázis nevére. Ez nagyon zavaró tud lenni, ha ismét ugyanazon a táblán akarsz valami műveletet végezni, és már megint scrollozhatsz le a listában.
3.) a query-k összepakolásánál hiányolom azt, ami megvan phpMyAdminban: a query összeállításánál felkínált lista a mezők nevével, amire elég csak rákattintani, és bedobja a textarea-ba.Ettől függetlenül elég ígéretes, és tényleg nagyon gyors. De azért sztem a fentiekben még fejlődnie kell, mert elég alapvető igények (nem?).
Egyébként hol tárolja az elmentett dolgait? Nem kér külön adatbázist, táblák beállítását, mint mondjuk a phpMyAdmin. localStorage-ban vagy ilyesmi?============
(#969) lakisoft :
Már elég rég használtam, de a MySQL Wordbench a dbForge Studio for MySQL-hez képest elég sok mindenben elmaradt, sok mindent hiányoltam belőle. Most nincs előttem, nem ugrik be hirtelen, mik voltak ezek, de a query-k összepakolása a dbForge-ban iszonyat kényelmes, míg a MySQL Workbench-ben nem nagy szám, nem lehet olyan szépen összerakni komplexebbeket.
Az is hozzátartozik viszont, hogy a dbForge nem ingyenes. -
#969
lakisoft
veterán
Sk8erPeter
#967
lakisoft
veterán
válasz
Sk8erPeter
#967
üzenetére
És mi a helyzet a MySQL Wordbench-el? Nekem ez tökéletesen bevált, eddig.
-
#968
Peter Kiss
őstag
Peter Kiss
őstag
http://www.sitepoint.com/dbninja-mysql-client/ - egy próbát talán megér.
-
#967
Sk8erPeter
nagyúr
martonx
#966
Sk8erPeter
nagyúr
Hát nem tudom. Sajnos az általad ajánlott Toad for MySQL sem jobb az én tapasztalataim alapján.
Nem biztos, hogy a phpMyAdmin okolható az általa tapasztalt probléma miatt (pl. arról nem esett egy szó sem, hogy kipróbálta-e simán, konzolról). -
syC
addikt
Sziasztok!
Egy kis segitség kellene. Bizotsan hibás a szintaktikám, valaki átnézné?
CREATE TRIGGER teszt_trigger1
after insert ON hirdetesek
FOR EACH ROW BEGIN
IF new.ccm=0 and new.nev like '% _._ %' -- Ha ccm értéke 0 és a nev sztringben van olyan 3 karakteres sztring aminek a 2. karaktere pont
SET @ccm=SUBSTRING(new.nev,LOCATE(new.nev,'.')-1 for 3); --@ccm változóba másold be
IF (IsNumeric(@ccm[0]) and IsNumeric(@ccm[2])) --ha a @ccm változó első és harmadik karaktere szám
INSERT INTO tr_teszt (ccm) VALUES(new.keres_azon,CAST(@ccm as FLOAT)*1000,'0','0'); -- illeszd be a tr_teszt.ccm cellába, floatként ezres szorzóval ( tehát 1.8 -> 1800 )
END IF;
END IF;
END;Köszi
-
#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... -
#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) -
#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. -
#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.
-
#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.
-
#957
Sk8erPeter
nagyúr
Speeedfire
#955
Sk8erPeter
nagyúr
válasz
Speeedfire
#955
üzenetére
-
#955
Speeedfire
félisten
Sk8erPeter
#954
Speeedfire
félisten
válasz
Sk8erPeter
#954
üzenetére
Bezzeg ha te lennél a munkatársa...
-
Lacces
őstag
Aha, köszönöm a válaszokat. Csak számomra mindig olyan érdekes, hogy rám szólnak, hogy bontsam szét selectre, és ne Joinoljak. Ezért is tettem fel a kérdést, mert ez számomra furcsa volt itt. És néha van egy olyan érzésem, hogy rossz szokásokat vernek belém.
Meg szerintem a Join esetében kevesebb szerver oldali kódot kell írni.
Vannak még itt furcsaságok... külső kulcs használata is ritka, normálfomákkal is alig találkozom.Aham a tranzakció rollback... Most ahogy néztem a folyamatot nekem is ilyen tűnt fel.
NoSQL számomra mindig is érdekes téma volt, mindig minden félét olvasok róluk. Nem sértődtem meg nagyúr
. Jahm, most legalább rádöbbentem, hogy mennyi hiányoságom van még ilyen téren. És a saját webes projekteknél jobban össze kell kapnom magam . -
#952
martonx
veterán
Peter Kiss
#951
martonx
veterán
válasz
Peter Kiss
#951
üzenetére
megelőztél, tökéletesen egyetértek.
A több select használata, és az azokból szerver oldalon eredmény összeidétlenkedése tipikus SQL-ezni nem tudó programozói attitűd. Ezek nem hogy gyorsítanak, de brutálisan lassíthatják az adatfeldolgozást. -
modder
aktív tag
Nem tudom neked mit tanítottak RDBMS-ekkel kapcsolatban egyetemen, de ha érdekel a téma, akkor tényleg érdemesebb lenne előbb jobban utána járni.
Ez a "jobban kedvelik szétbontani több szelektre egy join-t" hát ez rohadt sokmindentől függ. pl attól, hogy abban a rendszerben, amit átvettél fingjuk nem volt mi fán terem az sql, ezért a legegyszerűbb módszerhez folyamodtak, amit még ismertek. Egy megfelelően indexelt, nagy adathalmaznál (értsd: több millió sor) particionált táblákból álló relációs adatbázisban 3 tábla joinja gyorsabb lesz, mint 3 szelekttel lekérdezni. Nem illik okosabbnak lenni az adatbázisnál.
"NoSQL majdnem minden esetben gyorsabb az relációs adatbázisnál" -- ez is hatalmas tévhit. Még elosztott rendszerben is. nézd meg pl az alábbi cikket
Twitter, PayPal reveal database performanceNoSQL-re szeritem áttérni két szélsőséges esetben érdemes:
-- elosztott az alkalmazásod, több szerveren fut, és sokkal több írás történik az adatbázisba, mint lekérdezés (facebook eset)
-- több szerveren fut az alkalmazásod, és ki akarod használni az elosztott "NoSQL" (bár nem ugyanazt jelenti) által alapból nyújtott terheléselosztást anélkül, hogy bajlódni szeretnél egy MySQL clusterezéssel.Az, hogy mitől lehet lassú egy relációs adatbázis sokmindentől függ: rosszul megtervezett indexek, rosszul megtervezett lekérdezések, rossz particionálás, table lock használata írásnál sok írás mellett (érdemes inkább optimistic locking-ot használni)
Az autoincrement pedig azért is ugorhat, mert tranzakció végén rollback volt, új adat nem került beszúrásra véglegesen, de az auto increment érték nőtt.
-
#949
Sk8erPeter
nagyúr
Lacces
#943
Sk8erPeter
nagyúr
"2. Úgy vettem észre webes gyakorlatban, hogy a JOIN-lást nem nagyon szeretik. Számomra egyetem után meglepő volt, hogy inkább használjunk 3 SELECT-et, amit a szerver oldalon úgy mond összeállítunk és kérdezgetünk le WHERE ID = .... konstrukcióval, ez jobbnak tűnik, mint ha 3 táblát össze JOIN-olnék."
Ki mondta ezt a baromságot? Egyébként nyilván esetfüggő, milyen query-t érdemes használni, nincs erre általános recept.
De az egyszerűen hatalmas hülyeség ebben a formában, hogy jobb 3 különböző select, mint mondjuk egy értelmesen összerakott join.(#947):
"Lehet már tényleg kellene írnom e kettő adatbázis rendszerről, és megírni a személyes véleményt."
Most mindenféle bántás nélkül, a hozzászólásaidból, kérdéseidből az derül ki, hogy nem igazán vagy még kellően tájékozott ahhoz, hogy cikket írj a témáról, hogy átfogó összehasonlítást tudj ezekről írni. Ehhez komoly háttértudás, tapasztalat kell, és kellő magabiztosság, különben nagyon nagy eséllyel csak téves vagy ingatag információkat fogsz megosztani a publikummal, vagy az állításaid nagy része pusztán spekuláció, saját vélemények, érzésekre hagyatkozás megfogalmazása lenne, aminek meg nem túl sok értelme van szakmailag.
Én személy szerint nem venném a bátorságot ilyen összehasonlító cikk megírására (mostani tudásom egyszerűen nem elég hozzá), főleg, ha olykor láthatóan alapfogalmakkal nem lennék tisztában. -
PazsitZ
addikt
1.
Azt tudom elképzelni, hogy id-val lett beszúrva a 16588-as id-jű sor. Így az increment érték onnan folytatódik.
Magától nem ugrál
2.
Rendes indexelés tábla reláció mellett, 3 tábla összekapcsolása nem szabad, hogy gondot jelentsen.De alap esetben nézzük mit csinálhatsz.
Legyen product, category, region táblák.Lekéred az aktív product-okat.
Kapsz mondjuk 5000 rekordot. Ekkor a kategória lekérdezés WHERE IN -be sűríteni 250 id-t, a régió lekérdezésbe 2000 id-t elég fura megoldás.
Teljes kategória és régió táblalekérdezése és szerverkód általi összepárosítása megint csak fura megoldás.Kis adathalmaznál persze logikusabbnak tűnhet a WHERE IN. Viszont ilyenkor egy indexelt tábla JOIN is gyorsabb.
Speciálisabb esetekben elképzelhető, hogy optimalizálhatóak szétbontva egyes lekérdezések, de ez nem általános szvsz.
-
#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) -
#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. -
Lacces
őstag
Sziasztok!
Lenne 2 érdekes téma, amellyel a melóhelyen találkoztam.
1. Mitől lehet, hogy az autoincrement érték megugrik? 16585 után 16588 szerepl, és nem volt törlés az adatbázisban, nincs hozzá admin felület, én meg nem piszkálom meg az éles adatokat...
Ha tényleg kizárjuk azt, hogy nem lehet törölni belőle adatot, meg eshet, hogy magától megugrik a számozás? Esetleg szerver leállástól lehet ez?2. Úgy vettem észre webes gyakorlatban, hogy a JOIN-lást nem nagyon szeretik. Számomra egyetem után meglepő volt, hogy inkább használjunk 3 SELECT-et, amit a szerver oldalon úgy mond összeállítunk és kérdezgetünk le WHERE ID = .... konstrukcióval, ez jobbnak tűnik, mint ha 3 táblát össze JOIN-olnék.
Ez bevett szokás? Egyébként úgy vettem észre, hgoy 3 SELECT-re szét bontva tényleg van sebesség növelés, bár nem mindig figyeltem. (Bár az is igaz, hogy egyetemen még a LIMIT áldásos hatását sem mutatták meg)
Mikor célszerű egy webes alkalmazásnál össze JOIN-olni esetleg IN - alapú feltétel keresést használni, mint SELECT-ekre szét bontás? -
sonar
addikt
Sziasztok,
Egy kis restore/backup témával fordulnék hozzátok.
Valaki álmosabb volt a kelleténél és Select helyett Delete-vel kicsapott pár recordot.
Nem nagy gond mert van napi Backup. Viszont ha azt állitom vissza akkor a mai napi meló 90%-a elveszik.
Ezért egy másik adatbázisba visszatoltam a backupot és lefutattam a query-t (helyesen), export majd notepad++ szal megszerkesztettem és visszatoltam a helyes adatbázisba.
Szerencsém volt mert csak 50 rekordról volt szó.
Szóval lehet valahogy úgy exportálni egy query-t, hogy azt egyből bele tudjam tölteni a megfelelő táblába? -
#938
Speeedfire
félisten
Sk8erPeter
#937
Speeedfire
félisten
válasz
Sk8erPeter
#937
üzenetére
Nem referencia.
Csak leírtam, hogy én hogy teszteltem. -
#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? -
#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.
-
#935
Sk8erPeter
nagyúr
Sk8erPeter
#933
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#933
üzenetére
Meglepődve tapasztaltam localhostos tesztelés után, hogy a phpMyAdmin jóval gyorsabban töltődött be az SQL Buddy-nál is, amit pedig elvileg alternatívaként szoktak ajánlani, mondván, hogy gyorsabb, mint a phpMyAdmin.
Most már tényleg kicsit átértékeltem a phpMyAdminnal szemben érzett erős fenntartásaimat.
Épp úgy általában is elég lassan töltődik be nálam a MySQL, de az SQL Buddy-t előbb is indítottam el, de még mindig nem töltött be, a phpMyAdminnal meg már egy query-t is lefuttattam. Elég furcsa, hogy ennyit szarakodik az SQL Buddy. -
lakisoft
veterán
Sziasztok,
Aki hasonló témában dolgozik várom szeretettel:
MSSQL, SQLSERVER, T-SQL, SYBASE adatbázisfejlesztők, DBA-k, üzemeltetők ide -
#933
Sk8erPeter
nagyúr
martonx
#932
Sk8erPeter
nagyúr
"Teljesen érthető, amikor valaki felrak egy wampp-ot (linuxra érthető, windowsra minden esetben felelsleges)."
He? Nem értem a gondolatmenetet.
Ha Linuxban konzolon rámész, hogy mondjuk telepíteni akarod a phpmyadmint, akkor az összes függőséget is behúzza.
Windows-on meg végül is a külön telepítős macerát oldja meg az egyben telepítős módszer, ahogy a XAMPP is.
A WAMPP mozaikszóban az első pedig a Windows-t jelenti, de gondolom ezt nem kell külön mondanom. Akkor hogy érted, hogy Windows-ra ez felesleges?
Mondjuk Windows-on én még mindig IIS+Web Platform Installer-párti vagyok, ott is behúzza a függőségeket, és számomra tisztább megoldás. Meg értem én, hogy live serverhez hasonló környezetet akar valaki felrakni, ami esetek többségében Apache-on lesz, ez elfogadható érv, de én sokszor inkább a tájékozatlanságnak tudom be, hogy nem használnak az emberek PHP-zésre IIS-t Windows-on.Most kipróbáltam az általad javasolt Toad for MySQL-t, mert eddig nem tettem, de én sok alapvető dolgot nem találtam meg így elsőre, vagy csak nem kézenfekvő helyen van.
Ilyenek, mint az adatbázis egyszerű átnevezése, adatbázis tartalmának egy klikkre történő átmásolása vagy éppen mozgatása másik adatbázisba. Lehet, hogy ezt exportálni kell először egy scriptbe, és aztán behúzni, de nehogy már... ez phpMyAdminban egyből ott van az arcodba tolva, beírod az új db nevét, és megcsinálja, no para. Be lehet állítani, hogy egyből át is váltson arra az adatbázisra. Aztán továbbmenve importálási lehetőség. Ez miért nincs egyből jól látható helyen? Egyáltalán hol van? Biztos csak türelmetlenül futottam át rajta, de ez azért eleve nem tetszik, hogy nincs ott, egyértelmű helyen. Aztán diagramok létrehozásánál pattog, hogy túl sok a tábla, egy beállítás korlátozza. Miért nem kérdezi meg egyből, mennyi táblára akarom korlátozni épp a megjelenítést? A sokat szidott phpMyAdmin "Diagram" opciójára kattintva egyből kirajzolja az összes táblát, még ha rengeteg is van, aztán ezeket ki lehet szedni, és utólag korlátozni, melyek jelenjenek meg, így gyorsan lehet relationt létrehozni táblák közt.Kezdem átértékelni, hogy mégsem akkora fos ez a phpMyAdmin.
Amúgy nekem a dbForge Studio for MySQL jött be, de arra meg ugye korlátos az ingyen liszensz.
-
#932
martonx
veterán
Sk8erPeter
#931
martonx
veterán
válasz
Sk8erPeter
#931
üzenetére
Továbbra sem a wampp-al van a gondom. Teljesen érthető, amikor valaki felrak egy wampp-ot (linuxra érthető, windowsra minden esetben felelsleges).
Azon nevettem, hogy mindezt mysql-ezéshez, mert az első hsz-ből más nem derült ki. És igen, tudom bunkó vagyok
Ahogy visszaolvastam az egészet, ismét végig nevettem az első hozzászólás mysql - wampp - könyv javaslatán a data könyvtár átirányításáról. Legközelebb megpróbálom magamban tartani az érzelmeimet. -
#931
Sk8erPeter
nagyúr
martonx
#929
Sk8erPeter
nagyúr
Azért nem egészen olyan ez a helyzet, mint a hasonlatod.
Ha a WAMPP-ot telepíti, akkor abból sejthető, hogy elkezdte érdekelni a webfejlesztés, és most szétnézelődik, elkezd PHP-zni, nézegeti a MySQL-t, próbálgatja az Apache-ot, stb. Én is így kezdtem, csak én eleinte még szopattam magam azzal, hogy egyenként telepítettem őket, és próbáltam rájönni, hogyan kell őket konfigurálni, összehozni, miközben még lószart sem értettem az egészből. Egy csomó időt megspóroltam volna, ha egyszerűen telepítek egy WAMPP-ot, csak akkor még úgy voltam vele, hogy megpróbálom ezeket megismerni. Így utólag úgy gondolom, tök hülyeség ilyennel kezdeni, csak a tököd tele lesz vele már az elején. Miért ne lenne jó telepíteni egy WAMPP-ot? Egyáltalán nem értelek.
Főleg a gonoszkodó stílusodat vele szemben. Kezdő, Te is voltál az.
Egyébként mi van akkor, ha telepíti a WAMPP-ot, talán megeszi a gépét? Értem én, hogy sok felesleges dolog is felmehet vele, de majd ha akarja, kiszedi utólag, és kész. Úgyis ki akarja majd próbálni élete első PHP-scriptjét, tehát kelleni fog az Apache és a PHP is. Mondjuk Windows-on én még mindig IIS-párti vagyok, de ez már másik kérdés.
Ettől még a kezdőnek ne vegyük el a kedvét, inkább segítsünk neki, nem kérdezett olyan vad dolgokat, nem az volt a kérdése, hogy "nem működik, mit tegyek?", hanem részletezte.Szerk.: mondjuk nem vagyok az ügyvédje, majd megvédi magát, csak ez már nekem is feltűnt.
Biztos neked is szarul esett volna, ha az elején jól beoltanak. -
#929
martonx
veterán
Sk8erPeter
#927
martonx
veterán
válasz
Sk8erPeter
#927
üzenetére
Életem első használt adatbázisa a MySQL volt. Anno letöltötem a mysql.com-ról, meg leszedtem mellé a Toad-ot (gugli dobta ki), és next-next telepítettem őket. Akkoriban még fórumok se nagyon voltak, mégis boldogultunk. A Toad varázslóit használtam, közben buzgón elemzve a generált SQL scripteket. Bevallom soha nem olvastam egy SQL-es könyvet sem.
A wampp, xampp dolgokban nem maga a wampp, xampp a gáz, hanem az a röhejes, hogy valaki mysql-t akar tanulni, és ehhez nem az az első logikus lépése, hogy felteszi a mysql-t, meg hozzá egy rendes gui-t, hanem felrak egy komplett keretrendszert, minden felesleges szarral együtt.
Olyan ez mintha autót akarna megtanulni vezetni, és ehhez előbb vesz egy komplett autószalont, miközben csak egy autó kellene.Mondjuk később kiderült, hogy webfejleszt emberünk a gépén, szóval ha értelmesebben fogalmazott volna, és nem azt mondja, hogy a mysql miatt raktam fel wampp-ot, hanem a wampp adott volt, akkor nem is kezdem el fikázni, hanem csak a PHPmyadmin helyett javasoltam volna valami rendes GUI-t.
-
#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
-
#927
Sk8erPeter
nagyúr
martonx
#924
Sk8erPeter
nagyúr
Miért röhejes? Kezdőknek hasznos lehet, hogy nem kell szarakodni a külön-külön telepítéssel, egyben van minden, elindítod a setupot, next-next-csá. Van még pár ilyen gyorsan használható cuccos, mint az EasyPHP meg társai. Mondjuk Windows-on IIS + a Web Platform Installerrel is klattyolgatós felületen lehet ezeket telepíteni.
Azért egy kezdőt ne oltogass ilyen durván, ne vedd el a kedvét. Te is elkezdted valahogy, azóta a szokásaid nyilván sokat fejlődtek.
A phpMyAdmin lehet, hogy keveset tud, de a legtöbb hosting cégnél akkor is az van, nem árt, ha megtanulja kezelni.
A phpMyAdminban egyébként sztem az a nevetséges, hogy a mai napig framesetek használatára építenek, meg amúgy sem látok benne túl nagy fejlődést, már az is nagy számnak tűnt, hogy a jQuery UI-t kezdték el használni, meg AJAX-ot kezdtek el alkalmazni. Meg tényleg lassú.(#915) Bishoop :
tényleg "fura" az a tutorial, ahol ahelyett, hogy sql-dumpokat adnának a "kezedbe", inkább azt mondja, irányítsd oda a datadir-t... Lehet, hogy nem a legjobb segédanyag.(#920) Speeedfire :
tényleg könnyen feltörhető? -
#926
Speeedfire
félisten
martonx
#924
-
Bishoop
tag
Oké, kipróbálom a worbench-et !
Wamp-ot azért telepítettem, mert egyrészt egyszerű a használata, minden van benne ami az adatbázis kezeléshez kell, és van már tapasztalatom benne, mert a Joomla weboldalam készítésekor is ezt használtam.
Ha meg telepítem szólóban az MySQL-t és mondjuk a Workbech-et, gondolom kell még Apache is hozzá, mert gondolom közvetlenül nem lehet megnyitni fájlként egy adatbázist mind pl a Microsoft Access-ben(most ezzel gyakorlok) , úgy hogy kell Apache is.
De majd megpróbálom a Wamp mellett telepíteni a Workbench-et, hátha működik együtt !
Köszönöm a segítségeteket ! -
#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. -
martonx
veterán
A Mysql meg az INFORMATION_SCHEMA részeket még jó, hogy nem lehet törölni, mert ezek a Mysql saját belső működéséhez kellenek. Ezt még DB adminként se lehet törölni, még csak az kellene.
A phpmyadmin lassú és keveset tud és PHP-s webszerver kell hozzá. SQL-t tanulni bármi más jobb a phpmyadmin-nál (na jó az sql konzol ablakban még a PHPmyadmin-nál is reménytelenebb). Én a toad for Mysql-t ajánlom, de van kismillió normális MySQL GUI. -
#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ő. -
#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? -
Bishoop
tag
Szevasztok !
Most kezdtem el tanulni az SQL-t egy "SQL lekérdezések földi halandóknak" nevű könyvből, amelyhez mellékeltek egy CD-t ami példaadatbázisokat és lekérdezéseket tartalmaz, több formátumban. Én a MySQL mellett tettem le a voksom, mert ez a legelterjedtebb. Telepítettem a wamp servert, és rögtön ki is próbáltam a phpmyadmint, az alap adatbázisok működtek. A könyvhöz kapott mellékletben azt írta hogy a MYSQL DATA könyvtárát kell átirányítanom arra a könyvtárra ahol a példaadatbázisok találhatóak, amit meg is tettem:datadir=c:/AddisonWesley/SQLQFMM2/MySQL/Data -re cseréltem a
datadir=C:/Program Files/wamp/bin/mysql/mysql5.5.16/data
Ezek után kaptam egy olyan hibaüzenetet hogy:
"A MySQL mondta:
#2002 - A szerver nem válaszol (vagy nem megfelelően állították be a helyi MySQL szerver szoftvercsatornáját)"
Nem tudja valaki, hogy ez a semmitmondó üzenet miért jön ki?
Egészen biztosan újabb verziót használok, mit amiben csinálták az adatbázisokat, és elvileg itt is érvényesül a felülről kompatibilitás vagy nem -
#914
Peter Kiss
őstag
Sk8erPeter
#912
Peter Kiss
őstag
válasz
Sk8erPeter
#912
üzenetére
Igazából ezért hegesztek magamnak keret a .NET framework mentén (nyilván kisebbet, egyszerűbbet), építés közben szoktam néha ledöbbenni, hogy mennyire adják egymást a megoldások, pl. nem egyszer volt, hogy kigondoltam egy megoldást az adott problémára, és pont ugyanazzal a megközelítéssel találkoztam az MSDN-en is.
-
#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. -
#912
Sk8erPeter
nagyúr
Peter Kiss
#909
Sk8erPeter
nagyúr
válasz
Peter Kiss
#909
üzenetére
Na, ez tök jó, ilyen sem sűrűn volt közöttünk, most mindegyik mondatoddal egyetértek.
(Lehet, hogy ez egyszer nem fogunk vitába szállni, pezsgőt bontok 
) Kivéve azzal, hogy "nem PHP-s, tudom, kapjam be". Én aztán nagyon nem vagyok PHP-rajongó. Jelenlegi terveim szerint a jövőben webes területen éppen ASP.NET-re szeretnék átállni teljesen, vagy valamelyik Java-s technológiára. Eleve mondjuk az általam kedvelt C#, Java, C++ nyelvek közül bármelyikben sokkal szebben lehet kódolni (kevésbé sarkall gányolásra, vagy engedi azt), mint PHP-ben (tudom, kapjam be ).
Addig is az általad említett PHP-s frameworkök engem is foglalkoztatnak, pont ezek a "menőbbek", amiknek a használatát már sokszor szerettem volna megtanulni. -
#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.
-
#909
Peter Kiss
őstag
Sk8erPeter
#907
Peter Kiss
őstag
válasz
Sk8erPeter
#907
üzenetére
Entity Framework meg az ASP.NET MVC (nem PHP-s, tudom, kapjam be).
Amelyek most mennek nagyobb frameworkok mindegyik bugzik, a Zend Framework 2-t szeretném majd jobban átvizsgálni, illetve a Symfony-t, Doctrine-t.
-
#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. -
#907
Sk8erPeter
nagyúr
Peter Kiss
#906
Sk8erPeter
nagyúr
válasz
Peter Kiss
#906
üzenetére
Ha már itt tartunk, milyen framework az, ami tapasztalataid meg kódja alapján szted jónak minősül?
Minden frameworknek van valami bakija, de kíváncsi vagyok, szted melyik az, amelyiket lehet jónak nevezni. -
#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. -
#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.
-
#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.
-
#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...
-
#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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Szerintem ez rohadtul nem kezdőknek való feladat, és messze áll attól, ami a gyakori adatbázis-kezeléshez kell. Ezerszer értelmesebb lenne táblák megtervezésével, összekapcsolásával kapcsolatos feladatot adni...
Ha phpMyAdminban meg tudták oldani, nem igazán értem, itt miért nem. De már a felvetésedet sem igazán látom be, hogy miért ne lenne gond.
Új hozzászólás Aktív témák
- GAMER PC! i5-11400F / 16GB DDR4 / RTX 3060 12GB / H610 / 512GB NVMe / 600w! BeszámítOK
- Dell Latitude 5320 - hibás kijelzők - i5 1135G7 ,16GB RAM, SSD, jó akku, számla
- Dell Latitude E7440 - i5, 8GB RAM, HDMI, eu bill - számla, 6 hó garancia
- HP, DELL, LENOVO, ACER laptopok, WINDOWS 11, ÁFA-s számla, garancia
- Macbook Pro M1 Max 64GB RAM 512GB SSD GARANCIÁVAL
- BESZÁMÍTÁS! 3TB Western Digital WD RED SATA HDD meghajtó garanciával hibátlan működéssel
- Eladó szép állapotban levő Samsung S22 8/128GB / 12 hó jótállással
- GYÖNYÖRŰ iPhone 13 mini 256GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3180
- Gamer PC-Számítógép! Csere-Beszámítás! R5 3600 / RTX 2060 6GB / 16GB DDR4 / 512GB SSD
- MacBook Pro 16 i7-9750H 16GB RAM 512GB SSD RX 5300M 1 év garancia
Állásajánlatok
Cég: FOTC
Város: Budapest