Új hozzászólás Aktív témák
-
Petya25
őstag
Az a bajom, hogy ez egy eleve hiányosan érkező lista, és csak az érték nélküli mezőkbe kellene generálnom egyedi tartalmat. Ez a mező sajnos a fogadó táblában kulcs mező, üresen nem mehet be.
Esetleg szét tudom választani a listát töltött nem töltött ágra és az üres ágra identity-t tenni a betöltés előtt. Köszi. -
nyunyu
félisten
Általában igyekszem szabványos SQLül írni, de van amire nincs szabvány, és ahány DB, annyiféle szintaxis létezik rá.
Ilyen a maradékos osztás is.Meg úgysem a pontos szintaxis a lényeg, mert azt viszonylag könnyen át lehet írni egyik DB dialektusról a másikra, hanem a mögöttes logika.
-
nyunyu
félisten
Valami ilyesmire gondolsz?
Hogy itt is megmaradjon:
with nev_lista as
(select nev,
--row_number() over (order by nev asc) id,
mod(row_number() over (order by nev asc)-1,10) oszlop,
trunc((row_number() over (order by nev asc)-1) / 10) sor
from nevek)
select *
from nev_lista
pivot(
max(nev)
for oszlop
in (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
)
order by sor;SQL szeret mindent 1-től számozni, ez most nekünk nem praktikus, ezért van a sorszám-1 osztva 10-zel.
Melóhelyen szórakoztattam egyszer magamat azzal, hogy az időzített jobokat vezérlő táblából (id, folyamatnév, melyik_nap, kezdő_idő, vége_idő) rajzoltam heti naptárat negyedórás bontásban, az jóval nagyobb szopás volt
Pláne, hogy éjfélen túlnyúló folyamataink is vannak
-
sztanozs
veterán
-
martonx
veterán
Külön programmal. A DB csak tegye ki egy külön táblába, hogy kiknek kell emailt küldeni.
Aztán majd egy külön program ez alapján kiküldi a saját workflowja alapján.
Így a DB is csak azt teszi, amihez ért, és majd a programozó is azt teszi amihez ért (rem,élhetőleg). Ráadásul az email küldés egészen bonyolult is lehet retry policy-vel, fogadottság ellenőrzéssel stb....
A mindent DB-vel megoldatásban óhatatlanul ott van a deadlockok, bármilyen más okból db lockok okozása, amivel vicces módon mondjuk egy sima email küldéssel akár a komplett DB-det is bedöntheted, pedig de jó ötletnek tűnt emailt küldeni a DB-ből (mondom ezt úgy, hogy bármikor elismerem nem vagyok DB szakértő, de régebben láttam már MS SQL-t megállni, valami ilyen huszadrangú jó ötletnek tűnt feature megakadása miatt).
De nyilván mindenki akinek kalpácsa van, az utána mindent azzal akar megoldani, klasszikus probléma. Rám is igaz lehet az előbbi, hogy minél több mindent inkább külön programmal oldanék meg, simán lehetnek esetek, amikor nem ez a jó megközelítés pl. irdatlan adatmennyiségek esetén. -
nyunyu
félisten
Értsd már meg, hogy ezt nem engedi a Szent Mikroalkalmazás Architektúra.
Cipész maradjon a kaptafánál, ablakpucolás nem az ő feladata!Hasonlóval szívtam, csak Oracle oldalon: automatizált GDPR törlésekről kellett volna hibajelzéseket küldenem az érintett osztályoknak, hogy vizsgálják ki, milyen adathiba miatt akadt el a folyamat.
Van egy tömeges SMS+email küldő alkalmazásunk, ami feldolgozza a webservicére érkezett kéréseket, így az első ötlet az volt, hogy DBből kéne meghívni a webservice-t.
Oracle persze ebben nem remekel, de azt meg lehet oldani, hogy indít egy shell szkriptet, ami meghívja a servicet.
Mivel minden is agyon van tűzfalazva, így kéne nyitni egy lyukat a DB szerver és az alkalmazásszerver között.
Természetesen ezt a felettesek azonnal letiltották, erről szó sem lehet éles banki környezetben.Második ötlet az volt, ha már az üzenetküldő alkalmazás fizikailag ugyanazon a DBn lóg, mint amin az adatokat törlöm, és a webservice oda pakolja, hogy mikor kinek, mit kell küldeni, akkor használjam direktbe.
Kb. 2 óra volt kisakkoznom, melyik táblájába mit kell írni, hogy menjen az email küldés tőlem.
Jelentem készre a fejlesztést, erre a code reviewn kivágta a biztosítékot az, hogy grant insert on emailszerver.emailtorzs to gdprtorles.
Egyből le lettem ugatva, hogy ezt mégis hogy gondolom hogy csak úgy másik sémába akarok írni, meg hápogtak sokat a Szent Mikroalkalmazás Architektúráról, miszerint az alkalmazások, szerverek nem véletlenül vannak fizikailag és logikailag is elszeparálva, nem kommunikálhatnak csak úgy random össze-vissza egymással.Végül az architektek, rendszerszervezők, üzemeltetők kiokumulálták megoldásnak azt, hogy a saját sémámban csináljam meg az emailtörzs, címzett táblákat, ezt pollozni fogja a DB sémámon lógó Java alkalmazás (amit a többi alkalmazás kérdezget, hogy mik a már törölt azonosítók), aztán az hívja meg az emailküldő servicet, ha kimenő hibaüzenet emailt lát nálam.
Bő 3/4 évvel később élesbe is állt ez a nice to have feature, mert akkor ért rá a javás kolléga ezzel a minor requesttel foglalkozni.
De legalább nem sérült a Szent Mikroalkalmazás Architektúra.
-
tm5
tag
Amúgy csak megérteni szeretnéd, vagy átírni?
(Kis csiszolgatás után) beraktam beraktam sqlfiddle-be a mintádat, de nem sok értelmeset produkált: (null),1,...6-ig hozta az összes ID-t
Ha esetleg szeretnél hierarchiát építeni SQL Serverben arra ott a rekurzív CTE
-
#4697
RoyalFlush
őstag
Louro
#4673
RoyalFlush
őstag
Elsőre azt gondoltam, hogy az egymást követő rekordokra vonatkozó lekérdezés lefedi az esetek egészét, de ez végül téves feltételezésnek bizonyult a részemről és a Descartes-szorzatot használó megoldás több keresett találatot eredményezett. Úgyhogy bambano, tm5 köszönöm szépen mindkettőtöknek
-
nyunyu
félisten
tábla1.oszlop1 LIKE '%valami%' miatt mindig full table scan lesz, nem tud semmilyen indexet használni a joinhoz.
Míg ha tábla1.oszlop1 LIKE 'valami%' -t írnál (vagyis a string elején keresel, nem közben), akkor a tábla1.oszlop1-re tett index használható lenne, és nem kellene mindig végigolvasnia az egész táblát.
-
Szmeby
tag
Ó, én nem hibáztatom, biztos vagyok benne, hogy elhangzottak. Mindig elhangzanak.
Egy ideális világban ez úgy működne, hogy a beszállító szépen feláll az asztaltól és közli, hogy van egy minőségi szint, amihez már nem hajlandó adni a nevét, a megrendelő meg hajára kenheti az "igazát". Ha a megrendelő akkora polihisztor, hogy szakmai érveket vétóz meg (vagy eleve nem is egyeztet, csak utasít), akkor miért fordult a beszállítóhoz eleve. Egy tucat majom is tud pötyögni utasítás alapján, nem kell ehhez szakember.
Nyilván olyan szerződést kell kötni az elején, ami megengedi a minőséghez való ragaszkodást és annak nem teljesülésekor az elsétálást. Kár, hogy ritka az a beszállító, aki fontosnak tart ilyesmit belefoglalni a szerződésébe. Másrészről meg ott bukik meg a csipkerózsika történetem, hogy kell a pénz, etetni kell az alkalmazottakat, így a beszállító inkább nyel egyet, görbít a gerincén még egy kicsit, és azt mondja: "jól van".
Ami engem alapvetően bosszant ebben a viselkedésben, hogy mindkét résztvevő elhiszi, hogy ettől lesz jobb a világ. És értetlenül állnak például azon probléma előtt, hogy ó, hát milyen nagy a fluktuáció! Majd jönnek a menedzsment és hr tanácsadók, akik tudják a tuti receptet a fluktuáció csökkentésére. De valahogy nem sikerül. Mert a résztvevők még mindig azt hiszik, hogy valami leküzdhetetlen külső erő arra kényszeríti őket, hogy megalkudjanak és minden szakmai érvet nélkülöző utasítást egy megcáfolhatatlan törvényként fogjanak fel: "A magasságos megrendelő kinyilatkoztatott. Mégis legyen skálázható a rendszer, amit a jövő héten adunk át. A könyörületes megrendelő hozzátevé: a határidő 5 nappal bővülhet, ha kell. A megrendelő elvárja, hogy legyen olcsó. Dologra! Ámen."
Majd a fél-2 éves csúszást követően: "A mindenható megrendelő nagyon örül, hogy VÉGRE elkészült a rendszer. De csak akkor lesz elégedett a munkával, ha ezt a néhány frissen kitalált módosítást még ingyen beletesszük. Akkor majd boldog lesz, de azért érezzük egy kicsit magunkat szarul, amiért ilyen kontár munkát végeztünk, és ilyen sokáig tartott. De azért örülünk, hogy az áldott és kegyelmes megrendelő eltekintett a kötbér fenyegető suhintásától igénytelen munkánk ellenére is."
Komolyan, ha nem lettem volna (leginkább elszenvedő) részese ezeknek a játszmáknak, csak röhögtem volna ezen a bohózaton.
Minden szereplőnek megvan a helye, tökéletesen összeállt az ökoszisztéma. Egy szociológiai aranybánya. Nem is értem, mit ágálok ellene. -
nyunyu
félisten
Állami hivatal, napjainkban futó pármilliárdos IT tender.
Valamelyik nagyokos kitalálta, hogy Enterprise Architectben jól lemodellezi az egész rendszert, és megrajzolt egy olyan infrastruktúrát és adatmodellt, aminek az egyik fele felesleges, másik fele meg használhatatlan.
Hivatal IT osztálya persze ellenkezett, hogy ez így megvalósíthatatlan, kivitelezhetetlen, de hát nem ők voltak a döntéshozói szerepkörben, így el lett fogadva.
Megvalósítani meg úgyis a beszállítóknak kell...A hivatalnak van saját sokoldalas fejlesztési standardja, ami előírja a beszédes nevek használatát, minden objektumnak kell legyen egy _id végű egyedi kulcsa, minden mezőnév a táblanévvel kezdődik, stb.
Ezektől eltérni nem lehet, mert deploy előtti ellenőrzésen fennakad a kód, nem telepítik, ha valamelyik követelménynek nem felel meg.Lényeg: EAban szereplő adatmodellből generálják az objektumokat létrehozó szkripteket.
Probléma azzal még nincs, hogy a beszedes_elso_tablanev_elso_mezoje túl hosszú lenne, hanem azzal, hogy a külső kulcsok neve táblanév1_táblanév2_id alakú, illetve az N:M relációk leírásához szükséges táblák neve is konkatenálódik: táblanév1_táblanév2.
Így a benne lévő táblanév1_mezőre visszamutató mező neve elso_tabla_neve_masodik_tabla_neve_elso_tabla_neve_mezo_neve lesz.Ennek persze az lett az eredménye, hogy az EAból generált szkripteket a meglevő Oracle 12.1 rendszerük nem bírta lefuttatni, mert nem fértek bele a 30 karakteres tábla és oszlopnév limitjébe.
Főnököm felvetette, hogy akkor leimplementáljuk mi az adatmodellt, értelmesen rövidített táblanevekkel.
Na azt nem lehet, mert akkor nem felelünk meg az EAban leírt terveknek.Jó, akkor módosítsátok az EAban lévő adatmodellt úgy, hogy a konkatenált nevek is beleférjenek a 30 karakterbe.
Nem lehet, túl sok munka, meg már a projekt többi részéhez is hozzá kéne nyúlni.Harmadik opció?
DB upgrade, de annak jelentős szoftverlicensz vonzata van.Azóta a projekt alatt Oracle 19 dübörög, mivel annak a költségét egyszerűbb volt átverekedni az ilyen-olyan bizottságon, mint a szent és sérthetetlen (hetente ötször változó) haditervet módosítsák, mert az utóbbi annak a beismerése lett volna, hogy a terv alapból szar.
Akarom mondani a DB frissítés kisebb projekt kockázattal járt, mint a tervet módosítani.
-
nyunyu
félisten
Pár éve az egyik mobilszolgáltató adattárházának betöltő jobjait kellett géppel feldolgoznom, ott láttam mindenféle cifra tördelést, meg extrém szintaxist a huszonéve toldozott kódban.*
Mostani melóhelyen is látom a kollégák kódolási stílusa közti különbségeket:
- kulcsszavak kis vagy nagybetűvel (select vs SELECT)
- hány szóközt használ behúzásra 2? 3?
- egy oszlopba rendezi-e a mezőneveket, aliasokat, kommenteket, vagy ahogy esik, úgy puffan
- hova teszi a vesszőt felsorolásnál:
a,
b
vagy
a
, b
(utóbbit nem szeretem, mert ronda, de könnyebb --szal kikommentezni, ha nem kell a második sor!)
- használ-e vessző után szóközt
- használ-e az egyenlőségjel, kacsacsőr körül szóközt (a=b vs a = b)
- van aki minden WHERE alatti sorba 1=2 AND-ot ír (így nem tud véletlenül elindítva lefutni a kód), aztán ha véglegessé vált a query, csak akkor kommentezi vagy törli ki.Nekem mindegy, amíg legalább annyira tördelve van, hogy el lehessen olvasni.
*: UPDATE a SET mezo=b.mezo2 WHERE a.id=b.id; megfejtését kérném OLVASHATÓAN, SQL:2003 szintaxissal leírni a válaszokban.
-
nyunyu
félisten
Ez így nem jó, mivel ő az egyes costCategory alá tartozó tételek összegét külön-külön oszlopban szeretné látni.
Meg lehet csinálni PIVOT() nélkül is, oszloponként külön JOINnal:
SELECT p.projectName 'Project Name',
SUM(pc1.cost) 'Cost category1',
SUM(pc2.cost) 'Cost category2',
SUM(pc3.cost) 'Cost category3',
SUM(pc4.cost) 'Cost category4'
FROM Project p
LEFT JOIN ProjectCost pc1
ON pc1.projectID=p.projectID
AND pc1.costCategory='Cost category1'
LEFT JOIN ProjectCost pc2
ON pc2.projectID=p.projectID
AND pc2.costCategory='Cost category2'
LEFT JOIN ProjectCost pc3
ON pc3.projectID=p.projectID
AND pc3.costCategory='Cost category3'
LEFT JOIN ProjectCost pc4
ON pc4.projectID=p.projectID
AND pc4.costCategory='Cost category4'
GROUP BY p.projectName
ORDER BY p.projectName;Itt az egyes JOINoknál szűröm a costCategory értékét, hogy az adott oszlopban melyik értékhez tartozó tételek látszanak (amiket aztán szummázunk).
PIVOT()-tal rövidebben, tömörebben lehet ugyanezt megcsinálni, viszont a mit írjak a FOR és IN részekhez megértése elsőre nehéz lehet.
-
tm5
tag
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. -
martonx
veterán
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.
-
nyunyu
félisten
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. -
tm5
tag
Hát akkor lehet váltanék a helyedben egy olyan helyre ahol DBA-t keresenek és elfogadják az SQL-es múltadat és a szándékot, hogy te ebbe az irányba akarsz fejlődni.
A DBA-s tanfolyamok elég drágák, életszerű tudást úgyis meg munka közben lehet felszedni.
Tippre azt mondanám, hogy Oracle-s DBA-t többet keresnek, mint MSSQL-est. Mivel mind a két dialektussal foglalkoztál érdemes mind a két irányba próbálkozni, aztán amelyiknél hamarabb beesik a munka abban elmélyedni... -
tm5
tag
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. -
nyunyu
félisten
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.)
-
Szmeby
tag
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.
-
formupest
újonc
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 -
Szmeby
tag
"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. -
nyunyu
félisten
Egy 2008->2012 frissítésért is kuncsorogni kellett
Mielőtt Móricka azt képzelné, hogy régi DBn backup, aztán új szerveren restore, és máris megy minden, mint a karikacsapás, ennél nagyobbat nem is tévedhetne.
Annó egyik ügyfelünk nagyon nyüstölt minket az SQL Server 2000 miatt, hogy 2011-ben nem kéne már használni, aztán új DB szerver telepítésekor upgradeltette a rendszerét 2008R2-re.
Akkor a DBAink vagy egy fél hónapot reszelhették a régi kódot, hogy normálisan működjön a hárommal újabb DB verzióval, mivel felülről kompatibilitás ide vagy oda, az új DB motor sokmindent másképp optimalizált/futtatott, mint a régi.
Úgyhogy lehetett végignyálazni az indexeket, hinteket, meg utánaolvasni a 2008R2 újításainak, mivel a DBAnk főleg 2000-hez értett, meg kisebb részben 2005-höz. -
nyunyu
félisten
Ha jól értem, itt kőkemény gazdaságossági kérdések is bejátszanak.
Nektek kell eldönteni, hogy mire akartok költeni:
- újabb, erősebb vas
- toldozzátok-foltozzátok a régi kódot, hátha jobban fut az elégtelen vasonÍrtad, hogy van DBAtok.
Nem az ő dolga lett volna eddig kielemezni a rendszer gyenge pontjait, és azon optimalizálni?
Akár úgy, hogy megnézi, mi fut túl lassan, és a végrehajtási terv alapján kitalálja, milyen indexszel vagy hintekkel lehetne jobban futtatni ugyanazt, vagy akár úgy, hogy nyakára lép a trehány fejlesztőknek, hogy gondolkozzanak, mielőtt telibejoinolnak két sokmilliós táblát.Vagy azon is el lehet gondolkozni, hogy valami mentén partícionáljátok a táblákat.
Mittudomén, van egy folyamatod, aminek van egy azonosítója, akkor célszerű lehet az összes a folyamatban használt táblát a folyamat azonosító mentén partícionálni, és az összes joinba betenni a partíciókulcsot, így mindig csak az aktuális partíció pártíz-ezer során dolgozik a DB, nem az egészre megy a full table scan...[szerk:]Ja, hogy dobozos? Akkor a beszállítót kell rugdosni, ha még garis a termék, de sejtésem szerint már fizetős a support
Pénz meg szokás szerint nincs.Én sok kis lépéssel próbálok javítani. Igazából szorgalmiként, mert mellette ott vannak a feladataim is :/
Sajnos volt ilyen munkahelyem.
Amikor sikerült sok hónap munkával eloltanom egy évek óta lángoló tüzet, amit az egyik vezető fejlesztő nemtörődömsége okozott, akkor még vállveregetést sem kaptam érte, nem hogy fizuemelést.
Aztán még én voltam a szemét, amikor leléptem onnan... -
nyunyu
félisten
Replikáció erre való, hogy ha megváltozik egy adat, akkor a változás automatikusan át legyen víve a másolatra is.
Persze arra oda kell figyelni, hogy a táblák egyedi azonosítóit populáló szekvenciákat nem szokta szinkronizálni, így pl. ha kiesik az eredeti adatbázis, és ideiglenesen a replikát akarod használni helyette, akkor manuálisan léptetned kell a másolat DBben lévő szekvenciákat, hogy nagyobb értékről induljanak, mint a táblában lévő aktuális ID, különben egyedi kulcs sértést kapsz, amikor írni próbál a rendszer a replikába.
(aztán a kiesett eredeti DBre visszaálláskor is el lehet ezzel játszani.)Nyilván a replikációt elindítani sem munkaidőben kell, ha akkorák a tábláid, hiszen jó pár óráig eltarthat, mire nulláról felépíti a másolatot.
Kollégáimnak annó elég sok bajuk volt az SQL Server 2000 replikációjával, de a 2005, aztán a 2008 már jóval stabilabban működött.
-
tm5
tag
SQL Szerver replikáció nem játszik? Nem használtam sose. De ez elég régóta egy elérhető feature. Szóval ha olyat kellene csinálnom amit írtál, én ezt (a beépített replikációt) nézném meg először, hogy hogy működik.
Amúgy pontosan mi a lassú? Konkrétan a rekordok átmásolása, vagy nagy a késleltetés (latency) a két szerveren lévő adatok állapota között?
SSIS-t sem használtam, de azzal is megpróbálnám, ha ez csak olyan batch/bulk jellegű másolás lenne. Általában ezek az integrációs eszközök elég jók. -
ha server, akkor egyik sem, a t-sql ezt nem tudja, csak a mysql. nyilván 2008től érdemes ezzel t-sql-lel is próbálkozni, mert az vezette be a time adattípust.
a time_to_sec egyszerűen helyettesíthető egy datediff-fel, (
datediff(s,0,ido)), viszont a visszaalakítás az problémás lehet.
erre adja magát a dateadd (ie.:select dateadd(s, avg(datediff(s,0,ido)), 0) from tabla;), de az date formátumot az vissza, ezt még vissza kell csapni time-ba egy converttel. viszont a convert truncol, ott bukjuk a 24 órát meghaladó részét. mondjuk ha ez olyan, akkor a time egyáltalán nem használható. -
Petya25
őstag
Köszi, de még mindig azzal küzdök, hogy az időt nem konvertálja szám formába.
"Explicit conversion from data type time to float is not allowed."Olyan megoldást találtam a neten hogy az óra egységeit váltsuk át és összegezzük másodpercben int-ben. Na jó, aztán meg számoljam vissza a 127562-ből hogy az hány óra hány perc...
Excelben meg simán 5 karakteren megcsinálja az átlagot ugyanaz a cég... -
Louro
őstag
Ha HH:MI:SS kell, akkor
SELECT CONVERT(CHAR,CONVERT(DATETIME,AVG(CONVERT(FLOAT,t))),108)
FROM BASEIdőt előbb FLOAT-ba alakítod, majd átlagolod. A számot utána dátummá visszakonvertálod és abból kiszeded az időpontot. Ha csak óra és perc kell, akkor CHAR(5)
Oracle után szinte falnak szaladtam ennyi konvertálás láttán. M$ eléggé köti az ebet a karóhoz az adattípusaival.
-
bambano
titán
ezeket a feladatokat nem mindig értem. pl. életemben nem használtam having-ot, most per pillanat azt se tudom, mire jó. de a gugli ennyire azért a barátom, meg tudom találni, hogy mi az. akkor én most megbuknék nálatok?
vagy volt olyan, hogy az egyik rossz pontot úgy szereztem interjú előtti teszten, hogy nem tudtam kapásból, hogy a postgresql vacuum-ja mikor mit hogy lockol. mer úgy kb. ki a bánatos francot érdekli. ha gondom lesz vele, elolvasom, felfogom és alkalmazom. de erre nincs szükségem, mert oda nem kerültem be, mert nem tudtam fejből a vacuumot.
úgy látom, nem csak sql terén van baj, hanem toborzás terén is...
-
-
bpx
őstag
Kell egy adatbázis job, ott van rá az adatbázis saját ütemezője. Mi a baj azzal?
DBMS_SCHEDULER helyett van DBMS_JOB is, de az a régi módszer, nem ajánlom, arról le kellene szokni.Vagy ha nagyon Windows jobot akarunk (inkább ne), akkor kb. ennyit kell beütemezni:
set ORACLE_HOME=...
set ORACLE_SID=...
set PATH=%ORACLE_HOME%\bin;%PATH%
sqlplus user/password @script.sql -
#3061
Apollo17hu
őstag
Louro
#3059
Apollo17hu
őstag
Szerintem ketté kellene szedni az "azon" mezőt. Ha egyben marad, le kell vágni az első karaktert, és a mentén csoportosítani. Nem tudom ellenőrizni, hogy szintaktikailag helyes-e, de valahogy így nézne ki a sorszámozás:
SELECT rendeles.azon
,substr(rendeles.azon, 1, 1) ||
rank() over(PARTITION BY substr(rendeles.azon, 1, 1) ORDER BY rendeles.azon) +
CASE WHEN substr(rendeles.azon, 1, 1) = 'K'
THEN max_sorszam.max_k
WHEN substr(rendeles.azon, 1, 1) = 'L'
THEN max_sorszam.max_l
WHEN substr(rendeles.azon, 1, 1) = 'M'
THEN max_sorszam.max_m
END uj_azon
FROM rendeles
,(SELECT MAX(CASE WHEN substr(sorszam.azon,1, 1) = 'K'
THEN to_number(substr(sorszam.azon, 2)) END) AS max_k
,MAX(CASE WHEN substr(sorszam.azon,1, 1) = 'L'
THEN to_number(substr(sorszam.azon, 2)) END) AS max_l
,MAX(CASE WHEN substr(sorszam.azon,1, 1) = 'M'
THEN to_number(substr(sorszam.azon, 2)) END) AS max_m
FROM sorszam) max_sorszam -
martonx
veterán
Ehhez group by-t kellene használnod plusz valami aggregátor függvényt (mondjuk count). Példa nélkül ennél konkrétabb segítséget nem fogsz kapni.
Azaz kóddal, meg ciklusokkal, meg ilyesmikkel nem kell bohóckodnod, pusztán az SQL mindezt megcsinálja neked, ráadásul sokkal gyorsabban mintha program kóddal szeded össze az adatokat. -
-
Ispy
nagyúr
MS SQL-ben:
SELECT CASE Mezo
WHEN 1 THEN 'A'
WHEN 2 THEN 'B'
WHEN 3 THEN 'C'
ELSE 'D'
END
FROM tabla
vagy
SELECT CASE
WHEN Mezo = 1 THEN 'A'
WHEN Mezo = 2 THEN 'B'
WHEN Mezo = 3 THEN 'C'
ELSE 'D'
END
FROM tablaA 2. opcióban a WHEN részben tudsz OR vagy AND operátorral összetett feltételt is létrehozni.
-
rum-cajsz
őstag
Én szívesen segítenék, de nem értem a kérdésed sem. Tudnál készíteni egy példát az sqlfidle oldalon?
Már azt sem értem, ha ugyanazt a mezőt akarod ugyanazzal a mezővel összehasonlítani, és csak az egyik oldalon konvertálsz, akkor mit vársz? Ha konkrét értékeid vannak, akkor miért nem jó az egyenlőség helyett az IN () ?
Minden szereplőnek megvan a helye, tökéletesen összeállt az ökoszisztéma. Egy szociológiai aranybánya. Nem is értem, mit ágálok ellene.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- i3-8100 + ASUS H310M alaplap + 8GB RAM egyben (félkonfig)
- Asztali PC , R5 5500 , RX 6700 XT , 32GB RAM , 512GB NVME , 1TB HDD
- Sony PlayStation 5 Fat 825 GB eredeti doboz, gyári kontroller
- Dell XPS 3K Érintős,core i7,16GB RAM,256-512GB SSD,ÚJ AKKU,ÚJ TÖLTŐ,Szép állapot
- AKCIÓ!!!Acer V3,FullHD core i5 6200u(4X2,8Ghz),8GBRAM,nVme
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! Samsung Galaxy A16, Samsung Galaxy A26, Samsung Galaxy A36, Samsung Galaxy A56
- LG 40WP95XP-W - 40" NANO IPS - 5120x2160 5K - 72Hz 5ms - TB 4.0 - HDR - AMD FreeSync
- Felújított számítógépek/merevlemezek Számlával, garanciával! Ingyen Foxpost!
- CarPlay / Android Auto adapter meglévő Android alapú fejegységhez
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest