Új hozzászólás Aktív témák
-
martonx
veterán
válasz Speeedfire #1150 üzenetére
Szvsz nem ajánlott keverni, legalábbis vagy RDBMS-t, vagy dokumentum alapú NoSQL-t érdemes használni. És e mellé persze könnyen lehet gráf tárolót, vagy kulcs-érték tárolót használni (lásd pl. Facebook, ami MySQL alapú, de a kapcsolatokat gráf tároló NoSQL-ben tartja).
Én kérek elnézést!
-
Speeedfire
nagyúr
Egy táblában ilyen mezők vannak.
id + name + typeA type most lehet 1,2,3
Lehet olyan lekérdezést csinálni, hogy a type szerint rendezze, de ebben a sorrendben? 3,1,2?Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
rum-cajsz
őstag
válasz Speeedfire #1152 üzenetére
vagy írsz egy függvényt, vagy egy másik táblában definiálod a kívánt sorrendet.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
PazsitZ
addikt
válasz Speeedfire #1152 üzenetére
SELECT id, name, type FROM table
WHERE type IN (1,2,3)
ORDER BY
CASE type
WHEN 3 THEN 1
WHEN 1 THEN 2
WHEN 2 THEN 3
END;- http://pazsitz.hu -
-
Speeedfire
nagyúr
válasz rum-cajsz #1153 üzenetére
Meglett a megoldás, ennyire nem volt drasztikus szerencsére.
ORDER BY FIELD(
TYPE , '1', '3', '2' )
PazsitZ: Ez is jónak tűnik, megnézem melyik a gyorsabb lekérdezésben.Szerk.:
Amit írtam: a lekérdezés 0.0178 másodpercig tartott
Az általad írt: a lekérdezés 0.0005 másodpercig tartottA tied kicsit gyorsabb, még így 20db adattal is.
Szerk.: Na, most az enyémre is annyit írt mint a tiedre.
[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
bpx
őstag
válasz Speeedfire #1155 üzenetére
persze mert első futás után már cache-ből megy
-
PazsitZ
addikt
Igen, mérés esetén vagy a benchmark-al futtasd le mondjuk 10000 ismétléssel így mindegyik esetén azonosan használ cache-t a későbbi requestek esetén és hamarabb kibukik.
Vagy mindkettő futtatása elé szúrd be a: RESET QUERY CACHE; parancsot.
Feltéelezve, hogy mysql-t használsz.
[ Szerkesztve ]
- http://pazsitz.hu -
-
Speeedfire
nagyúr
válasz PazsitZ #1157 üzenetére
Megjelenített sorok: 0 - 29 ( 1 001 összesen, a lekérdezés 0.0038 másodpercig tartott)
Megjelenített sorok: 0 - 29 ( ~1 001 összesen , a lekérdezés 0.0026 másodpercig tartott)Gyorsabb, amit te írtál meg.
Query cache ürítés volt az 1. teszt után.
2x is megcsináltam ezeket a teszteket, mind a 2 esetben gyorsabb volt a case szerkezet.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
SektorFlop
aktív tag
Valaki esetleg tud erre válaszolni? Tudom csak félig tartozik ide, de hátha!
"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."
-
Sk8erPeter
nagyúr
válasz SektorFlop #1159 üzenetére
Te most minden alkalommal egy view-t akarsz létrehozni? Hát az úgy nem lesz jó.
Akkor inkább a view-t selecteld, vagy hagyd a view-t.Sk8erPeter
-
SektorFlop
aktív tag
válasz Sk8erPeter #1160 üzenetére
nem feltétlenül kell view... sima select is elég kell hogy legyen igaz?
"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."
-
Sk8erPeter
nagyúr
-
kisbandima
tag
Készítettem egy Silverlight alkalmazást, ami egy Microsoft SQL Server 2008 R2 Express Edition-ből olvassa ki az adatokat. Az adatokat a felhasználó szűrheti is (dátumtól - dátumig, összegtől - összegig). Ez ugye 4 paraméter és nem csak párban működnek, tehát lehet olyat is, hogy csak a bizonyos dátumtól újabb adatokat listázom ki. Ez működik is, csakhogy a favágó módszerrel. Tehát amennyi lehetőség annyi SQL lekérdezés amiből majd csak egy fut le. Nem lehet ezt valahogy elegánsabban megoldani?
-
lakisoft
veterán
válasz kisbandima #1163 üzenetére
Dynamic SQL? vagy Dynamic SQL és tárolt eljárás?
-
Sk8erPeter
nagyúr
válasz kisbandima #1163 üzenetére
Én is a tárolt eljárásra szavaznék, de nem ártana látni a "favágó" módszert, meg az alap query-t, vagy valami példaszerűséget, hogy meg tudjuk mondani, hogyan tudnád azt szebben elkészíteni.
Pl. a WHERE-ben is lehetne CASE-ek.(#1164) lakisoft :
Most már érdekelne, hogy ez a dynamic SQL miért jó? Ahogy nézegettem, ez igazából egy query feltételektől függő konkatenálgatása, aztán a query "elkészítése" során annak végrehajtása, ami szerintem elég randa.
Akkor már a WHERE-be elhelyezett, kicsit komplex CASE-ek is szebbnek tűnnek.
Persze aztán lehet, hogy csak nem találkoztam durva esetekkel, ahol nincs jobb, ezért kérdezem.[ Szerkesztve ]
Sk8erPeter
-
lakisoft
veterán
válasz Sk8erPeter #1165 üzenetére
Hááát figy. Valóban csúnya de az agyam ráállt teljesen. Így jól és gyorsan tudom használni. A teljesítménybeli vonatkozásait nem ismerem de igazából jelenleg nincs is rá szükségem.
Tárolt eljárást is sokszor használok Dynamic SQL-lel együtt. Ott már nem látod hogy csúnya .
[ Szerkesztve ]
-
Speeedfire
nagyúr
Na, akkor kérdeznék én is.
Adott egy log tábla az adatbázisban, ahol a felhasználók ip címe van mentve. x időközönként a legutolsó y mennyiségű adatot törölni kellene.
Van erre valami gyors megoldás?
Csak, mert ami nekem eszembe jutott, hogy groupba kellene szedni őket. Majd megnézni, hogy melyiknél mennyi van, ahol több mint y ott elmenti egy tömbbe azoknak a usereknek az id-ját. Majd egyesével időrendben növekvőbe tenni, lementeni az id-kat és megint csak lenne egy iteráció amiben törölve lennének ezek. Php-val oldanám meg, de ez így szerintem elég sok időbe telik és sok erőforrást emészt fel. Van erre esetleg valami egyszerűbb megoldás?Adatbázis:
id | uid | ip | time
id: ai, elsődleges kulcs
uid: másodlagos kulcs
ip: varchar(20)
time: int(10)Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
válasz Speeedfire #1167 üzenetére
Hát én komplexebb feladatokra tárolt eljárást használok, mióta belekóstoltam.
De a te feladatodat igazából nem értem, hogy miért akarod tömbökbe szedni a userek id-ját... Adott userekhez tartozó bejegyzéseknél X időközönként csak Y mennyiséget akarsz törölni, tehát azt akarod, hogy valamennyi az adott júzerhez mindenképp megmaradjon?
Szóval nem csak törölni kell a táblából azt az Y sort, azt' kész?
Fejtsd ki, MOST!===
(#1166) lakisoft :
"Tárolt eljárást is sokszor használok Dynamic SQL-lel együtt. Ott már nem látod hogy csúnya ."
Miért, a tárolt eljárás önmagában még nem ocsmány, de el lehet rondítani.Sk8erPeter
-
Speeedfire
nagyúr
válasz Sk8erPeter #1168 üzenetére
Azért akarom (illetve akarja a fene, de nem látom rá mást...), hogy utána ki tudjam törölni a régi bejegyzéseket.
tehát azt akarod, hogy valamennyi az adott júzerhez mindenképp megmaradjon?
Így van, y mennyiség bejegyzés megmaradni minden usernek.Nem tudom mit értetlenkedsz ha tudod mire gondolok.
Adott pl 1m rekord és 1k felhasználó és pl 500 bejegyzésnek kellene lennie csak felhasználónként maximum. Ergo akinek több mint 500 ilyen bejegyzése van, azoknak a legrégebbieket törölni kellene.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
kisbandima
tag
válasz Sk8erPeter #1165 üzenetére
Favágó módszer 2 paraméterre:
if ((a != 0) && (b == 0))
{
return ... Where Osszeg >= a;
}
if ((a == 0) && (b != 0))
{
return ... Where Osszeg <= b;
}
return ... Where Osszeg >= a & Osszeg <= b;Remélem így már érthető. A probléma, hogy nekem 4 paraméterem van és ezzel a módszerrel elég amatőr megoldásnak látszik. Igaz legalább működik.
-
lakisoft
veterán
válasz Sk8erPeter #1168 üzenetére
Persze hogy el lehet rondítani, de próbálok áttekinthető kódot kiadni a kezemből.
-
martonx
veterán
válasz kisbandima #1163 üzenetére
Ha már Silverlight, akkor gondolnám, hogy WCF RIA Services-el adod az adatokat, ez esetben LINQ-val simán meg lehet oldani az egészet.
Ha meg nem több millió adatsorról van szó, C#-al, XAML-lel elég szépen lehet memóriában szűrni az adathalmazt.Én kérek elnézést!
-
bpx
őstag
válasz Speeedfire #1167 üzenetére
PHP-t erre felejtsd el, adatok ilyen szintű manipulációját az adatbázis végezze, ne a hozzá kapcsoló alkalmazás
ez 1, azaz egy darab színtiszta SQL utasítás:
DELETE FROM tabla WHERE id IN(
SELECT id FROM(
SELECT id, RANK() OVER (PARTITION BY uid ORDER BY time DESC) r FROM tabla)
WHERE r > 500);magyarázat:
a legbelső select partíciókat képez a táblából az uid alapján, és a partíciókat idő szerint (time) csökkenő sorrendbe rendezi, és minden egyes id-hoz rendel egy sorszámot (rank), hogy adott partícióban a rendezés szempontja szerint hanyadik helyen áll
az eggyel kintebb levő select lekérdezi azokat az id-kat, ahol ez a "rang" 500-nál nagyobb, tehát kívül esik a kívánt limiten
a delete meg törli az ilyen id-val rendelkező sorokat
szerk: adatbáziskezelőt mondjuk nem írtál, ez Oracle-ben működik, én a tábládból úgy tippelem hogy MS SQL (auto increment PK, meg int típus), de ezek a funckiók mintha ott is meglennének
[ Szerkesztve ]
-
Speeedfire
nagyúr
Hát ez jól hangzik, ennek utána nézek, remélem menni fog nálam is. Én meg itt 50 soros php sql kódon agyaltam már.
MySql alatt vannak az adatok, de meglesem, hogy ezek ott is vannak-e.
Köszi.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
bpx
őstag
válasz kisbandima #1163 üzenetére
egyrészt, ha bind változókat használsz, ez így is csak annyi SQL, ahány esetet a feltételek megadása/meg nem adása eredményez
de ha minden esetet egy SQL utasítással akarsz kezelni, ám legyenMSSQL-t nem ismerem, szóval ez amolyan pszeudokód lesz
SELECT oszlop1, oszlop2
FROM tabla
WHERE datum > NVL(:B1, MINDATE)
AND datum < NVL(:B2, MAXDATE)
AND osszeg > NVL(:B3, 0)
AND osszeg < NVL(:B4, INT.MAXVALUE);B1-B4 bind változók, ami user input
ha a user nem ad meg semmit, akkor NULL-t adsz be neki
az NVL arra való, hogy ha az első paramétere NULL, akkor kicseréli a másodikratehát ha a user nem ad meg felső határt a dátumra, akkor a NULL-t kicseréli az NVL a lehetséges legnagyobb dátumra
ha a user nem ad meg alsó határt az összegre, akkor kicseréli 0-ra
és így tovább...ha meg linq vagy ilyesmi, abban nem vagyok otthon (sajnos)
[ Szerkesztve ]
-
martonx
veterán
válasz Sk8erPeter #1179 üzenetére
Én inkább úgy mondanám, hogy mióta az Oracle kezében van, nem olyan a fejlődési üteme, mint régen. Az Oracle bolond lenne saját magának konkurenciát állítani.
Én kérek elnézést!
-
lakisoft
veterán
válasz Sk8erPeter #1179 üzenetére
Itt nem ezekre gondoltam. A tárolt eljárásokra pl. vagy MySQL Partitioning vagy Storage Engine: NDB kibővítették az elérhető adattipusokat.
[ Szerkesztve ]
-
martonx
veterán
válasz Sk8erPeter #1182 üzenetére
Nincs itt nagyon mit megbeszélni. Az 5.1-es MySQL verzióban volt a legtöbb innováció. Ez pedig 2008 November 27-én jelent meg. Ez lassan 4 év távlatot jelent. lakisoft által jelzett újdonságok is ekkor kerültek bele. Azóta csak csiszolgatják.
Az Oracle pedig 2010 január 27-én vette meg a Sun-t, ami birtokolta a MySQL-t.
De ez részemről nagyon off topik, és nem vagyok egy nagy MySQL szakértő.Én kérek elnézést!
-
dellfanboy
senior tag
most ismerkedek a pl sql-el
van egy script
SELECT *
FROM táblanév
WHERE 1=1AND upper(g.NAME) LIKE '%lajos%';
segítsetek miért van az, hogy ha törlöm a where 1=1 feltételt errort kapok?
ill AND után miért kell az upper? miért nem jó ha simán ezt írom:
SELECT *
FROM táblanévAND (g.NAME) LIKE '%lajos%';
eladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei
-
ArchElf
addikt
válasz dellfanboy #1185 üzenetére
Nem a where 1=1 -et kell törölni, hanem az 1=1 AND-et
SELECT *
FROM táblanév
WHERE upper(g.NAME) LIKE '%lajos%';AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
Sk8erPeter
nagyúr
válasz dellfanboy #1185 üzenetére
Igazából szerintem így lenne értelme:
...
WHERE UPPER( stuff_name ) LIKE UPPER( '%lajos%' )...abban az esetben, ha az adatbázis case sensitive.
Pl. MySQL-nél alapból tök mindegy, hogy "lajos", "LAJOS" vagy "LaJoS" a tárolt név, simán az UPPER nélkül is kiadja mindegyik találatot, szóval ez case insensitive módon megtalálja az összeset - de collationnel arra is van mód, hogy ne így legyen: [link].Case sensitive esetben viszont mindkettőt jó, ha nagybetűssé teszed, és úgy veted össze, mert ellenkező esetben nem mindegy, hogy a fent felsorolt példák közül hogyan keresel rá.
Tehát ha nem mindkettőnek a nagybetűssé (vagy épp kisbetűssé) tett változatát veted össze, akkor lehet, hogy egyes találatokat kizársz az eredményekből, mert mondjuk valaki elgépelte a Lajost, és LajOst írt helyette (lásd nagy O).
A nagybetűssé tett "lajos"-ból "LAJOS" lesz, a nagybetűssé tett "LajOs"-ból is "LAJOS" lesz, tehát így már a két karaktersorozat egyezni fog ebben az 5 karakterben.
A Te fenti keresésed lehetővé teszi azt is, hogy a "LajOska" nevet is megtalálja.Remélem így valamennyire érthető.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #1187 üzenetére
Pontos egyezés vizsgálatához át lehet alakítani így is:
SELECT * FROM `test_names`
WHERE
BINARY(stuff_name) LIKE "%lajos%"Így csak azt találja meg, ahol "lajos" vagy "lajoska" van, a "Lajos" vagy "LaJos", stb. neveket már nem.
[ Szerkesztve ]
Sk8erPeter
-
SektorFlop
aktív tag
SQLite-ba dolgozok még mindig, és van egy táblám amibe hónapok szerepelnek. Szeretném elkerül azt hogy egy hónap több rekordba is szerepeljen, szóval pl a Január csak egyszer szerepelhessen a táblámba, van erre valami SQL okosság, vagy vagy le kell kérdeznem előtte táblát és az alapján eldönteni hogy mehet e feltöltés vagy nem?
"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."
-
martonx
veterán
-
bpx
őstag
válasz SektorFlop #1190 üzenetére
unique constraint a hónap oszlopára, és így nem szerepelhet kétszer ugyanaz az érték abban az oszlopban
feltöltésnél hibát fog dobni ha olyat akarsz feltölteni, ami már van, ezt kezelni kell
-
WolfLenny
senior tag
Üdv.!
Egy olyan kérdésem lenne, hogy adott egy kb. 4-500 MB méretű csv. Kb. 1-1.5 millió rekord kb. 40 mezővel.
A teszt felszedése 140.000 rekordot tartalmazott és több mint 1 órán keresztül szedte fel.
Ezt lehetne valahogy gyorsítani?Előre is köszi a választ...
-
-
WolfLenny
senior tag
Köszi a válaszokat.
Egy P-4s gép csinálta ugyan, de az a furcsa, hogy egy ilyen művelet foxproban ugyanezen a gépen pár másodperc.
MySQL + PHP vezérléssel próbáltuk.
-
martonx
veterán
válasz WolfLenny #1199 üzenetére
Egyrészt a PHP mint interpreter nyelv az ilyen műveletekre alapvetően kb. 100X lassabb (lehet, hogy cak 10-szer, erről ne nyissunk vitát), mint egy compiled (pl. java, .net) nyelv.
Másrészt ha ezen a szerencsétlen P4-esen még emellett egy MySQL-t is futtatsz, és mindehhez egy ősrégi lassú vinyú kerreg alatta, akkor nem csoda ez a futásidő.Én kérek elnézést!
Új hozzászólás Aktív témák
- XBOX ONE/PS4/PS5/XBOX SERIES/NINTENDO SWITCH konzolt vásárolnék!
- XBOX SERIES/PS4/PS5/XBOX ONE/NINTENDO SWITCH konzolt vásárolnék!
- PS5/PS4/XBOX ONE/XBOX SERIES/NINTENDO SWITCH konzolt vásárolnék!
- Új Dobozos Lenovo Ideapad Flex 5 x360 Érintős Ultrabook Óriás Tab 16" -40% Ryzen 5 5500U 16/512 QHD
- PS4/PS5/XBOX ONE/XBOX SERIES/NINTENDO SWITCH konzolt vásárolnék!