[Database] Subtotaal wegschrijven in order?

zondag 20 augustus 2006 21:29

EmilneM schreef op zondag 20 augustus 2006 @ 18:13:
Voor een ordersysteem ben ik bezig de database in te richten. Ik heb altijd geleerd om subtotalen en dergelijke niet in de order weg te schrijven. Het subtotaal is immers ook op te halen door een SUM los te laten op de orderregels (artikelregels) die bij de betreffende order horen.

Het systeem moet orders gaan vasthouden met een historie van maximaal 1 jaar. Dit houdt hier in dat er maximaal zo'n 500.000 orders in komen te staan. Gemiddeld betreft een order 5 orderregels. Dit houdt in dat er zo'n 2.500.000 orderregels in de database komen. Er moeten gemakkelijk overzichten gedraaid kunnen worden van ordertotalen per dag, week en maand.

Ik dat de performance sterk vooruit gaat als ik het subtotaal wegschrijf in de order i.p.v. het ophalen uit de orderregels (artikelregels). Zijn jullie het hiermee eens? Is het databasetechnisch erg slecht als ik het subtotaal wegschrijf in de order? Graag jullie reactie.

Nooit doen, je krijgt onherroepelijk problemen omdat het uit de pas gaat lopen door bugs in je code of dingen die je niet voorzien had.

Wat je zou kunnen overwegen is het gebruik van indexed views voor je overzichten. Dit zijn views die als resultaat worden opgeslagen. Oracle, DB2 en bv SqlServer ondersteunen dit. Het DBMS houdt dan de viewdata up to date, dus daar heb je geen omkijken naar, en je overzichten kunnen wellicht hier van profiteren. Maar ik zou sowieso mn datamodel NOOIT aanpassen voor processes of overzichten die de data consumeren, dit omdat het je datamodel zwakker maakt en wanneer het proces niet meer nodig is of het overzicht aangepast wordt, de optimalisatie niet meer nodig is maar nog wel in je datamodel zit.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

zondag 20 augustus 2006 22:09

+1 Overgewaardeerd

Als je gewoon nette update queries maakt en die op triggers zet in de order-regel query, is er niets aan het handje. Ook al maak je brakke code

Hangt er ook vanaf hoe vaak die rapporten gemaakt gaan worden. Als dat er iedere dag 100 zijn kan je er eens aan gaan denken. Als het eens in de maand een paar overzichtjes is zou ik het lekker in de order-regel tabel zetten.

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.

Acties:

Janoz

Moderator Devschuur®

!litemod

Heb je trouwens al nagedacht over een prijsverandering en wat voor effect dat heeft op een order van een half jaar terug?

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

zondag 20 augustus 2006 22:26

Acties:

djack

Je kan de subtotalen bij houden in een aparte tabel. Door middel van de orderid kan je deze dan linken aan je order tabel.
Dan hoef je om een history van de orders maar een select te doen van die subtotalen tabel en indien je dan het detail wil opvragen hoef je maar die subselect te doen die order tabel.

Prijs aanpassingen hebben zouden nooit geen invloed mogen hebben op orders van het verleden...
De sum gaat ook goed werken en op zich ga je van snelheidsverlies niet veel merken denk ik dan even hoor.

Heb net een app opgezet om leveringen te doen aan externe ... zit tot op heden al voor 500 000 euro aan omzet in dus ik spreek een deel uit ervaring. kleine rand bezigheid van mijne chef.

[ Voor 11% gewijzigd door djack op 20-08-2006 22:28 ]

Because Great minds Think alike

maandag 21 augustus 2006 00:09

Acties:

Verwijderd

EfBe schreef op zondag 20 augustus 2006 @ 20:59:
Maar ik zou sowieso mn datamodel NOOIT aanpassen voor processes of overzichten die de data consumeren, dit omdat het je datamodel zwakker maakt en wanneer het proces niet meer nodig is of het overzicht aangepast wordt, de optimalisatie niet meer nodig is maar nog wel in je datamodel zit.

Get real! Natuurlijk pas je je datamodel wel aan wanneer dat voor de gebruikers een betere performance geeft. OK, redundancy is evil, maar soms ontkom je er niet aan.

Neem bv. een hotel reservering programma (heb ik toevallig vrij veel ervaring mee): alle reserveringen staan netjes in een tabel, maar zowel de front desk als housekeeping wil een snel overzicht van de kamerbezetting voor de komende week, en ze willen dat ook nog snappen. Je komt dan op een grid van 7 dagen * 200 kamers of zo, en dat is prima uit de reserveringsgegevens op te bouwen, maar dat kost 3 seconden. En dat zijn 3 seconden teveel, dus bouw je dan een volledig redundante tabel die die grid per direct aan de gebruiker toont.

Klant blij, baas blij, ik blij.

maandag 21 augustus 2006 00:15

Acties:

Kama

Game Coordinator

Ik zou een view maken op "order" met daarin het SUM als extra veld. Heb je geen echte redundancy, maar wel performancewinst. Voordeel van een view is dat je DBMS mag uitzoeken hoe ie je view so efficient mogelijk up to date houdt (en de meeste slagen daar heel aardig in).

drs. Kama

maandag 21 augustus 2006 08:53

Acties:

maandag 21 augustus 2006 09:51

+1 Overgewaardeerd

Heb net een app opgezet om leveringen te doen aan externe ... zit tot op heden al voor 500 000 euro aan omzet in dus ik spreek een deel uit ervaring. kleine rand bezigheid van mijne chef.

Dat zegt natuurlijk niets over hoeveel ervaring jij hebt

Waarom zou je alleen subtotalen (echt alleen bedragen?) bijhouden in een aparte tabel, dan kan je toch net zo goed hele order-regels erin opslaan?

Een query uitvoeren over een tabel met 2 kolommen is niet echt sneller dan over een tabel met 50 kolommen. Of bedoel je iets anders?

Acties:

maandag 21 augustus 2006 10:18

@Janoz: had ik ook aan zitten denken, maar wellicht slaat hij de orderrow prijs op in de orderdow, maar indien niet, dan is dat inderdaad een heel goed punt om naar te kijken.

Verwijderd schreef op maandag 21 augustus 2006 @ 00:09:
[...]
Get real! Natuurlijk pas je je datamodel wel aan wanneer dat voor de gebruikers een betere performance geeft. OK, redundancy is evil, maar soms ontkom je er niet aan.

Je ontkomt er altijd aan, als je je datamodel MOET aanpassen aan wat voor troep er bovenop draait dan ben je IMHO aan het prutsen. Een datamodel is correct of niet, en je kunt t.a.t. verantwoorden waarom een entity die en die attributes heeft en waarom een zekere relatie er ligt ZONDER daarbij terug te vallen op schermpjes of andere code. Als je dat niet kunt, dan is het datamodel dus fout. Nu kun je wellicht aanvoeren "so what!?", maar bij een foutief datamodel krijg je kromme access code en als je code wijzigt en je datamodel 'optimalizaties' zijn niet meer nodig, dan heb je dus een probleem.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

maandag 21 augustus 2006 10:30

+1 Overgewaardeerd

EfBe schreef op maandag 21 augustus 2006 @ 09:51:
Je ontkomt er altijd aan, als je je datamodel MOET aanpassen aan wat voor troep er bovenop draait dan ben je IMHO aan het prutsen. Een datamodel is correct of niet, en je kunt t.a.t. verantwoorden waarom een entity die en die attributes heeft en waarom een zekere relatie er ligt ZONDER daarbij terug te vallen op schermpjes of andere code. Als je dat niet kunt, dan is het datamodel dus fout. Nu kun je wellicht aanvoeren "so what!?", maar bij een foutief datamodel krijg je kromme access code en als je code wijzigt en je datamodel 'optimalizaties' zijn niet meer nodig, dan heb je dus een probleem.

Och... ik heb gehoord van databases die vol staan met redundancy en toch echt niet anders kunnen. Waarom? De enorme hoeveelheid data. Bijvoorbeeld die van een niet-nader-te-noemen supermarkt (zeg maar de grootste van NL). Daar worden queries gedaan op de tabellen met alle kassabonnetjes. Vanwege de hoeveelheid data staan er niet eens indexen op de tabellen (indexen worden veel te groot) en staan de totalen netjes weggeschreven bij het kassabonnetje en wordt er niet op bonnetje-regel niveau gekeken.
Anders is de performance niet zo fijn, tabel kan tot enkele miljarden regels bevatten.

Maarja, da's een datawarehouse en daar gelden dan weer iets andere regels dan een live database denk ik

Acties:

Creepy

Tactical Espionage Splatterer

Voor een datawarehouse gelden zeker andere regels. Maar de DWH is vaak niet de database waarin live alle gegevens worden bijgewerkt. Vaak zie je dat er batchgewijs de live database wordt uitgelezen (of de data wordt op een totaal andere manier verzamelt) en dat dan de DHW wordt ingeschoten.
De kassa's schieten deze data echt niet direct het DWH in. Het punt van EfBe blijft dan ook zeker staan.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

maandag 21 augustus 2006 10:31

Acties:

whoami

Boss schreef op maandag 21 augustus 2006 @ 10:18:
[...]

Maarja, da's een datawarehouse en daar gelden dan weer iets andere regels dan een live database denk ik

Idd, een data-warehouse is heel iets anders dan een OLTP systeem.
Een datawarehouse wordt gebruikt om data te raadplegen, en beslissingen te nemen. Een datawarehouse bevat gegevens die niet meer (of nauwelijks) geupdated worden.
Een OLTP (online transaction processing), is het systeem wat de meeste mensen voor ogen hebben als er over een DB gesproken wordt: nl. een DB waar op 'gewerkt' wordt. (bv: Orders worden ingegeven, gewijzigd, facturen gemaakt, etc....).

Een datawarehouse kan op gezette tijdstippen (bv maandelijks, halfjaarlijks), aangevuld, gevoed worden met de gegevens uit een OLTP DB.

Aangezien de gegevens in een data-warehouse dus niet of nauwelijks gewijzigd worden, en er dus vooral (enkel) SELECT's op gebeuren, is data-reduncancy hier zeker geen vergissing, en kan het de snelheid ten goede komen.

https://fgheysels.github.io/

maandag 21 augustus 2006 20:49

Acties:

djack

Boss schreef op maandag 21 augustus 2006 @ 08:53:
[...]

Dat zegt natuurlijk niets over hoeveel ervaring jij hebt

Waarom zou je alleen subtotalen (echt alleen bedragen?) bijhouden in een aparte tabel, dan kan je toch net zo goed hele order-regels erin opslaan?

Een query uitvoeren over een tabel met 2 kolommen is niet echt sneller dan over een tabel met 50 kolommen. Of bedoel je iets anders?

Ik zeg niet dat ik het zou doen ... Ik doe gewoon een query op mijn sales tabel.
Maar als hij het echt zou willen doen dan zou het misschien wel een oplossing ....

Het zegt idd niet veel over mijn skills maar een app die op 3 weken in elkander gebokst is een koppeling maakt met een cobol app en een omzet mogelijk heeft gemaakt van 500 000 euro's (op 6 maand) geeft me wel het recht om te zeggen dat ik niet zo maar uit mijn nek aan het kletsen ben.

Because Great minds Think alike

maandag 21 augustus 2006 21:04

Acties:

kenneth

achter de duinen

Ik heb conciergewerk mogen verrichten op stinkapplicaties die voor meer omzet goed waren.
Misschien ben je heel goed, misschien niet, maar zo'n opmerking zegt gewoon niets

Argumenten, niet status

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.

maandag 21 augustus 2006 22:54

Acties:

dinsdag 22 augustus 2006 02:38

+1 Overgewaardeerd

W00t, het totaal dat maandelijks door mijn applicaties heengaat schat ik op enkele miljoenen. En sommige financiele uitbreidingen zijn in enkele uren gemaakt $_/-\o_$

Acties:

Verwijderd

EfBe schreef op maandag 21 augustus 2006 @ 09:51:
Je ontkomt er altijd aan, als je je datamodel MOET aanpassen aan wat voor troep er bovenop draait dan ben je IMHO aan het prutsen. Een datamodel is correct of niet, en je kunt t.a.t. verantwoorden waarom een entity die en die attributes heeft en waarom een zekere relatie er ligt ZONDER daarbij terug te vallen op schermpjes of andere code. Als je dat niet kunt, dan is het datamodel dus fout.

Maar je kunt niet t.a.t. aan je klant verantwoorden dat die troep die er bovenop draait 3 seconden duurt voor 't ge-update is, i.p.v. de halve seconde die de klant wenst/eist. Je kunt nog zo'n mooi datamodel hebben, maar als 't niet performt moet je of shortcuts gebruiken (redundancy), of klanten verliezen.

Begrijp me niet verkeerd, ik ben ook een purist als 't om het datamodel gaat, maar soms ontkom je niet aan het performance vs. purity probleem.

dinsdag 22 augustus 2006 11:51

Acties:

Jaspertje

Max & Milo.. lief

Is het acceptabel dat de overzichten die getoond worden een afwijking hebben van een dag? Dan zou je namelijk wel een DWH kunnen opzetten die los draait van je OLTP systeem. Als je orders van een minuut geleden al moet kunnen terug vinden in de rapportage dan zal dit natuurlijk niet gaan werken, maar anders is het wel het overwegen waard.

Tijdens het typen bedenk ik dat het misschien helemaal niet handig is, omdat je ook nog orders kan wijzigen neem ik aan en dan krijg je wel veel rompslomp omdat je dan gegevens wel dubbel vasthoudt en ook moet wijzigen dus (en dat is juist wat een DWH niet wil). En aangezien het systeem maar maximaal een jaar aan history vasthoud zal de rapportage wel preciezer moeten zijn dan een week terug oid.

Heb je al resultaten van beide mogelijkheden? Eigelijk is dat de enige manier om je beslissing te nemen, resultaten. Je geeft al aan dat niet geleerd wordt opslaan van redundante gegevens, maar ook snelheid is belangrijk. Als het een seconde scheelt op 500.000 records is het misschien accepatebeller voor een klant dan dat het 4 seconden langer duurt.

(in DWH land duurt het sowiezo lang om een rapport te genereren over x records is mij geleerd)

donderdag 24 augustus 2006 11:57

Acties:

donderdag 24 augustus 2006 13:16

EfBe schreef op zondag 20 augustus 2006 @ 20:59:
Nooit doen, je krijgt onherroepelijk problemen omdat het uit de pas gaat lopen door bugs in je code of dingen die je niet voorzien had.

Dat is wel erg kort door de bocht.

Er zijn genoeg situaties waarin je wel degelijk redundance nodig hebt om performance te waarborgen. Tabellen met miljoenen mutaties waarop je regelmatig dagrapportages moet dragen bijvoorbeeld, ik vind het in die situatie helemaal geen slecht idee om de geaggregeerde gegevens in een losse tabel te gooien waar dagelijks een regeltje aan wordt toegevoegd. Views zijn wel leuk maar veel te traag in die situatie door de vele aanpassingen. Liever hou je het puur, maar soms kan het niet.

Nog een situatie: achteraf moet er ineens bepaalde rapportage mogelijk worden die totaal niet aansluit bij het (daarvoor nog wel nette) datamodel. Je kan dan wel leuk maanden gaan spenderen om alles weer perfect te maken, of je gebruikt een extra tabel met totalen. Uiteraard zitten daar risico's aan, maar je kan niet maar blijven refactoren voor elke miniscule aanpassing.

In het geval van de topicstarter zal ik in ieder geval eerst eens gaan meten. Vul een database met representatieve data, en draai eens een rapportage. Mocht het traag zijn: ga je datamodel eens goed langs inzake queries/views/etc. Als het dan nog te traag is moet er misschien toch een extra tabelletje met dubbele data bij.

Pragmatisme

Acties:

donderdag 24 augustus 2006 16:40

joepP schreef op donderdag 24 augustus 2006 @ 11:57:
[...]
Dat is wel erg kort door de bocht.

Nee dat valt wel mee.

Er zijn genoeg situaties waarin je wel degelijk redundance nodig hebt om performance te waarborgen. Tabellen met miljoenen mutaties waarop je regelmatig dagrapportages moet dragen bijvoorbeeld, ik vind het in die situatie helemaal geen slecht idee om de geaggregeerde gegevens in een losse tabel te gooien waar dagelijks een regeltje aan wordt toegevoegd. Views zijn wel leuk maar veel te traag in die situatie door de vele aanpassingen. Liever hou je het puur, maar soms kan het niet.

Ik had het idee van indexed views al geopperd in deze thread. Indexed views zijn niet traag, want ze zijn opgeslagen resultsets. Dit IS redundant info opslaan, maar wel info die beheerd wordt door het RDBMS zelf, dus de programmeur van de sync code kan geen fout maken met het updaten van de redundante info want er is geen sync code. De zwakte van het gebruik van redundante info is nl. dat je je redundante info in sync moet houden, en dat dus ALTIJD, ook bij transaction rollbacks bv. Nu moet iedereen natuurlijk zelf weten of hij/zij zelf de redundante info-sync code gaat schrijven, maar ik zou me wel 2 keer bedenken.

Nog een situatie: achteraf moet er ineens bepaalde rapportage mogelijk worden die totaal niet aansluit bij het (daarvoor nog wel nette) datamodel. Je kan dan wel leuk maanden gaan spenderen om alles weer perfect te maken, of je gebruikt een extra tabel met totalen. Uiteraard zitten daar risico's aan, maar je kan niet maar blijven refactoren voor elke miniscule aanpassing.

'achteraf, ineens'... Tja, als je wanneer je huis bijna af is, aankomt kakken met de wens voor een extra toilet op de 1e verdieping ben je ook wat laat. Nu laat software zich nog wel in zekere mate makkelijk wijzigen, maar zonder gevolgen is dat natuurlijk niet.

'Even' een tabelletje erbij prutsen met daarin wat data die door een of ander obscuur last-minute procesje wordt geaggregeerd is wellicht leuk voor de deadline en de manager, maar gaat je op den duur opbreken. Dat veel software engineers dat niets kan schelen omdat ze dan alweer bij een andere klant zitten, is jammer. Bij mij vliegen dat soort mensen er direct uit: je maakt geen shortcuts voor een beetje tijdwinst, je denkt eerst goed na over wat je gaat doen, en past dan wat je hebt aan op die manier zodat wat na de aanpassing ontstaat weer van goede kwaliteit is.

Rapportage is sowieso een traag (relatief dan) gebeuren. Dat snel proberen te krijgen is onbegonnen werk, daar het per definitie over aggregatie van veelal erg veel data gaat, en dat kost per definitie veel tijd. Je kunt het wel wat beperken met wat kunstgrepen, maar veelal schiet je er zelden iets mee op.

Wat het belangrijkste is bij rapportage is dat de gegevens correct zijn. Een fout of achterhaalde gegevens levert foutieve rapporten op en wellicht verkeerde beslissingen. Dat kun je af doen als purisme, maar IMHO is men beter af bij een rapport wat correct is en een half uur duurt dan een foutief rapport wat 1 minuut duurt.

In het geval van de topicstarter zal ik in ieder geval eerst eens gaan meten. Vul een database met representatieve data, en draai eens een rapportage. Mocht het traag zijn: ga je datamodel eens goed langs inzake queries/views/etc. Als het dan nog te traag is moet er misschien toch een extra tabelletje met dubbele data bij.

Wat is dat nou voor advies? Realiseer je je wel wat je hier adviseert? even een tabelletje met dubbele data erbij is niet iets wat je zo maar even doet. Ten eerste kan het zijn dat je model dan inzakt en over een jaar iemand zegt: "WTF doet die tabel daar?" en iedereen de schouders ophaalt omdat degene die dat toen als 'tijdelijke oplossing' aandroeg allang weg is. Ten tweede is redundante data voor overzichten ZEER af te raden TENZIJ jij t.a.t. kan garanderen dat de data in sync is met de live data. Nou, voordat je roept "dat is simpel", zo simpel is dat niet.

Pragmatisme

Ik hou van pragmatisch werken, maar ik vind jouw advies echt niet onder pragmatisme vallen. Verre van dat.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

donderdag 24 augustus 2006 19:46

Leuk zo'n houding, maar daar kan je bij klanten niet mee aankomen. Vandaar dat jij ook voor jezelf werkt, en niet in loondienst projecten zit te kloppen

Ze vragen een feature, die kan -of- netjes in 3 maanden, -of- gehacked in 1 week. Ik zal dan soms kiezen voor de tweede optie, en eens per jaar de boel eens goed refactoren. In dat opzicht zie ik het net als code, of wat mij betreft een huis: kleine wensen kunnen best op een minder optimale manier worden ingevuld, als je maar van tijd tot tijd "de rotzooi" opruimt. Code hoeft niet altijd een kunstwerk te zijn, het moet gewoon werken. Je kan ook niet altijd alles van tevoren overzien, ook niet als je oneindig lang de tijd hebt. Let wel, liever doe ik ook alles netjes, maar uit het oogpunt van productiviteit is dat in mijn beleving niet altijd mogelijk.

Over de TS: als hij toekan met views die door de database worden aangeboden: perfect. Maar soms kan dat gewoon niet. Dan kan je wel leuk zeggen: tsja, rapporteren kost nou eenmaal tijd, maar als de klant snellere rapportages wil zal je weleens iets moeten doen waar je niet helemaal achter staat.

Acties:

Verwijderd

EfBe schreef op donderdag 24 augustus 2006 @ 13:16:
Ik had het idee van indexed views al geopperd in deze thread. Indexed views zijn niet traag, want ze zijn opgeslagen resultsets.

In MSSQL 2000 zijn indexed views lang niet altijd een optie:

The usability of indexed views is limited. While all editions of SQL Server can create and consume an indexed view, it is only the Enterprise Edition and Developer Edition that will make use of them without the addition of the query hint NOEXPAND.

(bron: artikel op databasejournal)

WITH NOEXPAND zorgt er effectief voor dat MSSQL die indexed view behandelt als een gewone table met een clustered index, en meteen zijn al je optimalisaties gewoon verdwenen. En aangezien vrijwel al onze klanten MSSQL 2000 gebruiken, maar slechts een handjevol de Enterprise versie, win je er eigenlijk niks mee.
Bovendien zijn lang niet alle performance problemen die via redundancy op te lossen of te verzachten zijn geschikt voor een indexed view oplossing.

Neem bv. een matrix-achtige presentatie van 21 bij 400 cellen (kamerrack voor 3 weken van een hotel met 400 kamers). De reserveringen die in feite voor het vullen van die cellen moeten zorgen beslaan natuurlijk niet 1 record per kamer per dag, dus zul je of die cellen client side of via een stored proc moeten opbouwen, of een redundant tabel moeten bijhouden die zelf al een representatie van die matrix is.
Als dan de 1e 2 opties een aantal seconden duren, en de 3e optie binnen een oogwenk op 't scherm staat, weet ik wel waar een hotelreceptie bij een drukke checkin voor zal kiezen...

Bovendien, wanneer je het bijhouden van die redundante tabel volledig door triggers laat gebeuren, is de impact niet of nauwelijks groter dan het bijhouden van de index op een indexed view. Bovendien gaan rollbacks dan ook gewoon goed, zonder extra sync code.
Als ik hier uberhaupt al indexed views had kunnen gebruiken...

Niet elke programmeur die met databases werkt schrijft boekhoud of CMS-pakketten...

vrijdag 25 augustus 2006 08:27

Acties:

vrijdag 25 augustus 2006 08:35

joepP schreef op donderdag 24 augustus 2006 @ 16:40:
Leuk zo'n houding, maar daar kan je bij klanten niet mee aankomen. Vandaar dat jij ook voor jezelf werkt, en niet in loondienst projecten zit te kloppen

Oh, dus dat is niet het 'echte' werk? En dat heb ik ook niet gedaan wilde je daarmee zeggen? Sterker: als ik mijn software zou maken zoals jij het beschreef dan zat ik nu bij de sociale dienst. Je piept wel over mijn houding, maar ik snap niet dat jij je als professional zo ver van wat je GEACHT wordt te doen (nl. goede, solide, onderhoudbare software maken) laat afdrijven en je dan terug valt op dingetjes als 'er maar even een tabelletje bij stoppen'.

Ze vragen een feature, die kan -of- netjes in 3 maanden, -of- gehacked in 1 week. Ik zal dan soms kiezen voor de tweede optie, en eens per jaar de boel eens goed refactoren. In dat opzicht zie ik het net als code, of wat mij betreft een huis: kleine wensen kunnen best op een minder optimale manier worden ingevuld, als je maar van tijd tot tijd "de rotzooi" opruimt. Code hoeft niet altijd een kunstwerk te zijn, het moet gewoon werken. Je kan ook niet altijd alles van tevoren overzien, ook niet als je oneindig lang de tijd hebt. Let wel, liever doe ik ook alles netjes, maar uit het oogpunt van productiviteit is dat in mijn beleving niet altijd mogelijk.

Ik zeg ook niet dat je geen compromissen mag sluiten, ik zeg alleen dat de bron van ERG VEEL troep het er 'maar even' bijpleuren van op het oog random tabelletjes en hack-code die die tabelletjes op wie-weet-wat voor tijdstippen vult met data.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

vrijdag 25 augustus 2006 09:15

Verwijderd schreef op donderdag 24 augustus 2006 @ 19:46:
[...]
In MSSQL 2000 zijn indexed views lang niet altijd een optie:

[...]
(bron: artikel op databasejournal)

Tja, ik had het niet per definitie over sqlserver 2000. Dat is al 6 jaar oud.

WITH NOEXPAND zorgt er effectief voor dat MSSQL die indexed view behandelt als een gewone table met een clustered index, en meteen zijn al je optimalisaties gewoon verdwenen. En aangezien vrijwel al onze klanten MSSQL 2000 gebruiken, maar slechts een handjevol de Enterprise versie, win je er eigenlijk niks mee.
Bovendien zijn lang niet alle performance problemen die via redundancy op te lossen of te verzachten zijn geschikt voor een indexed view oplossing.

Neem bv. een matrix-achtige presentatie van 21 bij 400 cellen (kamerrack voor 3 weken van een hotel met 400 kamers). De reserveringen die in feite voor het vullen van die cellen moeten zorgen beslaan natuurlijk niet 1 record per kamer per dag, dus zul je of die cellen client side of via een stored proc moeten opbouwen, of een redundant tabel moeten bijhouden die zelf al een representatie van die matrix is.
Als dan de 1e 2 opties een aantal seconden duren, en de 3e optie binnen een oogwenk op 't scherm staat, weet ik wel waar een hotelreceptie bij een drukke checkin voor zal kiezen...

Ik begrijp 1 ding niet in je redenatie: wat vult die redundante table dan? Dat is kennelijk zo snel dat je het niet merkt.

Maar goed, er zijn ook nog steeds mensen die een hierarchische tree van nodes die in 1 table staat niet met 1 query en een O(n) algorithme kunnen opbouwen en vele vele queries nodig hebben of redundante tables met parent-child info. Ik ken het probleem wat je schetst niet in detail dat ik er een uitspraak over kan doen hoe het het efficientst kan, maar er zijn veelal meerdere oplossingen dan de ge-eikte 'dan maar dubbele data'.

Tuurlijk is ieder probleem uniek en vereist wellicht een wat andere aanpak dan een ander probleem. Mijn punt was en is dat zodra je vervalt op tables met redundante info, JIJ verantwoordelijk bent voor het CORRECT vullen van die tables en dat is vaak niet een simpel karwei.

Bovendien, wanneer je het bijhouden van die redundante tabel volledig door triggers laat gebeuren, is de impact niet of nauwelijks groter dan het bijhouden van de index op een indexed view. Bovendien gaan rollbacks dan ook gewoon goed, zonder extra sync code.
Als ik hier uberhaupt al indexed views had kunnen gebruiken...

Het maakt mij niet uit hoe je je redundante info op peil houdt, als het maar correct is. En het zelf op peil houden geeft dus de verplichting dat je zelf die code gaat schrijven, testen etc. en dus in alle situaties moet die code goed werken.

Niet elke programmeur die met databases werkt schrijft boekhoud of CMS-pakketten...

Als je programmeurs gaat indelen in wie beter is en wie niet, dan weet ik ook nog wel een graadmeter, Afterlife, zullen we daar niet aan beginnen?

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

vrijdag 25 augustus 2006 09:35

EfBe schreef op vrijdag 25 augustus 2006 @ 08:27:
Oh, dus dat is niet het 'echte' werk? En dat heb ik ook niet gedaan wilde je daarmee zeggen? Sterker: als ik mijn software zou maken zoals jij het beschreef dan zat ik nu bij de sociale dienst. Je piept wel over mijn houding, maar ik snap niet dat jij je als professional zo ver van wat je GEACHT wordt te doen (nl. goede, solide, onderhoudbare software maken) laat afdrijven en je dan terug valt op dingetjes als 'er maar even een tabelletje bij stoppen'.

Je neemt dingen aan die niet waar zijn, trekt al mijn argumenten in het extreme, en ziet alles zwart-wit. Fijne manier van "discussieren". Mijn post is redelijk genuanceerd volgens mij, en jij wrijft mij impliciet even aan dat ik bij voorkeur zit te rommelen en te klooien.

Ik zeg ook niet dat je geen compromissen mag sluiten, ik zeg alleen dat de bron van ERG VEEL troep het er 'maar even' bijpleuren van op het oog random tabelletjes en hack-code die die tabelletjes op wie-weet-wat voor tijdstippen vult met data.

Dat zeg je dus wel. Elk voorbeeld wordt direct neergesabeld met veel geschreeuw en weinig wol. Natuurlijk zitten er risico's aan redundante data, maar als je duidelijk weet waar de brondata vandaan komt, en je daar je code netjes inricht, kan je ze echt wel in sync houden.

Samengevat: voor je eigen methoden denk je in oplossingen, en voor die van anderen in problemen. Een typische eigenschap van eigenwijze personen

Acties:

vrijdag 25 augustus 2006 10:39

joepP schreef op vrijdag 25 augustus 2006 @ 09:15:
[...]

Je neemt dingen aan die niet waar zijn, trekt al mijn argumenten in het extreme, en ziet alles zwart-wit. Fijne manier van "discussieren". Mijn post is redelijk genuanceerd volgens mij, en jij wrijft mij impliciet even aan dat ik bij voorkeur zit te rommelen en te klooien.

Nee dat 'bij voorkeur' zeg ik niet, ik zeg alleen dat het advies wat je hier gaf en de beschrijving hoe jij het zou oplossen IMHO niet echt strookt met wat van een professional verwacht zou mogen worden. That's all

[...]
Dat zeg je dus wel. Elk voorbeeld wordt direct neergesabeld met veel geschreeuw en weinig wol.

Mja, je kunt het geschreeuw en weinig wol noemen, dat is natuurlijk aan jou. Jouw opmerking hierboven impliceert dat ik er dus niet iets van begrijp. Nou... ik denk dat je je daarin een klein beetje vergist

Samengevat: voor je eigen methoden denk je in oplossingen, en voor die van anderen in problemen. Een typische eigenschap van eigenwijze personen

Ik geloof niet dat ikzelf nog hoef aan te tonen dat ik weet wat software maken is, Joep. En wat ik aandroeg is niet iets wat ikzelf verzonnen heb hoor, maar goed, je leest er maar in wat je wilt. Ik bedoel: het is niet mijn project waar jij aan werkt, maar jij vergeet dat het ook niet jouw project is waar de TS aan werkt, m.a.w.: wat voor advies je geeft is dus wellicht nadelig voor TS en niet echt voor jou.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

D4Skunk

Kind of Blue

offtopic:
grmbl

[ Voor 104% gewijzigd door D4Skunk op 25-08-2006 10:57 . Reden: offtopic geneuzel ]

vrijdag 25 augustus 2006 12:50

Acties: