Új hozzászólás Aktív témák
-
martonx
veterán
Pedig ez nálam simán működik (MSSQL 2008R2 Express):
create table #t (ertek1 int, ertek2 int)
insert into #t values (1,1)
insert into #t values (3,1)
insert into #t values (1,3)
insert into #t values (2,4)select SUM(ertek1 + ertek2) from #t
Inkább olyanra tudok gondolni, hogy szemetesek az adataid (mondjuk null van köztük), és ez okozza a problémát.
Én kérek elnézést!
-
bpx
őstag
kezdjük azzal, hogy mit szeretnél lekérdezni
folytassuk azzal, hogy a SUM az oszlopfüggvény, tehát nem tudsz olyat mondani, hogyselect oszlop1, sum(oszlop2) from tabla1
mert a select oszlop1 több 'sort' ad vissza, a sum(oszlop2) viszont 1 darab értéket, és ez a kettő nem fér össze
a hibaüzenet mondja is a megoldást, ilyen esetben group by-olni kell
-
martonx
veterán
Lehet picivel több gyakorlatom van MSSQL-ben, mint a tanárodnak. Másrészt oktatási szempontból a beágyazott select jobb, mert átláthatóbb, párszáz adatsornál a rosszabb futásidők nem is jönnek ki igazán. Viszont több tízmillió soros táblákat próbálj meg alselectekkel lekérdezni
Én kérek elnézést!
-
Sk8erPeter
nagyúr
Nem benned van a hiba, örülj neki, hogy normális lekérdezéseket jobban átlátsz.
Amúgy az is kérdés, milyen "alselectekre" gondolsz: van, amikor igazából nem is nagyon lehet másképp megoldani egy ilyet, vagy nehézkes, és most ne kérd, hogy azonnal mondjak neked ilyen példát, mert nem jut eszembe. Gyakorlatban jönne elő.Más: úgy tudom, MySQL-t használsz, ebben az esetben ezt ajánlom az egyszerűbbek közt viszonylag összetettebb (na, szóval érted ) lekérdezések elkészítésére: dbForge Studio for MySQL. Szerintem nagyon hasznos tud lenni, amikor az embernek hirtelen a fáradtságtól vagy a pillanatnyi elmezavartól a neve sem jut eszébe, nem hogy egy picit is összetettebb query. Van ilyen, ilyenkor jól jön egy grafikus alapú query-összedobálós program, ami meglepő módon egyáltalán nem gyárt gány kódot. Most ez persze elsősorban a JOIN-okra vonatkozik, nem arra, amikor mondjuk durvább query-d van, meg temporary táblák sora van több "alselectben", stb., tehát azért még mindig a viszonylag egyszerű query-k összerakására kell gondolni.
Sk8erPeter
-
PazsitZ
addikt
Szerintem teljesen intuitív dolog felismerni a NxM-es táblák kezelését.
Pedig a normalizáláshoz is kapcsolódik; ennek hiányában masszív adatduplikációval oldható fel bizonyos kapcsolatábrázolás probléma.
google gyorskeresés 1 eredménye: [link][ Szerkesztve ]
- http://pazsitz.hu -
-
martonx
veterán
Én valahogy idegenkedek a NoSQL-től. Jóllehet bizonyos esetekben kiválthatnak hagyományos funkciókat pl. cookie-kat, session-öket, illetve ezek közötti kommunikációt könnyű NoSQL-lel, szépen adminisztrálható, áttekinthető módon megoldani.
Jól jöhetnek akkor is, ha abszolút változó oszlopszámú rekordokat kell tárolni.
Illetve előnyük még, hogy a szöveg alapú keresésben hatékonyabbak (ez azért relatív), mint a hagyományos relációs adatbázisok.
Hátrányuk, hogy egy szépen felépített adatbázissal, ahol minden mindennel relációban van, egyszerűen nem vehetik fel a versenyt.
És itt jegyezném meg, hogy az ilyen "vannak oszlopok is, értékek, amelyek mindig tetszőleges számúak! Az egyik diagramnak 4 oszlopa van, míg a másiknak 8 oszlopa van." esetek meglátásom szerint túlnyomórészt adatbázis, program rendszer tervezési hibák miatt születő megoldások, ahol a tervezés butaságait a NoSQL sem fogja megoldani, maximum elfedi, sőt a kötetlensége miatt akár fel is erősítheti ezt a jelenséget.
A kétféle SQL használata abszolút nem zárja ki egymást, párhuzamosan is lehet használni őket.
Én kérek elnézést!
-
kispx
addikt
Express Edition-t lehet localhostra telepíteni.
-
modder
aktív tag
Ja, nem jó.
A user_hirdetés kapcsolótáblában inkább user_id és hirdetes_id-nak kellene szerepelnie.
De teljesen fölösleges is a kapcsolótábla, mivel ez egy one-to-many kapcsolat a user felől a hirdetések felé: egy user több hirdetés. így elég csak user_id-t tárolni a hirdetés táblában, mit te hirdető_id-nak nevezel. Kapcsolótáblát csak a many-to-many relációknál használnak.
... Esetleg akkor, ha a kapcsolatnak külön tulajdonságot rendelsz, ami a kapcsolatra vonatkozik. akkor viszont érdemes egy unique constraint-et tenni a kapcsolótábla hirdetés_id mezőjére, hogy elkerüld, hogy egy hirdetést véletlenül több felhasználóhoz kapcsolj
Hirdető táblában nem kell a hirdetés_id. akkor minden hirdetőhöz csak egy hirdetés tartozhatna. a hirdető<-->hirdetést megadja a hirdetés tábla hirdető_id-ja.
teljesítményben annyit tudsz javítani, hogy indexeld a keresésben használt mezőket, vagy ha egyszerre több mezőt is használsz egy-egy fajta keresésben, akkor indexet megadhatsz több mezőre is.
Ha pedig többmillió rekordod lesz meg brutál forgalom meg istentudja, akkor táblaparticionálás. ez a két legfontosabb dolog teljesítményben[ Szerkesztve ]
-
Sk8erPeter
nagyúr
modder sok mindent leírt előttem, ami a megvalósítást illeti, tehát azzal a résszel egyetértek. Viszont én még annyit tennék hozzá, hogy bennem a hsz.-ed láttán egyből az a kérdés merült fel, hogy vajon miért feltételezed, hogy a hirdető egy külön állatfaj. A hirdető is egy regisztrált felhasználó, tehát egy user, akinek a helye a user táblában van. Tehát teljesen felesleges a "hirdető neve, hirdető kora, hirdető egyéb adatai", stb. adatokat külön táblában tartani. Ez a felhasználóhoz tartozó adat (user tábla, vagy esetleg egyéb adatok miatt ehhez kapcsolt tábla, de ez opcionális). Az már másik kérdés, hogy ez a felhasználó egyáltalán hirdethet-e, ad-e fel hirdetést, és ha igen, az adott hirdetésekhez milyen adatok tartoznak.
Itt most a hirdetés hozzákapcsolása szempontjából tehát mellékes, hogy szerepkör alapján hirdethet-e csupán a felhasználó, vagy bármilyen bejelentkezett felhasználó feladhat hirdetést. Nyilván egy expressz.hu-hoz hasonló oldalon az a fő profil, hogy bárki feladhasson hirdetést (mondjuk adott összeg befizetése után), tehát ott nem kell külön hirdető szerepkör (hacsak nem a fizetés után kapja meg a felhasználó a "hirdető" szerepkört, ami akár le is járhat, de még ezt a kérdéskört is lehetne boncolgatni).Lényeg tehát: a hirdető is egy felhasználó. A hirdetés pedig külön adat, ami - ahogy előttem elmondták - egyértelműen egy felhasználóhoz tartozik (elég ritka az az eset, hogy több embert akarsz megjelölni hirdetés feladójaként...), tehát itt nem kell külön kapcsolótábla a hirdetés-user kapcsolathoz.
Sk8erPeter
-
Sk8erPeter
nagyúr
Akkor ezt folytatva: mindenki érti már szerintem, mit szeretnél, úgyhogy még egy ilyen csodás példa nem kell a magyarázat tisztázásához . Előbb linkelt cucc utsó hsz.-ében leírtam, hogy OK, minden hirdető júzer, de nem minden júzer hirdető.
Tehát akkor rövidre zárva a dolgot: nem kell az a kapcsolótábla. A hirdető egyéb adataiba egyszerűen bepakolod a user id-t.Persze lehet ezt tovább bonyolítani, ha még tovább lenne bontva, hogy bizonyos hirdetőknek extra paramétereik lehetnek, és akkor megint előkerül a probléma, hogy NULL értékűek bizonyos paraméterek azoknál a hirdetőknél, amelyeknél nincsenek meg azok az extra paraméterek.
Akkor már egy táblába kéne pakolni a user id-t, paraméter id-t, paraméterhez tartozó egyik lehetséges value id-t, és így tovább... de gondolom nálad egyezne az összes hirdető plusz adata.[ Szerkesztve ]
Sk8erPeter
-
martonx
veterán
Szerintem erre nincsen igazán jó szakirodalom. Esetfüggő, hogy mikor mennyire érdemes normálformára hozni, milyen táblastruktúrát érdemes létrehozni, mennyire kell teletömni indexekkel egy-egy táblát stb...
Egy-két SQL optimalizálás problematika elég szokott lenni, hogy felnyissa az ember szemét a DB tervezés alapjaira.
Nagyon általánosságban beszélve: 1. - 2. normálforma elég szokott lenni. Láttam olyan DB-t, ahol még az Igen/Nem is normalizálva volt külön paraméter táblába. Nos, ez már a ló túlsó oldalára átesés.
Ugyanez a helyzet az indexelésekkel. Egy bizonyos szintig nagyon jó, hogy van mindenféle joinokban használt index-ed. Aztán mikor már mindenen index figyel és szegény db motor egy-egy insertnél nem győzi az indextáblákat frissíteni, akkor ez már kontraproduktív.
Nagyon nincs, és nem is lehet általános érvényű tanácsot adni SQL adatbázis tervezéshez.Én kérek elnézést!
-
-
Sk8erPeter
nagyúr
"-labels ( ez egy olyan varchar lenne, ahol a label_id-k vanak tárolva, például ilyen formátumban: |1|34|45|54| ) - magyarul, minden egyes label_id | | között lenne."
Ha hatékony megoldást keresel, egyből le kéne, hogy essen, hogy ez aztán garantáltan nem lesz az.
Amúgy sem értem, minek kéne ilyen pipe-pal elválasztva tárolnod, amikor létrehozol neki egy külön táblát... A product id-val kéne összekapcsolnod, aztán kész.
Csak gondolj bele, hogy hogyan tudnál ezek között hatékonyan keresni, ha stringben egybe van b@szva... hatékonyan sehogy.Sk8erPeter
-
martonx
veterán
Ha kocka vagy a szó jó értelmében, akkor mindenhez PostgreSQL-t érdemes használni (már persze MySQL összehasonlításban, én egyébként MS SQL-re szavaznék a jelenlegi SQL felhozatalban).
Ha nem akarsz belemélyedni, csak annyit akarsz, hogy menjen, és az alapfunkciókat használod, akkor a MySQL elsőre szvsz jobban kézre áll.Én kérek elnézést!
-
lakisoft
veterán
VPS-re nem érdemes Oracle-t rakni, mert nem lesz valami sebes és elég drága lesz a VPS config ára hogy menjen egyáltalán az OracleDB. Lásd itt már kitárgyaltuk a témát.
-
bpx
őstag
"Kliensekre volt felrakva, a db szerver..."
jó, az iskolai (egyetemi) géppark nem a sebességéről híres
"Csak az a gondom, hogy én szeretnék VPS-t bérelni, amin futna olyan 4-6 oldal lenne rajta, 1 mongodb és egy rdbms is.
1GB ram, 2magos cpu, 50GB-ra menne, és nem tudom mennyire bírná a szerver. Esetleg ilyen tapasztalatod van ezügyben?"ezügyben sajnos nincs
1 GB memória elég kevés, de ha ezek valami minimál oldalak, akkor elképzelhetőnek tartom, hogy elég lehet
kérdés, hogy erre tényleg kell-e neked Oracle, vagy elég valami pehelysúlyú rdbmslakisoft: én nem emlékszem rá hogy ez így ki lett volna tárgyalva
-
lakisoft
veterán
Ez az átvinni dolgot migrálásnak hívják és elég kemény tud lenni ha adatbázis specifikusra van megírva a szerkezet is. MySQL -> Oracle migráción dolgozom éppen és elég kemény dolgok adódnak néha. .
Az adatbázis szerkezetétől, komplexitásától függ.
Tárolt eljárások lesznek? vagy egyéb logika lesz beépítve?
[ Szerkesztve ]
-
Sk8erPeter
nagyúr
"suli-ban" sulitiltás?
A tárolt eljárás pedig sokszor jó kis segítség tud lenni, például ASP.NET-ben. Amúgy a tárolt eljárás arra is jó, hogy nem kell a query-vel elrondítanod az alkalmazásod kódját, hanem az adatbázisban tartod azt, aminek épp ott a helye, vagy amit úgy érzel, nyugodtan rábízhatsz az adatbázisra, és azt terheled a feladat megoldásával, stb. Meg így adhatsz neki egy jó beszédes nevet, aztán meghívhatod az alkalmazásod kódjából a megfelelő paraméterek átadásával. Csomó mindent el lehet intézni benne, ami csúnya lenne alkalmazásból, vagy épp nem akarsz ORM-et igénybe venni rá, satöbbi.Sk8erPeter
-
martonx
veterán
na, ezt felejtsd el nagyon gyorsan. A NoSQL-ek jellemzően memóriában futnak, minél inkább ott tartják az adatbázisukat. Ezért is szokták javasolni, hogy NoSQL-t 64 bites oprendszerekre tegyünk, hogy bőven legyen alattuk memória. 1Gb memóriában fusson egy oprendszer, meg egy NoSQL és még erre akarsz rakni SQL szervert, meg web kiszolgálót is???
Ráadásul ha jól vettem ki a szavaidból a webkiszolgálást Java alapokon tervezed, ami alá a webszerverek nem éppen a karcsú memória igényeikről híresek. Ez így nagy bukta lesz.Én kérek elnézést!
-
martonx
veterán
"itt anti tárolt eljárás szellemiség van" - szóval gányoltok, vagy annyira kicsiben játszotok.
Mondok egy gyors példát, hogy mikor jó a tárolt eljárás és egyáltalán nem csak ASP.NET-nél
Egy táblába be kell szúrnod egy adatot, más táblák adainak függvényében.
Ezt megoldhatod úgy, hogy fogod, lekéred az adatokat 3-4 táblából a webszerverre, majd kódban megvizsgálgatod őket, ezek alapján összeraksz egy insert-et, és beszúrod az adatokat. Ez így mondjuk 4-5 DB-hez nyúlást jelent, mindig felépíted/feléleszted a kapcsolatot, az adatok jönnek mennek feleslegesen, kezeled a kivételeket stb...Ehelyett írhatsz egy tárolt eljárást, amivel SQL DB-n belül tudod megoldani ugyanezt. Egy adatbázis hívással, nulla felesleges adatmozgással.
Én kérek elnézést!
-
martonx
veterán
No, de mind a NoSQL, mind a hagyományos SQL-ek, annyi cuccot tartanak memóriában, amennyit csak tudnak, vagy amennyit kell.
Tehát ha most a teszt db-idben mind a 10 táblában van 10-10 sor adat, így persze, hogy egyik sql sem foglal sok memóriát. Csakhogy ez éppen semmit nem jelent, mert ha mind a 10 táblában lesz táblánként 200.000 adat, és ezeket másodpercenként 10-szer lekéri a webszerver, akkor mindjárt más lesz a leányzó fekvése.
Plusz a webszerver terhelése is gondolom nulla. Majd ha párhuzamosan 10-20 kérést fog kiszolgálni, és mindegyikre indít 1-1 VM-et, a maga 30-40 Mbyte-jával, akkor fogsz te nagyot nézni, és azt mondani, hogy pedig még a laptop-omon is milyen pöpecül futott minden, míg egymagam fejlesztgettem.
Nem véletlen, hogy kereskedelmi java hosting szinte sehol sincs (bár ennek szvsz másik oka a milliónyi java-s nyelvjárás is), ellentétben a PHP-s, ASP.NET-es hosting cégekkel, amikkel Dunát lehetne rekeszteni.Én kérek elnézést!