[MSSQL] Multiple result sets onderscheiden

[BikkelZ]

Nou heb ik altijd geleerd dat je nooit op indexnummer en altijd op kolomnaam je rows moet uitlezen. En terecht, mocht je ooit nog eens een keer gaan schuiven met de kolommen doordat je er een toevoegt moet je applicatie blijven.

Enter stored procedures & multiple result sets.

Hoe stap je daar door heen? Do...While (resultSet.NextResult()). OK. En dan per resultset met bijvoorbeeld een switch/case en een integer die meetikt dan bekijken welke rijen ik moet ophalen. Maar dan ben ik toch weer terug bij de integer-voor-kolomnaam problematiek maar dan een niveau hoger.

Is er niet een manier om resultsets te namen of op een andere manier met een naam in plaats van een arbitrair nummer onderscheid te maken?

[Janoz]

Zolang je niet een * gebruikt, maar gewoon de kolomnamen opsomt in je query (wat je ook zou moeten doen) is het gebruik van een index geen enkel probleem.

[mOrPhie]

Je weet toch per resultset welke kolommen je in die resultset hebt? Waarom zou dat bij multiple resultsets anders zijn?

Kun je wat specifieker zijn in de code die je jezelf voorstelt en in welke taal zou ook wel handig zijn. Ik gok op java, maar DAO en ADO kennen ook een resultset, dus vandaar.

[BikkelZ]

Ik zal de situatie schetsen:

Ik wil verschillende gegevens ophalen uit verschillende queries, soms met maar een row, soms met meerdere rows, en niet te combineren. Ik wil die in een keer ophalen omdat dat cleanere code oplevert en minder serverbelasting. Alleen iedere resultset moet wel op een eigen manier bewerkt worden. Hoe herken ik de resultset, zodat ik de bewerking kan uitvoeren? Alleen aan de namen van de kolommen? Dus:

code:

if veld != null { doeIets(veld) };

[__fred__]

Resultsets hebben slechts een nummer, geen naam. Wat je zou kunnen doen is een kolom maken met daarin de naam van de resultset of een extra resultset retourneren met voor elke resultset een rij met de naam erin.

Maar dat zijn wel erg lompe oplossingen voor een niet zo groot probleem. Een kolom in een resultset erbij of eraf lijkt me waarschijnlijker dan een resultset erbij of eraf en dan ook nog tussen de andere resultsets in.

Je moet je dan afvragen waar je mee bezig bent is mijn mening.

[mOrPhie]

Of het cleanere code oplevert valt nog maar te bezien, alsmede of het voor minder serverbelasting zorgt. Dat beetje overhead van de databasedriver voor 2 extra aanroepen zul je echt niets van merken. Daarbij loop je nu al tegen de herkenning van de resultsets aan. Dus ik zou me niet op jouw beoogde aanpak blind staren.

[BikkelZ]

Nou het is niet zo'n hele grote ramp, maar ik vind het alleen een beetje tegennatuurlijk omdat je het op kolomnaam nooit zo zou doen en het komt de leesbaarheid niet ten goede. Maar of dat je dat moet oplossen door een drie losse queries te doen, ik weet het niet.

[mOrPhie]

BikkelZ schreef op vrijdag 19 oktober 2007 @ 13:50:
Maar of dat je dat moet oplossen door een drie losse queries te doen, ik weet het niet.

Waarom niet? Drie losse queries (1 query per keer) is juist de meest gangbare aanpak. Ik ken de rest van je architectuur ook niet, maar de meeste OR-mappers doen zelfs voor samengestelde objecten aparte calls.

"premature optimization is the root of all evil" is daarom ook iets wat sterk onderbouwd wordt door veel engineers. De overhead die je genereert met drie queries is lang niet zoveel dat er echte significante winst te behalen valt. Richt je bij optimalisatie op de grote winsten. Later kun je altijd nog optimaliseren als het echt nodig mocht zijn.

[BikkelZ]

De onderliggende reden om het allemaal richting SP te schoffelen is omdat de onderliggende database structuur het beste te omschrijven is als Ad Hoc en waarschijnlijk bij een herbouw van de website ook onder handen genomen gaat worden. Queries die weer queries nodig hebben om de volgende query te kunnen bouwen waarna dynamisch met een string en EXEC (it's a dirty job....) van dynamisch bepaalde tabellen gelezen kan worden, het is nog redelijk complex.

Dan is het makkelijk dat ik deze code zonder enige wijziging kan blijven gebruiken en echt maar op een plek een stored procedure hoef aan te passen, in plaats van dat ik allerlei poep vanwege een brakke database door mijn code moet gaan weven.