OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 43.618
- Besturingssysteem
- Windows 10/MacOS
- Office versie
- Office 365
Alvast een kleine update: ik ben begonnen met het opschonen van de tabellen, d.w.z. dat ik alle velden uit tabellen verwijder die daar m.i. niet thuishoren. Dit dan gebaseerd op de Normalisatieregels. Dus de tabel t_Verzekering bevat straks alleen nog de verzekeringsgegevens van je materieel. In die tabel (die nu dus een verkeerd sleutelveld heeft (is nu aangepast naar ID_Verzekering) staan om te beginnen tientallen records met daarin wél materieel gegevens, maar géén verzekeringsgegevens. Die records zou ik dus willen verwijderen, want als het materiaal niet verzekerd is, heeft het ook geen plaats in de verzekeringstabel.
Daarnaast is die tabel nu niet helemaal te gebruiken omdat je geen tabel hebt met verzekeraars. Dat maakt het lastig om die gegevens goed op te slaan. Ik raad aan om daar een aparte tabel voor te maken die je koppelt met t_Verzekeringen. Daarnaast heeft een verzekering een Polisnummer als unieke waarde. Mis ik bij jou, ik zie alleen een factuurnummer. Als dat hetzelfde is: ik heb de naam van het veld al veranderd. Maar anders zou ik dus een nieuw veld erbij zetten voor de polisnummers.
Net zo belangrijk: een verzekering heeft een looptijd, meestal een jaar. Daarna krijg je een nieuwe polis, en eventueel een aangepast bedrag. Nou stel ik mij zo voor dat je de hele collectie hebt verzekerd, en bij één verzekeraar. Wat je nu hebt gedaan, is per stuk een verzekering afgesloten. Of in ieder geval: per stuk de verzekergegevens opgeslagen. Dat lijkt mij zowel voor jou als voor de verzekeraar een nodeloze berg werk. Dus leg even uit hoe je de verzekerkwestie in de praktijk hebt ingericht. Want er wordt met enige regelmaat verwezen naar de twee tabellen materieel en verzekering, maar volgens mij is de hele insteek dus verkeerd.
Dus prima als je een tabel Verzekering hebt met daarin de gegevens van de complete verzekerpolis, maar als je wilt weten of de verzekerde waarde nog klopt, en dat dan op basis van die nieuwe gegevens wilt aanpassen, dan heb je een andere structuur nodig. Wat ik zou doen: een koppeltabel maken tussen t_Verzekering en t_Materieel waarin je per verzekerd materieel vastlegt onder welke verzekering het stuk valt (koppeling met ID_Verzekering) en welk stuk het is (ID_Materieel). Dan kun je ofwel met die twee velden een nieuwe sleutel maken, ofwel een Autonummer veld gebruiken. Vervolgens leg je in de velden TaxatieDatum, VerzekerdeWaarde en TaxatieWaarde de nieuwe (gewenste) gegevens vast. Dat zou ik alleen doen op basis van mutaties. Het heeft, lijkt mij, geen enkele zin om elk jaar dezelfde gegevens opnieuw in te kloppen als die niet veranderen. De (totale) verzekerde waarde verandert er immers niet door, en de totale taxatiewaarde ook niet.
Met een Totalenquery bereken je dan de waarde van de totale collectie.
Andere werkwijze: je bent niet geïnteresseerd in welk materieel bij welke verzekeraar zit (kan ik mij ook goed voorstellen) maar wél in de waarde (en het bijbehorende verloop) van de stukken. In dat geval heb je genoeg aan de tabel die ik hierboven schetste, maar dan zonder het veld Verzekering_ID. Dan gaat het immers alleen om de prijsmutaties die je wilt vastleggen. Daarbij zijn dan het ID_Materieel belangrijk, de taxatiedatum en de nieuwe taxatiewaarde. Eventueel, als je met verschillende taxateurs werkt, een veld met daarin die taxateur. En een veld Opmerkingen natuurlijk, waarin je de taxatie kan omschrijven.
Daarnaast is de manier waarop je het materieel beschrijft niet geweldig; op zijn minst niet consequent. Neem nu deze twee omschrijvingen: "Kühlwagen (Bierwagen) mit Brhs" en "Kühlwagen mit Brhs (Bierwagen)". Kun jij de verschillen uitleggen? Ik niet... Ik vind dit ook meer categorieën dan omschrijvingen van het betreffende stuk. Dit: "Niederflur-Mittelwagen ´Rollende Landstraße mit LK" is ook niet hetzelfde als dit: "Niederflur-Mittelwagen ´Rollende Landstraße mit Lk". En dat zijn er maar twee die ik op één scherm tegenkom.
Databases zijn gebaat bij consequent ingevoerde gegevens, en afwijkende data die in beginsel hetzelfde beschrijft, moet je dus proberen te voorkomen. Bij voorkeur door die in keuzelijsten (op basis van tabellen in dit geval) te zetten.
Da's voorlopig wel voldoende
. Maar laat dus even weten hoe het nu zit met die verzekeringen.
Daarnaast is die tabel nu niet helemaal te gebruiken omdat je geen tabel hebt met verzekeraars. Dat maakt het lastig om die gegevens goed op te slaan. Ik raad aan om daar een aparte tabel voor te maken die je koppelt met t_Verzekeringen. Daarnaast heeft een verzekering een Polisnummer als unieke waarde. Mis ik bij jou, ik zie alleen een factuurnummer. Als dat hetzelfde is: ik heb de naam van het veld al veranderd. Maar anders zou ik dus een nieuw veld erbij zetten voor de polisnummers.
Net zo belangrijk: een verzekering heeft een looptijd, meestal een jaar. Daarna krijg je een nieuwe polis, en eventueel een aangepast bedrag. Nou stel ik mij zo voor dat je de hele collectie hebt verzekerd, en bij één verzekeraar. Wat je nu hebt gedaan, is per stuk een verzekering afgesloten. Of in ieder geval: per stuk de verzekergegevens opgeslagen. Dat lijkt mij zowel voor jou als voor de verzekeraar een nodeloze berg werk. Dus leg even uit hoe je de verzekerkwestie in de praktijk hebt ingericht. Want er wordt met enige regelmaat verwezen naar de twee tabellen materieel en verzekering, maar volgens mij is de hele insteek dus verkeerd.
Dus prima als je een tabel Verzekering hebt met daarin de gegevens van de complete verzekerpolis, maar als je wilt weten of de verzekerde waarde nog klopt, en dat dan op basis van die nieuwe gegevens wilt aanpassen, dan heb je een andere structuur nodig. Wat ik zou doen: een koppeltabel maken tussen t_Verzekering en t_Materieel waarin je per verzekerd materieel vastlegt onder welke verzekering het stuk valt (koppeling met ID_Verzekering) en welk stuk het is (ID_Materieel). Dan kun je ofwel met die twee velden een nieuwe sleutel maken, ofwel een Autonummer veld gebruiken. Vervolgens leg je in de velden TaxatieDatum, VerzekerdeWaarde en TaxatieWaarde de nieuwe (gewenste) gegevens vast. Dat zou ik alleen doen op basis van mutaties. Het heeft, lijkt mij, geen enkele zin om elk jaar dezelfde gegevens opnieuw in te kloppen als die niet veranderen. De (totale) verzekerde waarde verandert er immers niet door, en de totale taxatiewaarde ook niet.
Met een Totalenquery bereken je dan de waarde van de totale collectie.
Andere werkwijze: je bent niet geïnteresseerd in welk materieel bij welke verzekeraar zit (kan ik mij ook goed voorstellen) maar wél in de waarde (en het bijbehorende verloop) van de stukken. In dat geval heb je genoeg aan de tabel die ik hierboven schetste, maar dan zonder het veld Verzekering_ID. Dan gaat het immers alleen om de prijsmutaties die je wilt vastleggen. Daarbij zijn dan het ID_Materieel belangrijk, de taxatiedatum en de nieuwe taxatiewaarde. Eventueel, als je met verschillende taxateurs werkt, een veld met daarin die taxateur. En een veld Opmerkingen natuurlijk, waarin je de taxatie kan omschrijven.
Daarnaast is de manier waarop je het materieel beschrijft niet geweldig; op zijn minst niet consequent. Neem nu deze twee omschrijvingen: "Kühlwagen (Bierwagen) mit Brhs" en "Kühlwagen mit Brhs (Bierwagen)". Kun jij de verschillen uitleggen? Ik niet... Ik vind dit ook meer categorieën dan omschrijvingen van het betreffende stuk. Dit: "Niederflur-Mittelwagen ´Rollende Landstraße mit LK" is ook niet hetzelfde als dit: "Niederflur-Mittelwagen ´Rollende Landstraße mit Lk". En dat zijn er maar twee die ik op één scherm tegenkom.
Databases zijn gebaat bij consequent ingevoerde gegevens, en afwijkende data die in beginsel hetzelfde beschrijft, moet je dus proberen te voorkomen. Bij voorkeur door die in keuzelijsten (op basis van tabellen in dit geval) te zetten.
Da's voorlopig wel voldoende
. Maar laat dus even weten hoe het nu zit met die verzekeringen.
Laatst bewerkt:
) door o.a. de aankoopbonnen in te scannen en op te slaan in de database (niet de plaatjes natuurlijk). Koop je via een particulier, of op een beurs, dan is dat vaak wat lastiger en dan vul je de gegevens in voor zover je die hebt. Ik zou sowieso ook een veld toevoegen waarin je het type verkoper vastlegt.
