Nu har I jo besluttet at bruge VSS - Så må I vel følge praksis og filosofi for den.
Jeg synes det er et dårligt valg, men må vel samtidig erkende at der for et kompleks af kode, som du nævner, ikke vil være noget entydigt valg.
En anden oplagt kandidat ville jo være Oracle Designer.
Du spørger efter 'best practices'. Men jeg tror, at når du stiller det spørgsmål, har du i virkeligheden allerede en forestilling inde i hovedet om, hvordan projektet skal køre etc. Det viser sig ofte at man har forskellige ideer om hvad versionsstyring er.
På mit arbejde har vi lagt versionsstyring af tabeldefinitioner og dokumentation på word-format i Oracle Designer. Reports og PL/SQL ligger i CVS. På nogen af projekterne har vi valgt at køre med låsning, så kun een kan arbejde på en fil ad gangen.
Jeres arbejdsbetingelser har også indflydelse på 'best practices'. Har I een stor udviklingsserver, eller sidder hver projektdeltager med mulighed for at bygge sit private testmiljø? Hvis I har een stor fælles omgivelse er der fornuft i at køre med låse på filerne. Hvis I har private udviklingsmiljøer er der ingen grund til det.
Reports kan gemmes som binære eller som XML-filer. Men de binære rdf-filer er oftest de simpleste at gemme, fordi XML-formatet er så skrøbeligt for ændringer.
Men der er vel et par best practices som alle kan blive enige om, men som få kan få sat rigtigt op. Og det gælder om at få det rigtigt lige fra starten, så folk lærer at bruge det:
1. Lav et testmiljø der automatisk kan pilles ned og sættes op
2. Brug unittest på testmiljøet hver nat
3. Lav inkrementel udvikling i små bidder. Se fx Quick-kill i Dr. Dobb's
http://ddj.com/dept/java/1894019024. Lav test på realistiske data, så I ikke bliver overraskede, når I kommer i produktion.
5. Lav en fornuftig struktur af kildekode (pakke-spec og pakke-body hver for sig).
6. Lav al forretningslogik på serveren (forms og reports så enkle som muligt)
7. Overvej mulighederne for at lave autogenererede pakker til tabellerne: En pakke med typedefinitioner, en med query-håndtag, en med opdateringslogik og en med 'det løse'. Du kan måske finde noget om det, hvis du søger på 'Feuerstein'. Autogenererede pakker gør det nemmere at lave ændringer, fordi man refererer de autogenererede pakker og alle hardcodede ting ligger dér.
mvh
Jørn