[vb.net/sql] dataset opsliten

[Verwijderd]

Ik heb een sql result (van 3 tabellen) die er als volgt uitziet:

|..OrderID..|..SupplierID..|..Quantity..|..UserID..|..ProductID..|
+-----------+---------------+------------+----------+--------------+
|......1.......|..........2.........|......10......|.......3.....|.........8........|
|......1.......|..........2.........|.......5.......|.......3.....|.........7........|
|......2.......|..........2.........|......15......|.......1.....|.........8........|
|......3.......|..........3.........|.......1.......|......15....|........16.......|
+-----------+---------------+------------+-----------+-------------+

Gebaseerd op dit wil ik emails gaan verzenden naar de Suppliers met daarin de orders.

- Een email naar Supllier mag maar de order van 1 UserID bevatten

Dus gebaseerd op deze data wil ik dus 3 emails verzenden:

1) Order voor SupplierID 2 met productID's 8 en 7 voor UserID 3
2) Order voor SupplierID 2 met productID 8 voor UserID 1
3) Order voor supplierID 3 met productID 16 voor UserID 15

Hoe ga ik van de tabel naar 3 verschillende tabellen? Of hoe ga ik van die tabel naar drie verschillende datasets,datagrids,....?

Toevallig is er nu voor elke OrderID 1 email maar er had nog een order bij gekunt met OrderID 1 voor SupplierID 4...

----

Soms heb je toch nog wat aan die stagairs... de stagair hier kwam met het idee om op SupplierID en UserID te sorteren en hiervoor 2 variabelen aan te maken. Als de SupplierID of UserID veranderd dan een nieuwe email aanmaken. Klinkt als een goede oplossing.. of weet iemand iets beters?

-------

[ Voor 19% gewijzigd door Verwijderd op 24-03-2003 11:50 ]

[Verwijderd]

Er zijn zoveel manieren om dit te doen denk ik.

Een manier:

Haal eerste alle supplierIDs op
loop daar doorheen en haal er SupplierID de UserIDs op
loop daar doorheen en haal de ProductIDs op
maak daarmee de e-mails aan.

Op die manier hoef je geen gebruik te maken van variabelen geloof ik.

[whoami]

Verwijderd schreef op 24 March 2003 @ 12:32:
Er zijn zoveel manieren om dit te doen denk ik.

Een manier:

Haal eerste alle supplierIDs op
loop daar doorheen en haal er SupplierID de UserIDs op
loop daar doorheen en haal de ProductIDs op
maak daarmee de e-mails aan.

Op die manier hoef je geen gebruik te maken van variabelen geloof ik.

Nee, maar zo ga je wel veel meer gaan connecten met de database.
Wat neemt een variable nu nog in van resources op PC's met honderden megabytes aan geheugen.
Go figure wat het efficiënts is.

[Verwijderd]

Verwijderd schreef op 24 March 2003 @ 12:32:
Er zijn zoveel manieren om dit te doen denk ik.

Een manier:

Haal eerste alle supplierIDs op
loop daar doorheen en haal er SupplierID de UserIDs op
loop daar doorheen en haal de ProductIDs op
maak daarmee de e-mails aan.

Op die manier hoef je geen gebruik te maken van variabelen geloof ik.

Ja oke.. probeer dat maar eens om te zetten naar semi-code, want volgens mij kan het niet eens wat jij wilt...

of ik moet voor de selects voor elke supplier, userid, orderid op elke mogelijke manier selecten, want neer kan komen op tienduizende queries voor 10 bestellingen...

[ Voor 4% gewijzigd door Verwijderd op 24-03-2003 13:29 ]

[whoami]

de manier van die stagair is een manier....

Je kunt natuurlijk ook de nodige tables inlezen in DataTables, en deze in 1 DataSet zetten. Dan voeg je nog de DataRelations toe en kan je adhv daarvan de rows uitlezen

[Verwijderd]

whoami schreef op 24 March 2003 @ 13:09:
Nee, maar zo ga je wel veel meer gaan connecten met de database.
Wat neemt een variable nu nog in van resources op PC's met honderden megabytes aan geheugen.
Go figure wat het efficiënts is.

Daar heb je gelijk in. Misschien is de oplossing van de TS sneller qua performance. Het was ook alleen een mogelijkheid die ik bood.

[Verwijderd]

Verwijderd schreef op 24 March 2003 @ 13:17:
of ik moet voor selects voor elke supplier, userid, orderid want neer kan komen op tienduizende queries voor 10 bestellingen...

Sorry, wat staat hier?

[pistole]

als je nu vanuit deze result ff terugredeneert.. Doe een query die alle suppliers oplevert die een mail moeten gaan krijgen.... de rest kan je zelf raden denk ik?

Andere mogelijk heid is, inderdaad, om vanuit je hele recordset lokale variabelen gaat bijhouden. Maar dan moet je wel ff zeker weten dat je je recordset goed gesorteerd hebt

[Verwijderd]

pistole schreef op 24 March 2003 @ 13:27:
als je nu vanuit deze result ff terugredeneert.. Doe een query die alle suppliers oplevert die een mail moeten gaan krijgen.... de rest kan je zelf raden denk ik?

Andere mogelijk heid is, inderdaad, om vanuit je hele recordset lokale variabelen gaat bijhouden. Maar dan moet je wel ff zeker weten dat je je recordset goed gesorteerd hebt

Ja maar een mail mag niet alle orders voor 1 supplier bevatten, maar per supplier ook nog een keer per user een aparte email...

[pistole]

...dus ga je per supplier opnieuw querien welke users iets besteld hebben. En zo voorts.

Het lijkt logisch, toch?

[whoami]

pistole schreef op 24 March 2003 @ 13:48:
...dus ga je per supplier opnieuw querien welke users iets besteld hebben. En zo voorts.

Het lijkt logisch, toch?

Hoeveel queries ga je dan doen?

[Verwijderd]

pistole schreef op 24 March 2003 @ 13:48:
...dus ga je per supplier opnieuw querien welke users iets besteld hebben. En zo voorts.

Het lijkt logisch, toch?

Nu blijkt mijn sql kennis toch niet zo goed als ik dacht, of ik heb nog niet door wat je precies bedoelt maar ik heb geen idee hoe je jouw idee naar sql queries zou moeten omzetten...

[pistole]

whoami schreef op 24 March 2003 @ 13:53:

[...]

Hoeveel queries ga je dan doen?

DAt is de keuze van de TS.

Eén query, en dan in je code e.e.a. gaan bijhouden in je variabelen (dus om te zien wanneer je een nieuwe mail moet gaan opstellen).

Of genest gaan querien. Dan wordt het (aantal distinct producenten voor wie een bestelling is) * (aantal distinct klanten voor die producent).

Waar wil je je load leggen? Wat voor front-end / back-end / middleware gebruikt de TS? Al die zaken zijn van invloed op de "beste" oplossing

[whoami]

Het genest gaan query-en gaat gewoon het traagst zijn. Je gaat n keer een connectie maken met de databank, n keer de DBMS een query laten uitvoeren, ....
De andere oplossing is gewoon 1x connecten, 1 query, en dan door je resultset loopen.

[Verwijderd]

Ok, thanks allemaal ik ga voor het idee van de stagair... is volgens mij ook het meest overzichtelijk/snelst en minste onderhoud...