Hirdetés
Új hozzászólás Aktív témák
-
csabyka666
addikt
válasz bambano #2050 üzenetére
Beírtam a Google-ba, és beleolvastam. Szégyen ide, szégyen oda, én ezt így nem fogom megérteni. Az ilyen elméletektől mindig a falat kapartam.
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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ő.
[ Szerkesztve ]
x gon' give it to ya
-
csabyka666
addikt
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.
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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?[ Szerkesztve ]
-
drogery
tag
-
Ispy
veterán
válasz drogery #2061 üzenetére
Jobb klikk a view-n, Script View as, ALTER TO, New Query Editor Window.
És itt szerkeszted formázod, Execute-tal mented és soha többé nem nyitod meg dizájnerrel, mert szétkeféli az egészet.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
j0k3r!
senior tag
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!
some men just wanna watch the world burn...
-
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?
-
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!
Ajándék szesznek ne nézd a fokát!
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.
[ Szerkesztve ]
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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/
[ Szerkesztve ]
-
Ispy
veterán
Semmiképp sem tárolnék fix értékeket szövegként, vagy csinálnék egy Aktiv mezőt, ami bit, vagy egy Statusz mezőt, ami kódot tartalmaz, amihez egy másik táblában van letárolva a kódok tartalma.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
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?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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?
[ Szerkesztve ]
- http://pazsitz.hu -
-
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.
[ Szerkesztve ]
-
Ispy
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?
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).
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
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).
-
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.
x gon' give it to ya
-
Ispy
veterán
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).
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.
Én kérek elnézést!
-
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.Sk8erPeter
-
Ispy
veterán
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.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
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ó
[ Szerkesztve ]
- http://pazsitz.hu -
-
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
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.
Én kérek elnézést!
-
Ispy
veterán
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.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
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. -
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.
[ Szerkesztve ]
x gon' give it to ya
-
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?
Én kérek elnézést!
-
-
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.
-
Ispy
veterán
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!
"Debugging is like being the detective in a crime movie where you're also the murderer."
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen