[ASP/SQL] Elk request JOINEN of 'dubbel' opslaan

[Polderdijk]

Misschien een vage topictititel maar ik kon niks beters ervan maken

Maar ik heb dus een aantal website's waar ik logo's en ringtones verkoopt. Nu zit achter die site een aardige berg ASP-code (IIS 6.0) en MS SQL (2000) tabellen met de bijbehorende data.

Nu ben ik dus bezig met de site volledig opnieuw op te bouwen met al mijn wensen enzo erin, maar nu wil ik deze zo 'zuinig' mogelijk maken.

Ik heb dus een tabel 'verkopen' waarin elke keer dat als iemand wat besteld op mijn site dat er een record met alle informatie (gsmnummer, bestelnummer, etc.) in die database wordt gezet.
Ook heb ik een tabel 'ringtones' waarin alle beschikbare titels staan van ringtones die ik aanbied op de site.

Nu is dus de bedoeling dat je standaard de site bezoekt dat de Top 10 wordt opgebouwd uit de sortering van het aantel verkopen.

Is het nou beter om deze op te bouwen via een JOIN op de verkopen-tabel of, zoals ik het nu hebt, beter om te sorteren op het veld 'orders' dat staat in 'ringtone' tabel.

Ik heb dus een bestand xxx.asp wat dus wordt aangeroepen door de 'groothandel' zodra ik een item hebt verkocht via mijn site's. In dit bestand zet ik nu dus alle info in het tabel 'verkopen' en verhoog ik in het bijbehorende ordernummer in de tabel 'ringtone' of 'logo' het veld 'order' met 1!

Het gaat op mijn site voorlopig nog om maar enkele tientallen per dag, dus dat er 2 keer een UPDATE wordt uitgevoerd in die xxx.asp is niet zo'n ramp neem ik aan.

Ook vraag ik me af of het niet beter is om de Top 10's via Applications 1 keer per dag op te bouwen via de database en vervolgens via Applications elke keer weer oproepen. Is dit beter voor de performance?

[ Voor 12% gewijzigd door Polderdijk op 06-04-2004 09:17 . Reden: Het gaat hier om MS SQL en IIS 6.0 ]

[BlackBurn]

Ik heb altijd geleerd om data in ieder geval nooit dubbel op te slaan, je zou het misschien in een Array kunnen doen of evt een kleine losse table, die naar het ID verwijst van je logo/ringtone.

Aangezien je het nog maar of tientallen keer per dag hebt, zal het nog niet zo'n belasting voor je DB zijn.

[Polderdijk]

Wat versta je precies onder dubbel is dan de vraag!

Nu is het namelijk zo dat er voor ELK item wat ik verkoopt een nieuw record in de tabel 'verkopen' wordt geplaatst.

Maar in de tabel 'logo' of 'ringtone' verhoog ik bij elke verkoop het veldje 'orders' met 1!

[nescafe]

En dat laatste zou je eigenlijk achterwege moeten laten. Zeker omdat het hier niet om miljoenen records gaat wil je informatie niet dubbel opslaan. Gebruik dus je orderregels in 'verkopen' en laat het veld 'orders' in 'logo'/'ringtone' achterwege.

Met een query heb je zo de actuele status van het aantal orders. Kun je er ook nog gratis en voor niets criteria op loslaten (orders laatste week,..., in die richting)

[ Voor 7% gewijzigd door nescafe op 06-04-2004 09:43 ]

[cameodski]

nescafe schreef op 06 april 2004 @ 09:43:
En dat laatste zou je eigenlijk achterwege moeten laten. Zeker omdat het hier niet om miljoenen records gaat wil je informatie niet dubbel opslaan. Gebruik dus je orderregels in 'verkopen' en laat het veld 'orders' in 'logo'/'ringtone' achterwege.

Als er inderdaad sprake is van miljoenen records, dan zou het uit performance oogpunt juist wel eens verstandig kunnen zijn om een apart kolom met het aantal orders bij te houden.
Als je op deze kolom vervolgens een index legt, heb je in ieder geval een zeer goede performance. Maar het is inderdaad wel redundante informatie.

[Polderdijk]

nescafe schreef op 06 april 2004 @ 09:43:
En dat laatste zou je eigenlijk achterwege moeten laten. Zeker omdat het hier niet om miljoenen records gaat wil je informatie niet dubbel opslaan. Gebruik dus je orderregels in 'verkopen' en laat het veld 'orders' in 'logo'/'ringtone' achterwege.

Met een query heb je zo de actuele status van het aantal orders. Kun je er ook nog gratis en voor niets criteria op loslaten (orders laatste week,..., in die richting)

Oke, dan gaan we dat doen

Ik was er zelf al een beetje 'bang' voor dat dit idd beter zou zijn, maar idd kan je ook de verkopen van laatste x dagen er nog bijzetten (voor mijzelf dan natuurlijk!).

En mijn laatste vraag over Applications?

[nescafe]

cameodski schreef op 06 april 2004 @ 09:46:
[...]

Als er inderdaad sprake is van miljoenen records, dan zou het uit performance oogpunt juist wel eens verstandig kunnen zijn om een apart kolom met het aantal orders bij te houden.
Als je op deze kolom vervolgens een index legt, heb je in ieder geval een zeer goede performance. Maar het is inderdaad wel redundante informatie.

Hier ben ik het volkomen mee eens. Daarom ook mijn 'Zeker omdat het hier niet om miljoenen records gaat'-beperking.

Maar wellicht is deze redundante informatie goed te beheersen door gebruik te maken van triggers.


Waarom deze late reactie? Omdat ik alsnog een toevoeging wil maken in de richting van het juist wél gebruik maken van een aparte 'count'-veld:

Polderdijk schreef op 06 april 2004 @ 09:48:
[...]

Oke, dan gaan we dat doen

Ik was er zelf al een beetje 'bang' voor dat dit idd beter zou zijn, maar idd kan je ook de verkopen van laatste x dagen er nog bijzetten (voor mijzelf dan natuurlijk!).

Je kunt natuurlijk een splitsing maken van statistische informatie die vaak opgevraagd wordt en die in een redundante veld opslaan. Andere info, zoals 'verkopen laatste x dagen' kun je altijd voor jezelf uit de originele tabel trekken, ook al duurt het dan wat langer.

Polderdijk schreef op 06 april 2004 @ 09:48:
En mijn laatste vraag over Applications?

Ik denk dat je dan nog beter gebruik kan maken van een stukje transact-sql in de job scheduler (sql server agent, onder Management in de enterprise manager)