[SQL] Oppervlakte berekeningen

[deboer.bas]

Tweakers,

Ik zit met een probleem die mijn sql (access) kennis te boven gaat.

Het gaat om een tabel met deelobjecten die weer hun eigen inhoud hebben.
Voorbeeld:

Dorpslaan 1 | Woning | 250
Dorpslaan 1 | Serre | 50
Dorpslaan 2 | Woning | 350
Dorpslaan 2 | Uitbouw| 100

Het tabel- en kolomnamen ziet er als volgt uit:
Tabel: Nummeraanduiding
Kolom 1: Adres
Kolom 2: Deelobject
Kolom 3: Inhoud

Nu zou ik graag een query willen draaien die per adres de inhoudsvelden bij elkaar optelt.
Mocht je dat op bovenstaand voorbeeld draaien, als uitkomst:
Dorpslaan 1 | 300
Dorpslaan 2 | 450


Hopelijk kunnen jullie me opweg helpen....

Alvast bedankt!

Bas

[joekoe]

iets met sum?

[P_de_B]

SQL:

SELECT Adres, SUM(Inhoud) as TotaalInhoud
FROM Nummeraanduiding
GROUP BY Adres

Zie ook: Programming FAQ - SQL voor meer uitleg over de GROUP BY functie

[deboer.bas]

daar zou je wel is gelijk in hebben

hoe ga je dan om zodat dorpslaan 1 niet bij 2 word opgeteld? Er zal een selectie moeten worden gemaakt, maarja als je "WHERE Adres = Adres" gaat dit niet werken.....

[Flipke84]

Wat denk je dat "GROUP BY Adres" doet?

[Verwijderd]

deboer.bas schreef op woensdag 04 maart 2009 @ 16:57:
daar zou je wel is gelijk in hebben

hoe ga je dan om zodat dorpslaan 1 niet bij 2 word opgeteld? Er zal een selectie moeten worden gemaakt, maarja als je "WHERE Adres = Adres" gaat dit niet werken.....

Daarvoor wordt de GROUP BY gebruikt. Deze zorgt ervoor dat elk nieuw item onafhankelijk word behandeld.

[Creepy]

Aka: misschien handig dat je de FAQ eens leest waar P_de_B naar verwijst want daar staat dat netjes in uitgelegd

[deboer.bas]

Super!!! Weer wat geleerd, zocht me suf....maar zocht kennelijk in de verkeerde richting!

THX!!

[deboer.bas]

Word nog leuker hoor want ik moet inhoud gaan omrekenen naar oppervlaktes...waarbij VROM verschillende omreken factoren heeft vastgesteld.

Hoekwoning, flat, twee onder één kap, etc... en daarover nog verschillen in bouwjaar..haha...

[Woy]

deboer.bas schreef op woensdag 04 maart 2009 @ 17:04:
Word nog leuker hoor want ik moet inhoud gaan omrekenen naar oppervlaktes...waarbij VROM verschillende omreken factoren heeft vastgesteld.

Hoekwoning, flat, twee onder één kap, etc... en daarover nog verschillen in bouwjaar..haha...

Dat is iets wat je standaard niet in je database wilt gaan doen. Daar is je business logica voor. Verder zou ik eens naar Database Normalisatie kijken!

[ Voor 5% gewijzigd door Woy op 04-03-2009 17:45 ]

[cariolive23]

Woy schreef op woensdag 04 maart 2009 @ 17:44:
Dat is iets wat je standaard niet in je database wilt gaan doen.

En waarom niet? Databases kunnen uitstekend rekenen, de + en - en vele andere functies zijn allemaal bedoelt voor het rekenwerk, dan kan een volumeberekening daar ook nog wel bij. Er is niks mis met een database die je goed aan het werk zet, daar is hij voor bedoelt. Een database is meer dan een stuk kladpapier om wat data te onthouden, het wordt niet voor niets een DBMS genoemd.

[Luqq]

cariolive23 schreef op woensdag 04 maart 2009 @ 18:28:
[...]

En waarom niet? Databases kunnen uitstekend rekenen, de + en - en vele andere functies zijn allemaal bedoelt voor het rekenwerk, dan kan een volumeberekening daar ook nog wel bij. Er is niks mis met een database die je goed aan het werk zet, daar is hij voor bedoelt. Een database is meer dan een stuk kladpapier om wat data te onthouden, het wordt niet voor niets een DBMS genoemd.

Dat iets het kán, betekent niet meteen dat het dan ook logisch is Als jij een groot rekenprogramma OOP programmeert, en er iets fouts uitkomt, dan hoor je je probleem op te zoeken in je reken class, en NIET in je database layer. Dit is gewoon een van de basisprincipes van OOP waar ik me zoveel mogelijk aan vast probeer te klampen, om het voor mezelf en anderen zo duidelijk mogelijk te houden.

[P_de_B]

Zonder extra informatie kun je denk ik lastig zeggen of het extra rekenwerk in de database op de businesslogica thuishoort. Als er omrekentabellen zijn die ook in de database zijn opgenomen kun je door deze tabel ook je joinen snel berekeningen uitvoeren. Ik denk dat dat beter is dan alle data kaal naar de applicatie te halen en daar berekeningen te doen. Ik denk dat je heel goed berekeningen in de queries kunt uitvoeren. Maar zoals gezegd, dat hangt af van de uit te voeren berekeningen en de data.

[curry684]

cariolive23 schreef op woensdag 04 maart 2009 @ 18:28:
[...]

En waarom niet? Databases kunnen uitstekend rekenen, de + en - en vele andere functies zijn allemaal bedoelt voor het rekenwerk, dan kan een volumeberekening daar ook nog wel bij. Er is niks mis met een database die je goed aan het werk zet, daar is hij voor bedoelt. Een database is meer dan een stuk kladpapier om wat data te onthouden, het wordt niet voor niets een DBMS genoemd.

In de afkorting DataBase Management System zie ik nog steeds de term 'Calculator' niet staan. Hoewel het niet zo zwart-wit is als het hier en daar hier gesteld wordt denk ik wel degelijk dat je basisaanname moet zijn dat echte berekeningen in de business logic thuis horen behoudens DB-targeted strak gedefinieerde uitzonderingen zoals filters.

[cariolive23]

Wel of niet berekenen in de database, zou ik vooral laten afhangen van het doel: Wil je op basis van het resultaat een vergelijking doen en de bijbehorende records opvragen of niet. Het heeft weinig zin om bv. 25 miljoen records op te gaan halen, in je "business logica" de hele zooi uit te gaan rekenen, 24.999.999 resultaten richting prullenbak en bij dat ene resultaat de resterende data ophalen. Dat kan efficienter... En wel door de berekening in de database te laten doen, dan hoef je maar 1 resultaat op te halen, de database zal keurig voor jou gaan berekenen welk resultaat dit moet zijn.

OOP is handig, maar niet met grote databases en datasets. Span in dat soort gevallen de database voor jouw karretje en laat deze het werk voor je doen. Databases kunnen heel veel werk verzetten en veel meer doen dan alleen een simpele insert, update, select of delete. Het is niet voor niets dat er een behoefte is ontstaan voor het gebruik van stored procedures, vrijwel alle databases beschikken inmiddels over deze zeer krachtige mogelijkheden. Al moet je daar ook weer niet mee overdrijven, ze zijn geen doel op zich.

[P_de_B]

Als je voor je berekeningen een SP nodig hebt ben ik geneigd te zeggen om het toch aan de client te doen. Als je een setbased oplossing kunt gebruiken (zoals de genoemde join met een tabel met omrekenfactoren) kun je het imo wel goed in de database doen.Het gebruik van een SP suggereert dat je het al niet meer in het SELECT statement kunt doen.

[MrBucket]

In het algemeen ben ik het eens met de posters die zeggen dat dit soort zaken niet op je database thuishoren, maar in je business layer.

Er zijn imo twee goede argumenten om hier vanaf te wijken:
- Als het om een dusdanig grote hoeveelheid (bulk)data gaat, dat alles overpompen in je business layer om daar de berekeningen te doen je performance in het gedrag brengt.
- Als de berekening zo simpel is dat je het met een redelijk simpele SP kunt uitrekenen, en het min of meer onzin zou zijn om zulke simpele logica in je business layer vast te leggen

Anders denk ik dat je beter af bent om het in je business layer uit te rekenen. Procedurele code is vaak een stuk praktischer in dit soort gevallen dan SQL, en ook een stuk compacter vergeleken met bv T-SQL, en dus waarschijnlijk beter onderhoudbaar. Zeker als het gaat om complexere regels aan de hand waarvan je berekeningen gedaan worden, wat volgens TS een redelijke kans heeft.

Nu zag ik in de openingspost staan dat het MS Access betreft, en voor zover ik weet biedt dat sowiezo niet zoveel ondersteuning om complexere logica op de database op te lossen... Als ik TS was, zou ik (met de huidige kennis) ervoor kiezen de berekeningen in code te gaan doen en de database puur de benodigde data op een efficiente manier laten aanleveren.

Niet van toepassing op TS, maar voor de discussie in het algemeen: Als je SQL Server 2005 / 2008 gebruikt, kun je ook methodes uit een .NET-assembly aanbieden als user-defined function of SP. Dit kan voor sommige gevallen een uitkomst zijn, met name bij het in bulk uitvoeren van een berekening die complex is, maar weinig data als invoer nodig heeft (theoretisch voorbeeld: in bulk de oppervlakte bepalen van een groot aantal polygonen, waarbij elk polygon als een verzameling van ong. 20 punten in de database is opgeslagen).

[Woy]

P_de_B schreef op woensdag 04 maart 2009 @ 21:07:
Als je voor je berekeningen een SP nodig hebt ben ik geneigd te zeggen om het toch aan de client te doen. Als je een setbased oplossing kunt gebruiken (zoals de genoemde join met een tabel met omrekenfactoren) kun je het imo wel goed in de database doen.Het gebruik van een SP suggereert dat je het al niet meer in het SELECT statement kunt doen.

Idd, dat is ook mijn idee. Ik stelde het inderdaad erg zwart-wit, maar aan de hand van de volgende quote trok ik de conclusie dat er een stel regels aan zaten, en dus niet een simpele conversie factor die je in je set bewerking mee kan nemen.

deboer.bas schreef op woensdag 04 maart 2009 @ 17:04:
Word nog leuker hoor want ik moet inhoud gaan omrekenen naar oppervlaktes...waarbij VROM verschillende omreken factoren heeft vastgesteld.

Hoekwoning, flat, twee onder één kap, etc... en daarover nog verschillen in bouwjaar..haha...

[Niemand_Anders]

Ik zelf heb vrij weinig ervaring/kennis wat betreft access, maar zit VBA niet in Access op hetzelfde niveau als managed stored procedures in MSSQL?

Enkele maanden terug heb ik bij een installatie bedrijf nog een Access programma gezien welke zowel de frontend als de backend vormt.

[Woy]

Niemand_Anders schreef op donderdag 05 maart 2009 @ 11:06:
Ik zelf heb vrij weinig ervaring/kennis wat betreft access, maar zit VBA niet in Access op hetzelfde niveau als managed stored procedures in MSSQL?

Enkele maanden terug heb ik bij een installatie bedrijf nog een Access programma gezien welke zowel de frontend als de backend vormt.

Ja VBA zit compleet in Access geintergreerd. Dus het is relatief eenvoudig om wat berekeningen in VBA te doen.

[Kentsfield]

VBA zit inderdaad in access, maar wat is de frontend van de TS? je kan de access vba alleen goed gebruiken bij een access frontend.

Zelf is mijn eerste gedachte dat oppervlakte berekeningen business logic zijn. Ik zou het geheel in mijn applicatie uitschrijven.