controle optimaliseren/verbeteren database

Status
Niet open voor verdere reacties.
R

remcop1989

Gebruiker
Lid geworden
29 mrt 2012
Berichten
492
Ik heb mijn database nu zoals ik hem wil wat invoer van gegevens betreft.

Voordat ik verderga met de output die hij moet geven zou ik willen vragen of er iemand is die mijn database wil nakijken en mogelijk optimaliseren/verbeteren? Ik heb hem dan wel deels met hulp van dit forum opgebouwd (waarvoor nogmaals dank), maar gezien ik een beginner ben kan ik me voorstellen dat e.e.a. nog te verbeteren/optimaliseren is.:o

Bij voorbaat dank aan degene die hiertoe bereid is :):rolleyes::thumb:
 

Bijlagen

Laatst bewerkt:
Remcop1989,

Ik kan je bestanden niet uitpakken, kun je het als een bestand versturen?

Veel Succes.
 
Het is 1,35MB groot (te groot dus voor hier) en kan hier geen MDB posten helaas.......is er een andere mogelijkheid?
 
Remco,

Het spijt me maar ik krijg nog steeds de melding dat het bestand niet geopend kan worden.
"Onbekende database indeling".
Sorry ik kan hier verder niets meer mee.

Veel Succes.
 
Hij is gemaakt in Access 2010. Wellicht dat daar het probleem ligt?
Gebruikt u Access 2003?
 
Daar heeft het inderdaad mee te maken kom ik nu achter.

Ik heb het gebouwd in Access 2010 en daar zijn zaken in gebruikt die niet in 2003 te gebruiken zijn.
Levert ook een probleem op hier intern gezien niet iedereen 2003 heeft.

Damn.
 
Remco,

Ik maak gebruik van Access 2007 en dat blijkt inderdaad problemen op te leveren onder bepaalde omschandigheden.
Kun je het bestand converteren naar Access 2003 en deze naar me toesturen. Deze kan ik waarschijnlijk ook bekijken.
Een ander alternatief is de databasedocumentatie (onder hulpmiddelen voor database) te exporteren en naar mij toe te
sturen, het gaat toch over de structuur begrijp ik.

Veel Succes.
 
De db is prima te openen in 2010 (zal hij wel in gemaakt zijn) dus ik kijk er vanavond wel even naar.
 
Twee dingen moet je in ieder geval oplossen:
1. de relaties tussen de tabellen is in de huidige opzet waardeloos (als in: zonder waarde ;) ) want je controleert niet op <Referentiële integriteit>
2. in de tabel Producten heb je een veld ArtikelID en een veld Artikelcode. Eén van de twee zou genoeg moeten zijn. ArtikelID is het sleutelveld, maar je koppelt op Artikelcode?
3. een hele range aan zeer onhandige veldnamen, zoals [Huurprijs per stuk per week of weekend] (belachelijk lang) en [Straat en huisnummer/Postbus] (te lang en een slash in de naam; erg vervelend teken)
4. De tabel [Produkten] kun je nog scheiden; die is niet genormaliseerd.

Ad 1: als je <Referentiële integriteit> bij de relaties, dan gaat dat bij alle tabellen goed, behalve bij OfferteDetails, en Producten. Als je die optie niet aanvinkt, kun je net zo goed het veld [Offerte taal] koppelen aan [land], want je controleert toch niet of de gegevens wel overeenkomen. Of laat je koppelingen weg, dat is een stuk duidelijker.
Ad 2.Tabellen koppel je op een Sleutelveld en een koppelveld. In Producten is het veld ArtikelID de sleutel. Je koppelt echter op het veld Artikelcode, dat geen sleutel is. resultaat: de relatie tussen Offertedetails en Producten is niet te maken, en dat brengt je weer terug bij punt 1.
Ad 3: hou veldnamen kort en bondig, zonder tekens die wat te betekenen hebben, zoals #, * en /. Om er maar een paar te noemen. Zelfs al vind Access het best, in queries en exports ga je er de bietenbak mee op. Stel je voor dat je een bestand wilt exporteren en een naam wilt genereren op basis van het veld [Straat en huisnummer/Postbus]. Windows zal dan een nieuwe map willen maken op basis van de slash. Dus niet gebruiken!
 
Remco,

Ik ben het helemaal eens met OctaFish. Nog een paar opmerkingen:
- Alle tekstvelden hebben een lengte van 255 karakters dat lijkt me voor bijvoordeeld een postcode of voor geslacht veel te lang.
- Voor een aantal velden heb je een tekst gebruikt waar ik een ID naar een andere tabel verwacht.
Bijvoorbeeld het Type offerte, als je hier een tekst invoert dan is het maar te hopen dat je daar consequent in bent
want een typefout in dit veld zal betekenen dat je hem als je zoekt op een bepaald type niet meer terug vind.
- Het leveradres is opgenomen in de offerte terwijl ik deze als zou verwachten bij de klant.
Een klant kan meerdere afleveradressen hebben dus verwacht ik hiervan een aparte tabel.
- Plaats van opstellen is volgens mij hetzelfde als het afleveradres.
- De contactpersoon heeft een relatie met de offerte en de klant. De klant heeft ook een relatie met de offerte.
Dit is een soort van kringverwijzing die later voor onverklaarbare problemen kan zorgen. probeer dit zoveel mogelijk te vermijden.
Je kan wel contactpersoon opnemen in de offerte maar dan geen referentiele relatie aanmaken.

Veel Succes.
 
Exact de aanpassingen die ik ondertussen ook gemaakt heb :)
Overigens maakt een veldlengte van 255 tekens voor een tekstveld niet zoveel uit; je slaat alleen de ingevoerde tekens op. Maar handiger is het natuurlijk om e.e.a. in overeenstemming te brengen met het doel van het veld. Ik heb ondertussen ook geconstateerd (mede door de onhandige opzet van de tabel Produkten) dat sommige Artikelcodes aan verschillende artikelen hangen. Dat is natuurlijk uit den boze: één code hoort bij één artikel. En als je Artikelcode toch uniek is, maak er dan gelijk een sleutel van als je wilt koppelen met OfferteDetails... Al heb ik die dus nu gekoppeld aan ArtikelID. Want dat is wel uniek.
En je contactpersonen aan de offerte vasthangen kan wel, maar dan met een aparte keuzelijst die je laat filteren door het bedrijf. En dat doe je al, dus dat is verder in orde.

Heb je vaak wisselende afleveradressen voor één klant, dan kun je het afleveradres wèl opslaan in de Offertetabel. Dus daarin wijk ik dan weer af van de vorige sprekert! Een afleveradres is in dat geval een afhankelijkheid van de offerte, en niet van de klant. Denk maar eens aan AH; die worden helemaal gek als alle goederen altijd in Zaandam worden afgeleverd.
 
Een afleveradres is een klanteigenschap en zeker geen offerte eigenschap.
Volg de eerdere tip mbt afleveradressen van Elsendoorn2134.
Zorg er wel voor dat je een verwijzing naar het afleveradres vastlegt in de offerte.

Tardis
 
Een afleveradres hoeft geen klanteigenschap te zijn, maar is wel degelijk een aspect van een order. Neem alleen al de situatie dat je tijdelijk op een adres zit, en een bestelling plaatst die je hard nodig hebt. Je staat dan gek te kijken als je alsnog naar huis moet om het artikel in ontvangst te nemen. Daarom kun je bij orders ook meestal wel aangeven of je gebruik maakt van het vaste afleveradres (dat van de klant) of een ander adres wilt gebruiken. Ergo: afleveren van een order is een aspect van die order.
 
Dank jullie wel voor de reacties!

Ik heb ernaar gekeken en heb naar aanleiding hiervan nog vragen:

Octafish:
ad 1: inderdaad. Ik kan van iedere tabel de <referentiële integriteit> aanvinken, behalve tussen [offertedetails] en [producten]. Er is geen primaire index gevonden vermeld hij. De tabel [offertedetails] heeft "artikelcode" en "offertenummer" als primaire sleutel. Dit omdat deze samen het unieke vormen in de tabel. 1 "offertenummer" kan namelijk terugkomen in meerdere records van de tabel [offertedetails], telkens met een andere "artikelcode".
Welke oplossingen zijn er voor dit probleem?
ad 4: Hoe is de tabel [Producten] nog te normaliseren? Zelf zie ik dit namelijk niet...


Elsendoorn2134:
Ad 2: het type offerte wordt in het formulier uit een keuzelijst met invoervak gekozen. Dit zijn dus standaard gegevens. Welke andere "problemen" zie je nog m.b.t. dit probleem?
Ad 3: het is niet te doen om voor klanten (bedrijven) afleveradressen vast te leggen omdat geen enkel afleveradres 2 keer voorkomt. Het gaat namelijk op projectbasis.
Ad 4: nee, dat is niet zo. Plaats van opstellen is de plaats waar de offerte is opgesteld. Meestal "Sittard". Dit is standaard ingesteld in het formulier, maar kan naar believen aangepast worden als een offerte eens een keer elders wordt opgesteld.
Ad 5: tot wat voor problemen kan dit leiden volgens jou?
 
Type offerte zou ik op de keuzelijst laten staan; wel ervoor zorgen dat in het formulier alleen uit de lijst kan worden gekozen.
Wat betreft de extra koppeling tussen pc en order: ik heb ook al een aantal koker aangegeven dat die weg moet. Contactpersonen koppel je aan Klant. Zoals je gedaan hebt. Daarin leg je de Referentiële integriteit vast, dus je hebt alleen maar correcte pc's. Je hoeft die relatie dus niet in de orders vast te leggen. Bovendien werkt die relatie niet, omdat je ook al een KlantID in Orders opneemt. Op basis van de relatie CP-> Klanten, weet je voor welk bedrijf een order is als je de CP invult. Dus Ofwel je koppelt een order aan CP, ofwel aan Klant. Niet aan beiden.
Het gevaar is, dat Querido's niet meer gaan werken als er niet-eenduidige gegevens worden ingevoerd. Dat kan bijvoorbeeld als je KlantID 123 invult, en een CP kiest die bij Klant 325 zit. Omdat je in 1 record die twee gegevens straffeloos kunt invoeren, klopt je record niet.
In een formulier ondervang je dat door de keuzelijst CP afhankelijk te maken van Klant, zodat het probleem niet bestaat. Op tabelniveau kan dat niet. Je ondermijnt nu dus de integriteit van je database.
 
Dank voor de reacties.

Ik heb de DB aangepast op basis van alle tips hierboven.

1) de artikelcodes is inderdaad niet handig....dit ga ik opnemen met mijn opdrachtgever.
2) enkele veldlengtes heb ik aangepast, echter niet allemaal.
3) ik heb relaties ook aangepast: relatie contactpersonen <--> offertes heb ik weggehaald. Contactpersonen heeft nu alleen een relaties met klanten.

Hierbij de link naar de nieuwe/aangepaste DB:

http://www.mijnbestand.nl/Bestand-FU636KMAKTCI.mdb

4) welke aanpassingen/verbeteringen/optimalisaties kan ik nog doorvoeren?
5) hoe kan de tabel [producten] nog verder genormaliseerd worden?
 
1. De veldlengtes van de verschillende tekstvelden zou je nog eens kunnen bekijken; die staan allemaal op 255. En dat lijkt mij een beetje ruim.
2. Het veld [Minimale huurperiode] is een tekstveld; ik neem aan dat je wilt kunnen rapporteren op dit veld, en een aantal standaard waarden gaat gebruiken. Maak er dus een opzoeklijst van.
3. Wat is het verschil tussen de velden [Verkoopprijs] en [Verkoopprijs per stuk]? Lijkt mij dat er één weg kan. Als ze per bundel verkocht worden, maak dan een veld [Aantal] met standaardwaarde 1. Dan kun je de prijs altijd berekenen. Want dat is natuurlijk een probleem: als je één prijs aanpast, moet de ander ook kloppen.
4. Maak van het veld [Opmerkingen] een Memo veld, dan kun je meer tekst kwijt.
 
Wederom dank.

Ad 1. Veldlengtes zijn aangepast en teruggebracht naar 100.
Ad 2. Dit is puur informatief. Bepaalde producten hebben een minimaal aantal weken of dagen dat de klant ze moet huren/betalen. Hier hoeft niet op gerapporteerd te worden. Dit komt enkel in de offerte erbij te staan.
Ad 3. Inderdaad. Ik heb 1 veld verwijderd.
Ad 4. Gebeurd.

http://www.mijnbestand.nl/Bestand-BP6G7U3VE7QD.mdb

Is al hetgeen hierboven (in alle berichtjes in deze thread) is aangeraden correct doorgevoerd door mij?

Hoe kan de tabel [producten] nog verder genormaliseerd worden?

Graag weer nieuwe aanpassingen/optimalisaties :)
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan