Hirdetés
Új hozzászólás Aktív témák
-
martonx
veterán
válasz
GreenIT
#3496
üzenetére
Szia,
Szerintem nem csak ezek a lehetőségeid vannak. Ráadásul az adatbázis struktúra miért kellene, hogy bármennyire is befolyásolja az adatrögzítést?
A kettőnek nagyon kevés köze van egymáshoz 
Válassz olyan adat struktúrát, amilyet csak akarsz, az semmiben nem fogja befolyásolni az adatrögzítést.
Mivel a pontos feladatot nem ismerjük (nem is akarjuk megismerni a fent említett okok miatt), így ennél konkrétabb választ úgy sem fogsz tudni kapni. -
GreenIT
tag
válasz
martonx
#3488
üzenetére
Szerintem roviden irtam, de a kedvedert zanzasitva ismet leirom, ha hosszunak talalod, aminek megertesehez par ora kell, lapozz le az utolso mondathoz, ott a kerdes lenyege.
Ossze kell irnod a kapcsolataidat, gyorsan rajossz, hogy 2+x tablara van szukseged: NEV, CEG, es egyeb adatok - legyen csak cim es telefon az egyszeruseg kedveert - valamint datum es megjegyzes a valtozasok kovetesehez.
Gyorsan rajossz, hogy a NEV-hez es CEG-hez is tobb, sot tobbfele cim tartozhat, majd arra is rajossz, hogy a telefonnal meg bonyolultabb a helyzet, az tartozhat a NEV-hez, CEG-hez, sot a NEV-hez tartozo cimekhez es a CEG-hez tartozo cimekhez is.Legalabb haromfele valasztasod van:
1. A NEV-hez es CIM-hez is csinalsz tablakat kulon cimek es telefonok, valamint datum es megjegyzes mezokkel, es akkor a szemelyes es ceges adatok elvalnak egymastol, viszont tobb helyen lehet azonos adat.
2. Csinalsz egy harmadik tablat ADATOK neven es mindent abba teszel, lehetoleg minden tipusnak kulon mezovel (allando es ideiglenes lakcim, postacim, szekhely, telephely, telefontipusok, stb.) datum es megjegyzes - ekkor az adatrogzitok orulnek, mert konnyen rogzitheto, hogy adott idopontban adott indokkal milyen valtozasok tortentek.
3. Csinalsz egy harmadik tablat, amiben cim, cimtipus, telefon, teltipus, datum, megjegyzes mezok vannak, es akkor a tablak kozotti kapcsolatok jelentenek problemakat es lekerdezesek reven tudod kitalalni a helyzetet.Osszefoglalva: Az egyik modszer az adattarolas minimalizalasara, a masik az adatrogzites egyszerusegere, a harmadik az adatkapcsolatokra es lekerdezesekre fokuszal.
Nekem eddig az elso kettot sugalltak, hogy a normalizalasnal alapveto szempont, hogy ne legyenek parhuzamos adatok, es az emberi tenyezo kikuszobolese miatt az adatrogzitesnek egyszerunek es atlathatonak kell lennie. (A programozo pedig azert van, hogy a lekerdezeseket megoldja, es amugy is lesznek kesobb ujabb igenyek meg bonyolultabb lekerdezesekre.)
Egy programozo szerint ez mind marhasag, az adatrogzites egyszeri feladat, a lekerdezes viszont folyamatos, ezert mindent a lekerdezesekre kell tervezni.
-
kem
addikt
Sziasztok.
Van 2 db TimesTen SQL querym, es arra lennek kivancsi, hogy hogyan lehetne kiiratni a ketto eredmenyenek a kulonbseget?
select a.id as account, s.id subscription
from subscription s, account a
where s.OWNING_ACCOUNT_UID = a."UID"
order by a.id, s.id;select a.id as account, s.id subscription
from subscription_attribute sa, subscription s, domain_parameter dp, account a
where s."UID" = sa.SUBSCRIPTION_UID
and s.OWNING_ACCOUNT_UID = a."UID"
and sa.DOMAIN_PARAMETER_UID = dp."UID"
and dp.ID like 'ActualParameter'
order by a.id, s.id;Elore is koszonom a segitdeget!
Ha jol gondolom nem kell erteni a teljes adatbazist ahhoz, hogy ki lehessen iratni ezt az eredmenyt, de az is lehet, hogy hatalmasat tevedek. -
martonx
veterán
válasz
GreenIT
#3485
üzenetére
"A problema lenyege az, hogy ha van egy elvaras, hogy egy tablaba kell felvenni nehany adatot, de kiderul, hogy az adatok egy resze tobb mas adattol fugg, akkor mi legyen az eljaras?
Legyinteni, hogy ha nektek ez kell, akkor legyen, vagy megprobalni egy jo megoldast kitalalni es meggyozni a feladatot adot, hogy van jobb megoldas?"Egyre kevésbé értelek. Eddig ezért sem szóltam hozzá a "kérdéseidhez". Életvezetési tanácsokat vársz itt az SQL topikban, vagy önmenedzselési tanácsokat, vagy szakmai tanácsokat konkrét szakmai kérdésekre? Mert nagyon nem mindegy. Ha beküldesz egy SQL fiddle-el megtámogatott query-t, hogy mit és hogyan kellene, abban simán segítünk. De az ilyen szintű kérdésekre, hogy vajon hogyan tároljam a ki tudja milyen adatot, mégis mit vársz tőlünk? A feladatot sem ismerjük, de valószínűleg a megismeréséhez is több óra kellene, ami simán meghaladja egy jószolgálati alapokon nyugvó topik segítőkészségének a határát.
Életvezetési problémák megoldásához meg biztos, hogy nem ez a megfelelő topik, noha off-ban akár tudunk ez irányban is tanácsokat adni, de minek ide szemetelni? -
Ispy
nagyúr
válasz
GreenIT
#3485
üzenetére
Igen, és a fórum szó értelmezésével is sokszor vannak gondok.
A problema lenyege az, hogy ha van egy elvaras, hogy egy tablaba kell felvenni nehany adatot, de kiderul, hogy az adatok egy resze tobb mas adattol fugg, akkor mi legyen az eljaras?
Nos, erre aki akart volna választ írni már megtette volna. Csak az a baj, hogy ez egy külön szakma és ezt nem lehet 3 sornyi leírással megválaszolni, ezért emberek pénz szoktak kérni. Lehet ezen hőbörögni, hogy a sok szemét fórumozó nem akar segíteni, ja de várjál csak, miért is tenné? Nem fog neked senki tanfolyamot tartani itt adatbázis építésből, mert nem is lehetne.
Kezd el, csináljál valamit és amikor készen vagy, akkor tárd a nyilvánosság elé, és akkor fogsz rá kapni érdemi reagálást, hogy jó-e vagy sem, vagy hol és mit lenne érdemes változtatni.
Hogyan gondolkozzak, hogy adatrogzitesre, adattarolasra es lekerdezesre egyarant jo megoldashoz jussak?
Első körben olvasd el ezt:
OLAP vs. OLTP -
GreenIT
tag
Igen, hozzaallassal es szovegertelmezessel vannak itten a gondok, kerem alassan.
A problema lenyege az, hogy ha van egy elvaras, hogy egy tablaba kell felvenni nehany adatot, de kiderul, hogy az adatok egy resze tobb mas adattol fugg, akkor mi legyen az eljaras?
Legyinteni, hogy ha nektek ez kell, akkor legyen, vagy megprobalni egy jo megoldast kitalalni es meggyozni a feladatot adot, hogy van jobb megoldas?![;]](//cdn.rios.hu/dl/s/v1.gif)
Azert neztem CRM-et, mert ott joval bonyolultabb adatkapcsolatokat is be lehet allitani. Csak a Sugarban teljesen rossz az alapstruktura, ugy tunik nekem, jobb az alapmodulokat torolni es ujat irni.
CRM ugyben sztanozs linkjet erdemes megnezned, par honapja en is ezeket nezegettem, de figyelni kell, mert par egyaltalan nem ingyenes, sima reklamcikknek tunik. A suite-ot es sugar-t probaltam, az elobbinel ugy latom, hogy meg csak most kezdik kitalalni, mi legyen belole, az utobbi szepen kezelheto, csak eppen adateleresi hibak miatt nem hasznalhato.
-
GreenIT
tag
válasz
sztanozs
#3483
üzenetére
Erdekes, hogy folyamatosan az ellenkezojet irod annak, amit en irtam, de mindig ram hivatkozva.
Probald meg az alabbit szo-ta-gol-va olvasni, hatha segit:
Kiprobaltam a Sugarcrm CE verziojat, es nem mukodik.
Pontosabban szepen mukodik, amig nem akarsz bele adatokat irni.
Attol kezdve az adatok egy reszet lathatod, csak nem tudod elerni.
Erdekes megoldas. -
válasz
GreenIT
#3481
üzenetére
Nekem nincsenek ügyfeleim, egy nagy cégnél vagyok salaryman és sosem találkozom ügyfelekkel (munkaügyben legalább is). Itt csak jóérzésből (és tanulási szándékkal) osztom és kapom az észt.
Senkit nem akarok elhappolni és sosem kértem pénzt segítségért.Másrészt - a CRM egy jól fizető és meglehetősen zárt üzleti szegmens. Senki nem fog ingyen fejleszteni egy viszonlag bonyolult (és fiztős verzióban amúgy jól jövedelemező) üzleti rendszert. Ez nem egy middleware, amire lehet üzleti logikát építeni és jól keresni a fejlesztéssel, tanácsadással - neked valami kulcsrakész ingenyes szolgáltatás kell. Ezt pedig (vagy vcalószínűség szerint) nem fogod megkapni.
De ezeket nézd meg - és válogass: [link]
És bár úgy írja, van ingyen ebéd - valójában nincs:
- Fizetős szoftver Free Tier változata: korlátozva van a felhasználók, ügyfelek, lekérdezések, üzleti logika, stb.
- Open Source: neked kell telepíteni, konfigurálni, karban tartani -
Ispy
nagyúr
válasz
GreenIT
#3481
üzenetére
Nézd, ez egy ingyenes fórum. Nem azért van, hogy az ide járok tanítgassanak másokat hogyan kell adatbázist építeni. Ráadásul egy ilyen tök alap dologra. Kezd el, csináljad, ha elakadsz tedd fel a kérdésedet, de az nem kérdés, hogy hogyan is kell csinálni.
Ingyen meg nincsen semmi, ezt jó lenne, ha már mindenki bevésné az eszébe. Mindenért fizetni kell, vagy pénzzel, vagy mással. Miért is lenne ingyen egy CRM program? Mindenki pénzből él...
-
GreenIT
tag
válasz
sztanozs
#3464
üzenetére
Aha, magyar SI szabvany.
Az elsonel szerintem egyertelmu, hogy a tanulasnal a helyes gondolkodasmod elsajatitasa a legfontosabb, de ti valamiert azonnal ugy ertelmezitek, hogy jon valaki, aki el akarja happolni a ti ugyfeleiteket.
Erdekes.A masik eseteben ugy latom, ingyenes CRM-ek nem mukodnek, csak csalinak szolgalnak, hogy "vedd meg a fizetoset, az is csak azert fog mukodni, mert mi folyamatosan azon dolgozunk, hogy valahogy mukodokepes maradjon."
Amugy fogalmam sincs, hogy ti hogyan csinaltok penzt ingyenes CRM-bol, ugyhogy ez is magyar SI szabvanykategoria. -
#3480
martonx
veterán
PumpkinSeed
#3478
martonx
veterán
válasz
PumpkinSeed
#3478
üzenetére
Én egy adatbázist használnék, a régiónkénti szerverekhez pedig csak egy-egy saját cache-t (mondjuk redis vagy ilyesmi) tennék. Amikor bármi bemegy a DB-be, az X percen belül úgyis be fog futni a cache-be, semmi értelme kismillió adatbázissal szórakozni. Szerintem.
Illetve tényleg van értelme minden régióba szervert tennetek? Ez egy sima webszerver, nem media streaming vagy ilyesmi. Nálunk pl. az egész világot egy szál szerverről Írországi adatközpontból szolgáljuk ki, és nagyon nem lassú (nyilván ami késleltetés Nyugat-EU-ban 20ms, az USA-ban 60, Ausztráliában meg akár 100ms fölé is mehet, de ennyi latencyvel simán együtt lehet élni, ahelyett hogy emiatt elkezdenénk görbíteni a teret). A szerver mellé pedig régiónként vannak média streaming szervereink.
A legújabb rendszerünk pedig régiónként elosztva készül (saját pixel tracking maximum 5ms-os késleltetése miatt kritikus, hogy közel legyen a felhasználóhoz), mindegyik régiónak van egy saját kis fis-fos NoSql-je (kvázi cache-ként fogható fel), és egy sync service-e, ami bizonyos időközönként, események hatására szinkronizálja a lokális NoSql-t az egyetlen központi MS SQL szerverrel.
-
#3479
bambano
titán
PumpkinSeed
#3478
válasz
PumpkinSeed
#3478
üzenetére
én mindenre postgrest használok, abból lehet master-slave verziót. a lekérdezős frontendeket rátenném a slave-ekre, a hozzászólások posztolását meg a masterre. ha ez nem elég teljesítményben, akkor a blogokat szétültetném ilyen rendszerekből több párhuzamosra.
egy ilyesmi verziót csinálnék, neked tetsző sql adatbáziskezelővel.
-
#3477
bambano
titán
PumpkinSeed
#3476
válasz
PumpkinSeed
#3476
üzenetére
"Mit értesz az alatt, hogy soha nem szokott jól sikerülni?": az ígéretek meg a valóság között időnként eltérés mutatkozhat.
én nem mondtam, hogy nosql nem jöhet szóba, én azt mondtam, hogy én elkerülném a master-master replikációt. ha valaki szereti a nosql-t, használjon azt. fenti állítás még azt sem tartalmazza, hogy te ne használj master-master replikációt
én nem tenném, de mindenki a maga szerencséjének a pogácsa. -
#3475
bambano
titán
PumpkinSeed
#3474
válasz
PumpkinSeed
#3474
üzenetére
a blogolás eléggé lekérdezés-intenzív feladat, sokkal több lekérdezés megy, mint insert. szerintem egy master-több slave adatbázist érdemes használni, nagy in-memory frontendekkel. ráadásul a nyelvi korlátok miatt az adatbázis lekérdezése nem egyenletes eloszlású a földön, így ha témánként vagy témacsoportonként csinálsz egy mastert, akkor azt oda lehet tenni, ahol a többség használja.
szerk: én nem próbálkoznék master-master replikációval, az sose szokott jól sikerülni.
-
#3474
PumpkinSeed
addikt
martonx
#3473
PumpkinSeed
addikt
válasz
martonx
#3473
üzenetére
Tegyük fel, hogy ülsz egy vietnámi kávézóban és egy amerikai barátodnak írnál üzenetet, de a database server csak London-ban ezért 200ms lesz minden adatbázis lekérdezés nálad is meg a barátodnál is. De ha lesz egy vietnámban is meg amerikában is akkor ez valamivel gyorsabb lesz. Ez önmagában nem válaszolja meg a kérdést, de mivel message queue system-ből érkezik minden olyan művelet ami nem select ezért a szinkronizálási hibák elkerülése érdekében a vietnámi backend egy másik vietnámi master-be nyomja, nem londonra fog várni. Szóval megválaszoltam a kérdést?
Nem egymás mellett akarok 20 adatbázist, ha erre gondoltál. Azért használtam a végtelen szót, mert tulajdonképpen n mennyiségű ilyen-re van szükségem, és n lehetne 1 is meg 30 is. Kezdésnek egy, de ha valami terjeszkedik nem lehet azzal számolni, hogy csak eu-ban lesz szerver.
-
#3473
martonx
veterán
PumpkinSeed
#3472
martonx
veterán
válasz
PumpkinSeed
#3472
üzenetére
"szükségem van végetelen master-master replikációra" - mert miért is?
Nekem ez architekturális tervezési hibának tűnik, mikor valakitől ilyet hallok. -
#3472
PumpkinSeed
addikt
PumpkinSeed
addikt
Tegyük fel, hogy a blogger.com-t (vagy akármilyen más közösségi blogger oldalt) szeretném nulláról felhúzni. A kérdésem (ami nem teljesen SQL kérdés) de milyen adatbázist használjak.
SQL, NoSQL, Graph?
A SQL egész jó választás lenne, de szükségem van végetelen master-master replikációra. Erre a legjobb példa a Cassandra és nem nagyon tudok olyan SQL adatbázisról ami tudna hasonlót.
A NoSQL esetén túl nagy az inkonzisztencia. De viszont megoldja azt a problémát ami a SQL esetén feljött és gyors is.
A Graph elég ígéretesnek néz ki de nem túl kiforrott technológia. Konkrétan a Google Cayley weboldala 2 hónapja még Lorem Ipsum volt. Illetve nem találtam sok blog posztot arról, hogy a Neo4J hogyan működik production alatt.Eddig Cassandra az ami nyerő. De úgy gondoltam bedobom ide is hátha valaki többet tud.
-
válasz
GreenIT
#3462
üzenetére
Melyikkel? Az elsővel, vagy a másodikkal?
Az elsővel az a gond, hogy azt szeretnéd megtudni, hogy gondolkodj, de ebben nem tudunk segíteni. Ami segíthet, az az, hogy összeírod, hogy mi az igény (ne te találd ki), és az igények alapján elkészíed az a megoldást, amely a legtöbb (vagy legfontosabb) igényeket megvalósíja.
Viszont ha az kérdés, hogy az iglnyek összeszedése után sem tudod mit valósíts meg és hogyan, akkor azt hiszem, hogy ez neked túl nagy feladat, és nem ártana, ha ezt mielőbb közölnéd a megrendelőiddel.A másodikkal az a gond, hogy valószínüleg az "itt lakók" közül nincs senkinek megfelelő mennyiségű tapasztalata. Vagy van, de azt pénzért osztja meg tanácsadóként.
-
#3455
GreenIT
tag
Apollo17hu
#3423
GreenIT
tag
válasz
Apollo17hu
#3423
üzenetére
Csinaltam tobbfele valtozatot, de egyik se jo, inkabb kerdezek: mi a bevalt gyakorlat?
Hogyan gondolkozzak, hogy adatrogzitesre, adattarolasra es lekerdezesre egyarant jo megoldashoz jussak?A problemam az, hogyan lehet cimeket, telefonszamokat es egyeb adatokat egyertelmuen CEG-ekhez es EMBER-ekhez rendelni.
Cimek: kis cegek a sajat lakasukat hasznaljak irodanak is, tehat ceghez ES szemelyhez is tartozik a cim es telefonszam. Irodahaznal az a jellemzo, hogy a cim es telefonszam egy-egy irodahoz tartozik, nem a ceghez.
A mobil telefonok kapcsolodhatnak a ceghez, adott alkalmazottak hasznaljak, amig a cegnel vannak, majd az utodjaik kapjak meg. Masik eset, amikor az embere a telefon, de azt ceges munkara is hasznalja, amig az adott cegnel van.
Sot ugyan az a telefonszam tobb cegnel is megjelenhet egyszerre, kulonosen, ha az illetonek sok vallalkozasa van, vagy sok a mellekallasa.Tul sokfele lehetoseg van, es ha mindegyiket meg akarom engedni, akkor sok kulonbozo tablaban kell tarolni hasonlo adatokat, igy nehez az azonos adatok kiszurese.
A masik megoldas az adohivatali sema lenne, amikor egyetlen tablaban van az osszes adatmezo, de csak egyetlen datumkezd es datumvege es indoklas mezo van, igy soronkent csak egyetlen adat valtozhat.
Ez adatrogziteskor idegesito, mert minden potenciális adatmezö megjelenik, az adatrögzitön múlik, hova ir.
Ráadásul a cégek többsége kicsi, amikor a modositas indoka koltozes, ertelemszeru, hogy a szekhely es tobb telefonszama is valtozik, viszont ennel a modszernel ez sok soron oldhato csak meg.
Extrem eset a cegfelvasarlas, akkor minden adat egyszerre valtozik es mindegyiket kulon lehet csak rogziteni. Adatrogzitesnel az lenne a jo, ha egyszerre beirhatnak az osszes adatot, ami az adott datummal letrejott vagy megszunt, es ugyan az a szoveges megjegyzes tartozik hozza.Egy harmadik lehetoseg a ketlepcsos adatkezeles, az adatrogzito csak azt irja be, hogy az adott cim, telefon letrejott, vagy megszünt, és lekérdezések során kell kitölteni, hogy az adott cim mettöl meddig élt az adott cég esetében.
Sok telephelyes cégnél viszont áttekinthetetlen egy hosszú lista, aminel csak letrejott vagy megszunt datumok vannak, hogy akkor most melyik székhelye és telephelye(i) élnek most.A "most melyik ujjamat harapjam meg" helyett inkabb azt kerdezem, milyen gondolkodasi semara kellene beallitanom az agyam, hogy a fenti harom szempont szerint egyszerre tudjak gondolkozni?
-
Dilikutya
félisten
válasz
martonx
#3420
üzenetére
Mert nem vagyok annyira otthon az SQL-ben, de ez most nem is lényeges, a lényeg, hogy a megfelelő adatok meglegyenek. És a jelen ismereteimmel az egész nem is oldható meg máshogy, csak jó sok lekérdezéssel. Hülye xlsx táblákat kell feltölteni hülye adatbázisból, amiről tudjuk mi is, hogy szar.
Még egy kérdés: AVG-nek megadható, hogy az adott mező értékeiből csak egy tartomány alapján számoljon? Pl. van a mezőben 1-7 érték, de én csak az 1-5 közötti értékek átlagát kérdezném le.
-
#3452
tm5
tag
Apollo17hu
#3451
tm5
tag
válasz
Apollo17hu
#3451
üzenetére
Kb. fél éve nekem is volt egy ehhez nagyon hasonló problémám és ott is a 12c-re való átállás okozta a teljesítmény problémát.
Zeratul megoldása nekem is beugrott (mármint a hintek használata), csak nálunk az tilos és hozzá vagyok szokva, hogy ilyenkor át kell írnom a query-t.Amúgy ahol lehet én is szétszedem subquery-kre a feladatot, mert akkor magam is jobban értem, hogy mit csinálok. Elég sok 4-800 soros query-vel dolgozom, másképp nem is érteném meg őket
-
#3451
Apollo17hu
őstag
tm5
#3448
Apollo17hu
őstag
Szia!
Meg fogom nézni, hogy van-e lehetőség ilyen formára átírni. Igazából a két allekérdezésre úgy tekintettem, mintha logikailag "különállóak" lennének. Eddig úgy gondoltam, hogy a kód futása külön-külön megy végbe allekérdezéseken belül, és csak ezt követi a részeredmények összekapcsolása. Szándékosan így is írtam a legtöbb kódot, beszédes alias-t adva az allekérdezéseknek, hogy pl. hibakereséskor könnyebben értelmezhesse akár egy olyan személy is, aki először találkozik vele. Ezek szerint nagyon nem így működik...
-
#3450
Apollo17hu
őstag
Apollo17hu
őstag
Sziasztok!
Még nem volt időm minden választ megnézni, viszont -Zeratul- megoldása tökéletes (<1 sec lett a futási idő). Köszönöm szépen!
Később részletesen is átnézem, hogy tanuljak belőle. -
Nem volna egyszerűbb egy nested join?
SELECT t1.mezo_1
,t1.mezo_2
FROM (SELECT t.id
,t.mezo_1
,t.mezo_2
FROM tabla_1 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t1
INNER JOIN
(SELECT t.id
FROM tabla_2 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t2
ON t1.id = t2.id; -
#3446
bpx
őstag
Apollo17hu
#3445
bpx
őstag
válasz
Apollo17hu
#3445
üzenetére
Ha most tényleg az a cél, hogy a 2 subqueryt egymástól független megcsinálja 1-1 alkalommal, akkor kb. így:
SELECT /*+ use_hash(t1 t2) */ t1.mezo_1
,t1.mezo_2
FROM (SELECT /*+ no_merge no_push_pred */ t.id
,t.mezo_1
,t.mezo_2
FROM tabla_1 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t1
,(SELECT /*+ no_merge no_push_pred */ t.id
FROM tabla_2 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t2
WHERE t1.id = t2.id;A subquery itt úgy viselkedik mintha view lenne. A view-kat az adatbázis "kifejti" ha tudja, az eredeti példát szerintem simán átírja az adatbázis úgy, mintha nem is lennének subquery-k, csak a 2 táblára a join. Ez a view merging, ezt akadályozza meg a no_merge hint.
Ha a view-kon kívül is vannak egyéb feltételek, azt az adatbázis be tudja helyezni a view-n belülre. Pl. a "select * from view1 where column1='...'" lekérdezést végre lehet úgy hajtani, hogy előállítja a view1 teljes eredményhalmazát, majd a végén alkalmazza a column1 szűrést, de úgy is, hogy a column1 szűrést átírja úgy, mintha a view-n belül lenne. Ez nem csak egyszerű szűrésekre működik, hanem joinra is, tehát miután előállította a t1 tartalmát, az adatbázis a t2-be már beviszi a tabla_2.id = t1.id szűrést és felhasználja a t1-ből jövő id értékeket, ez a join predicate pushdown. Ezeket tiltja a no_push_pred.
A use_hash-t meg csak a biztonság kedvéért tettem oda, hogy mindkettő subquery-t csak 1-szer csinálja meg, és ne válasszon nested loops-t.
Aztán ezen kívül még lehetnek mindenféle más optimalizálások, amelyekre most nem gondoltam és további hintek kellenének.
De persze nem ezt tartom a jó megoldásnak.
-
#3445
Apollo17hu
őstag
bpx
#3443
Apollo17hu
őstag
PL/SQL Developer 9.x-ről álltunk át a napokban 12-es verzióra. Valószínűleg ez lehet a probléma forrása (talán az üzemeltetés nem hangolta tökéletesre az adatbázis szervert?).
Plant nem tudok mutatni, a lekérdezés egyébként kb. így néz ki:
SELECT t1.mezo_1
,t1.mezo_2
FROM (SELECT t.id
,t.mezo_1
,t.mezo_2
FROM tabla_1 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t1
,(SELECT t.id
FROM tabla_2 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t2
WHERE t1.id = t2.idEz futott korábban 1 másodpercig, most meg 5-10 perc között. t1 és t2 allekérdezés is 200-300 eredménysort ad vissza (mindkettő dimenziótábla), külön-külön 1 másodpercen belül most is lefutnak. Mindkét táblában az id egyedi, szám formátumú.
Az a vicces, hogyha t1 allekérdezésben találomra kikommentezek egy szűrőfeltételt (az eredménysorok száma 10-15%-kal nő), akkor az egész lekérdezés ismét 1 másodpercen belül fut.
Legalapabb hintekkel próbálkoztam (use_hash, use_nl stb.), de igazából nem tudom, mikor mit kell használni. Tapasztalatból csak annyi van meg, hogy nagyméretű ténytáblák kötésénél 90%-ban csökkenti a futási időt a use_hash hint.
Tudom, hogy ez még mindig kevés, és hogy jobban kellene specifikálni a problémát, de a hét végére valószínűleg kapok segítséget munkatársaktól, tehát mindenképp meg fog oldódni a probléma, csak azt hittem, vannak általánosan alkalmazható hintelések.
-
#3444
sztanozs
veterán
Apollo17hu
#3442
válasz
Apollo17hu
#3442
üzenetére
Vagy akár a lekérdezést (dummy mezőnevekkel)
-
#3443
bpx
őstag
Apollo17hu
#3442
bpx
őstag
válasz
Apollo17hu
#3442
üzenetére
Bocsánat, de ennyi információ birtokában én is csak ennyit tudok mondani: olyat, ami gyorsít rajta. Legalább egy plant mutass, de végrehajtási statisztikákkal még jobb lenne.
-
#3441
sztanozs
veterán
Apollo17hu
#3440
válasz
Apollo17hu
#3440
üzenetére
Hogy kötöd össze (NOT IN?)
-
#3440
Apollo17hu
őstag
Apollo17hu
őstag
Sziasztok!
Van két, 1 másodpercen belül futó lekérdezésem (néhány száz rekord). A kettő eredményét összekötve 5 percre növekszik a futási idő. Milyen hintet érdemes használnom?
-
Louro
őstag
Sziasztok!
Adott egy SMSS 2008 R2 és egy VS 2008.
VS-ban elkészítenénk a package-et. A package dolga annyi lenne, hogy megfog egy .xls (nem .xlsx) fájlt és azt be kellene töltenie táblába.VS-ban futtatva simán végrehajtódnak a lépések.
Ahogy job-ot készítenénk rá SMSS-ben, elhasal a dolog. A netet feltúrva már átállítottuk 32 bitesre a job-ot.
Nektek esetleg ötlet, javaslat? .csv-t is próbáltuk. Azzal is hasonló. Kicsit más, de hasonló.
A hibaüzenet:
Executed as user: xxxxxxxxxx. Microsoft (R) SQL Server Execute Package Utility Version 10.50.6000.34 for 64-bit Copyright (C) Microsoft Corporation 2010. All rights reserved. Started: 9:03:32 AM Error: 2017-06-13 09:03:34.35 Code: 0xC00F9304 Source: filename Connection manager "Excel Connection Manager" Description: SSIS Error Code DTS_E_OLEDB_EXCEL_NOT_SUPPORTED: The Excel Connection Manager is not supported in the 64-bit version of SSIS, as no OLE DB provider is available. End Error Error: 2017-06-13 09:03:34.36 Code: 0xC020801C Source: filename_import 1 Excel Source [77] Description: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Excel Connection Manager" failed with error code 0xC00F9304. There may be error messages posted before this with more information on why the AcquireConnection method call failed. End Error Error: 2017-06-13 09:03:34.37 Code: 0xC0047017 Source: filename_import 1 SSIS.Pipeline Description: component "Excel Source" (77) failed validation and returned error code 0xC020801C. End Error Error: 2017-06-13 09:03:34.37 Code: 0xC004700C Source: filename_import 1 SSIS.Pipeline Description: One or more component failed validation. End Error Error: 2017-06-13 09:03:34.37 Code: 0xC0024107 Source: filename_import 1 Description: There were errors during task validation. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 9:03:32 AM Finished: 9:03:34 AM Elapsed: 1.888 seconds. The package execution failed. The step failed. -
Sziasztok!
Teljesen kezdőként szeretnék segítséget kérni. Adott öt tábal:
1. Egy sima naptár a 2016-os és 2017-es dátumokkal és jelölve a nap sorszámával (hétfő=1, kedd=2, stb...)
2. Szállodai szobák száma és ára (szobaszám és mellette az egységára (1 éjszaka ára)
3. Szoba foglalások 2016. évre és 2017.év legelejére: szobaszám , dátumtól – dátumig foglalások
4. Hét napjaira felárak (Péntek, Szombat, Vasárnapra)
5. Speciális felár időszakokra (dátumtól – dátumig) speciális szezoni felár (téli, nyári időszakra)Felár számításnál a prioritás :
Ha vonatkozik adott napra „specfelár” , akkor azt kell figyelembe venni (téli, nyári napok illetve karácsony környéke),
ha nincs „specfelár” adott napra, akkor az „alapfelár” érvényesül (például a hétvégi alapfelár)Feladat: Mennyi az így keletkezett árbevétel a 2016. naptári évre?
Hogyan lehet ezt MS SQL lekérdezésekkel megoldani úgy, hogy az alap táblákat nem módosítjuk (view-kat létre lehet hozni).
Előre is köszönöm a segítséget
Munkahelyen ilyen kis házi versenyfeladat, de természetesen jelezni fogom, hogy nem veszek részt a versenyben, mert segítséget kértem. Excel-lel meg tudnám valahogy oldani, de SQL-ben még csak kapirgálom a felszínt.
Valahogy be kellene áraznom a naptárban a napokat (sima nap 1-es, feláras nap1,X-es szorzó a feláras táblák és prioritás alapján).
A foglalásokat meg szét kellene szednem napokra és a beárazott naptárral összevezetni. -
#3435
Sixkiller6
őstag
martonx
#3432
Sixkiller6
őstag
válasz
martonx
#3432
üzenetére
így van, alapvetően egy olyan interfész kellett, ahol az alapokat meg tudom mutatni vkinek és amivel lehet gyakorolni. nehéz úgy kérdezni, hogy nem ismerem az opcióimat.
semmi gond nincs a server telepítéssel, de egy weboldal nyilván a legegyszerűbb.
mondjuk az előny a szervernél, hogy könnyen fel tudok dobni nagy példaadatbázist.nagyon köszönöm mindkettőtöknek a segítséget
-
#3433
Apollo17hu
őstag
Apollo17hu
őstag
Egy rövid topikösszefoglalóra lenne szükség, amiben egy link mutat az sql fiddle -re.
-
-
#3430
martonx
veterán
Sixkiller6
#3426
martonx
veterán
válasz
Sixkiller6
#3426
üzenetére
sqlfiddle.com használatánál nincs egyszerűbb, és ingyenesebb. Nem is értem mások miért szívatnak
-
#3429
Ispy
nagyúr
Sixkiller6
#3428
Ispy
nagyúr
válasz
Sixkiller6
#3428
üzenetére
Igen, ms-nél az express mindig a free változatot jelenti.
-
#3427
Ispy
nagyúr
Sixkiller6
#3426
Ispy
nagyúr
válasz
Sixkiller6
#3426
üzenetére
MS SQL Server 2016 Express + SSMS 2017, pont most reggel raktam fel, kb. fél óra az egész....
-
#3426
Sixkiller6
őstag
Sixkiller6
őstag
üdv, mi a legegyszerűbb módszer, hogy otthoni windowsos pc-n legyen vmi sql környezetem, ahol pár egyszerű lekérdezést meg tudnék mutogatni?
az is jó ha besütött, kész táblák vannak, nem gond.egy appserv-et nem dobnék fel csak ezért. köszi
vagy dobjak fel egy régebbi ms sql servert?
-
#3424
GreenIT
tag
Apollo17hu
#3423
GreenIT
tag
válasz
Apollo17hu
#3423
üzenetére
Koszonom, dolgozok rajta, mar tobb valtozatot csinaltam.
Meg egy kerdesem lenne, valami vizualis szovegszerkesztot keresnek tablak kozti kapcsolatok abrazolasara.
Az a gond, hogy en vizualis vagyok, rengeteget rajzolok, tablakat hogyan tudom osszekapcsolni, de amikor mezoket at kell tenni masik tablaba, az egeszet ujra kell rajzolnom. Kepszerkesztok pedig nem jok erre.
-
#3423
Apollo17hu
őstag
GreenIT
#3422
Apollo17hu
őstag
válasz
GreenIT
#3422
üzenetére
Az új tábla valahogy így nézhetne ki:
CEG_CIMEK: ceg_kod, szekhely_fl, cim, kezdo_datum, bef_datum
A szekhely_fl jelölné, hogy székhelyről ('I') vagy telephelyről ('N') van-e szó.
A cim mezőt megbonthatod további mezőkre (orszag, telepules, iranyitoszam stb.).Ha egy rekordban kell megjelenítened a cég adott napra lekért összes telephelyét, akkor arra pl. a LISTAGG függvényt lehet használni.
-
GreenIT
tag
Kezdokent szeretnek becsatlakozni, ha lehet.
Kaptam egy feladatot, amit elvileg ertek, csak fogalmam sincs, hogy tudnam megvalositani.
Van egy "klasszikus" adatbazis ket tablaval, amit a harmadik tabla kapcsol ossze:
CEG, ALKALMAZOTT, MUNKAAz alapadatok a minimalisok:
CEG: cegnev, alapitas datuma, szekhely (varos, cim, irszam), telefon, webcim.
ALKALMAZOTT: nev, lakcim (varos, cim, irszam), telefon, mobil, e-mail
A kapcsolotabla:
MUNKA: ceg_kod, alkalmazott_kod, munkakor, kezdo_datum, bef_datumEnnyi van megadva azzal, hogy minden tovabb modositast nekem kell megoldani.
Ebbol egy olyan adatbazist kell csinalnom, amibol lekerdezheto, hogy
1. adott szemely mely cegeknel milyen munkakorben dolgozott eddig
2. jelen pillanatban hol dolgozik (tobb cegnel is dolgozhat, illetve egy cegen belul is lehet tobb munkakore, pl. team-be soroljak projektmunkara
3. Cegeknel legyen egy kulon tabla az osszes eddig cimevel (szekhelyek, telephelyek)
es lekerdezesnel az aktualis szekhelyet (csak egy lehet) es telephelyeket jelenitse meg.Ez utobbival vagyok a legnagyobb gondban, mert nem biztos, hogy most van telephelye,
de a multban lehetett egyszerre tobb is.Elnezest, ha nem ertheto, probaltam gyorsan es roviden irni es minden valaszt halasan koszonok.
-
#3421
Apollo17hu
őstag
Dilikutya
#3418
Apollo17hu
őstag
válasz
Dilikutya
#3418
üzenetére
Szerintem nem jó a táblaszerkezeted. Ez a "nagyon sok" mező "ki van forgatva", pedig meg lehetne oldani az egészet két mezővel: az egyik értéke a mostani mezőnév lehetne, a másik értéke pedig az, amire most is szűrsz.
Most így vannak az adataid:
[mező_1] | [mező_2] | [mező_3] | [mező_4] | [mező_5] | ... | [mező_n]
---------------------------------------------------------------------------------------------
'AA' 'BB' 'XX' 'YY' 'PP' 'MM' 'ZZ'
'ee' 'zz' 'bb' 'NN' 'PP' 'MM' 'ww'
'dd' 'UU' 'CC' 'tt' 'xx' 'AA' 'WW'helyette viszont lehetnének így is:
[mező_1] | [mező_2]
------------------------------
'mező_1' 'AA'
'mező_1' 'ee'
'mező_1' 'dd'
'mező_2' 'BB'
'mező_2' 'zz'
'mező_2' 'UU'
...
'mező_n' 'ZZ'
'mező_n' 'ww'
'mező_n' 'WW' -
Ispy
nagyúr
válasz
Dilikutya
#3415
üzenetére
MS SQL-ben a táblák és azok mezői lekérhetőek sys előtagú táblákból, én írnék rá egy table-valued függvényt (de lehet inkább egy template-et), amiben van egy cursor, ami végignyálazza a tábla mezőit, az outputja meg egy tábla, amiben minden rekord egy select utasítást tartalmaz.
A tábla azonosítóját megtalálod:
select * from sysobjectsA mezőket le tudod kérni:
select * from syscolumns -
Dilikutya
félisten
Van benne logika, mert minden sor ugyanazzal kérdez le, csak mind másik mezőből:
SELECT akármi(mezőnév1) FROM tábla WHERE `mezőnév1` = X;
SELECT akármi(mezőnév2) FROM tábla WHERE `mezőnév2` = X;
SELECT akármi(mezőnév3) FROM tábla WHERE `mezőnév3` = X;
SELECT akármi(mezőnév4) FROM tábla WHERE `mezőnév4` = X;Kód alatt valami C++/C# kódra gondolsz, vagy megoldható SQL-ből is?
-
Dilikutya
félisten
válasz
martonx
#3412
üzenetére
Köszi!
De a lényeg a folytatásban van.
SELECT akármi(mezőnév) FROM tábla WHERE `mezőnév` = X;
A lekérdezés fele beírva a megfelelő helyre, viszont máshova kell ugyanez, kibővítve úgy, hogy mezőnév -ből csak bizonyos adattartomány szerinti adatok kellenek. Erre van valami általános hivatkozás, ami a lekérdezésben egyszer már szereplő mezőnevet behelyettesíti, vagy kézzel kell beírni?
A lekérdezések ennél bonyolultabbak, de ez a lényeges része most nekem, a többi csak AND, OR, könnyen és gyorsan lehet azzal a résszel dolgozni, ez viszont minden sorban más és más lesz. És nagyon sok sor van.
-
Dilikutya
félisten
válasz
martonx
#3410
üzenetére
Nincs mögötte az adatbázis még.
Másik kérdés. Sok lekérdezés, de mind ugyanaz, csak más mezőből kéri le az értékeket ugyanazon feltétel szerint. Hogy lehet ezt a legjobban automatizálni? Illetve a lekérdezett mezőből bizonyos értékeket ki kell zárni (vagy csak bizonyos tartományt belevenni), és mivel ez ugyanaz a mező, ahonnan eleve lekérdezek, hogy lehetne elkerülni, hogy még a WHERE után minden lekérdezésbe is bele kelljen írni?
-
DS39
nagyúr
válasz
kw3v865
#3404
üzenetére
értem, akkor javítsuk meg az update-es megoldásodat:
(itt ugye csak a subquery-vel volt gond, azt én így orvosolnám)ALTER TRIGGER nepesseg_szum ON OVEZETEK
AFTER INSERT
AS
BEGINDECLARE @TERULET GEOMETRY
DECLARE @ID INTDECLARE @kurzor CURSOR
SET @kurzor = cursor FOR
SELECT SHAPE, OBJECTID FROM INSERTEDOPEN @kurzor
FETCH NEXT FROM @kurzor INTO @TERULET, @IDWHILE @@FETCH_STATUS = 0
BEGINUPDATE OVEZETEK
SET Nepesseg_ossz = (SELECT SUM(n.lakosok) from NEPESSEG_EOV N WHERE N.SHAPE.STWithin(@TERULET)=1)
WHERE OVEZETEK.OBJECTID=@IDFETCH NEXT FROM @kurzor INTO @TERULET, @ID
ENDCLOSE @kurzor
DEALLOCATE @kurzor
END;a kiemelt részt módosítottam, kivettem a belső selectet, ott felesleges, ha a kurzorban van már az id.
-
kw3v865
senior tag
válasz
kw3v865
#3403
üzenetére
Egyébként én valószínűnek tartom, hogy a PK (OBJECTID) okozhat gondokat, mert amíg csak UPDATE-elem, nincs gond, mindig növekszik szépen eggyel.
http://desktop.arcgis.com/en/arcmap/latest/manage-data/using-sql-with-gdbs/object-id.htmKicsit összekavarodnak a dolgok, amikor nem az ArcGIS adja az értéket az ObjectID-nak, viszont enélkül sem megy, mert ez a PK (és muszáj, hogy legyen egy PK).
-
kw3v865
senior tag
Most próbáltam így is, de hiába, sajnos nem megy.
Igen, a Management Studioban futtatom. Az övezeteket pedig ArcGIS-ben rajzolom.Tehát a lényeg az hogy az alábbival viszont jól lefut, HA csak egy sort commit-olok egyszerre:
ALTER TRIGGER nepesseg_szum ON OVEZETEK
AFTER INSERT
AS
BEGIN
DECLARE @TERULET GEOMETRYSET @TERULET = (SELECT SHAPE FROM INSERTED)
UPDATE OVEZETEK SET Nepesseg_ossz = (SELECT SUM(n.lakosok) from NEPESSEG_EOV N
WHERE N.SHAPE.STWithin(@TERULET)=1) WHERE OVEZETEK.OBJECTID=(SELECT OBJECTID FROM INSERTED); -
-
kw3v865
senior tag
Így gondoltad?
CREATE TRIGGER nepesseg_szum ON OVEZETEK
INSTEAD OF INSERT
AS
BEGIN
INSERT INTO OVEZETEK (OBJECTID, SHAPE, Nepesseg_ossz) SELECT I.OBJECTID, I.SHAPE, (SELECT SUM(n.lakosok) from NEPESSEG n
WHERE N.SHAPE.STWithin(I.SHAPE)=1) FROM INSERTED IEND;
Nem jó, mert "Unspecified error occured on SQL Server. Connection amy be terminated by server", miután megrajzolom az övezet poligont, majd mentem (commit-olom).
A kettőnek nagyon kevés köze van egymáshoz 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: Laptopszaki Kft.
Város: Budapest