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!

Egy táblában ilyen mezők vannak.
id + name + type

A 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

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=======

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 -

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 tartott

A 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

persze mert első futás után már cache-ből megy

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

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..."

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

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..."

Elvileg ja.

Sk8erPeter

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?

Dynamic SQL? vagy Dynamic SQL és tárolt eljárás?

É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

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 ]

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

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

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

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.

Persze hogy el lehet rondítani, de próbálok áttekinthető kódot kiadni a kezemből.

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!

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 ]

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

Pont ugyanezek a parancsok nincsenek, de hasonlót írtak át itt is. Menni fog szerintem. Holnap meglesem.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

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 legyen

MSSQL-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ásodikra

tehá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 ]

Mióta az oracle kezében van nagyon sok új dolgot beleraktak.

Hát int és autoincrement nem csak azóta van, mióta az Oracle tulajdonába került...

Sk8erPeter

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 ]

lakisoft, martonx: na, akkor most beszéljétek meg, hogy is van ez, mert egymásnak pont ellentmondó állításokat hoztatok fel.

Sk8erPeter

most ismerkedek a pl sql-el

van egy script
SELECT *
FROM táblanév
WHERE 1=1

AND 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év

AND (g.NAME) LIKE '%lajos%';

eladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei

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]

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

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

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..."

le kell kérdezni. Csodák nincsenek.

Én kérek elnézést!

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

aham valami ilyesmi kell nekem, köszi megnézem... ha nincs más akkor marad az hogy előtte lekérdezem.

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."

nagyon jól működik, most már csak annyit kell megoldanom hogy ne írja ki akkor is hogy sikeres feltöltés

Még egyszer köszönöm a segítséget!!

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."

Ü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...

Valahogy biztos. Ennek a méretnek nem órákig, hanem másodpercekig, na jó maximum 1-2 percig kellene futnia.
Mivel semmi konkrétumot nem írtál, így nehéz konkrétan segíteni.

Én kérek elnézést!

Ez elsősorban a server I/O teljesítményétől függ. Milyen gépen és milyen adatbázissal próbáltad/dolgozol?

Ha ezt a "felszedést" excel csinálta egy p4-es gépen, akkor teljesen ok az egy óra.

Egyéb esetekben jobban le kellene írnod, hogy mivel akartad betölteni hová, mert nagyon nem mindegy!

=Kilroy was here============================ooO=*(_)*=Ooo=======

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.

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!