- iPhone topik
- Vodafone mobilszolgáltatások
- Telekom mobilszolgáltatások
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Eleglide C1 - a középérték
- Milyen okostelefont vegyek?
- Android szakmai topik
- DIGI Mobil
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
Hirdetés
-
Nyár végén jön az idei THQ Nordic Digital Showcase
gp Az új bejelentések mellett újabb részleteket kapunk a Gothic Remake-ről és a Titan Quest II-ről is.
-
Snapdragon 8-as szériával várhatók a Honor 200-ak?
ma A Honor 200 állítólag a 8s Gen 3-at, a 200 Pro változat pedig a 8 Gen 3-at használja majd.
-
Az üzleti chatbot lehet az új fejőstehén
it Üzleti chatbotot indított az Anthropic, azt reméli, hogy sok pénz folyik majd be a cégektől.
Új hozzászólás Aktív témák
-
WonderCSabo
félisten
válasz rum-cajsz #746 üzenetére
Biztos jó ötlet név szerint csoportosítani? Mi van, ha van két azonos nevű oktató... A count-al meg sztem az oktatók óráinak számát akarja számoltatni, tehát a táblában hányszor fordulnak elő az azonos instuctor_id-k.
gaben: A 2. két select-et összevonhatod.
[ Szerkesztve ]
-
martonx
veterán
válasz rum-cajsz #813 üzenetére
Nem gondoltam, hogy lehet olyan eset, ahol az alselect gyorsabb lehet, de végülis mittudomén talán előfordulhat ilyen.
Éppen a héten optimalizáltam egy kolléga kódját, aki szerette az alselecteket (mondjuk régivágású programozók még emlékeznek az SQL-ek hőskorára, amikor NEM is létezett inner join - 2000-es évek előtt). Mit ne mondjak százezres tételszámoknál (mind főselect, mind alselect több százezer sor) perceket lehetett nyerni, hogy 4-5 inner joinba rendeztem át a cuccot.Tényleg és ti mit szóltok a temp táblákhoz? Múltkor ledöbbenve hallottam, hogy nem kellene használni őket. Szerintem ez hülyeség. Szerintetek? MSSQL alatt eléggé furcsállom, hogy ne kellene temp táblákat használni. Én még PostgreSQL, MySQL-ben is használok temp táblákat (8.0 felett, az ennél régebbiekben inkább csak elméleti lehetőség, mintsem gyakorlati).
Én kérek elnézést!
-
martonx
veterán
válasz rum-cajsz #815 üzenetére
Az volt a javaslat, hogy temp tábla helyett hozzunk létre minden esetben igazi táblákat. Belegondolni is nonszensz...
Megdöbbentő, hogy néha magukat szakértőnek kiadó emberek, cégek mennyire nem értenek az adott témához.
Azt mondták azért jobb a minden esetben fizikai tábla, mert azt jobban lehet optimalizálni. Ez akár igaz is lehetne, node legyen több száz, több ezer fizikai táblánk? Ki fogja ezt karbantartani, átlátni? Hülyék....Én kérek elnézést!
-
rum-cajsz
őstag
válasz rum-cajsz #887 üzenetére
A gyárban megtaláltam neked, ezzel lehet lekérdezni az aktuális selectet:
select sql_text from v$sqltext_with_newlines
where address = hextoraw(:sql_address)
and hash_value = :sql_hash_value
order by pieceAz :sql_address és a :sql_hash_value változókat pedig a v$session táblából tudod lekérdezni.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
bpx
őstag
-
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
-
Fecogame
veterán
-
Sk8erPeter
nagyúr
válasz rum-cajsz #1302 üzenetére
Idézem, amit itt írt:
"egy 10/11/12-ről megmondani, hogy mi volt az eredeti dátum 33%-os eséllyel lehet - és az adatbáziskezelő is ilyen eséllyel vesz fel jó értéket."
Ez egy jogos szempont, erre hogy alkalmazol dátumkonverziós függvényeket úgy, hogy biztosan a jó eredményt kapd?
Még akkor sem egyértelmű, ha legalább az évszám négy számjegyű, mert így is felcserélődhet a nap-hónap.====
(#1301) sztanozs : ez végül is igaz.
Mondjuk a UNIX timestamp (másodpercek) legalább tuti nem téved, aztán abból akármilyen formátumra is átalakíthatod.
A felhasználói inputnál meg normális esetben a normális fejlesztő úgyis megoldja, hogy a dátum szigorúbb feltételekhez legyen kötve, akár szétbontva a dátumot külön-külön mezőkre (év, hónap, nap, stb.), akár egy JavaScript-alapú datepickerrel egyszerűbbé téve a választást.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz rum-cajsz #1304 üzenetére
Na várj, szerintem elbeszélünk egymás mellett.
Senki nem is mondta eddig, hogy a prepared statement ne lenne jó, sőt, eddig mindenki amellett érvelt. Amit sztanozs felhozott, az az, hogy adatbázisonként eltérhet a datetime formátuma (erre én is linkeltem a MySQL-es, meg az MSSQL-es példát, hogy máshogy néz ki), ez már eleve problémát okozhat, tehát hiába adsz át stringként prepared statementtel valamit, ha a formátum akkor is rossz, mert mondjuk más formátumra van konfigurálva az adatbázisszerver, vagy mittudomén.
De már kezdek én is belezavarodni."Az a programozó, aki megengedi, hogy bármit beírhassanak a dátum típusú mezőbe, az megérdemli, hogy a tökén végigrobogjon egy GNU csorda."
Agreed.Sk8erPeter
-
martonx
veterán
válasz rum-cajsz #1323 üzenetére
mondjuk elnézve a problémákat (amellett, hogy access ellenes vagyok), pont nem az access maga a probléma, hanem egyrészt szarul lett felépítve a használt adatbázis, másrészt a program is szarul lett megírva ami ilyen duplikációkat hoz létre bele.
Ezek a hibák, ha béna a programozó, pont ugyanígy megmaradnak, bármilyen db motort is használjon az ember.Én kérek elnézést!
-
sztanozs
veterán
válasz rum-cajsz #1552 üzenetére
Más kérdés persze, hogy a keretrendszerek gyakran (?) nem készítenek tárolt eljárásokat, csak összehegesztik az adatstruktúrát és legenerálják a műveleteket közvetlen SQL utasításokként.
De végül is nem mindegy, hogy az ember keretrendszert haszál, vagy speciális környezetet fejleszt. Természetesen egy kis fejlesztésnél keretrendszer használatával az ember nem fog minden adat-reprezentációt kézzel megvalósítáani, mivel pont azért használ keretrendszert, hogy ezzel ne kelljen foglalkozni.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
-
martonx
veterán
válasz rum-cajsz #1582 üzenetére
hehe, ezen tényleg csak nevetni lehet.
Mondjuk ezt többször is hangoztattam, hogy leginkább MS SQL, PostgreSQL vonalon mozgok, néha egy kis MySQL-el, Oracle-el fűszerezve. Azért megkérdezném azt az oktatót, hogy mire alapozza amit mond (évtizedes berögzülés nem számít, illetve az Oracle 9i-re hivatkozást sem fogadom el érvként), és ugyan mutasson már egy példát.Én kérek elnézést!
-
martonx
veterán
válasz rum-cajsz #1584 üzenetére
MS SQL optimalizációit ismerve nagyon nem mindegy, hogy az sql motornak néhány soros (hangsúlyozom néhány), vagy ennél több, mondjuk pár százezer adattal kell dolgoznia. De hogy 100.000 vagy 100.000.000 az már édesmindegy. Klasszikus optimalizálási hiba tud lenni, hogy pár sornyi teszt adatokkal az sql-t beoptimalizálja a motor, majd amikor mindezt ráengeded 100.000-re akkor csodálkozol, hogy miért lassú.
De hogy jön ez a join-olás régi vagy új szintaktikájához? Nehogy már a használt join szintaktika határozza meg az sql motor optimalizálását.Én kérek elnézést!
-
martonx
veterán
válasz rum-cajsz #1586 üzenetére
Ezért is hangsúlyoztam mindenhol, hogy az Oracle-el felületesek (mondjuk azok nem túl pozitívak) az ismereteim, és egy szinte ismeretlen rendszerről nem volna etikus véleményt mondanom. Pláne, hogy történelmi okok miatt máig a legelterjedtebb db, annyira nem lehet rossz.
Őszintén én is bármit el tudok képzelni az Oracle db motor működéséről, de mivel az Oracle-höz bevallottan nem igazán értek, és db motor flame-be se akarok belemenni, maradjunk abban, hogy Oracle esetén akár igaz is lehet, hogy biztos ami biztos alapon érdemes a régi join szintaktikát használni.Én kérek elnézést!
-
PumpkinSeed
addikt
válasz rum-cajsz #2476 üzenetére
Ja igen az lemaradt. Miért lehet ez? <- a kérdés.
A változót teszteltem. Minden adatbevitel előtt kiírattam a változó értékét és mindig helyes adat volt benne. Ezenkívül teljesen random időnként kap 0 értéket. Semmi logikát nem véltem felfedezni benne.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
Louro
őstag
válasz rum-cajsz #2722 üzenetére
Szia,
decode-dal még nem néztem, de jó ötlet. Oracle az alap, de valamiért case esetén kiesnek az érintett sorok.
Decode-dal is megnéztem és úgyis csak kiejtette a találatokat.
A kód:
select id,name from somewhere
where 1=1
and decode (id, '1','A',
'2','B',
'3','C',
id) = idNem vagyok öregmotoros. Igyekszek a kérdéseim előtt azért utánanézni, szóval, ha kihagytam egy vesszőt, nem haragszok meg a segítségért
Mess with the best / Die like the rest
-
Khelben
nagyúr
válasz rum-cajsz #2729 üzenetére
Van időm rá, nem az a gond, hanem a visszahozhatatlanság. Tehát el kell tüntetni őket fizikailag a táblából, a logokból, esetleg magáról a hdd-ről is. Ha átadják a hdd-t egy sql gurunak, ő se tudja visszahozni.
(#2730) martonx : sajnos nem ilyen egyszerű, a delete csak töröltre állítja a sorokat, nem törli ki őket. De még ha törölné is, a logból bármikor vissza lehet őket állítani.
[ Szerkesztve ]
-
Sk8erPeter
nagyúr
válasz rum-cajsz #2752 üzenetére
Azt írta, hogy "van szám, szám per betű, számtólszámig és több más forma is." Szóval nem túl szabályos. A regexp, amit előbb írtam, a legegyszerűbb megközelítés, ha lenne több példaadat is, akkor persze könnyebb lenne több esetet is lefedő regexpet írni, de a megadott példaadatokkal ez is működik (ld. SQL Fiddle-példát).
Sk8erPeter
-
bambano
titán
válasz rum-cajsz #2752 üzenetére
ez azért nem jó, mert nem rendezi sorba az 5/a, 5/b, 5/c jellegű számokat.
az tűnik az elérhető legjobb megoldásnak, ha leválasztom az első számot, ebből lesz az első rendezési feltétel, kiveszem (ha van) a mínuszt és a pert, és ami utána van, abból csinálok egy másik rendezési feltételt. Ha ezt utcánként nézem, akkor annyira már nem elvadult a számozás, hogy túl nagy hibát vétsek. nyilván az összes lehetséges esetet ez nem fedi le, de úgy látom, hogy nem fordul elő minden kombináció minden utcában, tehát utcán belüli sorbarendezésre ez elég.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Új hozzászólás Aktív témák
- Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Milyen NAS-t vegyek?
- Milyen monitort vegyek?
- HP ProLiant MicroServer Gen8
- Helldivers 2 (PC, PS5)
- Milyen TV-t vegyek?
- Gördeszka topic
- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Xbox Series X|S
- További aktív témák...