Új hozzászólás Aktív témák
-
D@ni88
addikt
Meg lehet úgy oldani PL/SQL-ben hogy több mezőt szeretnék kinyerni egy selectből
pl
select first_name into fname,
last_name into lname
from users. -
D@ni88
addikt
Még egy kérdésem lenne:
Meg lehet azt oldani, hogy ha egy function-t pl így hívok meg.termekek('select name from termekek');
Ennek a kimeneteként egy varchar típust szeretnék kapni, amiben vesszővel elválasztva szerepeljenek a termékek nevei.
-
bpx
őstag
lehet, de ehhez nem kell újra feltalálni a kereket:
SQL> create table test1(name varchar2(10));
Table created.
SQL> insert into test1 values('Spongyabob');
1 row created.
SQL> insert into test1 values('Patrik');
1 row created.
SQL> insert into test1 values('Tunyacsáp');
1 row created.
SQL> commit;
Commit complete.
SQL> select listagg(name,',') within group (order by name) as nevek from test1;
NEVEK
------------------------------
Patrik,Spongyabob,TunyacsápEz mondjuk 11.2-es feature, ha ennél régebbi az Oracle, akkor google: oracle string aggregation
[ Szerkesztve ]
-
ArchElf
addikt
Nem CD-ről (vagy valamilyen írásvédett médiáról) próbálod felcsatolni véletlenül?
SQL Server szervízt futtató felhasználónak van oda hozzáférési joga?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]
-
Kommy
veterán
Sziasztok,
lehetséges olyat csináni, hogy egy lekérésből kizárni azokat a sorokat amelyekben az url mezo cikk/ -el kezdődik ( url kinézete: cikk/cikk_cime), ha ez lehetségea kkor hogyan
-
ubid
őstag
Helló!
MSSQL-be ( meg gondolom máshol is ) idegen kulcsnak uniqueidentifier-nek kell lennie, és csak a másik tábla ID-jához kapcsolódhat ami szintén uniqueidentifier ?
Vagy csak annyi a lényeg, hogy a két kulcs egyező típusú legyen ? ( mondjuk int - int )
[ Szerkesztve ]
-.-
-
ubid
őstag
Akkor ez azt jelenti, mondjuk ha idegen kulcsal szeretnék mutatni egy másik táblában lévő COMPANY_NAME-re ami mondjuk nvarchar(MAX) akkor az általam készített táblába csinálok mondjuk egy FK_C_NAME -et ami szintén nvarchar akkor ez így megfelelő neki ?
-.-
-
Lacces
őstag
Sziasztok!
Találkoztam ezzel a mongoDB-vel csak a nevével, de ez most mégis micsoda? Adatbázis, én úgy olvastam, hogy valami dokument alapú adatbázis, de ez mit jelent? (wikipédiás magyarázatot sem értem így hirtelen)
Én nézegettem neten, és aztláttam, hogy Json alapú, OOP világába jobban illik bele.Igazából gyakorlban milyen ezt használni, jobb mintha a sima SQL-t használnám?
Például. Weboldalt akarok, ahol van blog, user kezelés, de szeretnék diagramokat is kezelni,
A diagramoknak vannak adatai, id, név, téma, stb. Visszont vannak oszlopok is, értékek, amelyek mindig tetszőleges számúak! Az egyik diagramnak 4 oszlopa van, még a másiknak 8 oszlopa van.
Ebben az esetben MongoDB vagy SQL-t érdemes használni? Indokot is kérnék ha szabad
Nekem még vadiúj ez a NoSQL világ -
martonx
veterán
Én valahogy idegenkedek a NoSQL-től. Jóllehet bizonyos esetekben kiválthatnak hagyományos funkciókat pl. cookie-kat, session-öket, illetve ezek közötti kommunikációt könnyű NoSQL-lel, szépen adminisztrálható, áttekinthető módon megoldani.
Jól jöhetnek akkor is, ha abszolút változó oszlopszámú rekordokat kell tárolni.
Illetve előnyük még, hogy a szöveg alapú keresésben hatékonyabbak (ez azért relatív), mint a hagyományos relációs adatbázisok.
Hátrányuk, hogy egy szépen felépített adatbázissal, ahol minden mindennel relációban van, egyszerűen nem vehetik fel a versenyt.
És itt jegyezném meg, hogy az ilyen "vannak oszlopok is, értékek, amelyek mindig tetszőleges számúak! Az egyik diagramnak 4 oszlopa van, míg a másiknak 8 oszlopa van." esetek meglátásom szerint túlnyomórészt adatbázis, program rendszer tervezési hibák miatt születő megoldások, ahol a tervezés butaságait a NoSQL sem fogja megoldani, maximum elfedi, sőt a kötetlensége miatt akár fel is erősítheti ezt a jelenséget.
A kétféle SQL használata abszolút nem zárja ki egymást, párhuzamosan is lehet használni őket.
Én kérek elnézést!
-
Lacces
őstag
-
D@ni88
addikt
Hello,
Adnátok pár tippet adni, hogyan lehet egy selectet gyorsítani?
hint-ekről esetleg magyar leírás? -
bpx
őstag
megfelelő indexeket létrehozni, statisztikát gyűjteni
végrehajtási tervet megnézni
session trace, majd ott megnézni, hogy mi veszi el sok időtha ezek megvoltak, na akkor lehet hintelni
legvégső esetben hidden paraméterek, ha valami nagyon specifikus a probléma[ Szerkesztve ]
-
D@ni88
addikt
Illetve olvastam olyat, hogy Mysql-ben gyorsítja a lekérdezéseket a View-k használata.
Ez igaz az Oracle-re is? -
bpx
őstag
ha bekapcsolod, aprólékosan minden egyes aktivitást, várakozást feljegyez egy trace fájlba, amit később ki lehet értékelni
pl. tkprof-fal lehet ember által emészthető formára hozni, ahol lehet látni pl. minden egyes sql utasításra, hogy milyen tervvel futott, és a terv egyes lépései mennyi ideig tartottak#1026: a view nem más, mint egy elmentett lekérdezés aminek neve van, semmivel se gyorsabb se mysqlben, se Oracle-ben, csak kényelmesebb
[ Szerkesztve ]
-
rum-cajsz
őstag
Oracleben van lehetőség a Materializált Nézetekre, amivel valóban lehet gyorsítani a selectedet, de ezt körültekintően érdemes használni.
De a legfőbb kérdés, hogy mire akarod használni az adott selectet. A hálózati forgalom pl. minimalizálható, ha nézetet használsz, ám ha ezt a lekérdezést egy sql*plusban adod ki, akkor nem lesz különbség a két (select contra view) között.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
D@ni88
addikt
válasz martonx #1028 üzenetére
Munkahelyi anyagot nem rakhatok netre
Érdekes, mint kiderült nem is a Select-ekben van a hiba. (~160 sort dolgoz fel a select)
Fájlba történő kiírásnál van a probléma. Néha 1 oerc, néha 3 óra. Pedig ugyan azzal a paraméterrel hívom meg... Ha SQL navigátor debuggerjével megyek át rajta akkor nincs gond... -
D@ni88
addikt
Egyszerű select-el meg lehet tudni, milyen indexen vannak egy táblára, esetleg mezőjére?
Sajnos van 2x indexet hoztak létre egy táblára, és jobb lenne biztosra menni, nem mindet végignézni...
-
rum-cajsz
őstag
Nem írtad az adatbázist! Oracle-ben pl. az ALL_IND_COLUMNS nézetből lekérdezheted:
select
INDEX_NAME,
LPAD(TABLE_NAME,17) TABLE_NAME,
LPAD(COLUMN_NAME,15) COLUMN_NAME,
LPAD(COLUMN_POSITION,5) COLUMN_POSITION
from ALL_IND_COLUMNS
WHERE TABLE_NAME = upper('&tablename')
order by INDEX_NAME,COLUMN_POSITION;=Kilroy was here============================ooO=*(_)*=Ooo=======
-
wolandino
tag
Sziasztok,
Egy kis gondban vagyok, mert adott egy alkalmazásom, amit bővíteni kellene.
Az alkalmazás tartalmaz egy űrlapot, ahol legördülők vannak, kb 10 db.
Mindegyik legördülő mögött egy tábla van: (név, id) párokkal lényegében.Eddig ezek egymástól függetlenül léteztek, de most úgy kellene bővíteni a funkcionalitást, hogy egy admin felületen lehetőséget adni az adminnak arra, hogy kiválasztott listák egyes értékeitől tegye függővé, hogy a másik legördülő mit jelenít meg.
Az adatkapcsolat így lehet sok-sok, egy-sok és sok-egy is.Arra gondoltam, hogy két táblára lenne szükségem
az egyik mondjuk table_connect(melyik_táblát, melyikkel)
a másik pedig a data_tree( melyik_tábla, melyik_adata_id, melyik_táblával, melyik_adatával_id)Az első tábla adná meg, hogy melyik táblától melyik tábla függjön, a második tábla pedig megadná, hogy az egyik tábla mely konkrét értékekeihez a másik tábla mely értékeit rendeljük.
Nem tudom mennyire érthető, de érdekelne pár tapasztalt adatbányász véleménye.
Köszönettel,
W. -
martonx
veterán
válasz wolandino #1035 üzenetére
mivel nulla konkrétumot árultál el...
Általánosságban:
Kapcsoló tábla jellemzően a sok a sokhoz esetben kell, a többi esetet sima foreign key-ekkel meg tudod oldani.
Ha már kapcsoló táblád van, érdemes tábla-tábla közé létrehozni egy-egy kapcsoló táblát, legalábbis az ORM-ek ezeket tudják értelmesen feldolgozni, és itt már csak felesleges túlbonyolításnak érzem, egy nagy kapcsoló táblát létrehozni.
De te tudod.Én kérek elnézést!
-
wolandino
tag
válasz martonx #1036 üzenetére
Köszönöm
Igen, azért van szükség a kapcsolódó táblára, mivel valószínűleg elő fog fordulni a sok a sokhoz eset, ezt sajnos még nem tudom, a felhasználó fogja eldönteni..."Ha már kapcsoló táblád van, érdemes tábla-tábla közé létrehozni egy-egy kapcsoló táblát, legalábbis az ORM-ek ezeket tudják értelmesen feldolgozni, és itt már csak felesleges túlbonyolításnak érzem, egy nagy kapcsoló táblát létrehozni."
Itt nem nagyon értem, hogy mire gondoltolál
-
martonx
veterán
válasz wolandino #1037 üzenetére
"Arra gondoltam, hogy két táblára lenne szükségem
az egyik mondjuk table_connect(melyik_táblát, melyikkel)
a másik pedig a data_tree( melyik_tábla, melyik_adata_id, melyik_táblával, melyik_adatával_id)"Erre. Javaslom, hogy ez a koncepció helyett minden tábla között, ami között sok-sok kapcsolat lehet, vegyél fel külön kapcsolótáblákat. Ettől még a te ötleted is működik.
Ha pedig 10 tábla közül minden kapcsolódhat mindennel, akkor ott valami alapvetően félre van tervezve.Én kérek elnézést!
-
wolandino
tag
válasz martonx #1038 üzenetére
bármi kapcsolódhat bármivel, de nem minden mindennel.
Egymás alatt vannak a listák, amik egy meghatározott fogalom pontosításait adjákpl: első legördülőben kiválasztom a lehetőségek közül az élőlényt
így a második legördülőben már csak élőlények csoportjai vannak kiválasztom a gerinceseket
a harmadikban így csak a gerincesek vannak, abból kiválasztom az emlősöket,
stb...
vannak listák, amelyek nem függenek semmitől, és tőlük sem függ semmi, de sajnos azt még nem tudom, hogy mi mitől fog függeni, ráadásul ez változhat is, így inkább egy általános modelt próbálok megadni, ami flexibilis.[ Szerkesztve ]
-
InfiniteReality
őstag
válasz ArchElf #1041 üzenetére
Kérdés, adott egy adatbázis, amit szétdobtam az egyik mező adatai alapján évek szerint külön táblákba (tehát minden év összes bejegyzése külön táblában van már).
Amikor az egész egyben volt, akkor az alábbi lekérdezés hibátlanul működött (a jatekosl mező tartalma ugyanaz mint a jatekos mezőé, de kisbetűsítve):
SELECT jatekos, sum(pont) FROM jateklista WHERE pont >='1' GROUP BY jatekosl ORDER BY 2 LIMIT 50
Az évek szerint szétdobott táblák esetén a következő lekérdezést alkalmaztam, hogy a fenti eredményt elérjem (csak 2 évet írok le, mivel a teljes időszak lekérdezését PHPban állítom elő dinamikusan, a hiba úgyis ugyanaz):
(SELECT jatekos, sum(pont) FROM jateklista2005 WHERE pont >= '1' GROUP BY jatekosl) UNION (SELECT jatekos, sum(pont) FROM jateklista2006 WHERE pont >= '1' GROUP BY jatekosl) ORDER BY 2 DESC LIMIT 50
A hiba pedig az, hogy minden játékos annyiszor szerepel, ahány évben beleesik a fenti lekérdezésbe. Nyilván valami alap dolgot rontok el, de remélem tudtok segíteni Esetleg ha valakinek van "szebb" megoldása, megköszönöm.
http://logout.hu/cikk/samsung_led_tv_tudastar_d_szeria/alapok.html
-
rum-cajsz
őstag
válasz InfiniteReality #1042 üzenetére
Csak annyi hiányzik, hogy a lekérdezésed most évenként jön fel, szóval kívülre kell még egy group by.
Vagy csinálsz egy nézetet a szétbontott táblákra, és akkor elég egy group by a nézetre.pl:
SELECT jatekos, sum(pont) FROM
(
SELECT jatekos, pont FROM jateklista2005 WHERE pont >= '1'
UNION
SELECT jatekos, pont FROM jateklista2006 WHERE pont >= '1'
)
GROUP BY jatekos
ORDER BY 2 DESC LIMIT 50[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
ArchElf
addikt
válasz InfiniteReality #1045 üzenetére
Tedd bele az union-t egy view-ba (vagy temp táblába), és az már majd lehet...
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]
-
InfiniteReality
őstag
válasz ArchElf #1046 üzenetére
Ennyire nem vágom mélyen a MySQL-t, esetleg leírnád hogyan állítsam össze a lekérdezést? Temp táblát nem szeretnék ehhez használni...
Ha ennyire nehéz az évekre bontott táblákból megoldani ezt a fajta lekérdezést, akkor hagyom egyben, de már 428ezer sort tartalmaz az adatbázisnak ez a táblája, s gondoltam az egyes évekre irányuló lekérdezések valamint az új beírások az aktuális évbe gyorsabbak lesznek, ha szétcsapom az egészet évekre...http://logout.hu/cikk/samsung_led_tv_tudastar_d_szeria/alapok.html
-
PazsitZ
addikt
válasz InfiniteReality #1045 üzenetére
SELECT jatekos, SUM(pont) AS pont FROM (
(SELECT jatekos, sum(pont) AS pont FROM jateklista2005 WHERE pont >= 1 GROUP BY jatekosl)
UNION
(SELECT jatekos , sum(pont) AS pont FROM jateklista2006 WHERE pont >= 1 GROUP BY jatekosl)
) AS sumtable
GROUP BY jatekos
ORDER BY pont DESC- http://pazsitz.hu -
-
martonx
veterán
válasz InfiniteReality #1045 üzenetére
miért ne lehetne az union-t group by-olni?
Másrészt 428 ezer sor miatt szedted szét?
Majd ha sok millió sor lesz benne. Talán inkább rendesen indexelni kellene, ha a 428 ezer sor lassú.Én kérek elnézést!
Új hozzászólás Aktív témák
- 2db Acer AW2000h F2 blade szerver 2x4db AW170H F2 blade-del eladó!
- HP Probook 340S G7 i5-1035G1/8GB/256SSD/Windows 11 -10% Csak ameddig a készlet tart!89.780 Ft
- iPhone 14 Pro 128 GB Space Black, 11 hónapos, kártyafüggetlen, 2024. május végéig garis , akku 91%
- Asus VivoBook X509JA-BQ904T
- HP EliteBook 640 G9 Ezüst (14" / Intel i5-1235U / 16GB / 512GB SSD / Win 11 Pro) -10% Most 203.990 F