Hirdetés
- Luck Dragon: Asszociációs játék. :)
- GoodSpeed: Sapphire Radeon RX 9070 XT Pulse - út a harmadik AMD korszakig.
- GoodSpeed: Aquaphor Modern víztisztító
- Brogyi: CTEK akkumulátor töltő és másolatai
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Geri Bátyó: Agglegénykonyha 2 – Főzés: szabályok, vagy szabadság?
- sh4d0w: Netflix? Ugyan, VW előfizetés!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- eBay-es kütyük kis pénzért
Új hozzászólás Aktív témák
-
Ispy
nagyúr
Jaja, praktikus. Aztán majd mikor kiderül, hogy:
a) a státuszoknak meg is kell jelennie vizuálisan több nyelven is,
b) a státuszoknak ne adj isten előbb-utóbb folyamatokat is kell vezérelnie,
c) és még akár hierarchia is van közöttük,
d) ja és most még csak egy táblában van, de holnapután még 2-ben is használni kéne,akkor majd lehet szétszedni a remek kódok és megcsinálni rendesen.
Mondhatod, hogy neked ezek nem szempontok és áááá soha nem lesz ilyen és 1000 évig elleszel ezzel a 4 stringgel, de attól még szerintem nem ez a jó megoldás (és igen, nem lesz így sem lassabb, nem lesz így sem nagyobb az adatbázis, viszont neked jó lesz, mert kényelmes).
Egyébként meg ha már itt tartunk mégis mitől másabb egy szöveget látni, mint egy kódot, ha abból csak 4 darab van és soha nem is lesz több? Kb. 3x ránézel és már kód alapján is tudni fogod, hogy melyik mit jelent. Egyébként is manapság nagyon elkényelmesedett minden programozó, mert hát van sok terrabájt, meg gigabájt, meg sokmag és a hardware elfedi a nem hatékony programok hiányosságait, aztán amikor meg pár év múlva esetleg hirtelen megnő a program kihasználtsága, akkor az ilyen kis atombombák szépen elkezdenek felrobbanni.
Csak az idők során kezdek rájönni, hogy érdemesebb a legpraktikusabb megoldások felé menni
Volt jónéhány kollégám akik szintén ezt vallották, de sajnos mindig nekem kellett a végén visszalapátolni a lóba a sz@rt. Hidd csak el, ezeket a dolgokat nem azért találtak ki sok-sok éve, mert annyira rosszak lennének.
Peace!
-
modder
aktív tag
jaja, önigazolást
Amúgy kb. mindenki azt írta, hogy "persze, nem eretnekség, csak nem úgy szoktuk". Formálisan helyes, teljesítményben alig van/nincs különbség. Akkor pedig nem kókányolás, akármennyire is ezt akarjátok sulykolni. (persze nem mindenki)Nekem is van annyi tapasztalat a hátam mögött, hogy magabiztosan megkérdőjelezzek egy ilyen "best practice"-t, főleg ha találkoztam velük nyílt forráskódú keretrendszerekben, ahol előszeretettel tettek enum típusú értéket szöveg mezőbe, és még senki nem panaszkodott, hogy szar lenne a rendszer. Viszont fejlesztésnél rohadt jól jön, amikor nem egy nyamvadt számot látok a mezőben, amikor azt ellenőrzőm, hogy jó értéket tett-e az adatbázisba. Vagy azt, hogy jól működik-e az ORM cache, és tényleges adatbázis értéket olvasok, nem egy cache-elt halmazt. - Tegyük hozzá, nem egy egyszerű CRUD alkalmazásról van szó
De ne értsetek félre, nem mondom, hogy az egyik vagy a másik megoldás helyesebb, mindig sok mindentől függ, de amit felvetettem, semmiképpen sem helytelen. Szóval nem akarom megreformálni a nézeteket
Csak az idők során kezdek rájönni, hogy érdemesebb a legpraktikusabb megoldások felé menni, ha azok nem sértenek durván alapelveket, mert a szoftverfejlesztésben mindig előbukkanhat egy szopatás, és akkor én minél kevesebbet akarok oblákolni - és szoptam én már túltervezett adatbázistól is, ami nagyon megállta a helyét tankönyv szerint, de 1 nap volt, mire kitaláltam azt a furfangos lekérdezést, amivel azt kaptam meg, amit szerettem volna. -
martonx
veterán
- az egyik, amiből az egész kiindult, hogy ha a lekérdezéseket szerkesztem valamilyen kliens programban, akkor jobban esik az agyamnak, ha a konkrét információt látom a mezőben, ha ellenőrzöm, jó lekérdezést írtam-e meg. Ide tartozik még, ha valaki (vagy én) évek múlva hozzá akar nyúlni a szoftverhez és adatbázishoz, leegyszerűsödik a dolga.
Ez evidens, de ha ez így lenne, akkor mindjárt eljutunk oda is, hogy minek relációs adatbázist használni. Ennyi erővel eltárolod egy text file-ban az egészet, és nincs is miről beszélnünk.- a városos példánál maradva nincsen szükség joinra, ami egy kicsit le tudja egyszerűsíteni a lekérdezést, ha egyébként az nagyon összetett; sok másik jointot is tartalmaz.
Erre lennének valóak a view-k, tárolt eljárások.- ha szoftverben valamilyen ORM frameworkot használunk, közvetlenül benne lehet a város neve a személyek entitásban, ahelyett, hogy egy varos entitason keresztül kéne hozzáférnem az értékhez. (Elképzelhető, hogy egy-egy kapcsolatnál be lehet süllyeszteni a személy entitásba a várost, de most nem jut eszembe, hogy pl. JPA-nál lehet-e)
Hogy jön ide az ORM? Olyan view-t, vagy selectet, vagy tárolt eljárást írsz, amilyet akarsz, és az lesz benne, amit akarsz. Végül az ORM-et arra húzod rá, amire jólesik (legalábbis NHibernate, Entity Framework-ös tapasztalataim alapján).Szerintem maga a kérdés feltevés értelmetlen volt, hiszen ha ilyen bagatell a dolog a részedről, ilyen pici a projekt, ilyen minimális adattal, meg különben is ennyire értesz hozzá, akkor minek kérdezted meg? Úgy kókányolsz vele, ahogy akarsz. Ha viszont igényes munkára törekszel, akkor meg miért nem fogadod meg a tanácsokat?
-
#2096
fordfairlane
veterán
modder
#2095
fordfairlane
veterán
Egyébként én először olyan információt akartam szövegként tárolni, ami tipikusan egy enum (SQL) típus lenne, és a mező "kardinalitása" olyan 10 db érték körül mozog. Enummal az a baj, hogy nem elég dinamikus, ha új értékre van szükségem az alkalmazásban, akkor módosítanom kell az elérhető enumok listáját, ami MySQLnél azt is eredményezheti, hogy újragenerálja az egész táblát. És az enumra lett volna alternatíva a numerikus vagy szöveges érték, ahol én arra szavaznék, hogy legyen csak szöveges pl.
Státusz = {"active", "inactive", "suspended", "deleted"} ahelyett, hogy 1,2,3,4-t tennénk a mezőbe. És szerintem ez tényleg nem nagy eretnekség.Már miért lenne eretnekség, sehol nincs előírva, hogy felsorolás mezőnek INT-nek kell lennie. Enum mehet a fix készletnek, CONSTRAIN-es kapcstábla a variábilis jellegűnek. Felindexelve egy varchar is gyors, és csak emiatt fölösleges egy plusz INT-re absztrakciót beemelni a táblaszerkezetbe.
-
modder
aktív tag
válasz
PazsitZ
#2092
üzenetére
Csak hogy ne kanyarodjunk el nagyon, az előfeltételek, amiket már legelőször is említettem (vagy nem) a kutyafuttában összedobott hozzászólásomban:
- Átlagos/kis terhelésű weboldalról van szó, nem valami hatalmas terhelésről. Mit tudom én, napi pár 10e oldal lekérés
- Kis adatbázisméret: pár 10e rekord, pár 10MB adatbázis méret (ez mondjuk egy blog mérete sok cikkel)Azért fontos ezt megemlíteni, mert nagy tábláknál, amik sok I/O műveletet igényelnek, fontos, hogy ne növekedjen duplájára a rekord méret egy CHAR field miatt.
Mondok két előnyt:
- az egyik, amiből az egész kiindult, hogy ha a lekérdezéseket szerkesztem valamilyen kliens programban, akkor jobban esik az agyamnak, ha a konkrét információt látom a mezőben, ha ellenőrzöm, jó lekérdezést írtam-e meg. Ide tartozik még, ha valaki (vagy én) évek múlva hozzá akar nyúlni a szoftverhez és adatbázishoz, leegyszerűsödik a dolga.
- a városos példánál maradva nincsen szükség joinra, ami egy kicsit le tudja egyszerűsíteni a lekérdezést, ha egyébként az nagyon összetett; sok másik jointot is tartalmaz.
- ha szoftverben valamilyen ORM frameworkot használunk, közvetlenül benne lehet a város neve a személyek entitásban, ahelyett, hogy egy varos entitason keresztül kéne hozzáférnem az értékhez. (Elképzelhető, hogy egy-egy kapcsolatnál be lehet süllyeszteni a személy entitásba a várost, de most nem jut eszembe, hogy pl. JPA-nál lehet-e)...három lett
Egyébként én először olyan információt akartam szövegként tárolni, ami tipikusan egy enum (SQL) típus lenne, és a mező "kardinalitása" olyan 10 db érték körül mozog. Enummal az a baj, hogy nem elég dinamikus, ha új értékre van szükségem az alkalmazásban, akkor módosítanom kell az elérhető enumok listáját, ami MySQLnél azt is eredményezheti, hogy újragenerálja az egész táblát. És az enumra lett volna alternatíva a numerikus vagy szöveges érték, ahol én arra szavaznék, hogy legyen csak szöveges pl.
Státusz = {"active", "inactive", "suspended", "deleted"} ahelyett, hogy 1,2,3,4-t tennénk a mezőbe. És szerintem ez tényleg nem nagy eretnekség.VÁLASZOK:
----------------------------------------------------bambano, pazsitZ: De fontos ha rossz teljesítményt produkálna a szöveges tárolás. Az volt a gondom, hogy azt sugalltad, az SQLlel egyébként is teljesítményt vesztünk, következésképpen mindegy, hogy a szöveges tárolással teljesítményt vesztünk. Ezzel ki is dobhatnám az érvem, miszerint nem volt teljesítménybeli különbség. Egyébként itt az említett link - aki lemaradt volna -, érdemes megnézni, hogy 1.5 millió rekordnál, kis rekord méretnél, tehát befér a memóriába a tábla, nem volt különbség. http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/
Egyébként nem hálós adatbázisról beszélünk, hanem relációs adatbázisokról (és nem SQL adatbázis).martonx: Ebben teljesen igazad van, hogy szöveges mező index esetén, ha mysql B-TREE indexről van szó, az index mérete bizony jócskán megnövekedhet a numerikus indexhez képest, de a keresés nem lesz annyival lassabb, mert a string összehasonlítás csak az első nem egyező karakterig hasonlít, a fa magassága pedig nem nő akkorát, jellegéből adódóan. Hash indexnél pedig mindegy, mert ott úgyis csak a hash van eltárolva az indexben.
pazsitZ: Szóval mégis csak szükséged van egy másik táblára.
Ahol mondjuk település adatokat tárolsz. Ekkor viszont már minek a string?
(Arról az esetről van szó, ha szövegként tárolom a város nevét, de kell egy másik tábla, ahol az összes lehetséges város tárolva van) Nincs szükségem string joinra lekérdezésnél, hiszen a város neve ott van a személyek táblában. Beszúrásnál van szükség idegen kulcs ellenőrzésre, ami index alapján történik.martonx: Ráadásul pont ez az az általad is sokat kritizált gányolós, kókányolós, hozzáállás az, ami miatt aztán tömegek bele is kövesednek ebbe a programozói attitűdbe. Elvégre minek normálisra megcsinálni az indexeket, meg a relációs kapcsolatokat, há' nem sokkal egyszerűbb, mindent beb***ni egy táblába, megfelelő indexeket rátenni, és ha megnézem ezer sorig még gyors is?
Azért ez nem teljesen így van. Akkor lenne kókányolás (amúgy imádom ezt a szót, én is sokat használom), ha ezzel alapjaiban véve mennénk szembe a relációs adatbázis elvekkel, de ahogy kifejtettem a normalizálós hozzászólásomban, erről szó sincs. Egyébként én is nagy teljesítményhajhász vagyok, de nem szeretek lemondani a kényelemről ott, ahol nem kapok érte cserébe elég nagy előnyt teljesítményben. És úgy érzem, amíg tudom, hogy nem lesz több száz megabyteos az adatbázisom, addig ez egy ilyen helyzet. -
Ispy
nagyúr
válasz
PazsitZ
#2092
üzenetére
Én tudok neked mondani példát:
kedves ügyfél szervert cserélt és a kedves rendszergizda az új szerveren a Hungarian_CI_AS collation helyett valami Latin-t adott meg, és ettől a ponttól kezdve a szerver collation-je nem egyezett meg az adatbázis collation-jével és az összes string alapú join kifingott tőle, szóval mindegyiket kézzel meg kellett hekkelni (COLLATE DATABASE_DEFAULT), hogy ne szálljon el hibával. Ez az egész programban kb. 20x fordult elő. Ha nem integer alapú kötéssekkel lett volna tele az adatbázis, akkor ez a szám nem is tudom mennyi lenne, de biztosan 1000 felett.
-
#2093
martonx
veterán
Sk8erPeter
#2090
martonx
veterán
válasz
Sk8erPeter
#2090
üzenetére
Az, hogy a táblák lényegében mekkorák, soha nem indok arra, hogy csak azért is szopassuk már meg jól az SQL szervert
![;]](//cdn.rios.hu/dl/s/v1.gif)
Azért mondtam akkora méreteket, mert ha azt mondom, hogy nem 10 ms lesz a query ideje, hanem 500 ms, az nem fog elég elrettentőnek hatni.
Ráadásul pont ez az az általad is sokat kritizált gányolós, kókányolós, hozzáállás az, ami miatt aztán tömegek bele is kövesednek ebbe a programozói attitűdbe. Elvégre minek normálisra megcsinálni az indexeket, meg a relációs kapcsolatokat, há' nem sokkal egyszerűbb, mindent beb***ni egy táblába, megfelelő indexeket rátenni, és ha megnézem ezer sorig még gyors is? Különben is sokkal kényelmesebb visszanézni szemre az adatokat, meg a PHP-ban is egy select * from tabla, és mindenki happy.Nehogy már elkezdjünk erre bólogatni, hogy tényleg milyen igaz.
-
PazsitZ
addikt
Nekem a problémám megint csak ott van, h ellentmodnást érzek.
Szóval mégis csak szükséged van egy másik táblára.
Ahol mondjuk település adatokat tárolsz. Ekkor viszont már minek a string?
String join amúgy is lassabb lesz feltehetőleg, persze biztos elmegy úgy is, de végül akkor amúgy is lesz szükséged join-ra.
Nagyon egyszerű tesztelésen kívül pedig nem látom még mindig a rációt a kézzel túkálok a táblában érv mellett. De ekkor is én nem kézzel turkálnék, hanem query-vel populálnék be minta adatot is talán.Egyébként a karakterkódolásra bár azt mondtad, nem lehet gond, én mégis idegenkedek ilyen-olyan spec. karaktereket használni (bár konkrét példa most nem jut eszembe), az int index az viszont biztos, h teljesen egyértelmű és hibamentes lesz.
A hatékonysági kérdésekkel csak akkor érdemes ilyen mélyen foglalkozni
Feljebb még te linkeltél performance eredményeket a sztring tárolás védelmében, akkor fontos volt. Ha valaki negatív performance eredményt említ akkor már nem fontos?
U.i.:
Most téynelg nem kötözködni akarok, csak még mindig nem látom a hasznot. De persze ettől még nyugodtan tárolhhatod így, nincs ezzel gond, engem legalább is nem zavar.Nem zavar, amíg nem kell más ilyen DB-jét migrálnom. Sajnos kellett már, nem volt jó
-
#2091
Ispy
nagyúr
Sk8erPeter
#2090
Ispy
nagyúr
válasz
Sk8erPeter
#2090
üzenetére
Az, hogy a táblák kicsik még nem indok arra, hogy ne a tankönyv szerint csináld. Ha csak 1 rekord lesz benne, akkor is jól kell megcsinálni. Attól lesz valaki szakember, nem pedig vérpistike.
-
#2090
Sk8erPeter
nagyúr
martonx
#2089
Sk8erPeter
nagyúr
válasz
martonx
#2089
üzenetére
"kis tábla méreteknél ez észrevehetetlen, de ha egy táblában van 2-3 ilyen szarul megoldott indexed, és a tábláid több százezer sorosak"
Ha jól emlékszem, az eredeti felvetésben pont az szerepelt, hogy előre tudható, hogy a táblák relatíve kicsik (mit tekintünk egyébként kicsinek?), és sosem lesz bennük többszázezer rekord. Tehát szerintem arról nincs értelme jelen esetben beszélni, hogy "mi lenne, ha", hanem csak arról, ami van, mert pont azért érdekes a kérdés-felvetés, hogy vajon minden esetben helytállóak-e a tankönyvszerű, berögzült gondolatok, vagy van, amikor ettől el lehet térni, ha nem okoz észrevehető különbséget.
Az alapötleten először én is felhördültem magamban, hogy háccccezmicsodadolog, én nem így tanultam, és nem ehhez vagyok hozzászokva, és én amúgy sem így oldanám meg, aztán rájöttem, hogy elképzelhető olyan eset, amikor kicsit rugalmasabban is meg lehet közelíteni a kérdést, ha valakinek adott esetben úgy kényelmes, amennyiben AZ ADOTT ESETBEN (és nem akkor, HA más lenne) nem okozna észrevehető teljesítménybeli romlást. Épp ezért érdekelt, hogy vajon mik lesznek a meglátások ezzel kapcsolatban (még ha én még az adott feladat kedvéért sem így oldanám meg), de sajnos aztán bejött az, amire számítottam, hogy jönnek a tankönyvszerű elvekre hivatkozások (néhol helytelenül, lásd korábban (de)normalizálás fogalmának/elvének nem sok köze van ahhoz, hogy az elsődleges kulcs int vagy string), és a "na de gondolj bele, HA LENNE többtízcsillióbilliókétszáz rekordod"-jellegű megjegyzések, meg a többtízgigarammalnemparaöcsém, és ezek általában csak pont a lényegről terelik el a szót. -
martonx
veterán
Mivel semmi konkrétumot nem írtál, nyilván én se tudtam mit írni azon kívül, hogy még a felvetés is hülyeség. No, de közben jött itt egy példa a településnevekkel.
Szerinted melyik megoldás a rövidebb? Egy 16 - 32 bit hosszú mezőben eltárolni egy numerikus adatot, vagy egy 50X16 bitnyi mezőben eltárolni egy szöveges adatot.
"- index sebessége: annyival lassabb egy pl. 30 karakter hosszú CHAR vagy VARCHAR mezőn az index használata?"
Jelzem, amikor erre a mezőre indexet húzol, az indexed is pont ilyen méret differenciákkal fog létrejönni.
Aztán nézzünk még egy érvet. A processzorok leggyorsabban számok feldolgozásával működnek. Persze-persze, minden mást is fel tudnak dolgozni, ami binárisan leírható, de akkor is minden CPU alapja a "számolás".
Számszerűsítve a dolgot, olyan több mint 50-szeres sebességkülönbség simán lehet a két megoldás között. Azt persze aláírom, hogy kis tábla méreteknél ez észrevehetetlen, de ha egy táblában van 2-3 ilyen szarul megoldott indexed, és a tábláid több százezer sorosak, netán valami gyenguc hoszting gépen vagy többtized magaddal ugyanazon az adatbázison, akkor ez máris másodperceket, akár perceket jelenthet.Egyébként amit felvetettél, abszolút nem eretnek gondolat. Tegyél fel egy MongoDb-t, vagy bármilyen NoSql-t, toljál a hoszting gépedbe pár 10 Gb memóriát, és máris bármilyen lehet az adatbázisod, és még csak lassú se lesz.
-
bambano
titán
"Ez úgy hangzott, mintha az SQL használatával nagyságrendekkel rosszabb teljesítményt érnénk el": ez valószínűleg azért hangzott úgy, mert igaz, feltéve, hogy nem az eredeti szövegkörnyezetéből kiszakítva értelmezed a mondatot. az eredeti szövegkörnyezetben nem az volt az állítás, hogy egyik sql lekérdezés a másik sqlhez képest milyen, hanem az, hogy egy adott sql lekérdezés egy nem sql rendszerű, itt konkrétan hálós volt emlegetve, adatbáziskezelőhöz képest milyen. hát lassú.
Az eredeti mondat ez volt: "merthogy az sql masszívan nem hatékony akár a hálós adatbáziskezelőket nézed, " és igen, az sql rohadtul nem hatékony egy hálós adatbáziskezelőhöz képest, pláne, ha a lekérdezés olyan, amire a hálóst tervezték.
a személy meg a város kérdéskör meg akkor lesz érdekes, ha egy városból több személy van, pláne, ha nem egyszerre töltik be az adatokat, és akkor elkezdik a t. userek mindenféle néven illetni a településeket. ez még városoknál nem annyira nyilvánvaló, de én még nem láttam olyan adatbázist, ahol az utcaneveket képesek lettek volna egységesen írni. az meg, hogy ilyenkor nyakonvágjam a t. usert, kívánatos, de nem lehetséges megoldás
no mindegy, járod a magad útját, oszt jónapot.
-
Ispy
nagyúr
1-2 eset, amikor szerintem hasznos a numerikus tárolás:
- megváltozhat a neve
- többnyelvűség szempont
- listából választás
- kapcsolódó információk tárolásaKódból meg ha kell ugyanúgy csinálok rá egy enumot és máris olvashatóvá tettem, szóval szerintem nem az a kérdés, hogy mi szól a stringként tárolás ellen, hanem szól-e egyáltalán valami mellette?
Visszatérve az alap kérdésre, kis adatbázisok esetében semmi jelentősége a szöveges vagy numerikus tárolásnak teljesítmény vagy méret szempontjából, de más szempontok miatt kell végiggondolni, hogy mit érdemes törzsbe kiszervezni és numerikus értékként tárolni a kulcsot (ami egyébként lehet autonumber is, szóval +1 érv a numerikus mellett).
-
#2086
fordfairlane
veterán
modder
#2083
fordfairlane
veterán
Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig?
Ha a település neve egyedi, akkor a név lehet kulcsmező. Szövegként tárolni a települések közt, és idegen kulcsként is felhasználható egyidejűleg.
-
modder
aktív tag
Hát igen, végülis a kérdés az volt, hogy mi a véleményetek. Nem is akarok meggyőzni senkit, de szerintem nem árt, ha néha megkérdőjelezünk valamit, mert aztán lehet, hogy kiderül hogy egy egyszerű berögződés. Az előző posztomban igazából csak levontam magamnak a következtetést (meg válaszoltam egy-két hsz-ra).
-
Ispy
nagyúr
Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig?
Igen, pontosan, erről szól a relációs adatbázis kezelés, ettől még persze nem muszáj így csinálnod, de megerősítésre itt ne várj.
(12 éve dolgozok SQL-lel, megírni egy joint, olyan mint levegőt venni, fel sem tűnik)
"könnyebb elírni": miért, a numerikus azonosítót nem könnyű elírni?
Ha van numerikus mezőm, nem kézzel kell megadni az értéket, hanem listából választani, így elírni nem lehet (max. rosszat választani).
-
modder
aktív tag
válasz
bambano
#2081
üzenetére
Nem nagyon voltak meggyőző érvek a szöveges tárolás ellen. A település név tök jó példa.
Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig? Egy településeket tartalmazó táblára mindig szükségünk van, mert valahol el kell tárolni a lehetséges értékeket.
bambano:
Sématervezési szempontból semmivel sem rosszabb, ha szövegként van tárolva a település neve a személy táblában. Ez nem növeli a redundanciát, se nem lesz denormalizált. Redundanciáról akkor beszélhetnénk, ha a lélekszámot is mindig eltárolnánk a település neve mellett a személyek táblában, mert a település neve meghatározná a lélekszámot, így ez utóbbi tárolása is (még mindig a személyek táblában) csak bonyodalmat okozna. Pontosan ez is a redundancia definíciója. Ha már a normálformákat hoztad fel, vegyél elő egy egyetemi jegyzetet, és olvass bele. Vagy pl. ez egész jól leírja: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.2Ha van egy település táblánk, a település neve - mint szöveg - ugyanúgy lehet idegen kulcs a személyek táblában. Nem kell ahhoz numerikus elsődleges kulcs, hogy kikényszerítsük a személyek táblában, hogy csak bizonyos település neveket lehessen felvinni.
"azok után pedig, hogy azt állítottam, az sql-ben a teljesítményt feláldozzuk más célok elérése érdekében, ez a link mennyiben releváns?"
Attól, hogy állítasz valamit, az még nem biztos, hogy igaz. Ez úgy hangzott, mintha az SQL használatával nagyságrendekkel rosszabb teljesítményt érnénk el, pedig az SQL csak arra jó, hogy nem neked kell megírnod, hogy mikor melyik indexeket akarod használni. De az SQL végrehajtási tervbe fordítása mellett még száz másik szempont van, ami nagyban befolyásolja a lekérdezés sebességét, aminek semmi köze ahhoz, hogy milyen lekérdezőnyelvet használsz. És persze az sql-t is többféleképpen írhatod meg, hogy segíts az optimalizálónak a hatékonyabb végrehajtási terv elkészítésében.martonx: Köszönjük a hozzáértő, szakmailag megalapozott hozzászólást
Ami megfontolandó:
- karakterkódolási problémák: Ez általában olyan, hogy vagy fennáll az egész adatbázisra és az őt használó alkalmazásra, vagy nem, ami persze más szöveges mezőket is érint.
- "könnyebb elírni": miért, a numerikus azonosítót nem könnyű elírni?
- index sebessége: annyival lassabb egy pl. 30 karakter hosszú CHAR vagy VARCHAR mezőn az index használata?
- tárolás: a szöveg több byte-ot használ felA hatékonysági kérdésekkel csak akkor érdemes ilyen mélyen foglalkozni, amikor a tárolási kapacitás és pl. a beszúrási (index frissítési) sebesség sarkalatos pont, ami egy "egyszerű" webalkalmazásnál ritkán fordul elő.
pazsitZ: leginkább mysql cli, phpmyadmin vagy egyéb kliens programra gondoltam, amikor kotorászásról beszéltem.
-
PazsitZ
addikt
és kódban egy enumhoz kötöm
Pont kérdezni akartam, kód szinten hogy kezeled az értéket.
Viszont akkor már magadnak sikerült ellentmodani.
mert ha nekem az adatbázisban kell kotorásznom, nem fogom fejben visszafejtegetnem, hogy melyik numerikus azonosító mit jelent <-> és kódban egy enumhoz kötömHa kódban enum, akkor hol miért kellene kotorászni, fejtegetni?
-
bambano
titán
ha csinálsz egy személyzeti nyilvántartást, a település nevét ott se rakod be karakteresen, hanem csinálsz hozzá egy szótár táblát és integer azonosítóval "linkeled".
pontosan ugyanezért denormalizálás, amiről beszélsz.azok után pedig, hogy azt állítottam, az sql-ben a teljesítményt feláldozzuk más célok elérése érdekében, ez a link mennyiben releváns?
-
modder
aktív tag
válasz
bambano
#2077
üzenetére
Normalizálás kérdés: Lehet, hogy félreértettél. Legyen egy státusz mező és a kérdés, hogy ha van egy aktív és passzív érték, akkor azt numerikusan (0 és 1-gyel) vagy charként ("active" és "passive") érdemes-e tárolni. Ez esetben miért lenne az első normalizált, a második pedig denormalizált abban az értelemben, amit te is említettél, azaz ha normálformákról beszélünk.
Az eredeti kérdésemre pedig kaptam egy linket, ami nagyjából le is fedi az én esetemet: http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/
-
bambano
titán
ha egy táblában van ötezer sor, aminek egy mezőjében 10 stringből található 1, akkor az denormalizált.
a string rendszerű tárolással meg az a baj, hogy könnyű elgépelni, mikor hivatkozol rá, esetleg van benne ékezet is, amitől fejreállnak a kliensek, meg hasonlók. persze mondhatod erre, hogy nem, de abból az lesz, hogy most nem, és később?
az egész sql bagázs arról szól, hogy a hatékonyságot feláldozzuk más erények érdekében. merthogy az sql masszívan nem hatékony akár a hálós adatbáziskezelőket nézed, akár a nosql-t, vagy ilyeneket.
-
modder
aktív tag
válasz
bambano
#2073
üzenetére
attól, hogy stringként tárolom ugyanazt az információ tartalmú adatot, még nem lesz denormalizált.
A mezők kb max 10-féle értéket vehetnek fel, szóval numerikus számozással 1..10-ig. Csak a kérdés az, hogy mennyivel rosszabb/kevésbé hatékony az, ha én nem numerikus értékként akarom tárolni az információt (és kódban egy enumhoz kötöm), hanem egy max 20 hosszú karakterláncként.
-
bambano
titán
ezt az ötletet a Chomsky féle normálformákról és az adatbázis normalizálásról szóló vizsgán ne vezessétek elő, mert megbuktatnak
átfogalmazva: az ötlet rossz, nem denormalizálunk adatbázist.
a helyes megoldás, hogy felveszel egy kulcstáblát, és abba belerakod a szövegeket, azonosítóval.
amikor az adatbáziskezelés elveiről van szó, akkor a disk io nem számít szerintem.
-
Pilács
senior tag
Sziasztok, segítség kellene:
Weboldal PostgreSQL adatbázisában van két tábla, public.kepgaleriahu és public.galeria_2013hu. Struktúra ugyan az, tehát ugyan azok a mezők(oszlopok) vannak felvéve. A kepgaleriahu tartalmát kellene átmásolnom a galeria_2013hu - ba, egy az egyben. Hogyan tudom megtenni? Admin felülethez hozzáférek, phpPgAdmin-ban tudok parancsokat futtatni. Lekérdezéseket már korábban csináltam a SELECT paranccsal, de ennyi
Még egy dolog esetleg jó lenne ha nem nehéz:
Ez a struktúra:
cikkszam,sorszam,tsor,toszlop,vezerlo,ujsor,tipus,adatA cikkszám nem egytől fut, és van a sorban kihagyás, pl: 550 után az 568 jön, nem tudom miért, talán töröltek belőle, az új helyén lehet a cikkszámot 1től futtatni?
Köszönettel!
-
modder
aktív tag
Hali,
Most vitatkoztunk egyik ismerősömmel a következőről: Van egy tábla, aminek van egy típus és egy státusz oszlopa, amik eredetileg numerikus típusúak voltak, mondván az nem foglal sok helyet és "gyorsabb". Én pedig mondtam, hogy legyen pl. egy max. 20 hosszú karakter típusú, mert ha nekem az adatbázisban kell kotorásznom, nem fogom fejben visszafejtegetnem, hogy melyik numerikus azonosító mit jelent. A rekordszám nem sok, legyen mondjuk max 10 000, és a rekordok sem nagyon, összesen kb 50 byte pár mezővel.
Én arra gondoltam, hogy tárhelyben alig van különbség a két megoldás között, mivel kevés rekordról van szó. Ha pedig indexeket teszünk a mezőkre, akkor is mindegy, mert nem használunk intervallum keresést, így a hash indexelés a jobb mindkét mezőre, annál pedig megint csak nem számít, hogy egy számot hashelünk vagy egy 20 karaktert.
Ha nem indexelünk, hogy matchelni akarunk az értékekre, akkor sem fog sokat számítani, mert a lemezműveletek jóval többet lassítanak, mint a már egyébként is betöltött rekordokon string matchelés.
Mi a véleményetek?
-
j0k3r!
őstag
hello!
egy sql lekerdezesben kernem a segitsegetek. sqlfiddle itt. azt szeretnem megkapni, hogy az adott napon mennyi az osszfelhasznalo szam.
tehat az eredmenyhalmaz a kovetkezo lenne:
COUNT DAY
1 1
3 2
4 3
6 4remelem ertheto, hogy mit szeretnek
segitsegetek elore is koszonom! -
-
drogery
tag
Sziasztok,
van egy apró pici érdekes problémám. Találkozott már valaki hasonlóval? (sql server 2008+management studio)
Van egy lekérdezésem, ami faszául működik.
Ezt szeretném view-ként elmenteni.
A bejelölt részt egyszerűen átpakolja, amikor a view-t elmentem/elindítom/ a lekérdezést. Így nem jó eredményt ad.
WTF? -
bambano
titán
debian, postgresql
van-e arra mód, hogy egy select eredményéből újabb aggregált eredményt csináljak anélkül, hogy letenném egy ideiglenes táblába?
részletek:
van egy tábla, benne szerződések, és egy ügyfélazonosító. egy ügyfélnek tetszőleges számú szerződése lehet.
azt szeretném tudni, hogy hány ügyfél van, akinek 1,2,3,... darab szerződése van.
addig oké, hogy egy select ugyfelid,count(*) as darab from szerzodes megmondja, hogy egy ügyfélnek hány szerződése van, de erre kellene még egy aggregálás a darab szerint.tia
-
#2053
csabyka666
veterán
fordfairlane
#2052
válasz
fordfairlane
#2052
üzenetére
De, volt téma, pont én hoztam fel, de hiába olvasom a könyveket, én csak konkrét példa alapján tudom értelmezni ezeket.
Köszönöm, ez alapján már el tudok indulni!
Tudom, hogy ilyenekkel nem szép dolog offolni a fórumot, de nálam ez a leghatékonyabb módszer arra, hogy megértsem. Mármint, nem az offolás, hanem ez a konkrét-példás móka.
-
#2052
fordfairlane
veterán
csabyka666
#2049
fordfairlane
veterán
válasz
csabyka666
#2049
üzenetére
Ha az áruház nevéből indulsz, és a termék(ek) nevéhez akarsz elérkezni, akkor szükséged lesz mind a három táblára. Három táblát meg két JOIN-nal tudsz összekapcsolni. (Nem mostanában volt pont ugyanerről téma errefelé?)
SELECT termek.nev
FROM termek
(INNER) JOIN kapcstabla
ON termek.id = kapcstabla.termekid
(INNER) JOIN aruhaz
ON aruhaz.id = kapcstabla.aruhazid
WHERE aruhaz.nev = "nagyesszep";Vagy valami ilyesmi. Ez csak két equi-join, semmi nagy varázslat.
Szerk: Az INNER-t azért tettem zárójelbe, mert opcionális. Vagy SQL kiszolgálófüggő.
-
#2051
csabyka666
veterán
bambano
#2050
-
#2050
bambano
titán
csabyka666
#2047
bambano
titán
válasz
csabyka666
#2047
üzenetére
ahhoz, hogy lásd ennek a célját, érdemes először alaposan elolvasni a Chomsky-féle normálformákat.
-
#2049
csabyka666
veterán
sztanozs
#2048
válasz
sztanozs
#2048
üzenetére
Köszönöm, akkor legalább ezt már értem.
Oké, a kapcsolótáblán keresztül felbontom a több-a-többhöz kapcsolatot. Lekérdezésnél mindenképp JOIN kell, ha például azt akarom megtudni, hogy egy adott áruházban milyen termékeket vásárolhatok meg?
Mert - érzésem szerint - valahogy mindenképp bele kell venni a kapcsolótáblát is a lekérdezésbe, de hogy hogyan, az egyelőre nekem rejtély. -
#2048
sztanozs
veterán
csabyka666
#2047
válasz
csabyka666
#2047
üzenetére
Ebből azt tudom majd megmondani, hogy egy adott termék mely áruházakban van, illetve fordítva, vagyis hogy egy adott áruházban milyen termékek vannak? Tehát ennyi lenne a kapcsolótábla szerepe?
Igen, mivel egy rekord egy mezője csak egy elemet tartalmazhat (logikailag), így a
[tábla 1] n:m [tábla 2]
kapcsolatot fel kell bontanod:
[tábla 1] 1:m [kapcsoló tábla] n:1 [tábla 2]
formára. -
#2047
csabyka666
veterán
Üdv mindenkinek!
Arra kérnélek benneteket, hogy illusztráljátok konkrét példával, vagy csak simán konyhanyelven, hogy a több-a-többhöz kapcsolat esetén mi szükség van a kapcsolótáblára? Az addig rendben van, hogy bele kerül mindkét elsődleges kulcs, de ebben mi a pláne?
Leírom a saját példámat, kérlek véleményezzétek, jól értem-e a dolgot. Az egyik egyed legyen "termék", a másik pedig "áruház". Egy áruházban megtalálható több termék is, és egy termék több áruházban is megtalálható.
Tehát készítek például egy "megtalálható" nevű kapcsolótáblát, ebbe kerül 2 elsődleges kulcs, ami mutatni fog a "termék" és az "áruház" tábla elsődleges kulcsaira. Ebből azt tudom majd megmondani, hogy egy adott termék mely áruházakban van, illetve fordítva, vagyis hogy egy adott áruházban milyen termékek vannak? Tehát ennyi lenne a kapcsolótábla szerepe?A másik, ami még érdekelne, hogy SQL szinten ezeket hogy lehet bepötyögni, hogy megértse az adatbázis-kezelő rendszer? Olvastam REFERENCES kulcsszót is, meg valami CASCADE-t is, de utóbbit nem igazán tudtam értelmezni, hogy mire jó.
Aztán van még jópár problémám, például hogy miként töltöm fel a kapcsolótáblát? Sima INSERT, ahogy egy "átlagos" táblába szúrnék be, vagy van valami speciális kapcsolója?
Az a problémám, hogy a neten fellelhető doksik többnyire angol nyelven vannak, és hiába értem meg magát az angolt, ha ott olyan szavakkal dobálóznak, amit amúgy magyarul sem értek...
Köszi a válaszokat előre is!
-
-
DopeBob
addikt
Sziasztok,
valami leírás, tutorial félét keresnék ,belefuttottam egy (nekem) új témába, és nem nagyon boldogulok vele. Egy táblában faszerkezet, ebben kellene nekem számolni. A legalsó szint darabszámát kéne felszorozni az osszes szülője darabszámával.
Tud esetleg valaki valami jó leírást, ahonnan ezt a részt megérthetném?
-
#2041
drogery
tag
Apollo17hu
#2040
drogery
tag
válasz
Apollo17hu
#2040
üzenetére
Úgy értettem, hogy a left join működik rendesen, a right join pedig inner joinként viselkedik. Sajnos a left join nem a keresett eredményt adja vissza.
Az allekérdezés magában tökéletesen működik. A "bal oldali" lekérdezés is jól működik, csak ha jön a join akkor megy vmi félre.
Hasonló problémára gyanakodtam, mint a linken szereplő, de ha ennek megfelelően írom át, akkor se jó.
-
#2040
Apollo17hu
őstag
drogery
#2039
-
#2039
drogery
tag
Apollo17hu
#2038
drogery
tag
válasz
Apollo17hu
#2038
üzenetére
Az egyébként r.tipus lenne, azért nincs előtte where mert az is kényszerítené az inner joint. A right helyett left joinnal próbálom, akkor az jól működik, de csak akkor ha nincs ott a where.
A jelenlegi formájában ha beszúrom a where-t akkor nincs különbség az eredményben.A groub by pedig muszáj a végére, mert a sub-ból jön eredmény ami befolyásolja a left táblát.
-
drogery
tag
Sziasztok, egy kis segítséget szeretnék kérni. Van az alábbi lekérdezésem. És a kiemelt right join-t vmi inner joinra kényszeríti és nem tudok rájönni mi.
a bal lekérdezés kb 70k rekordot dob, a jobb oldali kb 4k-t. A végeredményemben 4k körül kéne lennie, de csak 1,5k lesz. Sejtésem szerint az aláhúzott részt szól bele, de nem tudom mi kéne kezdeni vele.
Ha esetleg vkinek beugrik erre vmi azt megköszönném.DECLARE @date date
set @date='2013.06.30'
SELECT r.[pkod]
,r.[fhely]
,cast (sum(r.[me]) as int) as me
FROM [crm_szamla] as r
[B] right join[/B]
(SELECT c.kod
,c.pkod
,c.szlakor
,a.[gyszam]
,[beszerel]
,[leszerel]
,b.utolsó_leolv
,b.utolsó_allas
FROM [crm_meroora] as a
inner join
(SELECT id_fhely
,[gyszam]
,max(kelte)as utolsó_leolv
,max(allas) as utolsó_allas
FROM [crm_leolv] where kelte<=@date
group by id_fhely, gyszam having max(kelte)<@date) as b
on a.id_fhely=b.id_fhely and a.gyszam=b.gyszam and utolsó_leolv<@date and beszerel<@date and (leszerel>@date or leszerel is null)
left join
crm_fhely as c on a.id_fhely=c.id and left(kod,3)<>312 and left(kod,3)<>317 and c.megszunt is null ) as c
on r.fhely=c.kod and r.pkod=c.pkod and tipus='VF' [U]and idoszak_i<=@date and r.idoszak_t>=c.utolsó_leolv [/U]
group by r.fhely, r.pkod
order by fhely -
#2036
csabyka666
veterán
Apollo17hu
#2035
válasz
Apollo17hu
#2035
üzenetére
Igen, lényegében a szabály alapján is így kell eljárnom, ha egy-a-többhöz kapcsolat lesz. De még lerajzolom párszor, meg átgondolom, aztán majd jelentkezem, hogy mire jutottam.
-
#2035
Apollo17hu
őstag
csabyka666
#2034
Apollo17hu
őstag
válasz
csabyka666
#2034
üzenetére
Nagyvonalakban ezek az infóid vannak:
felhasználó | felhasználói infók (több mező) | termék | termékinfók (több mező)
Azt írod, hogy nincs két ugyanolyan termék (-> különböző vonalkódok). Ha így van, akkor szerintem felesleges a kapcsolótábla. Az egész mehetne egy táblába. Annyit lehetne normalizálni rajta, hogy a felhasználóknak külön táblát hozol létre, amibe minden felhasználói infót letárolsz, a másik táblában pedig elég csak felhasználóazonosítót használnod.
-
#2034
csabyka666
veterán
Apollo17hu
#2033
válasz
Apollo17hu
#2033
üzenetére
Húh, lehet, hogy nem értjük egymást, bár szerintem én is körülményesen magyaráztam.
Amit mondasz, az lehet, sőt biztos, hogy működne, de az a probléma, hogy esetemben kezdésnek 0 felhasználó és 0 termék van, szóval nem kivitelezhető, hogy előre felvigyem őket.
Gondolkoztam, és lehet, hogy így nem is logikus, mert mi a fenéért vinné fel több felhasználó is ugyanazt a terméket?! Tehát annyiban módosítani kell majd az ábrát, hogy egy felhasználó több terméket is felvihet, viszont egy adott terméket csak egy felhasználó vihet fel. De ebben az esetben az időpont sem kell, mert teljesen mindegy, mikor vitte fel, nincs jelentősége...
Szóval akkor egy-a-többhöz lesz, és innen már más a helyzet. Na, ezt még át kell gondolnom...
-
#2033
Apollo17hu
őstag
csabyka666
#2032
Apollo17hu
őstag
válasz
csabyka666
#2032
üzenetére
Én úgy csinálnám, hogy a meglévő adatok alapján felvinném az összes felhasználót a felhasználó táblába, az összes terméket pedig a termék táblába (mindenkit és mindegyiket csak egyszer).
Nem tudom, hogy hívják magát a "feltöltést", de hasonló esetben én a tranzakció kifejezéssel találkoztam. Tehát van egy halom tranzakciód, ami tartalmazza, hogy ki, mit és mikor töltött fel. Ezeket kell a kapcsolótáblába felvinni. (felhasználó egyedi azonosítója + termék egyedi azonosítója + feltöltés dátuma)
Innentől kezdve csak a kapcsolótáblát töltöd. Akkor kell a másik kettőhöz hozzányúlnod, ha új felhasználó vagy új termék jelenik meg egy tranzakcióban. (Ez esetben a felhasználó- és/vagy a terméktáblát kell előbb kiegészíteni.)
-
#2032
csabyka666
veterán
Üdv mindenkinek!
Feltettem már a kérdésemet több topicban is, aztán martonx fórumtárs javaslatára idetévedtem, és megkérdezlek benneteket is a dologról.
Adott a következő részlet egy EK diagramból, ezt szeretném átírni relációs adatbázisba:
Elméleti szinten megy a dolog, viszont az SQL-lel bajban vagyok. Ami "biztos", hogy 3 táblám lesz. A felhasználó és a termék marad ugyanúgy, de kell készítenem egy kapcsolótáblát, legyen mondjuk feltöltötte, ami megkapja a felhasználó és a termék tábla elsődleges kulcsát, és ez a kettő együtt lesz az idegen kulcsa, valamint megkapja a kapcsolat tulajdonságát is.
Innentől van a gond, mert nem tudom, hogy miként tudom helyesen feltölteni az adatbázist...
Például olyan lekérdezésekre szeretnék választ kapni, hogy Józsi milyen termékeket töltött fel?, vagy hogy a Danone joghurtot ki töltötte fel?.
A kapcsolótábla teljesen megzavar, ezt hogy kell létrehozni SQL-ben, és aztán feltölteni bele?
-
Kommy
veterán
válasz
bambano
#2028
üzenetére
Hát igen ez lett úgy néz ki a megoldás, de akkor is zavar, hogy miért nem megy join-al
(#2029) fordfairlane: nem ír semmi hibát, amúgy ez egy visual studio-ban íródó program ami Microsoft Access adatbázisból dolgozik.
(#2031) martonx: Amúgy igen eltér egymástól mivel ebben már van egy csomó rekord (több 100), én örülnék a legjobban ha tiszta lenne és nem kénének a régi adatok.
De most simán bambano ajánlása szerint működik
Megpróbálom azért úgy is. -
bambano
titán
-
Kommy
veterán
Elég fura egy szerzet sqlfiddle-n működik: [link]
Szétszedve a lekérdezést működik:
"SELECT * FROM AddressBook a
INNER JOIN Rating r ON r.RacerID = a.ID
WHERE r.EventID = " + eventID + " ""SELECT * FROM Rating r
INNER JOIN Classes c ON r.ClassID = c.ID
WHERE r.EventID = " + eventID + " "Összerakva nem:
"SELECT * FROM AddressBook a
INNER JOIN Rating r ON r.RacerID = a.ID
INNER JOIN Classes c ON r.ClassID = c.ID
WHERE r.EventID = " + eventID + " " -
#2022
Kommy
veterán
fordfairlane
#2021
Kommy
veterán
válasz
fordfairlane
#2021
üzenetére
Én is így gondoltam, mert itt lekérdezésem
SELECT * FROM AddressBook a
INNER JOIN Rating r ON r.RacerID = a.ID
INNER JOIN Classes c ON r.ClassID = c.IDUgyan ezt írom le mégsem ad eredményt
-
#2021
fordfairlane
veterán
Kommy
#2020
fordfairlane
veterán
de ha ehhez a lekérdezéshez hozzáadok még egy join-t akkor már nem lesz eredménye a lekérdezésnek. (pedig van olyan id-jű versenyző)
Pedig sok variáció ezzel nincs, mivel egyértelmű, kit mivel kell összekapcsolni. Versenyzőket a nevezésekkel, azt meg a kategóriákkal, a megfelelő kulcsmezők mentén. Dupla Equi-Join. Versenyzo INNER JOIN Nevezett ON Versenyzo.id = Nevezett.versenyzoid INNER JOIN Kategoriak ON Nevezett.kategoriaid = Kategoriak.id
-
Kommy
veterán
válasz
martonx
#2019
üzenetére
Az oké, csak valahogy nem akarja úgy kiadni biztos valamit én rontok el.
Tehát ha összekapcsolom a nevezetteket a kategóriával akkor szépen ki tudom íratni a kategórianevét és látom a versenyző id-ját is, de ha ehhez a lekérdezéshez hozzáadok még egy join-t akkor már nem lesz eredménye a lekérdezésnek. (pedig van olyan id-jű versenyző)
-
Kommy
veterán
Sziasztok!
Van 3 táblám a következők
Versenyző: id, név, szám
Kategóriák: id, kategóri megnevezés
Nevezett: versenyzoid, kategóriidMiképpen tudnám én a nevezettek nevét és kategóriáját megkapni egyetlen lekérdezésben.
Két lekérdezéssel sikerült megoldanom, de egyel kéne megcsinálnom. Inner join-al kapcsoltam össze a két táblát és a z eredmény kielégítő volt, csak nem tudom a 3. táblát hogyan lehetne hozzákapcsolni, hogy akkor is adjon eredményt.
-
#2016
martonx
veterán
TaylorXIII
#2014
martonx
veterán
válasz
TaylorXIII
#2014
üzenetére
Segítek: Sqlfiddle
Rajta! -
#2015
Ispy
nagyúr
TaylorXIII
#2014
Ispy
nagyúr
válasz
TaylorXIII
#2014
üzenetére
Megírni senki nem fogja helyetted, kezd el, ha elakadsz és kérdésed van, akkor azt tedd fel.
-
#2013
bpx
őstag
dellfanboy
#2012
bpx
őstag
válasz
dellfanboy
#2012
üzenetére
create database link B connect to user identified by pw using 'A';
select * from tabla@B; -
#2012
dellfanboy
őstag
dellfanboy
őstag
hello
szükségem lenne egy kis sql adatbázis link segítsége
belépek A adatbázisba ésle szeretnék futtatni egy tök egyszerű selectet ami B-re hivatkozik. tudnátok segíteni hogy kell ezt pontosan leírniselect * from tábla
create database link B connect to user identified by pw
using 'A' -
#2010
sztanozs
veterán
TaylorXIII
#2009
válasz
TaylorXIII
#2009
üzenetére
Wow, ti is új okospénztárgépet fejlesztetek?
-
-
#2007
PazsitZ
addikt
fordfairlane
#2004
PazsitZ
addikt
válasz
fordfairlane
#2004
üzenetére
Azon túl, hogy megzavrjam az isteni movoltovadat megkérdezhetem a miértedet is?
Én már csak ilyen kíváncsi fajta vagyok. -
#2006
Apollo17hu
őstag
Tv
#1998
Apollo17hu
őstag
Nekem egyetemen a 2.-at (JOIN-ok) oktatták, munkahelyen az 1.-t használjuk. Szerintem aki teljesen kezdő SQL-ben, annak könnyebben rááll az agya az 1. verzióra, mert ott az egyenlőségjelen kívül (+) jelöli a gyenge kötést, míg a 2. verzióban LEFT, RIGHT, OUTER stb. kulcsszavak is használandóak. Az 1. verzió egyetlen hátránya, hogy a FULL OUTER JOIN-t nem lehet szépen megvalósítani (UNION kell hozzá). Ebben az egy esetben használom én is inkább a JOIN-t.
Ja, és fórumtársak írták, hogy nekik a JOIN sokkal átláthatóbb, mert egyből látszik, hogy mi hova kapcsolódik. Ez igaz, de ha tucatnyi tábla van összekapcsolva, akkor talán jobb, ha előbb látszik, hogy egyáltalán milyen táblákat használ a lekérdezés (1. verzióban FROM után a legtöbb tábla felsorolásra kerül). Ha az ember az ideje 90%-ában ugyanazokkal a táblákkal dolgozik, akkor úgyis fejből tudja a kapcsolatokat.
Amúgy kb. mindenki azt írta, hogy "persze, nem eretnekség, csak nem úgy szoktuk". Formálisan helyes, teljesítményben alig van/nincs különbség. Akkor pedig nem kókányolás, akármennyire is ezt akarjátok sulykolni. (persze nem mindenki)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ezért kértem itt segítséget
Új hozzászólás Aktív témák
- Mini PC
- Fotók, videók mobillal
- HiFi műszaki szemmel - sztereó hangrendszerek
- E-roller topik
- Hammer Watch 2 - na szia, engem kövessél ezennel, bitte!
- Milyen okostelefont vegyek?
- World of Tanks - MMO
- Xbox Series X|S
- Kerékpárosok, bringások ide!
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- További aktív témák...
- LG 27GP850P-B - 27" NANO IPS - 2560x1440 - 180Hz 1ms - NVIDIA G-Sync - AMD FreeSync - HDR 400
- Azonnali készpénzes AMD Radeon RX 7000 sorozat videokártya felvásárlás személyesen/csomagküldéssel
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Acer TravelMate P214 i3-1115G4 16GB 512GB 14" FHD 1év garancia
- 24 hónapos PlayStation Plus Premium előfizetés a legolcsóbban, egyenesen a PlayStation-től!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest