Wie heeft er een templete of kant en klare database voor een rolling sales forecast??
- Onderwerp starter bridon
- Startdatum
- Status
OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 43.695
- Besturingssysteem
- Windows 10/MacOS
- Office versie
- Office 365
Ik sluit me gedeeltelijk bij de vorige spreker aan, met de aantekening dat een voorbeeldje uiteraard niet hoeft; je vraagt immers om een voorbeeldje. En een voorbeeldje maken van hoe het voorbeeld er uit moet zien? Lijkt mij een beetje dubbelop. Wat wél belangrijk is is de vraag wat je nu precies wilt. Ik zou sowieso nooit een bestaande db als uitgangspunt nemen voor een eigen db, en zeker niet als je daar specifieke dingen mee wilt doen als forecasting. Een adressenbestand is redelijk standaard te maken, maar ook daar kun je tig verschillende eisen aan stellen waardoor de ene variant wel voor jou werkt, en een ander totaal niet.
Wat hebben we dus van je nodig? Bij voorkeur (een samenvatting van) je Functioneel Ontwerp waarin je beschrijft wat de db allemaal moet kunnen. En dan vooral om wat je er uit wilt kunnen halen. Dat bepaalt namelijk in grote lijnen wat je er in moet stoppen. In ICT land geldt heel sterk: Garbage In = Garbage Out.
Daarnaast moet de db de door jouw beschreven processen ondersteunen, en ook dat moet in het FO terug te vinden zijn.
Op basis van het FO maak je een ER diagram en dat bepaalt dan weer welke tabellen er nodig zijn. En dan ga je dus kijken hoe e.e.a. gebouwd moet worden.
Een bestaande db als leidraad nemen is dus een heel slecht plan, omdat die db vast niet volgens jouw FO is gemaakt. De kans dat de db dus exact doet wat jij wilt is niet zo heel groot. De kans dat jij jouw processen gaat aanpassen om binnen het werkproces van de database te kunnen werken is ongeveer omgekeerd evenredig aan de kans dat de db exact doet wat jij wilt. En dat moet je dus op voorhand al niet willen!
Een programmeur kan uiteraard wel technieken uit een bestaande db halen en hergebruiken; dat doen we allemaal wel. Maar alles staat of valt dus bij een goed FO.
Wat hebben we dus van je nodig? Bij voorkeur (een samenvatting van) je Functioneel Ontwerp waarin je beschrijft wat de db allemaal moet kunnen. En dan vooral om wat je er uit wilt kunnen halen. Dat bepaalt namelijk in grote lijnen wat je er in moet stoppen. In ICT land geldt heel sterk: Garbage In = Garbage Out.
Daarnaast moet de db de door jouw beschreven processen ondersteunen, en ook dat moet in het FO terug te vinden zijn.
Op basis van het FO maak je een ER diagram en dat bepaalt dan weer welke tabellen er nodig zijn. En dan ga je dus kijken hoe e.e.a. gebouwd moet worden.
Een bestaande db als leidraad nemen is dus een heel slecht plan, omdat die db vast niet volgens jouw FO is gemaakt. De kans dat de db dus exact doet wat jij wilt is niet zo heel groot. De kans dat jij jouw processen gaat aanpassen om binnen het werkproces van de database te kunnen werken is ongeveer omgekeerd evenredig aan de kans dat de db exact doet wat jij wilt. En dat moet je dus op voorhand al niet willen!
Een programmeur kan uiteraard wel technieken uit een bestaande db halen en hergebruiken; dat doen we allemaal wel. Maar alles staat of valt dus bij een goed FO.
(heeft nu natuurlijk veel om over na te denken- Status
