Ik heb een database (in sql server 7.0) waarvan ik van elk van de aanwezige kolommen wat statistische informatie moet hebben. Ik wil bijvoorbeeld de min/max waarde, het gemiddelde, de variantie, etc hebben. Echter aangezien ik veel kolommen heb, vroeg ik me af of er een manier bestaat om deze slim te generen zodat ik niet voor elke kolom en elk informatiedeel steeds een query moet runnen. Eigenlijk is het dus de bedoeling dat ik voor een aantal kolommen een soort 'verslagje ' maak met voor mij interessante gegevens. Ik heb geprobeerd dit te doen mbv stored procedures maar ik kom er niet echt uit. Kan iemand mij op weg helpen of mij wat tips gegeven.
speciale tabel / file maken waar je de resulaten in cached.. als het dan veranderd (insert / update) dan genereer je de cache overnieuw.
Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR
Het is me niet helemaal duidelijk wat er fout gaat. Lukt het maken van de stored procedures niet, of wil je misschien dynamische queries opzetten en uitvoeren in je query en loop je daar op vast?
Of wil je zoals dusty aangeeft een 'platte' presentatie van je data genereren voor rapportages (performance-wise is dat soms handig). In dat geval kan je kijken naar triggers (real-time bijwerken) of DTS i.c.m. queries/stored procedures (gescheduled) om je cache bij te werken.
p.s. (voor het geval je dit nog niet wist) de books online is vaak een goed startpunt voor onderzoek. Een enorme berg informatie over van alles en nog wat mbt mssql.
Of wil je zoals dusty aangeeft een 'platte' presentatie van je data genereren voor rapportages (performance-wise is dat soms handig). In dat geval kan je kijken naar triggers (real-time bijwerken) of DTS i.c.m. queries/stored procedures (gescheduled) om je cache bij te werken.
p.s. (voor het geval je dit nog niet wist) de books online is vaak een goed startpunt voor onderzoek. Een enorme berg informatie over van alles en nog wat mbt mssql.
Today's subliminal thought is:
ik zou in ieder geval alles live opvragen, ... een soort van cache maken lijkt me het slechtste wat je kunt doen, zeker als je met zo iets krachtigs werkt als sql server.
storedprocedures lijken mij toch de beste oplossing, je kunt er gewoon al je (dynamische) querys in kwijt en alles gaat supersel.
een hint: gebruik de systabels om het e.e.a geautomatiseerd op te vragen. in de systeemtabellen staan alle tabel en kolomdefiniteis, een bron van informatie, zeker als je een stored procedure schrijft die algemeen is aan te roepen voor een tabel / kolom; kan je eventueel met een query door alle tabellen lopen en de 'statistiek stored procedure' uitvoeren zonder ook maar een letter code te hoeven aanpassen als er tabellen / kolommen bijkomen.
storedprocedures lijken mij toch de beste oplossing, je kunt er gewoon al je (dynamische) querys in kwijt en alles gaat supersel.
een hint: gebruik de systabels om het e.e.a geautomatiseerd op te vragen. in de systeemtabellen staan alle tabel en kolomdefiniteis, een bron van informatie, zeker als je een stored procedure schrijft die algemeen is aan te roepen voor een tabel / kolom; kan je eventueel met een query door alle tabellen lopen en de 'statistiek stored procedure' uitvoeren zonder ook maar een letter code te hoeven aanpassen als er tabellen / kolommen bijkomen.
[ Voor 8% gewijzigd door JamesTiberius op 27-10-2003 23:31 ]
I laugh in the face of danger ... ... then I hide and wait until it goes away -
Soms is het gewoonweg niet handig om in een OLTP omgeving allerlei 'statistische' queries los te laten. De data is normaalgesproken niet opgeslagen op de meest ideale manier om aan deze gegevens te komen wat dus slecht voor je performance is. Het is natuurlijk niet prettig om allerlei locks op je tables te hebben terwijl een hele afdeling gegevens wil invoeren alleen omdat jij een rapportje wil uitdraaien.
Waar je het dus vandaan haalt dat dit 'het slechtste' is wat je kan doen weet ik niet. Even los van het feit of het hier van toepassing is natuurlijk, ik ken de data en de hoeveelheid niet.
Als tweede zou ik willen aanraden om de system-tables alleen bij ad hoc queries te gebruiken en zo min mogelijk in je applicatie. Bij elke upgrade van mssql heb je kans dat de structuur van de system-tables wijzigt en je dus aan je applicatie kan gaan sleutelen. Gebruik dan liever de daarvoor bedoelde views (INFORMATION_SCHEMA).
offtopic:
Alles is imho. Dus je hoeft het er niet mee eens te zijn
Alles is imho. Dus je hoeft het er niet mee eens te zijn
Today's subliminal thought is:
Daar ga ik dus wel vanuit omdat hij zei "verslagje".Annie schreef op 27 October 2003 @ 23:23:
[..]
Of wil je zoals dusty aangeeft een 'platte' presentatie van je data genereren voor rapportages [..]
Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR
Super dat ik al zoveel reacties heb gehad! Omdat er onduidelijkheid bestaat over mijn precieze bedoelingen zal ik dit toelichten.
Wat ik 'wil' is een overzicht (een report?) met daarin een aantal gegevens over de waarden in een kolom. Dit zouden waarden als MIN/MAX moeten kunnen zijn als bijvoorbeeld een grafiek met daarin uitgezet de voorkomens van een gebeurtenis tegen de tijd.
Performance gewijs zou het best een platte respresentatie mogen zijn. Als iemand echter iets beter weet dan hoor ik het graag.
Ik heb wel wat bestaande Stored Procedures (sp) gevonden zoals sp_colunns_ex echter zij geven alleen de algemene informatie.
Ik heb helaas niet echt ervaring met sp en dat scheelt wel veel omdat ik misschien daardoor voor de hand liggende oplossingen over het hoofd zie.
Wat ik 'wil' is een overzicht (een report?) met daarin een aantal gegevens over de waarden in een kolom. Dit zouden waarden als MIN/MAX moeten kunnen zijn als bijvoorbeeld een grafiek met daarin uitgezet de voorkomens van een gebeurtenis tegen de tijd.
Performance gewijs zou het best een platte respresentatie mogen zijn. Als iemand echter iets beter weet dan hoor ik het graag.
Ik heb wel wat bestaande Stored Procedures (sp) gevonden zoals sp_colunns_ex echter zij geven alleen de algemene informatie.
Ik heb helaas niet echt ervaring met sp en dat scheelt wel veel omdat ik misschien daardoor voor de hand liggende oplossingen over het hoofd zie.
Het is best mogelijk om met behulp van de INFORMATION_SCHEMA.COLUMNS view dit te genereren, maar het lijkt me beter om aandacht te besteden aan de tijd die het kost om de query uit te voeren, en niet de tijd die het kost om hem te schrijven.
Als je dit wel graag wilt, onderstaande geeft je de kolommen:
Als je dit wel graag wilt, onderstaande geeft je de kolommen:
code:
1
| SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.Columns WHERE TABLE_NAME = 'authors' |
Oops! Google Chrome could not find www.rijks%20museum.nl
Pagina: 1