- Fotók, videók mobillal
- Szívós, szép és kitartó az új OnePlus óra
- Xiaomi 17 Ultra - jó az optikája
- Yettel topik
- Xiaomi Watch 5 - kínai időszámítás
- Bemutatkozott az Oppo kamerás csúcsmodellje
- Apple iPhone 13 mini - miért nem veszik elegen?
- Poco F8 Ultra – forrónaci
- Samsung Galaxy S24 - nos, Exynos
- Google Pixel topik
Új hozzászólás Aktív témák
-
Mondjuk a főnök minden hétfő reggel 8-ra kér valami riportot excelben a mailboxába.
Lehet menne SQLből is, de ez pythonban tényleg csak egy pár sor. Mondjuk kell valami ütemező is. OK, ez épp pont nem data analysis , hanem csak egy kis automatizáció, de pont azt mutatja, hogy mennyi mindenre jó.
Én is most kezdek majd belemélyedni pythonba a sok SQL-ezés mellett, mert össze akarok rakni egy dashboardot arról, hogy 1. megy a rendszer 2. jók az adatok.
De ha nagyon tanulni akarsz valamit az SQL mellett akkor lehet érdemes megnézned az AWS-t vagy Azure-t. Most ezek a menő dolgok...a python mellett persze.
-
Mondjuk a főnök minden hétfő reggel 8-ra kér valami riportot excelben a mailboxába.
Lehet menne SQLből is, de ez pythonban tényleg csak egy pár sor. Mondjuk kell valami ütemező is. OK, ez épp pont nem data analysis , hanem csak egy kis automatizáció, de pont azt mutatja, hogy mennyi mindenre jó.
Én is most kezdek majd belemélyedni pythonba a sok SQL-ezés mellett, mert össze akarok rakni egy dashboardot arról, hogy 1. megy a rendszer 2. jók az adatok.
De ha nagyon tanulni akarsz valamit az SQL mellett akkor lehet érdemes megnézned az AWS-t vagy Azure-t. Most ezek a menő dolgok...a python mellett persze. -
Köszönöm. Nekem is ez a legizgalmasabb a jelenlegi munkámban, bár többnyire SQL-ben oldom meg. Persze a vizualizáció Excel-ben történik - sajnos.
Esetleg tudsz mondani egy példát, hogy mi az, amit SQL-ben nem lehet vagy rosszabbul, mint Python-ban? De érzem, hogy pont a vizualizáció lesz a kulcs
Mondjuk a főnök minden hétfő reggel 8-ra kér valami riportot excelben a mailboxába.
Lehet menne SQLből is, de ez pythonban tényleg csak egy pár sor. Mondjuk kell valami ütemező is. OK, ez épp pont nem data analysis , hanem csak egy kis automatizáció, de pont azt mutatja, hogy mennyi mindenre jó.
Én is most kezdek majd belemélyedni pythonba a sok SQL-ezés mellett, mert össze akarok rakni egy dashboardot arról, hogy 1. megy a rendszer 2. jók az adatok.
De ha nagyon tanulni akarsz valamit az SQL mellett akkor lehet érdemes megnézned az AWS-t vagy Azure-t. Most ezek a menő dolgok...a python mellett persze. -
A Python ott jön a képbe, hogy a Data Science szakmának maga az adatlekérdezés része a legkevesebb, senki nem ettől lesz data scientist. Hanem utána jön az adatok elemzése, vizualizálás, statisztikák, és erre jelenleg a legelterjedtebb a Python (megjegyzés: kb. bármilyen nyelv is jó erre pl. java, c#). Ettől még csomó esetben Python nem is kell a gépre, mert különböző IDE-kben, GUI-kon keresztül elég megírni pythonban a cuccokat, és az majd úgyis a szerveren fog futni.
Köszönöm. Nekem is ez a legizgalmasabb a jelenlegi munkámban, bár többnyire SQL-ben oldom meg. Persze a vizualizáció Excel-ben történik - sajnos.
Esetleg tudsz mondani egy példát, hogy mi az, amit SQL-ben nem lehet vagy rosszabbul, mint Python-ban? De érzem, hogy pont a vizualizáció lesz a kulcs
-
Most jövök a kérdéseimmel
A képzések kapcsán végül a felhő alapú BI-t kezdtem el a M$ oldalán.De párhuzamosan Python-t is.
Ezutóbbival kapcsolatban lenne egy olyan kérdésem, hogy mi lehet a Python mellett erős érv, amivel meg lehetne indokolni, hogy "kell a Python a gépekre"? Este a Stackoverflow-t olvasgatva nem nagyon találtam érvet a Python mellett. Értem, hogy az egyik egy lekérdező nyelv, másik pedig programozási. De mégis rengeteg adattudós (, de csúnya így magyarul) használ Python-t. Csak még nem látom hol jön a képbe. Aggregáció során SQL nyert. ETL során az adatok manipulálását SQL-ben is el tudnám végezni.
Elnézést, ha láma kérdés, de inkább kérdezek. (Tanulnom kell valamit, mert már pár éve csak toporgok az SQL-ben és nem hinném, hogy 20 év múlva is piacképes maradnék csak SQL-lel.)
-
Louro
őstag
Most jövök a kérdéseimmel
A képzések kapcsán végül a felhő alapú BI-t kezdtem el a M$ oldalán.De párhuzamosan Python-t is.
Ezutóbbival kapcsolatban lenne egy olyan kérdésem, hogy mi lehet a Python mellett erős érv, amivel meg lehetne indokolni, hogy "kell a Python a gépekre"? Este a Stackoverflow-t olvasgatva nem nagyon találtam érvet a Python mellett. Értem, hogy az egyik egy lekérdező nyelv, másik pedig programozási. De mégis rengeteg adattudós (, de csúnya így magyarul) használ Python-t. Csak még nem látom hol jön a képbe. Aggregáció során SQL nyert. ETL során az adatok manipulálását SQL-ben is el tudnám végezni.
Elnézést, ha láma kérdés, de inkább kérdezek. (Tanulnom kell valamit, mert már pár éve csak toporgok az SQL-ben és nem hinném, hogy 20 év múlva is piacképes maradnék csak SQL-lel.)
-
Utóbbi pár évben járt nálunk pár webváltós arc, többek között Oracle fejlesztők és egy DBA is.
Fő profiljuk elvileg az oktatás, céges tanfolyamok szervezése, de szoktak cégekhez szakértőket és/vagy frissen képzetteket kölcsönözni is. (Kb. mint a csapból is csöpögő IT gyorstalpalók: GreenFox, Training360)
[szerk:]Hmm, fél misi náluk egy egyhetes (40 óra) Oracle DBA tanfolyam?
Kb. annyi, mint a feljebb linkelt Számalknál. -
Én is mellőzöm a right join-t, mert az agyunk balról jobbra értelmez. De, amikor mondja, hogy mi a feladat és hogyan kezdet neki, akkor ott volt,hogy right kellett volna. Amikor nagyon junior voltam, szégyeltem volna olyan kérdéseket feltenni, mint amiket én kapok manapság.
A senior-nak is már ajánlottam az sqlzoo.net oldalt és tegnap találtam az Oracle oldalán is egy tök jó leírást kezdőknek, ahol elég sok példa mentén van elmagyarázva.
Kicsit ON is legyek. Már 8 éve SQL-ezek. Bár nem tartom magam veteránnak kódismeret szintjén, de 5 év Oracle és most 3 év T-SQL a hátam mögött kicsit tovább lépnék. DBA irány szimpatikus. Van olyan iskola, ami különösen ajánlott vagy nagyon kerülendő?
-
Bár multi, de a smucig fajta. Inkább önerőből oldom meg. A VBA-t és az SQL-t is autodidakta módon tanultam meg. De úgy érzem eljutottam arra a szintre, hogy ezt nem oldom meg önerőből.
Ahogy este olvasgattam, az SQL Server képzések szimpatikusabbnak tűnnek. Persze oda is kell más alapozó ismeret.
Eddig csak bőszen írtam az SQL-eket és próbáltam figyelni a performanciára.
-
Egyáltalán kellhet valamihez a right join?
Vagy csak én kezdem mindig a fix adattartalmú táblákkal a lekérdezést, és ahhoz left joinolom az opcionálisakat?
Legalábbis az én fejemben ez a kettő ekvivalens:
select a.*,b.*
from a
right join b
on b.id=a.id;
select a.*,b.*
from b
left join a
on a.id=b.id;(Sima select * esetén az adattartalom ugyanaz lenne, csak a táblák oszlopainak sorrendje változna.)
-
Iskola alatt tanfolyamos cégekre gondolsz? Olyanok vannak, illetve, hát, az Oracle-nak vannak különböző adminisztrációs tanfolyamai aranyárban. Szerintem ezeket olyanok tarthatják csak akik tudnak hozzá infrastruktúrát (sandbox-okat) biztosítani, akárki nem. Én kb. ezekkel kezdeném:
12c administration , Grid infrastructure
Lehet vannak újabbak is belőle. Viszont nem 2 fillérek. Valahogy a cégedet, ahol dolgozol, kéne rávenni, hogy finanszírozzák. Illetve ha multi akkor be kellene rotálni a DBA csapatba. -
Én is mellőzöm a right join-t, mert az agyunk balról jobbra értelmez. De, amikor mondja, hogy mi a feladat és hogyan kezdet neki, akkor ott volt,hogy right kellett volna. Amikor nagyon junior voltam, szégyeltem volna olyan kérdéseket feltenni, mint amiket én kapok manapság.
A senior-nak is már ajánlottam az sqlzoo.net oldalt és tegnap találtam az Oracle oldalán is egy tök jó leírást kezdőknek, ahol elég sok példa mentén van elmagyarázva.
Kicsit ON is legyek. Már 8 éve SQL-ezek. Bár nem tartom magam veteránnak kódismeret szintjén, de 5 év Oracle és most 3 év T-SQL a hátam mögött kicsit tovább lépnék. DBA irány szimpatikus. Van olyan iskola, ami különösen ajánlott vagy nagyon kerülendő?
Iskola alatt tanfolyamos cégekre gondolsz? Olyanok vannak, illetve, hát, az Oracle-nak vannak különböző adminisztrációs tanfolyamai aranyárban. Szerintem ezeket olyanok tarthatják csak akik tudnak hozzá infrastruktúrát (sandbox-okat) biztosítani, akárki nem. Én kb. ezekkel kezdeném:
12c administration , Grid infrastructure
Lehet vannak újabbak is belőle. Viszont nem 2 fillérek. Valahogy a cégedet, ahol dolgozol, kéne rávenni, hogy finanszírozzák. Illetve ha multi akkor be kellene rotálni a DBA csapatba. -
Egyáltalán kellhet valamihez a right join?
Vagy csak én kezdem mindig a fix adattartalmú táblákkal a lekérdezést, és ahhoz left joinolom az opcionálisakat?
Legalábbis az én fejemben ez a kettő ekvivalens:
select a.*,b.*
from a
right join b
on b.id=a.id;
select a.*,b.*
from b
left join a
on a.id=b.id;(Sima select * esetén az adattartalom ugyanaz lenne, csak a táblák oszlopainak sorrendje változna.)
-
-
Igen, erre van a HAVING feltétel (aggregált kifejelzés ellenőrzésére, pl a darab több, min 3
kiscica).select
1 + 2 as harom,
null as ertek2,
created as letrehozva,
sum(user_id) as valami,
count(*) as darab,
'hello' as ertek3
from
dba_users
group by
created
having
count(*) > 3
order by
harom,
letrehozvaKöszönöm
-
Apollo17hu
őstag
Bocsánat mindenkitől, a group by-ba tévesen Erteket írtam. Ott egy második mező van, amely szintén kell az összegzés
select 'adat' ad, ID, nev, nev2, ertek1, ertek2
from tabla
union
select "osszesen" ad, ID, null nev, ID2, sum(ertek) ertek1, null ertek2
from tabla
group by id, id2
order by ID, ad -
Group by után minden olyan mezőt fel kell sorolni, ami nem szerepel az oszlopfüggvények paraméterében.
Ha van egy fixen 'kiscica' oszlopod, akkor azt is.
Értelmes interpreterrel bíró DBken valahogy így nézne ki:
select "osszesen" ad, ID, null nev, sum(ertek) ertek1, null ertek2, null ertek3, null ertek4,
null ertek5
from tabla
group by id, ad, nev, ertek2, ertek3, ertek4, ertek5;Kevésbé értelmeseken valahogy így:
group by id, 1, 3, 5, 6, 7, 8;(Ha már a hülye Oracle nem tud alias alapján rendezni, csoportosítani, csak oszlopszámmal...)
-
Hali, ennek tutira mennie kellene:
select 'adat' ad, ID, nev, ertek
from tabla..
union
select "osszesen" ad, ID, null nev, sum(ertek)
from tabla..
group by idha pedig van 5 érték, amiből csak az elsőt summázod, a többi meg üres lesz a végén:
select 'adat' ad, ID, nev, ertek1, ertek2, ertek3, ertek4, ertek5
from tabla
union
select "osszesen" ad, ID, null nev, sum(ertek) ertek1, null ertek2, null ertek3, null ertek4, null ertek5
from tabla
group by idSőt a végén még össze is rendezheted, hogy minden ID-hez a a felsprplás végére tegye az összeget, ne a tábla végére ID-nként:
select * from (
select 'adat' ad, ID, nev, ertek1, ertek2, ertek3, ertek4, ertek5
from tabla
union
select "osszesen" ad, ID, null nev, sum(ertek) ertek1, null ertek2, null ertek3, null ertek4,
null ertek5
from tabla
group by id)
order by ID, ad -
Hali, ennek tutira mennie kellene:
select 'adat' ad, ID, nev, ertek
from tabla..
union
select "osszesen" ad, ID, null nev, sum(ertek)
from tabla..
group by idha pedig van 5 érték, amiből csak az elsőt summázod, a többi meg üres lesz a végén:
select 'adat' ad, ID, nev, ertek1, ertek2, ertek3, ertek4, ertek5
from tabla
union
select "osszesen" ad, ID, null nev, sum(ertek) ertek1, null ertek2, null ertek3, null ertek4, null ertek5
from tabla
group by idSőt a végén még össze is rendezheted, hogy minden ID-hez a a felsprplás végére tegye az összeget, ne a tábla végére ID-nként:
select * from (
select 'adat' ad, ID, nev, ertek1, ertek2, ertek3, ertek4, ertek5
from tabla
union
select "osszesen" ad, ID, null nev, sum(ertek) ertek1, null ertek2, null ertek3, null ertek4,
null ertek5
from tabla
group by id)
order by ID, ad -
-
-
-
Alapvetően jó az elképzelés, de ezt lehet egyszerűbben is írni, mivel joinolt táblákat is tudsz szummázni:
SELECT
vasarlo.id,
vasarlo.nev,
sum(vasarlas.darab*vasarlas.vetelar) koltes_osszesen
FROM t_vasarlo vasarlo
INNER JOIN t_vasarlas vasarlas
ON vasarlas.vasarlo_id = vasarlo.id
GROUP BY vasarlo.id, vasarlo.nev;
Köszönöm. -
Adatbázis ugyan az: [kép]
Feladat: Írjon egy SQL utasítást, amely kilistázza a vásárlók azonosítóját és nevét, valamint azt, hogy mennyit költött az adott vásárló társasjátékokra a vásárlásai során! Az összeg meghatározásakor a vásárlás vételárát és a vásárolt termékek darabszámát is vegye figyelembe!
Erre ez a megoldásom:
SELECT
vasarlo.id,
vasarlo.nev,
vasarlas.koltes_osszesen
FROM t_vasarlo vasarlo INNER JOIN ( SELECT
vasarlo_id,
sum(darab*vetelar) koltes_osszesen
FROM t_vasarlas
GROUP BY vasarlo_id) vasarlas
ON vasarlas.vasarlo_id = vasarlo.id;Ránézésre jó adatokat ad vissza a kérdésem inkább arra vonatkozna, hogy logikusan építettem fel a lekérdezést vagy van ennél kézenfekvőbb megoldás?
Köszönöm!
-
Sziasztok,
Adott az alábbi adatbázis:
[kép]
Szeretném megkapni a legdrágább társasjátékok neveit. Az első fele megy, kitudom gyűjteni a legdrágább árakat:SELECT
tarsasjatek_id, MAX(ar)
FROM t_cikk
GROUP BY tarsasjatek_id
order by tarsasjatek_id;Viszont nem tudom hogy húzzam be a társasjátékok neveit ID alapján a t_tarsasjatek táblából.
Sejtem, hogy egy beágyazott select kell, de nem tudom összerakni a logikáját fejben
-
Sziasztok,
Adott az alábbi adatbázis:
[kép]
Szeretném megkapni a legdrágább társasjátékok neveit. Az első fele megy, kitudom gyűjteni a legdrágább árakat:SELECT
tarsasjatek_id, MAX(ar)
FROM t_cikk
GROUP BY tarsasjatek_id
order by tarsasjatek_id;Viszont nem tudom hogy húzzam be a társasjátékok neveit ID alapján a t_tarsasjatek táblából.
Sejtem, hogy egy beágyazott select kell, de nem tudom összerakni a logikáját fejben
-
vamzi
senior tag
Sziasztok,
Adott az alábbi adatbázis:
[kép]
Szeretném megkapni a legdrágább társasjátékok neveit. Az első fele megy, kitudom gyűjteni a legdrágább árakat:SELECT
tarsasjatek_id, MAX(ar)
FROM t_cikk
GROUP BY tarsasjatek_id
order by tarsasjatek_id;Viszont nem tudom hogy húzzam be a társasjátékok neveit ID alapján a t_tarsasjatek táblából.
Sejtem, hogy egy beágyazott select kell, de nem tudom összerakni a logikáját fejben
-
user112
senior tag
select id
,sum(adat1)
,sum(adat2)
,sum(case when ho=2 then adat3 else 0 end)
,sum(case when ho=9 then adat4 else 0 end)Tökéletes köszönöm.
-
Apollo17hu
őstag
Sziasztok!
Egy táblából összesített adatokat szedek le, de lenne köztük pár egyedi feltételnek megfelelő adat is: pl: select id, sum(adat1), sum(adat2),adat3, adat4 ahol adat3 csak pl a ho=2 adatsor értéke legyen, az adat4 pedig a ho=9-é.
Hogyan tudom ezt megcsinálni? Belső select? Szeretném egy sorban megjeleníteni. Oracle
Köszönöm. -
Ezeket egy selectben nem tudod összeszedni, mivel az oszlopfüggvények egymástól függetlenül értékelődnek ki.
Tehát nem max(valid_from)-hoz tartozó min(valid_to) értéket kapod vissza, hanem a globálisat.Maximum azt tudod tenni, hogy egy belső selectben leválogatod a max(valid_from)-okat minden termékhez, majd az a köré írt másik selectben kiveszed a min(valid_to)-t.
Valahogy így:
select product,
price
from products p
join (select
p1.product,
a.max_valid_from,
min(nvl(p1.valid_to, to_date('9999-12-31'))) min_valid_to
from products p1
join (select p2.product,
max(nvl(p2.valid_from, to_date('0000-01-01'))) max_valid_to
from products p2
group by p2.product) a
on a.product = p1.product
and a.max_valid_from = p1.valid_from
group by p1.product, a.max_valid_from) b
on b.product = p.product
and b.max_valid_from = nvl(p.valid_from, to_date('0000-01-01'))
and b.min_valid_to = nvl(p.valid_to, to_date('9999-12-31'));Oszlopfüggvények alapból figyelmen kívül hagyják a nullokat!
-
-
-
-
Apollo17hu
őstag
-
Nyilván, de a fórumtárs írta is, hogy otthonra rakná fel, tanulási célból, én erre javasoltam, hogy akkor csavarja le a memória használatot, és probléma megoldva. Gondolom otthon úgyse 2TB-s táblákat fog egymáshoz joinolni
Természetesen, otthon használatra megy, tanulásra - hobby célokra. Vagyis kb. zéró terhelés, max 1-2 user egyidejű kiszolgálása lesz. Eddig max 3000-es táblám volt a legnagyobb (retro számítógép program kategorizálásnál). De ez sem jellemző.
Szóval tényleg nem kell sok. Viszont most felhőbe menne majd cucc és jelenleg 1GB RAM-ot bérelek, szeretném, ha ennyi is maradnaDesktop gépen (win10) sikerült még az 5.7-est leszorítanom alapjáratban 30MB körüli értékre. [kép]
A 8-ast is megpróbálom valamennyire visszavenni (win10 / linux), de majd kiderül hogy sikerült. -
Egyébként MySql-nek (meg amúgy bármelyik SQL-nek) tök jól lehet paraméterezni a memória foglalását.
A teljesítmény rovására.
Nézz meg egy ingyenes, egy procimag+1GB RAMra limitált MS SQL licenszet, meg a rendes verzióját.
DB tipikusan olyan alkalmazási terület, ahol a több RAM mindig jobb.
Persze ha van három táblád, 10-10 sorral, akkor az 1GB is elég lehet, de párezer soros táblák joinolgatásánál már észreveszed a különbséget.
Nyilván, de a fórumtárs írta is, hogy otthonra rakná fel, tanulási célból, én erre javasoltam, hogy akkor csavarja le a memória használatot, és probléma megoldva. Gondolom otthon úgyse 2TB-s táblákat fog egymáshoz joinolni
-
Egyébként MySql-nek (meg amúgy bármelyik SQL-nek) tök jól lehet paraméterezni a memória foglalását. Emlékeim szerint a MySql defaultban nagyon is visszafogottan foglal memóriát (rendszergazdák első MySql optimalizációja szokott lenni, átírni a memória foglalást valami egészségesebbre).
Szóval szerintem tedd fel nyugodtan. -
-
Egy lekérdezésben kérném segítségeteket.
Hogyan tudom megírni úgy a lekérdezést, hogy válasszak két rekord közül.
Van egy árlista tábla. Elég hülyén van kitöltve, de ez most mindegy.
Van egy árnak kezdő érvényességi dátuma, ez kötelező, és lehet befejező dátuma, ez nem kötelező. Az indexelés úgy van belőve, hogy lehet olyan rekord, hogy azonos a kezdő dátum, azonos lehet az ár is, de nem feltétlenül, de az egyiknél van záró dátum, másiknál nincs. Na, ha ilyen duplikációk vannak, akkor azt kell vennem, ahol van záró dátum, ha nincs duplikáció, akkor jó a záró dátum nélküli is. Soha nem láttam még ennyire hülye megoldást, de ezzel kell élni. -
Apollo17hu
őstag
Egy lekérdezésben kérném segítségeteket.
Hogyan tudom megírni úgy a lekérdezést, hogy válasszak két rekord közül.
Van egy árlista tábla. Elég hülyén van kitöltve, de ez most mindegy.
Van egy árnak kezdő érvényességi dátuma, ez kötelező, és lehet befejező dátuma, ez nem kötelező. Az indexelés úgy van belőve, hogy lehet olyan rekord, hogy azonos a kezdő dátum, azonos lehet az ár is, de nem feltétlenül, de az egyiknél van záró dátum, másiknál nincs. Na, ha ilyen duplikációk vannak, akkor azt kell vennem, ahol van záró dátum, ha nincs duplikáció, akkor jó a záró dátum nélküli is. Soha nem láttam még ennyire hülye megoldást, de ezzel kell élni. -
Egy lekérdezésben kérném segítségeteket.
Hogyan tudom megírni úgy a lekérdezést, hogy válasszak két rekord közül.
Van egy árlista tábla. Elég hülyén van kitöltve, de ez most mindegy.
Van egy árnak kezdő érvényességi dátuma, ez kötelező, és lehet befejező dátuma, ez nem kötelező. Az indexelés úgy van belőve, hogy lehet olyan rekord, hogy azonos a kezdő dátum, azonos lehet az ár is, de nem feltétlenül, de az egyiknél van záró dátum, másiknál nincs. Na, ha ilyen duplikációk vannak, akkor azt kell vennem, ahol van záró dátum, ha nincs duplikáció, akkor jó a záró dátum nélküli is. Soha nem láttam még ennyire hülye megoldást, de ezzel kell élni. -
Egy lekérdezésben kérném segítségeteket.
Hogyan tudom megírni úgy a lekérdezést, hogy válasszak két rekord közül.
Van egy árlista tábla. Elég hülyén van kitöltve, de ez most mindegy.
Van egy árnak kezdő érvényességi dátuma, ez kötelező, és lehet befejező dátuma, ez nem kötelező. Az indexelés úgy van belőve, hogy lehet olyan rekord, hogy azonos a kezdő dátum, azonos lehet az ár is, de nem feltétlenül, de az egyiknél van záró dátum, másiknál nincs. Na, ha ilyen duplikációk vannak, akkor azt kell vennem, ahol van záró dátum, ha nincs duplikáció, akkor jó a záró dátum nélküli is. Soha nem láttam még ennyire hülye megoldást, de ezzel kell élni. -
Használ valaki itt mssql-hez schema compare toolt?
Átraktuk az adatbázist a .net source controlba, és a módosításokat az sql schema comparrel töltjük vissza, de iszonyat lassú, és nem igazán találok rá megoldást. Pedig remek eszköz lenne, ha normálisan lehetne használni, de egy pár tábla módosítás visszaírása is 25 percig fut, ami hát nem túl hatékony. De egy check/unchek is el tud futni percekig...
-
-
a probléma pár órás tojtorozása után nekem úgy tűnik, hogy a legegyszerűbb megoldás a következő:
csinálsz egy táblát, olyan szerkezettel, ami neked tetszik, plusz hozzáadsz egy oszlopot, pl. sor néve, text típussal:tmp=> \d merestmpTable "public.merestmp"Column | Type | Collation | Nullable | Default--------+------------------+-----------+----------+--------------------------------------id | bigint | | not null | nextval('merestmp_id_seq'::regclass)subid | bigint | | |azon | text | | |meres1 | double precision | | |meres2 | double precision | | |meres3 | double precision | | |meres4 | double precision | | |sor | text | | |utána belemásolod az input fájljaidat úgy, hogy a szövegből minden sort egyben tegyen bele a sor mezőbe:
\copy merestmp(sor) from '/tmp/mteszt.txt';Majd adatbáziskezelős függvényekkel szétszeded a sorokat.
update merestmp set subid=id,azon=trim(both from sor) where array_length(regexp_split_to_array(sor,' +'),1)=1;ezek után a subid-t beállítod az előtte levő sorra:
update merestmp m1 set subid=(select max(subid) from merestmp m2 where m2.id<m1.id) where array_length(regexp_split_to_array(sor,' +'),1)=5;
ennél a megoldásnál nyilván van szebb is, windowing funkciókkal...
utána már csak regexp-ekkel ki kell szedni a mezőket a sorból és betenni a helyükre. -
Sziasztok!
Egy elég alap lekérdezést szeretnék csinálni. Ma kaptunk a cégnél egy hibakezelő rendszer ahol egyben van az összes lezárt hiba.
status=resolved ezzel megkapom a megoldott hibákat de a "Dealer name" oszlopból ki akarom választani az én kódomat és csak azokat akarom látni amikhozzám tartozik akkor ezt a kódot hogyan folytassam? Dealer name=kód ? Közel 10 éve nem foglalkozta sql lekérdezéssel.
Azt még nem írtam le, hogy JQL.
Köszi a segítséget! -
cekkk
veterán
Sziasztok!
Egy elég alap lekérdezést szeretnék csinálni. Ma kaptunk a cégnél egy hibakezelő rendszer ahol egyben van az összes lezárt hiba.
status=resolved ezzel megkapom a megoldott hibákat de a "Dealer name" oszlopból ki akarom választani az én kódomat és csak azokat akarom látni amikhozzám tartozik akkor ezt a kódot hogyan folytassam? Dealer name=kód ? Közel 10 éve nem foglalkozta sql lekérdezéssel.
Azt még nem írtam le, hogy JQL.
Köszi a segítséget! -
MS SQL-ben valami ötlet erre? Azonosító+dátum és adat sorok követik egymást.
Többszáz megás textben van de így tagolva be tudom tenni egy táblába.
A következő azonosítóig tartanak a hozzá tartozó adatok.
Full változó az adadatsorok száma egy blokkon belül.
Na ebből kellene egy select azonosító, dátum, mező1....5 végül.
-
nem ismerem az mssql-t, postgresql-ben így csinálnám:
csinálnék egy táblát, amiben van egy id mező, aminek serial (más adatbáziskezelőkben autoincrement), meg van benne egy másik id2 mező, aminek a defaultja egy serial aktuális értéke, van egy text mező, meg négy real.
tennék rá egy szabályt, hogyha mind a négy real mezője null, akkor a második mezőt növelje egyel és úgy húzza be a többi sort.szerk: persze a triviális megoldás az, ha awk-val insert-té alakítod a fájlokat.
szerk2: esetleg dobj fel valahova 3-4 ilyen kis fájlt, amivel kísérletezni lehet.
Oh tényleg, AWK, imádok vele pepecselni.
-
MS SQL-ben valami ötlet erre? Azonosító+dátum és adat sorok követik egymást.
Többszáz megás textben van de így tagolva be tudom tenni egy táblába.
A következő azonosítóig tartanak a hozzá tartozó adatok.
Full változó az adadatsorok száma egy blokkon belül.
Na ebből kellene egy select azonosító, dátum, mező1....5 végül. -
MS SQL-ben valami ötlet erre? Azonosító+dátum és adat sorok követik egymást.
Többszáz megás textben van de így tagolva be tudom tenni egy táblába.
A következő azonosítóig tartanak a hozzá tartozó adatok.
Full változó az adadatsorok száma egy blokkon belül.
Na ebből kellene egy select azonosító, dátum, mező1....5 végül. -
MS SQL-ben valami ötlet erre? Azonosító+dátum és adat sorok követik egymást.
Többszáz megás textben van de így tagolva be tudom tenni egy táblába.
A következő azonosítóig tartanak a hozzá tartozó adatok.
Full változó az adadatsorok száma egy blokkon belül.
Na ebből kellene egy select azonosító, dátum, mező1....5 végül. -
Petya25
őstag
Fix szélesek az oszlopok, ugye? INSTR(), SUBSTR(), TRIM() jellegű függvényekkel ki tudod mazsolázni belőle mind a 7 mezőt. A SELECT után 7 db függvénykombináció adná ki a 7 db mezőt.
-
Apollo17hu
őstag
MS SQL-ben valami ötlet erre? Azonosító+dátum és adat sorok követik egymást.
Többszáz megás textben van de így tagolva be tudom tenni egy táblába.
A következő azonosítóig tartanak a hozzá tartozó adatok.
Full változó az adadatsorok száma egy blokkon belül.
Na ebből kellene egy select azonosító, dátum, mező1....5 végül. -
Petya25
őstag
MS SQL-ben valami ötlet erre? Azonosító+dátum és adat sorok követik egymást.
Többszáz megás textben van de így tagolva be tudom tenni egy táblába.
A következő azonosítóig tartanak a hozzá tartozó adatok.
Full változó az adadatsorok száma egy blokkon belül.
Na ebből kellene egy select azonosító, dátum, mező1....5 végül. -
Szia,
ha jól értem lesz két tábla. A kettő között a kapcsolatot a "gyógyszerkészítmény" fogja adni.
Egyik táblában az összetételek lesznek. Feltételezem soronként. Kicsit furcsa lenne olyan struktúra, hogy összetétel1, összetétel2, összetétel3,.... .
Másik táblában a tulajdonságok lesznek. Feltételezem itt is soronként lesznek felsorolva a hatások.Ha a számomra "furcsa" megoldás van, akkor simán JOIN-nal összeköthetőek. Ugyanaz, mint a VLOOKUP az Excelben
A másik megoldás esetén simán mellé tenni, LEFT JOIN-nal nem érdemes, mert összes lehetséges párosítást adná vissza, ami biztos nem jó. PIVOT kicsit macera kezdőként.
Én személy szerint soronként tárolnám mindkét táblát. Az összetevőket és a tulajdonságokat is katalogizálnám. Azaz bevezetnék egy táblát, amiben egyes adatok kapnának egy azonosítót és a két táblában csak az azonosítókat kellene eltárolni. Később lehet meghálálja a rendszer és a tárhely. Például a penicilin szót eltárolni 9 karakter, de ha ez a 17-es kódú összetevő, akkor ez egy sokkal kisebb helyet igénylő adat.Példa:
1-es azonosítójú gyógyszerkészítmény eseténElső tábla
1 - összetevő: por
1 - összetevő: víz
1 - összetevő: penicilinMásik tábla:
1 - tulajdonság: Fejfájás
1 - tulajdonság: HányingerHa ezt kötöd össze, akkor ilyet kapnál:
1 - összetevő: por - tulajdonság: Fejfájás
1 - összetevő: víz - tulajdonság: Fejfájás
1 - összetevő: penicilin - tulajdonság: Fejfájás
1 - összetevő: por - tulajdonság: Hányinger
1 - összetevő: víz - tulajdonság: Hányinger
1 - összetevő: penicilin - tulajdonság: HányingerNa ez jó hosszú lett. Jó lenne ismerni a kiindulási alapot. Akár fake adatokkal összedobsz egyet a Google Drive-on, talán könnyebb lenne a megoldást megtalálni.
-
Apollo17hu
őstag
Oké, azt hiszem nem jól fogalmaztam. Ígérem, ez az utolsó off.
Az, hogy az optimalizálatlan lekérdezések miatt lassú a szolgáltatás, gondolom kimeríti a fejesek felett állók igényeinek kielégítését. Az, hogy nincs elég kapacitás tesztelni, optimalizálni, backupot készíteni ínségesebb időkre, ésatöbbi, mind mind a szolgáltatás színvonalát befolyásolja. Ha az ún. fejes (vagy a felette álló) azt hiszi, hogy nem, akkor vagy hülye vagy igénytelen. Szerény véleményem szerint.
Azzal takarózni, hogy valami túl kocka, ezt nem tudom hova tenni. Ha valami kocka, akkor nincs köze a szolgáltatás színvonalához? Az igényességhez? Ha fejesnek ez túl kocka, akkor miért használ számítógépet? Dolgozzon kockás füzetben, és szolgáltasson abból! Vagy ha az is túl kocka, akkor vonalas füzetből.Bocsánat a kirohanásomért, csak pont ebből lett elegem az IT szférában, és érzékenyen tudok reagálni a hasonló hozzáállásra. Kiborító, amikor azt hallom egy menedzsertől, hogy csak dobj össze valamit, csak működjön; menjen élesbe, mindjárt határidő; ezeknek így is jó lesz, és hasonló szóvirágok. Többnyire ugyanez a menedzser kongatja a vészharagot, hogy nagy baj van a projekten, több erőforrást kell bevonni; azonnali tűzoltásra van szükség; lehalt az éles szerver, mindenki hétvégézik; ha ez ma nem lesz kész, holnap már nem kell bejönnöd; ha ezt megcsinálod még ma, holnap kapsz egy sütit. A fejlesztő meg nyilván megtörik, és inkább hekkel, drótoz, gányol. Mert azt jutalmazzák, aki vilámgyorsan összedob valamit, aki tüzet olt, még ha a saját gányolását is javítja valójában. Ahogy te is mondtad, fontosabb a jó munkánál a "mindenki fel akar valamit mutatni". És aztán eljön az a pont, amikor többségbe kerülnek a valamit felmutatni akaró egyedek a jó terméket gyártó egyedekel szemben. Csodálkozunk, ha kiég az ember?
Csak arra akartam célozni, hogy így látatlanban szerintem a te igényeid nincsenek összhangban a fejesek igényeivel, ami hosszú távon eléggé lélekölő. Persze ha neked (még) tetszik, akkor folytasd nyugodtan. Minden tiszteletem a tiéd, én már eljutottam arra a pontra, hogy az általad lefestett fejeseket nem akarom elviselni.
Mindenesetre sok sikert kívánok és bocs, hogy elkanyarodtam a témától. Ahhoz nem tudok hozzászólni.
-
[Személyes vélemény on]
Ez témába nem vág, csak a kérdésre válasz
:
A feladatok el vannak látva. Még plusz is. Többieknek segítek. Megosztom az infót és a társosztályoknak is segítek, amitől az osztály reputációja is nő. A fennmaradó időben próbálom javítani a rendszerünket, spórolni erőforrásokat. Amikor a jelenlegi helyemre kerültem, annyira nem volt kapacitás, hogy folyamatosan jobokkal dolgozott az adatbázisszerver. Volt, ami több, mint 3 órát futott. Kis átírással 10 perc alatt lefutott. (Több nagy tábla összekötve egy lekérdezésben, indexek nélkül. Ezeket szedtem szét több kisebb lépésre.)A fejeseknek az a fontos, hogy az ő felettük állók igényei ki legyenek szolgálva és persze mindenki fel akar valamit mutatni, de azzal nem foglalkozik, hogy a meglévő rendszerrel faragjon, mert túl kocka terület. Sajnos ilyennek miatt olyanok a nagyobb cégek rendszerei, amilyenek. Szívás minden fejlesztés.
[Személyes vélemény off]
Oké, azt hiszem nem jól fogalmaztam. Ígérem, ez az utolsó off.
Az, hogy az optimalizálatlan lekérdezések miatt lassú a szolgáltatás, gondolom kimeríti a fejesek felett állók igényeinek kielégítését. Az, hogy nincs elég kapacitás tesztelni, optimalizálni, backupot készíteni ínségesebb időkre, ésatöbbi, mind mind a szolgáltatás színvonalát befolyásolja. Ha az ún. fejes (vagy a felette álló) azt hiszi, hogy nem, akkor vagy hülye vagy igénytelen. Szerény véleményem szerint.
Azzal takarózni, hogy valami túl kocka, ezt nem tudom hova tenni. Ha valami kocka, akkor nincs köze a szolgáltatás színvonalához? Az igényességhez? Ha fejesnek ez túl kocka, akkor miért használ számítógépet? Dolgozzon kockás füzetben, és szolgáltasson abból! Vagy ha az is túl kocka, akkor vonalas füzetből.Bocsánat a kirohanásomért, csak pont ebből lett elegem az IT szférában, és érzékenyen tudok reagálni a hasonló hozzáállásra. Kiborító, amikor azt hallom egy menedzsertől, hogy csak dobj össze valamit, csak működjön; menjen élesbe, mindjárt határidő; ezeknek így is jó lesz, és hasonló szóvirágok. Többnyire ugyanez a menedzser kongatja a vészharagot, hogy nagy baj van a projekten, több erőforrást kell bevonni; azonnali tűzoltásra van szükség; lehalt az éles szerver, mindenki hétvégézik; ha ez ma nem lesz kész, holnap már nem kell bejönnöd; ha ezt megcsinálod még ma, holnap kapsz egy sütit. A fejlesztő meg nyilván megtörik, és inkább hekkel, drótoz, gányol. Mert azt jutalmazzák, aki vilámgyorsan összedob valamit, aki tüzet olt, még ha a saját gányolását is javítja valójában. Ahogy te is mondtad, fontosabb a jó munkánál a "mindenki fel akar valamit mutatni". És aztán eljön az a pont, amikor többségbe kerülnek a valamit felmutatni akaró egyedek a jó terméket gyártó egyedekel szemben. Csodálkozunk, ha kiég az ember?
Csak arra akartam célozni, hogy így látatlanban szerintem a te igényeid nincsenek összhangban a fejesek igényeivel, ami hosszú távon eléggé lélekölő. Persze ha neked (még) tetszik, akkor folytasd nyugodtan. Minden tiszteletem a tiéd, én már eljutottam arra a pontra, hogy az általad lefestett fejeseket nem akarom elviselni.
Mindenesetre sok sikert kívánok és bocs, hogy elkanyarodtam a témától. Ahhoz nem tudok hozzászólni. -
Szia,
ha jól értem lesz két tábla. A kettő között a kapcsolatot a "gyógyszerkészítmény" fogja adni.
Egyik táblában az összetételek lesznek. Feltételezem soronként. Kicsit furcsa lenne olyan struktúra, hogy összetétel1, összetétel2, összetétel3,.... .
Másik táblában a tulajdonságok lesznek. Feltételezem itt is soronként lesznek felsorolva a hatások.Ha a számomra "furcsa" megoldás van, akkor simán JOIN-nal összeköthetőek. Ugyanaz, mint a VLOOKUP az Excelben
A másik megoldás esetén simán mellé tenni, LEFT JOIN-nal nem érdemes, mert összes lehetséges párosítást adná vissza, ami biztos nem jó. PIVOT kicsit macera kezdőként.
Én személy szerint soronként tárolnám mindkét táblát. Az összetevőket és a tulajdonságokat is katalogizálnám. Azaz bevezetnék egy táblát, amiben egyes adatok kapnának egy azonosítót és a két táblában csak az azonosítókat kellene eltárolni. Később lehet meghálálja a rendszer és a tárhely. Például a penicilin szót eltárolni 9 karakter, de ha ez a 17-es kódú összetevő, akkor ez egy sokkal kisebb helyet igénylő adat.Példa:
1-es azonosítójú gyógyszerkészítmény eseténElső tábla
1 - összetevő: por
1 - összetevő: víz
1 - összetevő: penicilinMásik tábla:
1 - tulajdonság: Fejfájás
1 - tulajdonság: HányingerHa ezt kötöd össze, akkor ilyet kapnál:
1 - összetevő: por - tulajdonság: Fejfájás
1 - összetevő: víz - tulajdonság: Fejfájás
1 - összetevő: penicilin - tulajdonság: Fejfájás
1 - összetevő: por - tulajdonság: Hányinger
1 - összetevő: víz - tulajdonság: Hányinger
1 - összetevő: penicilin - tulajdonság: HányingerNa ez jó hosszú lett. Jó lenne ismerni a kiindulási alapot. Akár fake adatokkal összedobsz egyet a Google Drive-on, talán könnyebb lenne a megoldást megtalálni.
Szia Louro,
köszönöm a választ. Gyakorlatilag részben eltaláltad ,hogy mi a feladat és tetszik nagyon a javaslatod. Kicsit bonyolultabb a dolog, mert gyógyszertípusonként más és más tulajdonságokat kell megadni, de vannak olyan tulajdonságok is amelyek minden vagy legalábbis több gyógyszertípusnál szerepelnek. Így például a sűrűség minden készítménynél fontos paraméter, míg például az emulzióstabilitás csak bizonyos esetekben mérhető stb. Ezért mondtam azt, hogy annyi tulajdonságtábla van ahány gyógyszertípus. Holnap este összerakok egy DEMO-t , azaz táblázatokat adatokkal együtt.
üdv -
"ez nem fontos a fejeseknek"
Nem értem. Miért nem fontos a fejeseknek?
Inkább másképp kérdezem. Akkor mi a fontos a fejeseknek? A fejesek számára fontos dologhoz ennek nincs köze? Akkor neked miért fontos? Azon kívül, hogy téged szórakoztat ilyesmivel foglalatoskodni.
De tudok még tovább is menni. [irony on ] A fejeseket nem zavarja, hogy olyan felesleges dolgokkal töltöd a (munka)időd, ami számukra nem fontos? Mivel foglalkozhatnál helyette a fontos dolgokkal is. Remélem nem jönnek rá, hogy titokban nem a céges irányelvek és vízió mentén végzed a munkád, még a végén lapátra kerülsz.[Személyes vélemény on]
Ez témába nem vág, csak a kérdésre válasz
:
A feladatok el vannak látva. Még plusz is. Többieknek segítek. Megosztom az infót és a társosztályoknak is segítek, amitől az osztály reputációja is nő. A fennmaradó időben próbálom javítani a rendszerünket, spórolni erőforrásokat. Amikor a jelenlegi helyemre kerültem, annyira nem volt kapacitás, hogy folyamatosan jobokkal dolgozott az adatbázisszerver. Volt, ami több, mint 3 órát futott. Kis átírással 10 perc alatt lefutott. (Több nagy tábla összekötve egy lekérdezésben, indexek nélkül. Ezeket szedtem szét több kisebb lépésre.)A fejeseknek az a fontos, hogy az ő felettük állók igényei ki legyenek szolgálva és persze mindenki fel akar valamit mutatni, de azzal nem foglalkozik, hogy a meglévő rendszerrel faragjon, mert túl kocka terület. Sajnos ilyennek miatt olyanok a nagyobb cégek rendszerei, amilyenek. Szívás minden fejlesztés.
[Személyes vélemény off]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Építő/felújító topik
- Forza sorozat (Horizon/Motorsport)
- A Linux megnégyszerezte magát a Steamen — a Microsoft ismét ígérget
- Fotók, videók mobillal
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Samsung kuponkunyeráló
- Gyúrósok ide!
- exHWSW - Értünk mindenhez IS
- Mibe tegyem a megtakarításaimat?
- Képregény topik
- További aktív témák...
- Teljesen ÚJ - iPhone 17 Pro 256 GB Kártyafüggetlen - Fóliás - 0 ciklus - Apple garancia
- Intel Core ULTRA 9 285K +32GB 7600MHz Patriot Viper XTREME 5 DDR5 kit! (Bolti ár: kb 600ezer Ft!)
- RYZEN 7 5700X3D (8 mag/16 szál, 96MB L3 cache)! GARANCIA/SZÁMLA (a Te nevedre kiállítva)!
- Intel Core i3-4160, 16GB DDR3 félkonfig - Alaplap, CPU, RAM, SSD, hűtő
- 2 darab Metalica VIP Superior 2 napos jegy csere 4 darab egynaposra
- HP Pavilion 15 AMD Ryzen 5500U / 16 GB DDR4 / 256 GB SSD 6 hónap Garancia Beszámítás Házhozszállítás
- 27% - Intel xeon E5 2630 / RX550 / 16GB / 512GB / 500W Konfiguráció
- MacBook Air laptop 15 2023 / M2 / 8GB / 256GB SSD
- GYÖNYÖRŰ iPhone 14 128GB Midnight -2 ÉV GARANCIA - Kártyafüggetlen, MS5308
- Akció!!! Sosemhasznált! HP OmniBook 5 i5-1334U 16GB 1TB 16" FHD+ Gar.: 1 év
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest