Új hozzászólás Aktív témák
-
Szmeby
tag
válasz
jocomen
#2840
üzenetére
Talán azért van ez így, mert nincs különösebb oka a beavatkozás és a számla tétel táblák szétválasztásának. Vagy mégis?
Például a díjszabás forintban kerül megállapításra, a beavatkozás ezen leíró tábla alapján egyértelműen beárazható (szerintem a lehető leghamarabb érdemes jelölni a kiszabott árat). Viszont az ügyfél eurós számlát kér, vagyis a számla tételben már euróban kell szerepelnie az összegnek. Az meg már tiszta sor, hogy a számla fejen lévő összeg a számla tételeket összegzi.
És ha már a valutakonveziónál járunk, ahhoz asszem illene egy teljesítés dátuma mező, ami alapján meghatározható, hogy melyik napi árfolyam alapján történt a konverzió.
Ha jól látom, a rendszer jelenleg nem kezeli a sztornó és helyesbítő számlát sem, ehhez is elkelne majd pár új mező (pl. számla típusa, számlák egymásra hivatkozása, ilyesmi).
Vagy a proginak nem lesz köze a számlázáshoz?Formailag nekem pl. nem tetszik, hogy bizonyos táblanevek egyes számban, mások meg többes számban szerepelnek, és nem látom az okát. Kevés olyan tábla van egy adatbázisban, amiben csak egy sor van, totál felesleges belekeverni a számosságot a táblanévbe, bátran lehet mindegyik egyes számú.
Ha nagyon zavar a kerülő útvonal, hát egyesítsd a táblákat. Pl. úgy, hogy eltörlöd a kategóriát (az legfeljebb a fogon szerepel mint plusz információ), a díjakat pedig foganként adod meg. Nincs olyan sok fogunk, hogy ez drasztikus mértékben rontaná a teljesítményt. Persze ha igény van arra, hogy kategóriához adunk meg árat, akkor ne tedd.
Megjegyzem, hogy mindig is utáltam a normalizálós feladatokat a suliban, és nincs is benne gyakorlatom, ezért csak módjával hallgass a hülyeségeimre.
-
Szmeby
tag
válasz
bambano
#2845
üzenetére
A redundancia növeli a biztonságot, az integritást.
Ugyan hibát nem javít, de jelzi, ha teszemazt valaki kézzel belenyúlt és átírt egy összeget (és persze trehány módon elfelejtette átírni a többi hivatkozott összeget is).
Egy "hús-vér" (vagyis papír) számlán is szerepelnek tételesen a részösszegek, és a végösszeg is.
Nem érzem ezt annyira ördögtől valónak. -
Szmeby
tag
válasz
pittbaba
#2849
üzenetére
Ilyesmire gondoltál?
select *
from hirdetes h
inner join user u on u.id = h.userid
inner join kategoria1 k1 on k1.id = h.kategoria1
inner join kategoria2 k2 on k2.id = h.kategoria2
inner join kategoria3 k3 on k3.id = h.kategoria3
inner join custom c on c.hirdetes_id = h.id
where c.mezo_neve = 'szobak_szama' and c.ertek = 3;Egyébként nem lenne ésszerűbb az egymástól független fogalmakat külön táblában tárolni?
Vagyis külön tábla az ingatlan hirdetéseknek, külön az autóknak, stb.
És akkor lehet minden szépen field. Az úgy már csak nem olyan sok. -
Szmeby
tag
válasz
pittbaba
#2851
üzenetére
Tele van inner joinnal. Rendesen indexelt táblákkal nincs ebben semmi kíméletlen.
Az adatbázistól elkérheted egy lekérdezés execution plan-jét (legalábbis Oracle alatt biztosan), abból ki lehet bogarászni, hogy hogyan optimalizálja azt, és hol lehet gyorsítani rajta.Természetesen ha nem használod pl. a kategória3-mat, nem kell belevenni a lekérdezésbe. Továbbá biztosan nem lesz szükséged az összes tábla összes mezőjére, így a select * helyett a szükséges mezőnevek felsorolása célszerű.
Az ember mindig elszúrja valahol, ez természetes dolog. Azért gyakorlunk, hogy minimalizáljuk ezt.
Egy normális adatbázis több tíz, száz, ezer táblát tartalmaz - sémákba rendezve -, mindegyiknek megvan a célja. Egyes táblák akár sokszáz oszloppal rendelkezhetnek, bennük több milliárd rekorddal. Ha ezen táblák tartalmát egy táblába gyűjtenénk az adatbázis szerintem már az indexelésnél összeomlana.Viszont ezzel, hogy mindent "belehánysz" egy táblába, azt éred el, hogy borzasztóan sok _felesleges_ adattal duzzasztod azt fel. Szerencsétlen adatbázis minden teszemazt ingatlanos lekérdezésnél kénytelen végigfutni az autós meg az összes többi irreleváns hirdetések adatain/indexein is. Egy kicsit is tágabb szűrést adsz meg véletlenül, és csodálkozol, hogy miért lett ez ilyen tetü lassú.
Én úgy vélem, hogy ne hagyjuk az adatbázist feleslegesen dolgozni, ha van más lehetőség. Nagyon könnyen teljesítmény problémákba futhatsz bele, és azokon már nehezebb javítani, mint pár elrontott lekérdezésen. -
#2998
Szmeby
tag
aprokaroka87
#2997
Szmeby
tag
válasz
aprokaroka87
#2997
üzenetére
Örülök, hogy akad olyan ember, aki rájött, a roottal milyen orbitális biztonsági rést nyitott a telefonján. De hát erről szól ez az egész, mindenki a résért csinálja.
Sajnálom, hogy nem tudok érdemben segíteni neked, de ugye arról van szó, hogy a fájlokhoz nem nyúlhatsz, hiszen a gmail appnak látnia kell, márpedig ha te lekódolod a tartalmát, azzal már nem fog tudni mit kezdeni. Esetleg a fájl hozzáféréssel lehetne játszani, hogy pl csak a gmail tudja őket listázni / olvasni, de hát mielőtt rootoltad, pont ezt csinálta.
Drasztikus megoldások persze vannak: unroot.
Vagy rootolt eszközön ne tarts érzékeny adatokat. Tudom, ez képtelenség. -
Szmeby
tag
válasz
bandi0000
#3624
üzenetére
Szevasz,
én nem tudom elmagyarázni, de az biztos, hogy az iskolán kívül nem kell először kettesbe, majd hármasba forgatni, hanem a cél, hogy minél előbb kellően normalizált legyen az a DB, és gyorsan szállítsuk a megrendelőnek, mert már tűkön ül, hogy miért nincs még kész.
2NF
Ha eltekintünk attól a ténytől, hogy a valóságban egy gyerek több általánosba is járhat, és a példánál megszabjuk, hogy márpedig nem járhat, akkor nyilvánvalóvá válik, hogy egy gyerek csak egy általánosba jár, így a középiskolás kiszervezésével meg is van a 2nf. Gondolom. Mivel a gyerek önmagában meghatározza az általános iskolát is. Amiből csak egy lehet, mint ahogy korábban megszabtuk. Míg középsuliból több is, így szükségessé válik a gyerek duplikációk megszüntetése. Amit egy szuper kis kapcsolótáblával oldunk meg. Így 1 tanuló csak egyszer fog szerepelni a tanulók táblában, mert már nincsenek ott azok a csúnya középiskolák, amelyek megduplázták (megtöbbszörözték) a sorok számát.3NF
Viszont azt is látjuk, hogy ez még nem elég, mert ugyan a gyerekek már egyediek, de a Csillagvár bizony kétszer is feltűnik, két gyerek is ugyanoda jár. Ez nagy pazarlás, minden gyereknél nyilvántartani ugyanannak a sulinak a címét. Mi van, ha a suli elköltözik? Vagy kedves vezetőnk átnevezi az utcát, mert ahhoz van kedve? Elkezdjük tömegesen átírogatni a tanulók tábláját azért, mert az iskola adataiban valami megváltozott? Ha kézzel kellene átírnod, neked se lenne természetes a mosolyod egy néhány tízezres tanulóbázis esetén. Mennyivel egyszerűbb lenne 1 helyen átírni a suli címét, és az automatikusan az összes adott suliba járó gyerekre igazzá válna. Hát ezért szervezzük ki az általános iskolát is külön táblába. Felhívnám a figyelmet, hogy ez esetben egy-több a kapcsolat, így a kapcsolótábla szükségtelen.Összefoglalva: Úgy látom, a 2NF arra jó, hogy a sok-sok duplikált SOROK számát csökkentsük le. A tanulók táblában a tanulók a fontosak, vagyis a cél, hogy soronként különböző tanulókat lássunk. Ne szerepeljen két sorban ugyanaz a tanuló. A 3NF pedig arra jó, hogy az adott táblában található kiegészítő (értsd: a tanuló személyéhez nemigazán tartozó) ADATOK ne szerepeljenek feleslegesen többször, mert ha azokat át kell írni, az halál.
Hogy mi az, ami nem tartozik a tanuló személyéhez? Azt érezned kell. A neved például a tiéd, a születési dátumod is a tiéd, mivel az nem változhat, vagy ha változik, akkor te is változol vele. A lakcímed pl. nem a tiéd, mert simán elköltözhetsz, és más költözhet a te címedre. A sulid sem a tiéd, mert rajtad kívül sokan mások is abba a suliba járnak, még a mobilod sem a tiéd, mert bármikor lecserélheted, másnak adhatod. Ami nem a tiéd, nem a téged nyilvántartó táblába tartozik, hanem egy másikba.
Persze megfontolás kérdése, ha csak az iskola nevét akarjuk a tanulónál tárolni, akkor még akár maradhat is a tanuló táblában. Nem szép, de van olyan helyzet, amikor ez a hatékonyabb. De ha mondjuk a suli neve mellett a suli címe is nyilvántartásra kerül, meg a suli alapításának éve, meg az ott dolgozó tanárok száma, stb stb... Azt már nehéz megmagyarázni, hogy a suli alapításának éve mit is keres a tanulók nyilvántartásában. A gyereknek semmi köze hozzá, mikor alapították az iskolát. Szóval ha már ilyen kacifántos tranzitív függőségeket látsz, akkor szólaljon meg benned a csengő, hogy ez külön táblát kíván.Lehet, hogy mégis sikerült elmagyarázni?
Az okosok javítsanak ki, ha hülyeséget írtam. -
#4439
Szmeby
tag
DrojDtroll
#4438
Szmeby
tag
válasz
DrojDtroll
#4438
üzenetére
DDL? Főleg a tábla és a constraint lehet érdekes.
Ha nem a táblában van a hunyó, akkor nyilván valami másban, amit a constraint használ. Teszemazt egy oszlopra akasztott sequence, ami nem olyan értéken áll, ami az insertedet megenné. Bár a hibaüzi félrevezetően nem erről szól, de bele lehet képzelni, ha nagyon akarom. Amúgy nem értek a postgreshez, csak tippelgetek.
-
Szmeby
tag
Nem léteznek már eleve elosztott működésre képes megoldások?
Ami hirtelen eszembe jut, egy mongo is könnyedén szét tudja szórni az új adatot a cluster összes node-ján. Real time. A relációs DB-k erre nem képesek? Vagy olyan a felhasználási mód, ami mellett ez a megoldás nem jó ötlet?
-
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. -
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.[ Szerkesztve ]
-
Szmeby
tag
És gondolom, a projektben résztvevő összes cég azt állítja magáról, hogy csak minőségi szoftvert adnak ki a kezükből, a szakmai kiválóság az elsődleges.
Szerintem amúgy nem szar a terv, csak a tervező bizonyára elfelejtette, hogy a munkája nem ér véget a Generate gomb megnyomásával. A többi résztvevő meg nem volt elég tökös visszadobni a félkész produktumot. Pénz van, idő nincs, nyilván a gányolás felé húz ezek után minden résztvevő szíve. Nem szar ez, hanem kihívásokkal tűzdelt. Azt meg minden fejlesztő szereti, sokan a cv-be is beírják, a kihívás fontos.
(Sosem értettem, miért nem illik megosztani a nyilvánvaló ostobaságokat elkövető (jogi) személyek / projektek nevét. Mások okulására és tájékoztatására, hogy "ide ne gyertek dolgozni, ha nem akartok inkompetens, egyeztetésre képtelen egyedekkel együtt dolgozni". Mindig csak a cukormáz látszik. Pedig hibázni jó dolog, de azt nem beismerni totális káoszba vezet. És kinek van kedve káoszban létezni? Habár biztos akad olyan is, de én nem tartozom közéjük.)
-
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. -
#4669
Szmeby
tag
Apollo17hu
#4668
Szmeby
tag
válasz
Apollo17hu
#4668
üzenetére
Köszi Apollo! Fantasztikus ez az Oracle.
És tm5 azért csomagolta egy WITH-be, mert WHERE mögött ezek az analitikus cuccok nem használhatók, csak projekcióban (vagy hogy is hívják a from előtti részt)?
A next_id kiszámításának van valami különleges oka, vagy az amúgy elhagyható? Én feleslegesnek érzem az aktuális probléma szempontjából. Hacsak az oracle belső mechanizmusai ezt mégis megkövetelik valami mágikus okból.
Ez a megoldás amúgy a Descartes szorzathoz képest milyen előnyöket nyújt? Gyorsabb? Kíméli a memóriát? Elegánsabb?
A paraszti eszem azt súgja, hogy nem igazán lehet gyorsabb, hiszen ígyis úgyis kétszer szelektál a táblából, csak más sorrendben teszi a folyamat során. Hacsaknem attól ér el gyorsabb működést, hogy a nyers adatok diszken való rendezettségének köszönhetően a vinyó kevesebb fejmozgással is végre tudja hajtani a lekérdezést egy nagy adathalmazon. Bááár, azzal, hogy az eredeti halmazon nincs orderby, a lead függvény meg sorrendezett halmazon operál, még ez sem feltétlenül biztos. Asszem elkalandoztam. -
Szmeby
tag
Értem, és köszönöm a választ. Én is szeretem elszeparálni egymástól a lazán kapcsolódó dolgokat. SRP FTW!
Az mondjuk valóban egy fontos kérdés, hogy mi lehetett a kérdező szándéka. Tök érdekes látni, hogy ennek hiányában két egészen eltérő megoldás is született. Az, hogy nem akarja szemmel verni, mindkét esetben teljesül. De hogy ezután mihez kezd velük... arra lehet, hogy egy harmadik megoldás lesz az ideális.
-
Szmeby
tag
válasz
bambano
#4743
üzenetére
Szerintem ez csak egy házifeladat.
Már eleve életszerűtlen, hogy egy rakás fontos dolgot nem vesz figyelembe. Illene ellenőrizni, hogy a teljes rendszer egyenlege egyáltalán pozitív-e. Ha nem, akkor el kell dönteni, hogy inkább a kis hiánnyal rendelkező üzletek készletét optimalizáljuk és hagyjuk a nagy hiánnyal küzdő üzletet megdögleni. Vagy a nagy hiányra összpontosítunk és a kis hiánnyal rendelkező üzletek majd megoldáják valahogy. Teljesen más megközelítést igényel a két üzleti igény.
Ha feltételezzük, hogy a teljes egyenleg pozitív, akkor is kell egy korlát, ami alatt egyszerűen nem éri meg megmozdulni. Továbbá sokkal jobb minden üzlet készletét egy átlagos érték felé közelíteni. Vagyis ne a 0 hiány, 0 többlet legyen a cél, hiszen, ahogy te is mondtad, a raktárkészlet állandóan forog: ha csak a nullát tűzzük ki célul, akkor az első vásárláskor újra negatívba fordul, ami optimalizálási igényt kényszerít ki... abszolúte nem hatékony.
De még az átlagos szint sem feltétlenül optimális, hiszen egyes üzletek forgalma historikusan nagyobb, másoké kisebb, így érdemes ez alapján egy átlagtól való korrekciót alkalmazni. Ami aztán további problémákat szül, mivel egy tűpontosságúra optimalizált rendszerben - amennyiben az ember elfelejt gondoskodni az utánpótlásról - nagyon könnyen a teljes rendszer szintjén fellépő hiány alakulhat ki nagyjából ugyanabban a pillanatban.
A feladat nem veszi figyelembe az üzletek egymástól való fizikai távolságát, a megközelíthetőséget. Nagyon szépen hangzik, hogy egy db procedure megmondja, hogy a kettes id-jú üzletből vigyünk át 50 bizbazt a 14-es id-jú üzletbe, de ha ezek a város két végén helyezkednek el, akkor az ész nélküli ide-oda szállítgatás felzabálja a profitot. Arról nem is beszélve, hogy az ezt intéző munkavállalók azt fogják kérdezgetni, hogy ki volt az az idióta, aki ezt így kitalálta... és teljesen jogosan fogják megkérdőjelezni az értelmét.
A való életben ennél sokkal komplexebb feladat egy elosztott raktárkészlet optimális fenntartása, marhára nem egy temptáblával megoldható probléma. Mármint megoldható, csak az olyan is lesz. Ízlés dolga, kinek mit vesz be a gyomra ugye.
[ Szerkesztve ]
-
Szmeby
tag
válasz
Micsurin
#4778
üzenetére
Nem hiszem, hogy a feladat szovegeben talalni fogsz egy kulcsszot, ami elarulja, mit hova tegyel egy lekerdezesben.
En sem ertem pontosan a problemat, de ha az a gondod, hogy nem latod a kulonbseget a
SELECT e.department_id, last_name, legkisebb
FROM employees e, (SELECT department_id, MIN(salary) legkisebb
FROM employees GROUP BY department_id) min
WHERE e.salary=min.legkisebb AND e.department_id=min.department_id;es a
SELECT e.department_id, last_name, legkisebb
FROM employees e
INNER JOIN (SELECT department_id, MIN(salary) legkisebb
FROM employees GROUP BY department_id) min ON e.department_id=min.department_id
WHERE e.salary=min.legkisebb;kozott, akkor az azert van, mert nincs kulonbseg.
En az utobbi formatumot szoktam meg es szeretem hasznalni. Az utobbi egy ujabb talalmany, a hosidokben az elobbit hasznaltak. De ez a ketfele formatum a subquerytol pont fuggetlen, sima tablakkal ugyanugy alkalmazhato mindket forma.---
Hogy subqueryt tablakent hasznalsz egy lekerdezesben es joinolgatsz, vagy a where feltetelben szursz a subquery eredmenyevel egy masik tabla egy mezojen*, szerintem ez ket annyira eltero dolog, hogy adja magat. Join-ba azert teszed, mert mondjuk a subquery-bol is szeretnel ertekeket megmutatni az eredmenyhalmazban. Vagy mert tobb mezore is szurnel, es join-nal atlathatobb a lekerdezes, vagy mert a DB jobban optimalizalja igy a lekerdezest, mint ugy. Probalgasd, gyakorolj, idovel raerzel!
* Mondjuk valami ilyesmi:
SELECT e.department_id, last_name
FROM employees e
WHERE e.salary=(SELECT MIN(salary) FROM employees min WHERE e.department_id=min.department_id);---
Vagy ha a subqueryt a szelekcioba rakod, hat, meg nem mondom, mikor van ennek haszna. Annyira nem vagyok expert, hogy ezt most igy hirtelen meg tudjam fogalmazni, es sose filozofalgattam azon, hogy milyen kulcsszavak milyen strukturaltsagot implikalnanak. Szelekcioba nagyon ritkan tettem subselectet, mert borzaszto rossz hatasfoku volt.
Szerintem egy jo okolszabaly, hogy ird meg join-nal a lekerdezest, es ha azt latod, hogy a join felesleges, mert mondjuk a kapcsolt tablabol semmit nem mutatsz meg az eredmenyhalmazban, akkor kis atalakitassal talalj neki egy szebb / jobb formatumot. Erdemes kiprobalni, hogy mennyire hatekonyan hajtja vegre a DB az egyik es a masik valtozatot. Sok gyakorlas utan pedig mar raerzel majd, hogy melyik megoldas optimalis, es eleve ugy kezdesz hozza. Meg az exists egy olyan okossag, ami egesz jo hatekonysagot mutat, annak a probalgatasat is ajanlom.
Ha elkepzeled, hogy melyik tabla vagy subquery hany sorral ter vissza, es az alapjan probalod beloni, hogy a DB vajon egyik-masik konstrukcioban mennyire izzadna meg, akkor az talan segit eldonteni, hogy merre erdemes elindulni.
Na de en is kivancsi vagyok egy hozzaerto gondolataira, hatha van egyszerubb mod.
[ Szerkesztve ]
-
Szmeby
tag
válasz
nyugis21
#5271
üzenetére
Az alapvető probléma, hogy magyar "igazság"szolgáltatás tele van technológiai analfabétákkal, tisztelet a kivételnek. Ebből fakadóan a bíróság semmilyen mai szemmel nézve modern megoldást sem fogad el bizonyító erejűnek, mert nem ért hozzá. Nem érti, hogyan működnek a kriptogáfiai eljárások, hol vannak a gyenge pontjai, mely részei számítanak hitelesnek és melyek nem. Ezért aztán le van ragadva úgy a 19. századi technológia környékén, a közjegyző által hitelesített dokumentumok és tértivevényes levelek világában. Esetleg a telefonhívásokat még vissza lehet kerestetni... a telkók megőrzik elég részletesen a hívás adatokat sok évre visszamenőleg. Nem látnám akadályát, hogy ezeket egy bíróság kikérheti.
A saját magam által karbantartott adatbázist pedig ott hamisítom meg, ahol csak jólesik, ez alól az access sem kivétel. Ha a jogászok értenének hozzá, akkor emiatt sem fogadnák el bizonyítékként.
Vagyis maradnak a rendszeresen auditált, hiteles adatkezelési jogosítványokkal ellátott természetes és jogi személyek, akiket a társadalom, a bíróság hitelesnek ismer el, és ők nyilvánvalóan megkérik a szolgáltatásuk árát. Még a blockchainben való adattárolásért is kell fizetni, amit meg aztán végképp nem várom el a bíróságtól, hogy elismerjen, mert segghülye hozzá. Talán majd néhány évszázad múlva sikerül felnőniük a feladathoz, ki tudja.Persze ettől még vezethetsz naplót, van esély rá, hogy valaki jófej lesz és hisz neki. De arra mindenképp számíts, hogy a bíróság valószínűleg nem fogja elfogadni bizonyító erejűnek.
Idézetek gyűjtésére viszont jó megoldás a napló. Egy adatbázis erre a feladatra lehet, hogy ágyúval verébre kategória, de ki tudja, lehet később hasznos lesz majd, hogy gyorsan tudod szűrögetni a 26 millió soros tábládat... egy excel nem feltétlenül alkalmas ilyesmire. Vagy mit tudom én, egy új dolog megtanulásának öröme is lehet cél, az idézetgyűjtemény meg csak a bónusz.
---
Habár! Most eszembe jutott valami. Elvileg van egy személyi igazolványunk, amihez a drága magyar állam ingyen nyújt digitális aláírás szolgáltatást, hiteles időbélyegzővel, meg minden. Életembe nem használtam még, de talán ebből lehetne faragni egy talán a bíróság által is elfogadható megoldást. Ami hirtelen eszembe jutott, hogy csinálnék egy email fiókot egy megbízható szolgáltatónál, és a nekem fontos adatokat a saját email fiókomból a saját digitális aláírásommal aláírva elküldeném arra a címre. Kérdés, hogy a bíróság elfogadja-e ezt hitelesnek. Ingyen van, lehet benne keresni. Persze ez is csak az elküldés tényét és a hamisítatlanságot bizonyítja, az információtartalom helyességéről nem mond semmit. Na jó ez már nagyon offtopic.
-
Szmeby
tag
válasz
nyugis21
#5378
üzenetére
Parancsolj, a fenti móricka példa első két eseménye és résztvevői. Valahogy így fog kinézni a tábláid tartalma. Megszíneztem az összetartozó dolgokat, hogy könnyebb legyen szemmel összepárosítani. (A "meg a többieket" lespóroltam róla, mert nem volt elég konkrét a példához.)
[ Szerkesztve ]
-
Szmeby
tag
Akkor is a saját scriptek tartalmát látod benne, amikor 7 kilo és akkor is, amikor 7 mega? Nem hinném.
Mármint lehet, hogy azt látod, de bizonyára más is van mellette, különben miért is lenne 7 mega.Az adatbázisok nem csak nyers adatokat tárolnak, vannak benne indexek, dolgozik egy rakás átmeneti adattal, metaadattal, millióegy dologgal. Miért ne írná ki ezeket az adatokat is fájlba? Attól még lehet az ebből exportált script töredék méretű, a kettő szerintem nem zárja ki egymást.
(Amúgy semennyire sem értek az adatbázisok lelkivilágához, de számomra így logikus.)
