- Honor 200 - kétszázért pont jó lenne
- iPhone topik
- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Milyen okostelefont vegyek?
- Mobil flották
- India felől közelít egy 7550 mAh-s Redmi
- Android alkalmazások - szoftver kibeszélő topik
- Profi EKG-s óra lett a Watch Fitből
- Honor 400 Pro - gép a képben
Új hozzászólás Aktív témák
-
fjanni
tag
válasz
rum-cajsz
#5994
üzenetére
Jelenleg van kb. 200 tábla, ez talán felmehet max. 500-ra, tehát nem olyan sok tábláról beszélünk.
Negyed óránként történik a szenzorokbol kiolvasás, ez lehet gáz fogyasztás számláló, vagy villamos energia számláló állás, tehát rekord sem lesz olyan sok.
Van még egy olyan gond is hogy nem ugyanabban az időben olvasnak ki minden szenzort, tehát nem 00/15/30/45 a datetime-ban a min értéke. Ez olyan gondot okoz hogy simán nem lehet join-al kapcsolni az adatokat ha pl. számolni akarok velük, hanem külön külön át kell előbb konvertálni a fent említett 15 perces osztásra és utána mehet a Join.
A fentebb javasolt View megoldás jó lehetne olyan szempontból is, hogy abban ezt az átalakítást már meg lehetne tenni, így a View-ből indított Query-k már egyszerűbbek lehetnek. Ezt úgy tenném meg hogy a legközelebbi 15 perces egész értékre tenném át a View-ban az adatot, de ügyelni kellene arra is hogy ha több olvasás is történt akkor is csak egyet használjon fel. Az új mérési pont belépésekor pedig elég lenne azt csak a View-be felvenni.
Értem azt hogy egy táblában kellene lenni az összes szenzor adatnak és minden adatnak legyen egy szenzor azonosítója pl. "MP001". De azt hogyan javasoljátok megtenni? Tehát lineárisan, azaz Union-al egymáshoz fűzni őket, vagy mátrix szerűen, egy rekordba összefűzni az összes adatot ami egy időponthoz tartozik? Ez utóbbi esetben Join-al az átkonvertált negyed órás adatokat lehetne felhasználni. Ez utóbbi a felhasználás szempontjából (műveletek végzése, Grafana diagramban megjelenítés) talán jobb lenne, de mivel a szenzor azonosítók lennének a mezőnevek, előre kellene definiálni az összes lehetséges MP mezőt hogy egy új MP esetén ne kelljen adatstruktúrát változtatni. Ez nem túl elegáns megoldás.
A View egyébként mindig a tartalmazza az összes adatot, azaz magától frissül?
Egyedi ID mezőt hogyan tudok ez esetben mellé tenni?Az említett Triggeres módszert nem ismerem, az mennyiben lenne más/jobb?
-
RedHarlow
aktív tag
válasz
rum-cajsz
#4209
üzenetére
Igen ismerem a cront, a probléma ott kezdődik, hogy hogy mentem excelbe az adatokat. Rendszeresen ki kell küldenünk bizonyos illetőknek adatokat excelben, dátumozva. Kettőt minden hónap elsején a harmadikat minden szerdán. Jelenleg windowson sql developerrel kérik le az adatokat és onnan másolják ki az excelben aztán outlook fájlok csatolása, küldés. Ezt szeretném valahogy automatizálni.
-
ALFA
senior tag
válasz
rum-cajsz
#3215
üzenetére
1. röviden annyi a lényeg, hogy a select eredménye lesz a paramétere a következő lekérdezésnek.
Asztatat értem, de nekem úgy tűnik, előre gondolkodik, vagy már valahonnan tudja, hogy honnan lehet további lekérdezéseket inditani és honnan nem. Ezt a logikát nem értem, hogyan oldják meg.
2. A PHP nyelven belül kellene átvenned az SQL témakört anblock.
Szivesen átvenném, de honnan?
php-vel nem foglalkoztam, illetve csak minimális szinten, mint a basic pár tucat parancsával anno.
3. szivesen átmentem volna a másik fórumba, bár ott is csak ezt az egy kérdést tenném fel, de a php programozás fórumban három napja nem válaszolt nekem senki, és amíg nem kapok választ, nincs jogosultságom újabb kérdést feltenni.
-
válasz
rum-cajsz
#3032
üzenetére
Máshogy írom le.
(Telesen más a téma, de itt csak körbeírnom szabad, ezért elnézést a hülye példáért.)
Table A-ba parkolóba érkező autókat viszek fel.
Mikor ezt felviszem, megnézi az autók listájában (Table B) a rendszám alapján, hogy az milyen autó. Ha a beérkező autó teherautó, akkor Table A-ból néhány mező Table C-be másolódik. -
bambano
titán
válasz
rum-cajsz
#2984
üzenetére
nem igazán látom, hogy ez hogy is működne.
a sum(decode(jóérték))) helyett elég lenne a select count(*) where mezo=joertek, de nem ez a kérdés.
az a kérdés, hogy egy ügyfélnek egy rekordja van, ha csak egy szolgáltatásra fizet elő és kettő, ha mindkét félére.
erre kellene valami szép megoldás, mert barkács módon én is meg tudom oldani. -
zolynet
veterán
válasz
rum-cajsz
#2814
üzenetére
Még 1 megoldás:
select top 1 * from prohardver
where helyes=1
order by time descsorszám oszlop bővítéssel, itt még nincs leszűrve arra hogy 1 rekordot adjon 1 user-re, de view-nak jó alap:
select *,ROW_NUMBER() over (order by time desc) sorszam
from prohardver
where helyes = 1
order by sorszamIdőre lehet használni a MAX függvényt is ha nem top 1-el akarunk játszani.
még1
select kvizid,name,
convert(char(10),time,120) as időpont
from prohardver
where helyes=1
group by kvizid,name,convert(char(10),time,120) -
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.
-
#2753
Sk8erPeter
nagyúr
rum-cajsz
#2752
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).
-
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.
-
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
-
#2477
PumpkinSeed
addikt
rum-cajsz
#2476
PumpkinSeed
addikt
-
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. -
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. -
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. -
#1556
Sk8erPeter
nagyúr
rum-cajsz
#1552
-
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.
-
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. -
#1305
Sk8erPeter
nagyúr
rum-cajsz
#1304
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. -
#1303
Sk8erPeter
nagyúr
rum-cajsz
#1302
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. -
#1155
Speeedfire
félisten
rum-cajsz
#1153
Speeedfire
félisten
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.
-
bpx
őstag
-
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.
-
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.... -
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).
-
#747
WonderCSabo
félisten
rum-cajsz
#746
WonderCSabo
félisten
Ez így túl egyszerű. 
Köszönöm.
.
Új hozzászólás Aktív témák
Hirdetés
- BESZÁMÍTÁS! Apple MacBook Pro 14 M4 Pro 24GB RAM 512GB SSD garanciával hibátlan működéssel
- HP Rack szerverek és tartozékok egyben vagy külön-külön
- BESZÁMÍTÁS! ASRock Z370 i5 8500 16GB DDR4 512GB SSD 2060 Super 8GB Zalman Z9 Plus Enermax 750W
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Konzol felvásárlás!! Xbox Series S, Xbox Series X
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest