Link tussen records

[Bodson]

Goedemorgen, ik zit met het volgende; ik werk in Microsoft SQL Server.

Ik heb een database met honderdduizenden units, bijv. auto's. Per maand (boekperiode) worden meerdere gegevens voor elk van deze units vastgelegd, wat resulteert in miljoenen records. Bijvoorbeeld 'leeftijd auto in maanden'. Voor auto_ID 1 is dat bijv. 4 maanden in januari, 5 maanden in februari etc. Allemaal prima, maar nu krijgt deze auto een andere eigenaar, het probleem is nu dat 'leeftijd auto in maanden' wordt gereset terwijl ik wil dat deze doorloopt. Bij de nieuwe unit, auto_ID XX is wel terug te vinden dat auto_ID 1 de voorgaande was, je zou deze 'leeftijd auto in maanden' er dus in feite bij op willen tellen.

Misschien iets met een loop? Verwijzen naar de vorige record/twee records met elkaar vergelijken wil niet omdat de data soms ook door elkaar staat.

Zie bijlage. Ik ben (nog) niet handig met SQL en bovenstaande kan onduidelijk zijn, maar ik heb 't zo duidelijk mogelijk proberen uit te leggen.

Bedankt voor eventuele hulp!

Bekijk bijlage Map3.xlsx

 

[wampier]

Als dit gebeurt is het database design niet in orde. Details specifiek naar de eigenaar horen in een eigenaar tabel. Details specifiek voor de auto horen in een auto tabel en de koppeling tussen deze informatie hoort in de mastertabel. Tenminste uitgaande van de informatie die je geeft.

Ook kan je "leeftijd" een afgeleide maken van de startdatum en huidige datum met "datediff".

 

[Bodson]

Ervan uitgaande dat ik m'n database-design niet kan wijzigen (heb enkel lees-rechten op de database) en datediff() niet toegepast kan worden ('startdatum' wordt ook gereset bij nieuwe eigenaar), dan nog enig idee hoe ik dit kan aanpakken?

Alvast bedankt!

 

[wampier]

Dan heb je volgens mij niet veel keuze dan dit buiten SQL op te lossen in je frontend. Nou ja, ik verdien deels mijn geld met foute designs herstellen, dus ik kan eigenlijk niet klagen

Overigens bestaan er wel recursieve opties zoals hier:

http://stackoverflow.com/questions/239275/how-do-i-create-a-recursive-query-in-mssql-2005

Maar meestal zijn die niet vrij te creëren dus moet je mogelijk toch aan de slag met de beheerders.

 

[PgVincent]

Het is een ongebruikelijk model, maar of het fout is kan ik niet zeggen want ik weet niet wat de behoeften van de ontwerper zijn geweest. De totale leeftijd van de auto hoeft je niet op te slaan, dat is gewoon NOW()-bouwjaar. Het ziet er erg uit als een materialized view, maar ook dat kan een ontwerpbeslissing zijn als je deze data gewoon bizar-snel moet kunnen oproepen.

Ik zou ook voor recursie gaan, CTE's kun je gewoon uitvoeren als elke andere query. In de gepostte link zegt iemand dat je stored procedures moet kunnen maken maar MS zelf zegt van niet (en het zou ook lichtelijk bizar zijn).

 

[wampier]

en het zou ook lichtelijk bizar zijn

vanuit user oogpunt ja, maar vanuit beheer niet. Recursieve functies hebben een onbekende load en onvoorspelbaar gebruikspatroon. Caching is dan ook erg moeilijk te doen. 1 gebruiker kan makkelijk een hele database omlaag halen door queries met ongelimiteerde recursie. De beheerder kan dan ook besluiten alleen specifieke recursieve queries toe te laten en alleen als stored procedure (en zelfs die nog limiteren naar een maximum aantal queries per minuut).

 

[PgVincent]

Recursieve functies hebben een onbekende load en onvoorspelbaar gebruikspatroon. Caching is dan ook erg moeilijk te doen.
1 gebruiker kan makkelijk een hele database omlaag halen door queries met ongelimiteerde recursie.

Natuurlijk wil je als DBA zoveel mogelijk controle over wat je gebruikers met de database kunnen doen door de SELECT rechten te beperken en de tabellen te ontsluiten via stored procedures.
Maar ik zou het apart vbinden als MS-SQL alleen recursie ondersteunt in stored procedures.

Overigens geldt wat jij zegt voor alle queries, ook een foutje met een crossjoin, of een WHERE clausule met iets simpels als een LIKE of een LOWER() kan de performance al op de knieen krijgen.

en zelfs die nog limiteren naar een maximum aantal queries per minuut.

Zo'n lolbroek heb ik gehad bij een hostingpartij, die hadden bedacht dat ze de belasting van hun database server konden beperken door elke klant maximaal 500 queries per minuut te laten uitvoeren. Gevolg; een van onze websites, die toevallig een populaire questionnaire had, was telkens na 20 seconden onbereikbaar. Maar, die hoster had ook een absurd beleid om alle queries die langer dan 1 seconde draaiden af te schieten. Er zijn heel wat prutsers in de wereld