Hogyan lehet megoldani?

[zagabumm]

Sziasztok!

 

Teljesen kezdő vagyok SQL téren és most belefutottam egy olyan problémába ami eddig tranzakciós adatbázisoknál nem volt probléma:

 

Adott egy tábla, amiben van 10 mező. A 10 mezőből az első 5 adja az egyedi kulcsot. A többi mező az információkat ezekről az elemekről.

 

Azt szeretném, hogy az első 5 mező szerint csoportosítva (group by) ÉS ezen belül a 6. mező szerint a legutolsó (MAX 6. mező) ki tudjam írni a 7. mező tartalmát IS.

 

Az eleje ez lenne:

 

SELECT a, b, c, d, e, MAX(f) AS max_f

FROM tabla X

GROUP BY a, b, c, d, e

 

Namármost, ha a select-be berakom "g"-t is, akkor hiba üzi jön, hogy nenenananananunu...

 

Segítsen valaki!

 

Köszi: Zaga

[arpsoft]

Ennek mennie kéne:

select a,b,c,d,e,max(f) as max_f,g from tabla group by a,b,c,d,e

 

Egyébként nem igazán értem a problémát. Miért kell a max(f), amikor az első 5 mező elsődleges kulcs, azaz egyedi. A group by miatt max nélkül is ugyan az az eredmény születne, mivel minden sor egyedi lesz a kulcs miatt.

[zagabumm]

Bah, elírtam:(

A 6. mező is része az egyedi kulcsnak és az első 5 mezővel kell a group by.

Ez egy számla történet valójában, ha ez segít megérteni a problémát.

 

De már lehet, hogy megvan a megoldás: a g-re is ki kell adni a max-ot és a végrehajtási sorrend miatt ott már csak 1 rekord van.

[Pjotr]

Hegesztenem kellene egy olyan adatbázist, amiben CUCCOK vannak. Egy CUCCnak van ~50-féle attribútuma.

 

Olyan rendszerben kellene mûködnie a dolognak, hogy tudjak új CUCCOKat felvenni, emellett attribútumbõvítés is kellene. Az egész leginkább webshophoz hasonlít, de még olyat sem kellett csinálnom.

 

A legtöbb séma, amit találtam, kimerül annyiban, hogy vannak megrendelõk, termékek, aztán ezeket összedrótozza rendelés táblával meg ilyenek, de nekem ez pont nem kell.

 

Arra kellene megoldás, ötlet, amivel egyszerûen, gyorsan lehet menedzselni ezt a rengeteg attribútumot. Persze ugyanebbõl a rendszerbõl kellene összerakni majd a keresõ, adatfelvivõ form-ot is.

 

Köszi!

[payskin]

3 tábla: CUCCOK, ATTRIBÚTUMOK, CUCCOK_TO_ATTRIBÚTUMOK (vagy fordítva, ha úgy logikusabb).

 

Például webáruházban:

 

PRODUCTS (products_id, ..... n+1 másik mező),

CATEGORIES (categories_id, .... n-3 másik mező),

PRODUCTS_TO_CATEGORIES (products_id, categories_id)

 

Tagelést pont ugyanígy szokták megcsinálni.

[Pjotr]

Totál máshogy (kreténül) gondolkodtam.

 

Az ATTRIBÚTUMOK táblába csak az kerülne, hogy milyenek vannak, az értékük nem? Mert most úgy nézem, hogy a kapcsolatot biztosító táblába kerülhetnének az adott CUCChoz tartozó értékek.

És akkor lehetne olyat hegesztenem, hogy az elõzõ értékek közül ki lehetne választani felvételkor, hogy pl. hány ujja van a kesztyûnek meg hasonlók. Talán menni fog.

 

[payskin]

Értem, hogy mire gondolsz. Az attribútum értékeket is a CUCC_TO_ATTR táblába tenném 3. oszlopnak, így megvolna az a megfeleltetés, hogy melyik CUCC-hoz milyen attr tartozik és annak épp mi az értéke.

[KGigi]

Kicsit hosszú olvasmány, de ajánlom a Panem kiadónál megjelent Adatbázisrendszerek, alapvetés című könyvet, abból is a sématervezést, ha gyakran kell ilyet csinálnod. Ez a Stanford tankönyve, de pl. mi is ebből tanultunk. Egyébként Balázs megoldása teljesen jó. Egy tábla a cuccoknak, egy az attribútumoknak, egy pedig az összekapcsolásnak és a multiplicitásnak, darabszámnak, értéknek, tehát ami egyik másik táblába sem tartozik, hanem a kapcsolathoz.

[Pjotr]

 

Már tudok attribútumot felvenni (törölni is, ekkor minden CUCC-nak törlõdnek az ilyen tulajdonságai), megy a CUCCfelvétel, CUCCmódosítás.

 

Még a keresés van hátra, mint fõ mûvelet, utána már csak össze kell lapátolni a programokat valami értelmes formában, meg szépíteni kell a kódot.

[nagyjani]

Szerintem egyszerű, de nem tudom kilogikázni.

Van 2 tábla, az egyikben fényképek, a másikban a hozzászólások. Az első tárolja a fotók adatait, a második kapcsolódik hozzá ("fotoId" mindkettőben benne van), plusz a hozzászólásban még a "userId" is.

Egy képhez több usertől is érkezhet hozzásólás, és van olyan is hogy még NULL az érték.

Azokat a képeket kilistázni ahova a bejelentkezett user írt, nem gond (where tabla2 userid = @userid) egy kontrolleren keresztül kilistázni.

Viszont ha az kellene ahova még nem szólt hozzá, akkor az kapásból az ellenkezője (where tabla2 userid <> @userid)

Ez viszont kilistázza azt is ahová a bejelentkezett user hozzászólt. Logikus mondjuk, hiszen azt kértem tőle, hogy azokat adja ahol nem egyenlő a userrel, és hát a más hozzászólása nem is egyenlő.

Hogyan lehetne kizárni, ezt, vagy simán megoldani, hogy csak azokat a képeket listázza ahol az adott user még egyáltalán nem szerepel a 2-es táblában?

Kösz!

[Fujitsu]

Ebből, amit leírtál, nem látom át a problémát, de ha jók a sejtéseim, a NOT IN záradék lehet a te barátod. Lekérdezed, hová írt a bejelentkezett felhasználó (ha jól értem, ez megy), aztán lekérdezed azokat a képeket, amelyek nem szerepelnek ebben a felsorolásban, ezt pl. a

 

SELECT valami FROM valami WHERE fotoid NOT IN (SELECT akarmi FROM akarmi WHERE tabla2 userid = @userid) 

 

segítségével tudod megtenni. (A szintaktika nem érdekes, nem tudom, hogy néz ki nálad a történet, de a lényeg látszik.)

[nagyjani]

Hello!

A not in-re én is gondoltam. Holnap lepróbálom, aztán jelzek vissza.

üdv.

[nagyjani]

Kösz, ez le a nyerő. Vagy 2 órát variáltam vele mire elfogadta és működik is, lett egy jópár sor...