Bericht 1 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | John Kopmels (Sysop) | Datum | : | 15-05-2004 |
| Aan | : | All | MsgID | : | 1451.1 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
Hallo,
Omdat er op dit forum minstens n expert op dit gebied is :-)
M.b.t. het omzetten bestaande applicaties en opnieuw ont-
wikkelen in MSDE wil ik graag wat tips/aanwijzingen hoe het
beste de server,database,connections en users in te richten
om niet later tegen grote problemen/wijzigingen aan te lopen
Tools:
Frontend : Access 2002 (adp)
Provider : SQL OLEDB
Interface : ADO
Database : MSDE met SQLserver Admin tools
Installatie: Mixed mode
Doel:
databases met Gemeentelijke gegevens OZB raadplegen en muteren
Per Gemeente 1 database waarin behalve de initile aanlevering
records bijgemaakt worden voor meerdere tijdvakken en mutaties
voor identificatie van tijdvakken is er een ID veld
initile levering (ID 1) wordt reglematig vervangen en niet
gemuteerd maar alleen geraadpleegt, deze records worden dus
periodiek uit de database verwijderd en opnieuw toegevoegd
dus simplistisch voorgesteld :
ID Objectnr Objectadres Tijdvak Verdere gegevens
1 12345678901 Hier 13 Nergens 19990101 abcdefg122345500
2 12345678901 Hier 13 Nergens 20010101 dertyyu329643439
3 12345678901 Hier 13 Nergens 20030101 vrtyuew462379301Eerst wordt een desktop applicatie gemaakt waarbij deze parallel
wordt nagebouwd als webapplicatie die op zelfde database draait
(waarover geen vragen maar wel mee te nemen in overwegingen)
Vragen:
Wat is de eenvoudigste maar goede opzet in SQLserver hiervoor
(vooral m.b.t. de delete/appends van nieuwe initile gegevens)
Welke inlog het beste gebruiken (user/sa) bij ontwikkelen/testen
Moet de server een Named Instance zijn (nu local en default naam)
Andere belangrijke settings/tips ?
Het meeste werk wordt gedaan in een form waarin een aantal subforms
maar steeds gaat het over 1 Wozobjectnummer wat met een verschillend
ID meerdere keren kan voorkomen dus kleine recordsets ca 2-5 records
In een eerste opzet doe ik dat met voor elke datasource een aparte
Stored Procedure met als parameter het Wozobjectnummer (opgeslagen
in een Public Variabele) deze Public wordt steeds opgehaald door een
item uit een combobox te kiezen, wat goed werkt, mijn vraag is:
- is een Stored Procedurede 'goedkoopste' manier (netwerkverkeer)
- en hoe 'duur' is een View t.o.v. een Stored Procedurede
- de rowsource van de comboboxen baseer ik het beste op ?
Voorlopig laatste vraag:
Er zit wat redundant informatie in de database zoals oa NAW gegevens
Hierop wordt niet gemuteerd, nu is de database eenvoudig te norma-
liseren maar nadelen zijn er ook zoals: meer Views maken, onderhoud
bij wijzigen maar vooral het steeds inlezen en terugleveren van de
data wat zonder bewerking veel eenvoudiger is, in hoeverre zou de
ca 20% meer nodige opslag capaciteit de performance erg benvloeden?
Zelf begin ik (na jaren van veel normaliseren) te neigen naar minder
normaliseren vanwege soms eenvoud en soms zelfs snellere benadering
b.v.b. mijn dank voor het meedenken/antwoorden
groetjes --John Kopmels
--john kopmels
(Sysop)
Bericht 2 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 17-05-2004 |
| Aan | : | John Kopmels (Sysop) | MsgID | : | 1451.2 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
Hoi John,
> Omdat er op dit forum minstens n expert op dit gebied is :-)
Bedoelt u mij?
Ik hoop dat ik je kan helpen, maar ik ben vooral "expert" in het gebruiken van MSDE/SQL Server (tabellen en views ontwerpen, SQL schrijven, triggers en stored procedures maken), ik weet een beetje van performance (indexen aanpassen en zo), maar erg weinig van inrichting, vrees ik.
Maar dat wat ik weet zal ik met je delen. :-)
> Tools:
> Frontend : Access 2002 (adp)
> Provider : SQL OLEDB
> Interface : ADO
Dit stukje is denk ik nog iets emer jouw specialiteit dan de mijne. Ik weet dat er verschillende interfaces tussen Access en SQL Server bestaan, maar ik kan nooit onthouden welke nu welke is en welke ik gebruik, ADO of DAO.
> Database : MSDE met SQLserver Admin tools
Kan een goede keuze zijn (want is gratis), mits je kunt leven met de beperkingen. De "workload governor" van MSDE is ingesteld op 8 gelijktijdige "workloads". Drie daarvan gaan op aan interne processen van SQL Server, de rest is dus beschikbaar. Kom je daarboven, dan wordt de handrem van de performance flink aangetrokken (dus heel incidenteel een overschrijding hoeft nog niet direct het einde te betekenen).
Let op: het gaat dus NIET om maximaal 5 gebruikers, of maximaal 5 verschillende gebruikers. En het gaat ook niet om maximaal 5 connecties (ik heb in elk geval in het verleden vaak gezien dat Access -afhankelijk van hoe het frontend precies gecodeerd was- 2 of meer connecties open houdt, maar die zijn dan wel "idle".
En gebruiker kan meer dan 5 workloads starten, door asynchroon meerdere queries naar de server te sturen. Veel gebruikelijker is het omgekeerde scenario: tien mensen hebben de database "in gebruik", maar omdat ze de meeste tijd doorbrengen met bekijken en invoeren van gegevens op het frontend hoeft MSDE op dat moment voor hun niets te doen. Alleen als er meerdere mensen tegelijk een actie uitvoeren waardoor MSDE aan het werk moet loop je het risico dat je de 5 workloads gaat overschrijden.
> Installatie: Mixed mode
Lijkt me een goed keuze. Zorg wel dat userid "sa" een moeilijk te raden wachtwoord heeft. Alleen als je heel zeker weet dat alle huidige n toekomstige gebruikers altijd via Windows authentication kunnen inloggen, kun je overwegen dit in te stellen op Windows Authentication Mode. Dan wordt er berhaupt geen sa userid gemaakt en is de kans dat dit wachtwoord gekraakt wordt helemaal gelijk aan nul.
Maar als je ooit zoiets als internet-toegang zou overwegen, dan doe je er beter aan voor mixed mode te gaan. (Overigens is de authentication mode later eenvoudig te veranderen via Enterprise Manager).
Oh, ik zie net dat je inderdaad ook een webapplicatie wilt maken, dus dan bijft dit inderdaad de beste keuze.
Wat ik in dit rijtje mis is de default character set en de collation order. Dit zijn belangrijke keuzes. Sinds SQL Server 2000 is het weliswaar mogelijk om de standaard keuze per database of zelfs per kolom te vervangen, maar het is handiger om hier direct over na te denken. De character set bepaalt welke tekens worden toegekend aan ASCII 128-255; de collation order bepaalt hoe vergelijkingen en sortering worden gedaan. De meeste keuzes spreken voor zich (wel niet case sensitive, accent sensitive, etc). De keuze voor een "binary sort order" betekent dat alleen naar de ASCII code wordt gekeken. Dit is het snelste, maar het betekent wel dat Jan ongelijk is aan jan en dat bij sorteren van teksten alle hoofdletters voor de kleine letters komen
> Doel: databases met Gemeentelijke gegevens OZB raadplegen en muteren
>
> Per Gemeente 1 database waarin behalve de initile aanlevering
> records bijgemaakt worden voor meerdere tijdvakken en mutaties
Als je de databases van alle gemeentes in n MSDE wilt stoppen, dan denk ik dat je toch tegen die 5 workloads gaat aanlopen (ik neem althans aan dat alle gemeentes ook willen kunnen raadplegen). Hoeveel gemeentes heeft Nederland eigenlijk? Per instantie van MSDE/SQL Server kun je "slechts" 32767 databases installeren.
Overigens vraag ik me af waarom je niet gewoon kiest voor n database met alle gegevens bij elkaar.
Als je bedoelt dat er voor elke gemeente ergens een MSDE op een server van die gemeente wordt genstalleerd, dan is het een andere zaak. En dan is ook meteen duidelijk waarom je per gemeente een aparte database hebt :-)
> voor identificatie van tijdvakken is er een ID veld
Wat is er mis met ingangsdatum van het tijdvak als primaire sleutel?
> initile levering (ID 1) wordt reglematig vervangen en niet
> gemuteerd maar alleen geraadpleegt, deze records worden dus
> periodiek uit de database verwijderd en opnieuw toegevoegd
> dus simplistisch voorgesteld :
>
> ID Objectnr Objectadres Tijdvak Verdere gegevens
> 1 12345678901 Hier 13 Nergens 19990101 abcdefg122345500
> 2 12345678901 Hier 13 Nergens 20010101 dertyyu329643439
> 3 12345678901 Hier 13 Nergens 20030101 vrtyuew462379301
Ik hoef je vast niet te vertellen dat deze gegevens niet genormaliseerd zijn, maar daar kom ik verderop nog wel even op terug.
Verder begrijp ik je niet helemaal. Bedoel je dat de gegevens van het tijdvak 19990101 (ik neem aan dat dit de begindatum van het tijdvak is) periodiek worden vervangen en niet worden gewijzigd, maar dat de gegevens van de latere tijdvakken door de gemeente worden ingevoerd en eventueel gewijzigd?
[More]
Bericht 3 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 17-05-2004 |
| Aan | : | Hugo Kornelis | MsgID | : | 1451.3 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
[Continued]
> Eerst wordt een desktop applicatie gemaakt waarbij deze parallel
> wordt nagebouwd als webapplicatie die op zelfde database draait
> (waarover geen vragen maar wel mee te nemen in overwegingen)
Ok.
> Vragen:
> Wat is de eenvoudigste maar goede opzet in SQLserver hiervoor
> (vooral m.b.t. de delete/appends van nieuwe initile gegevens)
Als ALLE gegevens uit een tabel moeten worden vervangen en dit kan gebeuren op een moment dat de database niet gebruikt wordt, dan kun je de bestaande inhoud heel snel vervangen met TRUNCATE TABLE. Dit komt overeen met DELETE FROM TABLE zonder WHERE-clause (dus alle rijen), maar er wordt geen logging toegepast. Mocht de stroom uitvallen, dan kan de inhoud niet hersteld worden (maar als je toch alles kwijt wilde is dat niet erg). Een alternatief voor TRUNCATE is de tabel verwijderen (DROP TABLE) en weer maken (CREATE TABLE).
Beide opties zijn niet mogelijk als je een deel van de rijen wilt bewaren. Je moet er ook rekening mee houden dat in beide gevallen eventuele triggers niet worden uitgevoerd (na DROP/CREATE moet je ze zelfs opnieuw maken). In dat geval is DELETE [FROM] TABLE ... WHERE ... de enige optie.
Ook voor het toevoegen kun je naast de standaard INSERT overwegen om de niet gelogde versie BULK INSERT te gebruiken, of het command-line tool bcp (die in wezen hetzelfde doet). Beide opties halen de gegevens uit een bestand en gebruiken die gegevens om een tabel te vullen. Omdat er geen log wordt bijgehouden is het niet mogelijk na een abnormaal einde de data te herstellen en bovendien worden geen triggers uitgevoerd. Ik meen (maar weet dat niet meer helemaal zeker) dat indexen voor zo'n actie moeten worden verwijderd en daarna weer hersteld moeten worden, maar als je dit zeker wilt weten kun je het beter nakijken in Books Online (of testen).
> Welke inlog het beste gebruiken (user/sa) bij ontwikkelen/testen
Als je zelf ontwikkeld is er niet zoveel mis met sa gebruiken. Net zoals je op je eigen coomputer c.q. je eigen netwerk rustig voor al je werk kunt inloggen met het Administrator account. Zelf doe ik dat niet - ik heb op mijn PC naast Administrator een userid Hugo, met iets minder bevoegdheden, en op dezelfde manier werk ik ook in SQL Server niet als sa. Dat betekent dat ik in elk geval voor de meest schadelijke acties nog even extra moet nadenken...
> Moet de server een Named Instance zijn (nu local en default naam)
Heb ik zelf nooit gebruikt. Een Named Instance is nodig als je een tweede instance van SQL Server (of MSDE) op dezelfde machine wilt installeren, anders hoeft het niet. Ik denk dat Named Instances vooral worden gebruikt voor applicaties die MSDE installeren (omdat ze dat zelf nodig hebben) en geen roblemen willen krijgen met een eventueel reeds op dezelfde server genstalleerde andere instantie van MSDE of SQL Server (dus wellicht in jouw geval erg interessant, vooral als je een installer met je applicatie meelevert die MSDE mee-installeert zonder dat de gebruiker dat ziet. Een ander alternatief, dat ook vaker wordt gebruikt, is MSDE installeren als dat er nog niet is en anders een "eigen" database op de bestaande SQL Server of MSDE toe te voegen)
> Andere belangrijke settings/tips ?
Fijn, die open vragen. :-))
Ik zou in elk geval nog even nadenken over de accounts die je gebruikt voor SQL Server. Als je de local system account gebruikt heb je als nadeel dat je geen toegang tot netwerken hebt. Daarom wordt doorgaans aangeraden een speciaal account te maken voor SQL Server en hetzelfde of een ander specifiek account voor Agent. Hoe dat met de SQL Mail service zit weet ik niet, want die heb ik nog nooit gebruikt.
Let goed op welke autorisaties je toekent aan de user die gebruikt wordt om de SQL Server service te draaien. Er zit in SQL Server een stored procedure die een commando naar het operating systeem stuurt (xp_cmdshell). Dat commando wordt dan uitgevoerd vanuit de security context van het userid dat de SQL Server service uitvoert. Als dat userid bevoegd is de harde schijf van de server te formatteren en Joop heeft execute permissie voor xp_cmdshell, dan kun je maar beter zorgen dat Joop f dit niet weet, f niet al te boos op jou wordt....
Overigens is standaard de execute permissie voor xp_cmdshell alleen toegekend aan gebruikers in de sysadmin rol.
Een tweede tip: denk goed na over de backup/restore strategie. Hoe belangrijk is het dat je tot op de seconde van de crash alles kunt herstellen? SQL Server kan dat, maar dat heeft wel een prijs. In Books Online staat veel meer informatie over dit onderwerp dan ik hier kan geven, dus ik raad je aan die hoofdstukken door te nemen. Heb je dan nog vragen, dan zal ik proberen die te beantwoorden.
> Het meeste werk wordt gedaan in een form waarin een aantal subforms
> maar steeds gaat het over 1 Wozobjectnummer wat met een verschillend
> ID meerdere keren kan voorkomen dus kleine recordsets ca 2-5 records
>
> In een eerste opzet doe ik dat met voor elke datasource een aparte
> Stored Procedure met als parameter het Wozobjectnummer (opgeslagen
> in een Public Variabele) deze Public wordt steeds opgehaald door een
> item uit een combobox te kiezen, wat goed werkt, mijn vraag is:
>
> - is een Stored Procedurede 'goedkoopste' manier (netwerkverkeer)
> - en hoe 'duur' is een View t.o.v. een Stored Procedurede
Als je een aantal rijen wilt selecteren op basis van een bepaald objectnummer, dan heb je niets aan een view. Je kunt kiezen uit een stored procedure of een SELECT statement. Het SELECT statement zou je in je frontend kunnen opbouwen en dan naar de server sturen; dit moet er dan ongeveer uitzien als "SELECT kolom1, kolom2, kolom3 FROM tabelnaam WHERE Objectnr = 12345678901" (de constante waarde is dan ingevuld door het frontend). Kies je voor een stored procedure, dan maak je die zo:
CREATE PROC HaalObject (@Objectnr int)
AS
SELECT kolom1, kolom2, kolom3
FROM tabelnaam
WHERE Objectnr = @Objectnr
En dan moet je vanuit de frontend naar de server sturen: "EXEC HaalObject 12345678901".
Voor de utivoering zijn er tussen deze opties geen relevante verschillen. Voor het netwerkverkeer is het enige verschil dat het tweede commando iets minder tekens bevat - maar dat is vast niet wat jij bedoelt :-))
Wat je in elk geval net moet doen, is de selectie uitvoeren als een Jet query. Dan moet Access namelijk in het ergste geval de gehele tabel over het netwerk ophalen om zelf de selectie te kunnen doen (wellicht is er onder de motorkap wel iets geoptimaliseerd, maar ik zou er niet op vertrouwen).
Zorg verder in elk geval voor een index op objectnummer. Ik zou persoonlijk de hele ID kolom eruit laten en de primaire sleutel definiren op de combinatie van objectnummer en ingangsdatum-tijdvak. Doe je dat in die volgorde, dan kan de index die voor die primaire sleutel wordt gemaakt ook meteen voor deze query gebruikt worden. Wellicht dat voor andere queries de omgekeerde volgorde handiger is (bv het selecteren van alle rijen met tijdvak 19990101).
[More]
Bericht 4 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 17-05-2004 |
| Aan | : | Hugo Kornelis | MsgID | : | 1451.4 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
[Continued]
> - de rowsource van de comboboxen baseer ik het beste op ?
Als de verzameling bestaande Woznummers gedurende een dag niet wijzigt, dan is het denk ik het snelst om tijdens het starten van het frontend een locale tabel te maken en die te vullen met de uitvoer van "SELECT DISTINCT Objectnr FROM tabelnaam" (als je op de server een aparte tabel met de objecten hebt is dat natuurlijk nog beter). Of die truk ook werkt voor de webapplicatie weet ik niet. Kun je de lijst niet locaal opslaan, dan moet je f de bovenstaande query gebruiken als rowsource, f (wellicht iets snelller) een aparte tabel met alle objectnummers op de server zetten en "SELECT Objectnr FROM Objecten" als rowsource gebruiken.
> Voorlopig laatste vraag:
Phew. <g>
> Er zit wat redundant informatie in de database zoals oa NAW gegevens
>
> Hierop wordt niet gemuteerd, nu is de database eenvoudig te norma-
> liseren maar nadelen zijn er ook zoals: meer Views maken, onderhoud
> bij wijzigen maar vooral het steeds inlezen en terugleveren van de
> data wat zonder bewerking veel eenvoudiger is, in hoeverre zou de
> ca 20% meer nodige opslag capaciteit de performance erg benvloeden?
>
> Zelf begin ik (na jaren van veel normaliseren) te neigen naar minder
> normaliseren vanwege soms eenvoud en soms zelfs snellere benadering
Het antwoord hierop hangt ook af van de onduidelijkheid die ik in het begin aangaf. Worden alle gegevens in de database periodiek vervangen en wordt de inhoud alleen voor raadplegen gebruikt, dan kan denormaliserern inderdaad een grote tijdwinst opleveren. Het voornaamste doel van normaliseren is immers om de consistentie bij updates te behouden.
Als alleen de "oudste" gegevens vast zijn en de rest door de gebruikers wordt toegevoegd/gewijzigd, dan zou ik de NAW-gegevens direct naar een aparte objecten-tabel verbannen. Met een primaire sleutel op objectnummer is de extra actie voor SQL Server om die ene rij op te halen echt te verwaarlozen en je voorkomt een hoop problemen.
Zelfs als dit wel een datawarehouse achtige applicatie is durf ik niet a priori te zeggen of DEZE denormalisatie winst oplevert. Je hebt inderdaad alle gegevens in n tabel. Maar daardoor worden de rijen wel een heel stuk breder. Je moet dus veel vaker fysieke I/Os doen. SQL Server doet I/O's per page van pak 'm beet 8000 bytes. Als er een tiental van die pages in de cache zitten en elke rij is 40 bytes, dan heb je al 20000 rijen in de cache en is bij een directe benadering de kans groter dat de rij uit de cache kan worden gehaald dan wanneer de rij 400 bytes is (en er dus 2000 rijen in de cache zitten).
Als je ook nog de rowsource voor de combobox niet als tabel in Access kunt houden (omdat dat met je web frontend niet kan of omdat er gedurende de dag WOZ-objecten bij kunnen komen of kunnen verdwijnen), dan denk ik dat je zeker een aparte objecten tabel moet maken. Als je mutaties moet verwerken ook. En als dat beide niet het geval is, dan zou ik je aanraden om beide opties te testen - vermoedelijk zul je zelfs dan nog merken dat een aparte objecten tabel in dit geval te prefereren is.
> b.v.b. mijn dank voor het meedenken/antwoorden
Graag gedaan!!
Groetjes, Hugo
Bericht 5 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | John Kopmels (Sysop) | Datum | : | 17-05-2004 |
| Aan | : | Hugo Kornelis | MsgID | : | 1451.5 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
Dag Hugo
Allereerst reuze bedankt voor het uitgebreide antwoord !
het meeste is meteen duidelijk verder inline opmerkingen
-----------------------------------------------------------
>> Omdat er op dit forum minstens n expert op dit gebied is :-)
> Bedoelt u mij?
Ja zeker !
-----------------------------------------------------------
>> Tools:
> Dit stukje is denk ik nog iets meer jouw specialiteit
Was voor de volledigheid en inzicht :-)
-----------------------------------------------------------
>> Database : MSDE met SQLserver Admin tools
> Kan een goede keuze zijn (want is gratis)
> mits je kunt leven met de beperkingen <knip>
De MSDE wordt alleen voor opzetten en tests gebruikt
in produktie kiezen we voor de 'volwassen' SQL server
-----------------------------------------------------------
>> Wat ik in dit rijtje mis is de default character set
en de collation order. Dit zijn belangrijke keuzes.
Goede tip, voorlopig default (bij maken vorige test db) gelaten
maar zal ik zeker naar kijken bij het opzetten van de database
-----------------------------------------------------------
>> Doel: databases met Gemeentelijke gegevens OZB raadplegen en muteren
> Als je de databases van alle gemeentes in n MSDE wilt stoppen
OK (We hebben ca een tiental gemeentes als opdrachtgever)
-----------------------------------------------------------
>> voor identificatie van tijdvakken is er een ID veld
> Wat is er mis met ingangsdatum van het tijdvak als primaire sleutel?
Ook overwogen maar er moet dan wel validatie plaatsvinden op geldige
invoer en ter voorkoming van onnodige tijdvakken, zowel het ID veld
evenals tijdvak zijn beide reeds aanwezig ID 'lijkt' eenvoudiger ...
-----------------------------------------------------------
>> Verder begrijp ik je niet helemaal. Bedoel je dat de gegevens van het
tijdvak 19990101 (ik neem aan dat dit de begindatum van het tijdvak is)
periodiek worden vervangen en niet worden gewijzigd, maar dat de gegevens
van de latere tijdvakken door gemeente worden ingevoerd en event gewijzigd?
Allemaal goed verondersteld :
- Begindatum ja (als voorbeeld dus arbitrair)
- Periodiek vervangen of updaten
- Worden niet gemuteerd
- Later tijdvakken wel zelf invoeren en muteren
-----------------------------------------------------------
>> Wat is de eenvoudigste maar goede opzet in SQLserver hiervoor
>> (vooral m.b.t. de delete/appends van nieuwe initile gegevens)
> <knip optie 1 en 2>
> Beide opties zijn niet mogelijk als je een deel van de rijen wilt bewaren.
Je moet er ook rekening mee houden dat in beide gevallen eventuele triggers
niet worden uitgevoerd (na DROP/CREATE moet je ze zelfs opnieuw maken).
In dat geval is DELETE [FROM] TABLE ... WHERE ... de enige optie.
Deze wordt het dan (incl logging)
-----------------------------------------------------------
>> - is een Stored Procedurede 'goedkoopste' manier (netwerk)
>> - en hoe 'duur' is een View t.o.v. een Stored Procedurede
> Als je een aantal rijen wilt selecteren op basis van een bepaald
objectnummer, dan heb je niets aan een view. Je kunt kiezen uit
een stored procedure of een SELECT statement. Het SELECT statement
zou je in je frontend kunnen opbouwen en dan naar de server sturen
Ik had in eerste test voor de sp optie gekozen wat goed bevalt
btw waarvoor gebruik je specifiek de views dan meestal...?
> Zorg verder in elk geval voor een index op objectnummer.
Ik zou persoonlijk de hele ID kolom eruit laten en de primaire sleutel
definiren op de combinatie van objectnummer en ingangsdatum-tijdvak.
OK (subject voor overleg)
-----------------------------------------------------------
>> Er zit wat redundant informatie in de database zoals oa NAW gegevens
> voornaamste doel van normaliseren is immers
om de consistentie bij updates te behouden.
zo zie ik het ook, de integriteit van de data is
voor mij ook een van de meest belangrijkste reden
De NAW gegevens zijn juist de gegevens die niet gemuteerd *mogen* worden
dus is dit niet van belang, wat meer telt is : weinig onderhoud, snelle
opvraagbaarheid, vooral de frequente uitwisseling van gemuteerde gegevens
> Zelfs als dit wel een datawarehouse achtige applicatie is durf ik niet
a priori te zeggen of DEZE denormalisatie winst oplevert. Je hebt inder
daad alle gegevens in n tabel. Maar daardoor worden de rijen wel een
heel stuk breder. Je moet dus veel vaker fysieke I/Os doen. SQL Server
doet I/O's per page van pak 'm beet 8000 bytes. Als er een tiental van
die pages in de cache zitten en elke rij is 40 bytes dan heb je al 20000
rijen in de cache en is bij een directe benadering de kans groter dat de
rij uit de cache kan worden gehaald dan wanneer de rij 400 bytes is
(en er dus 2000 rijen in de cache zitten). Als je ook nog de rowsource
voor de combobox niet als tabel in Access kunt houden dan denk ik dat je
zeker een aparte objecten tabel moet maken. En als dat beide niet het
geval is, dan zou ik je aanraden om beide opties te testen
OK ook even testen dus, al is het natuurlijk altijd moeilijker in een
testopstelling conclusies te trekken dan in een real-life situatie..
Ik ga al deze informatie delen met 2 collega's en daar onze verdere
ontwerpomgeving op af stemmen, er zullen in later stadium zeker nog
vervolg vragen komen, voor zover nogmaals bedankt, het was heel waardevol!
Groetjes --John
Bericht 6 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 18-05-2004 |
| Aan | : | John Kopmels (Sysop) | MsgID | : | 1451.6 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
Hoi John,
> >> voor identificatie van tijdvakken is er een ID veld
>
> > Wat is er mis met ingangsdatum van het tijdvak als primaire sleutel?
>
> Ook overwogen maar er moet dan wel validatie plaatsvinden op geldige
> invoer en ter voorkoming van onnodige tijdvakken, zowel het ID veld
> evenals tijdvak zijn beide reeds aanwezig ID 'lijkt' eenvoudiger ...
Ook als je de datum niet als sleutel gebruikt is identificatie nog steeds essentieel. En ik denk dat je het hele ID veld wellicht kunt schrappen, maar daar heb ik verderop in mijn originele antwoord al iets over geschreven.
-----------------------------------------------------------
> >> Wat is de eenvoudigste maar goede opzet in SQLserver hiervoor
> >> (vooral m.b.t. de delete/appends van nieuwe initile gegevens)
>
> > <knip optie 1 en 2>
> > Beide opties zijn niet mogelijk als je een deel van de rijen wilt
> bewaren.
> Je moet er ook rekening mee houden dat in beide gevallen eventuele
> triggers niet worden uitgevoerd (na DROP/CREATE moet je ze zelfs opnieuw
> maken). In dat geval is DELETE [FROM] TABLE ... WHERE ... de enige optie.
>
> Deze wordt het dan (incl logging)
Die logging is een onvermijdelijk bijproduct van de strenge integriteitsbewaking van SQL Server. SQL Server is zo ontworpen dat er nooit dataverlies kan optreden. Als een transactie als "compleet" is gemeld aan de frontend, dan blijft'ie altijd behouden, zelfs al zou de stroom slechts een milliseconde later uitvallen (en de gewijzigde data dus nog niet vanuit de cache naar de schijf terug zijn geschreven). En als een transactie nog niet compleet is gemeld op het moment van de stroomuitval, dan wordt'ie na het opnieuw starten van de service geheel ongedaan gemaakt, alsof er niets gebeurd is. De log file speelt een centrale, nee: cruciale rol in dat proces.
Als je kiest voor een "simple" recovery model, dan wordt de logruimte weer vrijgegeven zodra de gewijzigde data fysiek naar de schijf is geschreven. Als je kiest voor een "full" recovery model, dan blijft de log alles bijhouden totdat je een backup maakt van de database en de logfile. Op deze manier is "point-in-time" recovery mogelijk (doordat eerst een backup wordt teruggezet en dan vanuit de logfile alle wijzigingen tot aan het gewenste moment worden nagespeeld), terwijl bij "simple" recovery je na een crash genoegen moet nemen met de stand van zaken van de laatste backup.
Euuuhh ... vroeg je dit eigenlijk?
-----------------------------------------------------------
> >> - is een Stored Procedurede 'goedkoopste' manier (netwerk)
> >> - en hoe 'duur' is een View t.o.v. een Stored Procedurede
>
> > Als je een aantal rijen wilt selecteren op basis van een bepaald
> objectnummer, dan heb je niets aan een view. Je kunt kiezen uit
> een stored procedure of een SELECT statement. Het SELECT statement
> zou je in je frontend kunnen opbouwen en dan naar de server sturen
>
> Ik had in eerste test voor de sp optie gekozen wat goed bevalt
>
> btw waarvoor gebruik je specifiek de views dan meestal...?
Views kunnen vooral een nuttige rol spelen als je eindgebruikers zelf SQL opdrachten mogen/kunnen maken. In dat geval zijn voordelen van views:
* Je kunt een complexe query met verschillende joins als view definiren; de (in het algemeen minder SQL-bedreven) eindgebruikers kunnen dan hun gegevens uit die view halen.
* Je kunt een deel van de kolommen en/of een deel van de rijen die de eindgebruiker niet mag zien buiten de view laten. Een klassiek voorbeeld is natuurlijk de tabel met personeelsgegvens. De chef van een afdeling krijgt geen rechten op die tabel, maar wel op een view die alleen de rijen laat zien van werknemers van "zijn" afdeling en dan nog slechts een deel van de kolommen (bijvoorbeeld niet het salaris).
* Je kunt ook inserts, deletes en updates doen via een view.
De eerste twee voordelen gelden ook voor stored procedures, maar die kun je niet zo makkelijk in SQL gebruiken. Het derde voordeel geldt alleen voor views.
Een mogelijke toepassing van een view in jouw situatie is als je kiest voor een genormaliseerde tabelstructuur, maar de gebruikers willen graag de tabel zien zoals jij hem in jouw post hebt beschreven, dus met de adresgegevens op elke rij (of die structuur blijkt gewoon beter uit te komen voor jouw front-end). In dat geval maak je een view:
CREATE VIEW WozGegevensCompleet
AS
SELECT Objecten.WozObjectnr, Objecten.Adres,
WozGegevens.Ingangsdatum, WozGegevens.WozWaarde, .....
FROM WozGegevens
INNER JOIN Objecten
ON Objecten.WozObjectnr = WozGegevens.WozObjectnr
Vervolgens kun je deze view gebruiken in een query alsof het een tabel is:
SELECT WozObjectnr, Ingangsdatum, WozWaarde
FROM WozGegevensCompleet
WHERE Adres LIKE 'Lindenlaan %'
AND Ingangsdatum > 20030425
-----------------------------------------------------------
> De NAW gegevens zijn juist de gegevens die niet gemuteerd *mogen* worden
> dus is dit niet van belang, wat meer telt is : weinig onderhoud, snelle
> opvraagbaarheid, vooral de frequente uitwisseling van gemuteerde gegevens
Als ik op mijn gevoel afga, dan denk ik dat je op al deze punten wint als je de objectgegevens in een aparte tabel zet. Maar meten is weten, en dat is altijd beter dan een gevoel. Probeer dus een representatieve inhoud in je test database te krijgen die ook groot genoeg is om zinvolle metingen te kunnen doen.
Groetjes, Hugo
Bericht 7 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | John Kopmels (Sysop) | Datum | : | 18-05-2004 |
| Aan | : | Hugo Kornelis | MsgID | : | 1451.7 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
Hoi Hugo
>> Ook als je de datum niet als sleutel gebruikt
is identificatie nog steeds essentieel. En ik
denk dat je het hele ID veld wellicht kunt schrappen
Uiteraard is het zinvol, ID veld zit al in database
de converter maakt deze aan en is in aanleg bedoelt
om meerdere administraties in 1 db te identificeren
alleen gebruiken we dat niet dus ID zit daar al wel
-----------------------------------------------------------
> Als je kiest voor een "simple" recovery model,
> dan wordt de logruimte weer vrijgegeven zodra de
> gewijzigde data fysiek naar de schijf is geschreven.
> Als je kiest voor een "full" recovery model,
> dan blijft de log alles bijhouden totdat je een
> backup maakt van de database en de logfile.
> Euuuhh ... vroeg je dit eigenlijk?
Nog niet maar je bent me voor :-)
Wat zijn de commando's hiervoor in een Stored Procedure
en is het in een View ook mogelijk dit mee te geven ?
-----------------------------------------------------------
> Views kunnen vooral een nuttige rol spelen als je
> eindgebruikers zelf SQL opdrachten mogen/kunnen maken.
> In dat geval zijn voordelen van views:
> * Je kunt een complexe query met verschillende joins als
> view definiren; de (in het algemeen minder SQL-bedreven)
> eindgebruikers kunnen dan hun gegevens uit die view halen.
> * Je kunt een deel van de kolommen en/of een deel van de
> rijen die de eindgebruiker niet mag zien buiten de view laten.
> Een klassiek voorbeeld is natuurlijk de tabel met personeels
> gegvens. De chef van een afdeling krijgt geen rechten op die
> tabel, maar wel op een view die alleen de rijen laat zien van
> werknemers van "zijn" afdeling en dan nog slechts een deel van
> de kolommen (bijvoorbeeld niet het salaris).
> * Je kunt ook inserts, deletes en updates doen via een view.
> De eerste twee voordelen gelden ook voor stored procedures
> maar die kun je niet zo makkelijk in SQL gebruiken.
> Het derde voordeel geldt alleen voor views.
wist niet dat je geen inserts, deletes en updates in een SP
> Een mogelijke toepassing van een view in jouw situatie is
> CREATE VIEW WozGegevensCompleet
> Vervolgens kun je deze view gebruiken in een query alsof het een tabel is:
> SELECT WozObjectnr, Ingangsdatum, WozWaarde
> FROM WozGegevensCompleet
> WHERE Adres LIKE 'Lindenlaan %'
> AND Ingangsdatum > 20030425
nuttige info, kan je in een SP een View aanroepen ?
het lijkt erop dat je dus een benoemd object (SP View)
in alle situaties aan kan roepen gewoon bij naam ?
overigens zie ik dat je de term Query nog steeds gebruikt
of noem je een vraagstelling in T-SQL altijd een Query
de View wordt gemaakt op de server, dus je trekt alleen
het resultaat over het lijntje h, hoe is dat met queries
die worden lokaal geprocessed dus eerst alles ophalen en
dan uitvoeren en dus duurder ?
Groetjes -- John
Bericht 8 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 18-05-2004 |
| Aan | : | John Kopmels (Sysop) | MsgID | : | 1451.8 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
Hoi John,
> > Als je kiest voor een "simple" recovery model,
> > dan wordt de logruimte weer vrijgegeven zodra de
> > gewijzigde data fysiek naar de schijf is geschreven.
>
> > Als je kiest voor een "full" recovery model,
> > dan blijft de log alles bijhouden totdat je een
> > backup maakt van de database en de logfile.
>
> > Euuuhh ... vroeg je dit eigenlijk?
>
> Nog niet maar je bent me voor :-)
>
> Wat zijn de commando's hiervoor in een Stored Procedure
> en is het in een View ook mogelijk dit mee te geven ?
Het recovery model wordt ingesteld voor de gehele database. Dat kan je vast wel doen via een SQL-opdracht of een aanroep van een standaard meegeleverde stored procedure, maar het is veel eenvoudiger om dit gewoon vanuit Enterprise Manager in te stellen.
Op basis van het ingestelde recovery model bepaalt SQL Server dan of de inhoud van de log kan worden geschoond na elk checkpoint (dat is als alle gewijzigde I/O buffers naar de harde schijf worden teruggeschreven), of dat de log blijft groeien tot je een backup hebt gemaakt.
Het zou niet werken als je per SQL opdracht het recovery model kan veranderen. Een "full" recovery model kan per definitie alleen maar werken als ALLE wijzigingen sinds de laatste backup in de log staan. Als er maar n wijziging niet gelogd is, heb je ook niets meer aan alle andere wijzigingen in de log.
-----------------------------------------------------------
> wist niet dat je geen inserts, deletes en updates in een SP
Oeps - even een misverstandje rechtzetten, want dat bedoelde ik niet.
In een SP kun je alles doen wat je wilt. Tot en met het aanmaken van databases etcetera, dus zeker ook gewone inserts, deletes en updates.
Wat ik bedoelde is dat een view flexibel is - je kunt SELECT ... FROM viewnaam doen (al dan niet met WHERE), maar je kunt ook UPDATE viewnaam SET
.. doen, of DELETE view WHERE ..., INSERT INTO view (...) VALUES(...) of INSERT INTO view(...) SELECT ... Wat dat betreft zijn views dus te vergelijken met queries in Access, die kunnen (afhankelijk van hoe ze zijn opgebouwd) ook updateble zijn. In SQL Server heb je via speciale triggers dan nog een extra mogelijkheid om ook een insert, delete of update op een niet-updateble view toch te kunnen verwerken, maar dat voert op dit moment wellicht wat te ver.
Met een SP kan dat niet. Een SP die is ontwikkeld om een selectie van de gegevens te tonen kun je ook alleen gebruiken om die gegevens te tonen. Zie je dan een foutje en wil je die wijzigen, dan moet je dat hetzij direct op de tabel doen (als je weet uit welke tabel de getoonde waarde afkomstig is en rechten op die tabel hebt), of de update verrichten via een andere SP (die dan specifiek voor die update-actie is geschreven). Wat dat betreft heeft een SP dus veel weg van een module in Access.
Met SP's leg je de SQL gebruikende eindgebruiker dus meer aan banden dan met views.
> > Een mogelijke toepassing van een view in jouw situatie is
>
> > CREATE VIEW WozGegevensCompleet
>
> > Vervolgens kun je deze view gebruiken in een query alsof het een tabel
> is:
>
> > SELECT WozObjectnr, Ingangsdatum, WozWaarde
> > FROM WozGegevensCompleet
> > WHERE Adres LIKE 'Lindenlaan %'
> > AND Ingangsdatum > 20030425
>
>
> nuttige info, kan je in een SP een View aanroepen ?
Je kunt een view overal gebruiken waar je een tabel mag gebruiken. Dus ook in een SP. Of in de definitie van een andere view.
> het lijkt erop dat je dus een benoemd object (SP View)
> in alle situaties aan kan roepen gewoon bij naam ?
Niet helemaal.
Een view gedraagt zich als een tabel. Voor de eindgebruiker is het niet relevant (en in feite zelfs niet zichtbaar) of iets nu een tabel of een view is. Je kunt een view dus overal gebruiken waar ook een tabel mag worden gebruikt (met uitzondering van de CREATE TABLE, TRUNCATE TABLE en DROP TABLE opdrachten, uiteraard). Maar niet op andere plaatsen.
Om een stored procedure moet je een EXECUTE opdracht uitvoeren. Als de stored procedure n of meer SELECT (of FETCH) opdrachten uitvoert, dan worden er n of meer result sets naar de client teruggestuurd. Als de stored procedure geen SELECT of FETCH uitvoert is er geen andere terugmelding dan eventuele foutmeldingen en de returncode. updates, inserts en deletes worden dus in stilte uitgevoerd.
Een bizarre uitzondering is dat je een EXECUTE opdracht ook in een INSERT opdracht kunt plaatsen. In dat geval wordt de stored procedure uitgevoerd en de result set die door de SP wordt opgeleverd wordt niet naar de client gestuurd, maar in de tabel geplaatst. Dit vereist uiteraard wel dat het aantal kolommen en de datatypes van de result set van de SP compatible zijn met de tabel waar de INSERT betrekking op heeft.
> overigens zie ik dat je de term Query nog steeds gebruikt
> of noem je een vraagstelling in T-SQL altijd een Query
SQL staat voor Structured Query Language. Elke opdracht in SQL wordt dus een query genoemd, ook opdrachten die gegevens wijzigen (insert, update, delete). Omdat dit voor mensen met een Access achtergrond verwarrend kan zijn heb ik geprobeerd de term query hier alleen te gebruiken als ik een Access query bedoel, maar kennelijk heb ik 'm er toch af en toe doorheen laten glippen.
> de View wordt gemaakt op de server, dus je trekt alleen
> het resultaat over het lijntje h
Klopt. En hetzelfde geldt voor het aanroepen van een stored procedure die een result set met de gevraagde gegevens oplevert.
> , hoe is dat met queries
> die worden lokaal geprocessed dus eerst alles ophalen en
> dan uitvoeren en dus duurder ?
Als je Access queries bedoelt is ook hier het antwoord ja. Maar je kunt je queries ook definiren als pass-through query; in dat geval wordt de tekst van de query naar de server gestuurd en het resultaat getooond. Let er dan wel op dat je moet overschakelen van de Jet-SQL syntax op de syntax van SQL Server (ANSI compliant, met nog een flink aantal Transact-SQL constructies (sommige voor backwards compatibility, andere om SQL Server een streepje voor te geven op de concurrentie))
Ik kan me situaties voorstellen dat een Access query goedkoper is dan een view, stored procedure of pass-through query, maar alleen in heel uitzonderlijke situaties. Denk aan een CROSS JOIN (volledig carthesisch product van twee tabellen, waarbij het resultaat meer is dan de som der delen) of aan een heel rekenintensieve query op een toch al overbelaste server, terwijl de CPU van de eindgebruiker zich suf zit te vervelen.
Groetjes, Hugo
Bericht 9 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | John Kopmels (Sysop) | Datum | : | 19-05-2004 |
| Aan | : | Hugo Kornelis | MsgID | : | 1451.9 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
Hoi Hugo
> Het recovery model wordt ingesteld voor de gehele database.
> Het zou niet werken als je per SQL opdracht het recovery
> model kan veranderen. Een "full" recovery model kan per
> definitie alleen maar werken als ALLE wijzigingen sinds de
> laatste backup in de log staan.
ok duidelijk, heb je een (heel ruwe) indicatie van de grootte
van een log bestand (x% van de database) bij b.v. dagbackup
-----------------------------------------------------------
> In een SP kun je alles doen wat je wilt. Tot en met het aanmaken
> van databases etc dus zeker ook gewone inserts, deletes en updates.
> Wat ik bedoelde is dat een view flexibel is - je kunt <knip>
> Wat dat betreft zijn views dus te vergelijken met queries in Access
> die kunnen (afhankelijk van hoe ze zijn opgebouwd) ook updateble zijn
> Met een SP kan dat niet. Een SP die is ontwikkeld om een selectie van
> de gegevens te tonen kun je ook alleen gebruiken om die gegevens te tonen.
> Zie je dan een foutje en wil je die wijzigen, dan moet je dat hetzij direct
> op de tabel doen (als je weet uit welke tabel de getoonde waarde afkomstig
> is en rechten op die tabel hebt), of de update verrichten via een andere
> SP (die dan specifiek voor die update-actie is geschreven).
> Wat dat betreft heeft een SP dus veel weg van een module in Access.
> Met SP's leg je de SQL eindgebruiker dus meer aan banden dan met views.
ook duidelijk(er)
>> nuttige info, kan je in een SP een View aanroepen ?
> Je kunt een view overal gebruiken waar je een tabel mag gebruiken.
> Dus ook in een SP. Of in de definitie van een andere view.
OK
>> het lijkt erop dat je dus een benoemd object (SP View)
>> in alle situaties aan kan roepen gewoon bij naam ?
> Niet helemaal. Een view gedraagt zich als een tabel.
> Voor de eindgebruiker is het niet relevant (en in feite
> zelfs niet zichtbaar) of iets nu een tabel of een view is.
> Je kunt een view dus overal gebruiken waar ook een tabel
> mag worden gebruikt (met uitzondering van de CREATE TABLE,
> TRUNCATE TABLE en DROP TABLE opdrachten, uiteraard).
> Om een stored procedure moet je een EXECUTE opdracht uitvoeren.
> Als de sp n of meer SELECT (of FETCH) opdrachten uitvoert,
> dan worden er n of meer result sets naar de client teruggestuurd.
> Als de stored procedure geen SELECT of FETCH uitvoert is er geen
> andere terugmelding dan eventuele foutmeldingen en de returncode.
> updates, inserts en deletes worden dus in stilte uitgevoerd.
frappante overeenkomst met db.Execute op de JET engine
alleen kan die zelfs geen return waarde geven
> Een bizarre uitzondering is dat je een EXECUTE opdracht ook
> in een INSERT opdracht kunt plaatsen. In dat geval wordt de
> stored procedure uitgevoerd en de result set die door de SP
> wordt opgeleverd wordt niet naar de client gestuurd, maar in
> de tabel geplaatst. Dit vereist uiteraard wel dat het aantal
> kolommen en de datatypes van de result set van de SP compatible
> zijn met de tabel waar de INSERT betrekking op heeft.
OK
>> overigens zie ik dat je de term Query nog steeds gebruikt
>> of noem je een vraagstelling in T-SQL altijd een Query
> SQL staat voor Structured Query Language. Elke opdracht in
> SQL wordt dus een query genoemd, ook opdrachten die gegevens
> wijzigen (insert, update, delete). Omdat dit voor mensen met
> een Access achtergrond verwarrend kan zijn heb ik geprobeerd de
> term query hier alleen te gebruiken als ik een Access query bedoel
> maar kennelijk heb ik 'm er toch af en toe doorheen laten glippen.
OK overigens kan je wat mij betreft de term query gebruiken
ik wilde alleen weten wat er precies mee bedoelt wordt :-)
>> de View wordt gemaakt op de server, dus je trekt alleen
>> het resultaat over het lijntje h
> Klopt. En hetzelfde geldt voor het aanroepen van een stored
> procedure die een result set met de gevraagde gegevens oplevert
OK
>> hoe is dat met queries> die worden lokaal geprocessed
>> dus eerst alles ophalen en dan uitvoeren en dus duurder ?
> Als je Access queries bedoelt is ook hier het antwoord ja.
> Maar je kunt je queries ook definiren als pass-through query
<knip>
OK
en wederom bedankt voor de uitvoerige uitleg !
groetjes --John
Bericht 10 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 19-05-2004 |
| Aan | : | John Kopmels (Sysop) | MsgID | : | 1451.10 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
Hoi John,
> > Het recovery model wordt ingesteld voor de gehele database.
> > Het zou niet werken als je per SQL opdracht het recovery
> > model kan veranderen. Een "full" recovery model kan per
> > definitie alleen maar werken als ALLE wijzigingen sinds de
> > laatste backup in de log staan.
>
> ok duidelijk, heb je een (heel ruwe) indicatie van de grootte
> van een log bestand (x% van de database) bij b.v. dagbackup
Nee. Om te beginnen omdat ik daar zelf nooit op gelet heb en er ook geen informatie over heb kunnen vinden. Maar ook omdat hier geen algemene richtlijn voor te geven is.
Om te beginnen hangt het af van het recovery model. Bij de keuze voor "simple" wordt de grootte van de log min of meer bepaald door de "grootste" (in log-termen) transactie die je uitvoert; bij de keuze voor "full" door het totaal van alle transacties tussen twee backups.
En verder hangt het af van de frequentie en omvang van de wijzigingen. De informatie in de log is voldoende om achteraf alle wijzigingen te kunnen reconstrueren, zowel om zaken ongedaan te maken (rollback) als om zaken nog eens over te doen (roll forward). Een voor de hand liggende manier is om bij elke wijziging een before en een after image op te slaan. Ik meen echter ergens te hebben gelezen dat er ook andere technieken kunnen worden toegepast.
In elk geval is het bij full recovery model zo dat hoe hoger de frequentie van wijzigingen en hoe groter de omvang van die wijzigingen is, des te groter zal de logfile worden. In principe kan een log-file zelfs vele malen groter zijn dan de database zelf. (Extreem voorbeeld: voer DELETE FROM tabel uit zonder WHERE-clause op alle tabellen; de database zelf is dan tot vrijwel niets gekrompen, maar de logfile zal minimaal zo groot zijn als de database was voordat je met die deletes begon - en vermoedelijk zelfs groter).
Ik hoop dat ik je met deze algemene richtlijnen een stukje de goede kant op heb kunnen helpen. Voor de definitieve antwoorden helpt alleen testen.
Groetjes, Hugo
Bericht 11 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | John Kopmels (Sysop) | Datum | : | 21-05-2004 |
| Aan | : | Hugo Kornelis | MsgID | : | 1451.11 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
Hoi Hugo
>> een (heel ruwe) indicatie van de grootte van een log bestand
<knip>
> Ik hoop dat ik je met deze algemene richtlijnen
> een stukje de goede kant op heb kunnen helpen.
> Voor de definitieve antwoorden helpt alleen testen.
Ok bedankt voldoet zo'n beetje aan het al verwachte scenario
Voorlopig gaan we
- starten met een protoype in Access97
(makkelijke verplaatsbaar en UI simpel 2 porteren naar 2002)
- deze overzetten in een Access 2002 ADP
(uiteindelijke desktop applicatie)
- webbased bouwen in VB.net
(uiteindelijke web applicatie)
Tijdens de laatste 2 zal ik nog regelmatig met gerichte vragen
terugkomen in een nieuw draadje hopelijk zie ik je dan weer :-)
Groetjes -John
Bericht 12 van 12NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 22-05-2004 |
| Aan | : | John Kopmels (Sysop) | MsgID | : | 1451.12 |
| Onderwerp | : | SQLserver inrichten | Forum | : | ws-nlcomputer |
Hoi John,
> Tijdens de laatste 2 zal ik nog regelmatig met gerichte vragen
> terugkomen in een nieuw draadje hopelijk zie ik je dan weer :-)
Als je zorgt dat "SQL Server" in het onderwerp staat, dan mag je ervan uitgaan dat ik de thread zal lezen. En als ik onverhoopt toch niet reageer, stuur dan eventueel nog even een mailtje, voor het geval ik 'm over het hoofd heb gezien. Je hebt mijn e-mail adres.
Groetjes, Hugo
