Jag har funderat på det här ett tag och vill bara ha nån att fundera ihop med :)

Om jag ska hämta data från en tabell och jag får cirka 10 träffar. Bland dom träffarna finns ID'n som jag vill joina mot en annan tabell med säg 1 milijon poster. Det finns inget i sökningen som kan filtrera ner de där 1 milijon posterna förutom just mina relaterade id'n.

Hur har microsoft tänkt att man ska lösa sånt med ett dataset och DataSetRelations? Det går inte lösa på ett effektivt sätt som jag kommer på ..


ps. Varför inget ado.net forum fresten?
Man måste ju som jag förstår det hämta först de där 10 posterna och lägga det i ett dataset .. och sedan göra en query mot tabellen med 1 milijon poster och lägga in det i samma dataset .. sen kan jag ju fixa en parant-child relation men som sagt .. man vill ju helt hämta 10 eller mindre poster än 1 milijon ..

Man kan ju förstås oxå hämta först de 10 posterna och sedan hämta ut ID'n på dom och smalna av sökningen mot den stora tabellen men om man ska göra så måste väl en gammal hederlig join vara snabbare?

Jag skulle till Ado.net 2.0 vilja ha så man på ett Dataset kan ange en en key och en "relations" tabell av nåt slag .. och sen så borde dataadaptern automagiskt kunna hämta två tabeller filtrerade och fina med just de poster som behövs .. precis som en vanlig join med utan redundant data ..

Hehe .. fy va långt det här blev men jag var tvungen att skriva av mig lite .. säg till om jag är ute och cycklar och ni har nån sjusst lösning på detta, eller bara vill tala ut :)

Det kanske hade varit smidigt i vissa lägen med en sådan funktion som du beskriver, men jag hade definitivt kört med :

<info>
SELECT * FROM [StorTabell] WHERE [ID] IN
(SELECT ID FROM [LitenTabell] WHERE ...)
</info>

eller en SP :

<info>
CREATE PROCEDURE getstuff
@idlist varchar(1024)
AS
DECLARE @sql varchar(4096)
SET @SQL='SELECT * FROM [StorTabell] WHERE [ID] IN (' + @idlist + ')'

EXEC @SQL
</info>

Som du säger, att läsa upp så mycket data som inte behövs är ju vansinnigt...

Som hultan säger använder man något som kallas joins. Du har 1000 kunder som har orders, i detta fall 1 miljon orders fördelat på dessa tusen kunder.

Om du skulle välja alla 1000 kunders order får du 1 miljon, men troligen är det antingen 1 kunds order, eller i ditt fall 10 kunders order - varför du nu skall välja det.

Oavsett detta så börjar du med att ta fram dom tio kunderna du behöver komma åt, säg att dom har postnr 118.

<info>
select kundid, förnamn, efternamn, firmanamn
from kunder
where postnr = '118%'
</info>
resultatet blir 10 poster

Nu har vi nästa problem. Dessa 10 kunder har nu ordrar liggandes, totalt har dom tillsammans 250 order och det är väl hanterbart. Hur du skall visa det är ju upp till dig, all data eller kanske bara en summa.

tabellen order har också ett kundid - och det är för att du skall kunna knyta en order till en kund. Joinen blir som följer

<info>
select kundid, förnamn, efternamn, firmanamn, orderid, produkt, antal, pris
from kunder k, order o
where postnr = '118%'
and k.kundid = o.kundid
</info>

Det som händer nu är att du får ut 250 rader och det har troligen gått blixtsnabbt. Anledningen är bl.a. att du har ett index på kundid i din tabell order, sökningen går på nolltid.

Ett annat exempel på tid. I forumet finns 100.000 inlägg. Varje läsning loggas i en annan tabell så ni 15.000 medlemmar skall kunna se vad som är nytt, ändrat eller läst tidigare. Denna tabell är ca 2.5 miljoner poster nu och varje gång en medlem tittar på översiktssidan i forumet görs en fråga mot all denna data - och det tar ju inte lång tid att se den sidan - eller hur.

Hoppas detta ger dig något att bita i. Om inte, förklara tydligare ditt problem eller din fundering.

Jag håller med hultan, undvik joins då du får redundant data i mängder när du gör på det sättet.

Dessutom blir det grymt mycket enklare att programmera om du har datan i två tabbeller istället för i en .

Tack för ditt utförliga svar, men du missupfatta mig nog lite. Jag är fullt på det klara med hur joins och sådant fungerar. Min funderar var mer hur man löser det i .net och bygger relationer med datasets och dylikt. Gör man en vanlig join som du föreslår så får du ju bara tillbaka en tabell med redundant data som egentligen är helt onödig (alltså du får kundnamn osv för varje order).

Ska kolla de andra svaren här nu .. vet inte riktigt hur detta forum fungerar .. verka vara nånslags hybrid mellan "platt" och hierikiskt .. är det meningen att man ska skriva ett svar per inlägg om man undrar nåt mer eller ska man svara alla med ett inlägg ;)

Så du menar att jag typ ska ..

- Hämta t.ex 10 st meddelanden
- fixa fram alla unika t.ex userid's från datan som returneras
- anropa en funktion som hämtar ett nytt dataset med bara de id jag behöver från den stora tabellen
- lägga ihop de två dataseten och sedan arbeta med den datan jag får tillbaka

Det är så du menar om jag förståt det hela rätt. Det vore jävligt intressant att se nån slags performance mätning på detta. I min hjärna så känns det ju i princip alltid som att en fråga mot databasen är snabbare än två. Även om man kanske får lite mer data från den ena .. fast man får ju alltid väga performance mot läsbarhet och tid att koda osv ..

Jag vill fortsätta denna diskussion :)

Jag tolkade dig nog rätt men var kanske lite otydlig.

Jag tycker att det är ok (eller t o m bra) att använda flera tabeller i ett dataset och att använda relationer i datasetet när det fyller en funktion, som i ditt fall. Men att läsa upp mer data än man behöver är (nästan) alltid fel så läs upp enbart det som du behöver till dina tabeller och sätt relationen därefter. Det vill säga, gör precis så som du tänkte men läs inte upp mer data än du behöver (det var där mina SQL-satser kom in).

Jag förslog ingen join, det var andra som föreslog det, och det har också sina för och nackdelar. Som jag ser det är den strategi som din fråga gäller minst lika bra som att strula med joinar (ja, jag är inte helt bekväm med joins) i många fall. I ditt specifika fall tycker jag t o m att den är bättre än en join. Fast det är ju bara min personliga åsikt...

Lite förvirrande forum det här ibland .. mitt svar där uppe var ju typ till Pelle .. aja .. du kanske inte hann set mitt andra svar som mer var riktat till dig .. hehe ..

> du kanske inte hann set mitt andra svar som mer var riktat till dig

Helt riktigt :-)

>- Hämta t.ex 10 st meddelanden
>- fixa fram alla unika t.ex userid's från datan som returneras
>- anropa en funktion som hämtar ett nytt dataset med bara de id jag behöver från den stora tabellen
>- lägga ihop de två dataseten och sedan arbeta med den datan jag får tillbaka

Precis så var min tanke. Jag använder ofta denna teknik och tycker den fungerar bra...som sagt, det går ju att joina också och det är väl kanske en smaksak.

Men om vi fortsätter :)

Vi har ett scenario där jag måste joina i t.ex en sökning. Om jag t.ex vill ha hitta alla produkter i databasen från personer som bor i sverige. Då måste jag i sök queryt joina mot user tabellen och kolla land .. och då kan man ju passa på att hämta all data som man behöver om användaren oxå ..

Eller så kan man ju fortsätta och göra som vi pratat om innan .. att helt enkelt fortfarande bara hämta datan om produkten och sedan ta alla userid jag hittar där och hämta dom från user tabellen ..

Detta måste man ju tappa performance på i.o.m att man dels måste göra en join och sedan dessutom göra en extra fråga ..

Men sen om man blandar in att man kanske vill ha ett rent snyggt datalager där man hämtar data från en tabell i varje klass och kör med typed dataset och skit .. och sen kanske kan merga ihop dom osv i business lagret .. men fan .. jag tänker för mycket på sån här skit istället för att jobba effektivt :D ..

Försök använda JOIN om det går, det ger dig bäst prestanda och bara en tur till databasen.

Annars kanske denna artikel om parent-child resultat i Dataset kan vara till hjälp:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconnesteddatarelations.asp

Ola