Hallo allemaal,
Momenteel ben ik bezig aan een project, waarin voor de berekeningen gebruik gemaakt wordt van formules in een excel bestand. Dit houdt in dat er een excel bestand met input geupload wordt, waarna deze waardes gekopiëerd worden naar een ander excel bestand, waarin de formules staan. Het resultaat van deze formules wordt dan weer gekopieerd naar een derde bestand, welk ter download aangeboden wordt.
Van het bestand waarin de formules zich bevinden, dient 1 regel opgeslagen te worden in een oracle database. Deze regel bestaat momenteel uit 234 kolommen, maar in de toekomst zouden dit er meer of minder kunnen worden. De waardes in deze kolommen moeten gebruikt kunnen worden om te filteren.
We komen er echter niet onmiddelijk uit wat nu de beste structuur voor onze database zou zijn.
Een mogelijkheid die ik zie is om een tabel Calculation en een tabel CalculationValues te maken, die er dan zo uit zouden zien:
Een andere mogelijkheid die we zien, is om alles in 1 tabel te steken, en die zou er dan zo uitzien:
In de eerste mogelijkheid lijkt het mij makkelijker om aanpassingen aan het aantal kolommen, maar gaat ik een aantal joins moeten doen als ik alle Calculations wil ophalen waar kolom AA de waarde X heeft en kolom AB de waarde Y. Dit gaat volgens mij wel een impact hebben op de performance.
Als ik echter alles in 1 tabel steek, dan is het weer een stuk moeilijker om een verandering in het aantal kolommen op te vangen. Ook zal de hibernate entiteit er niet zo fraai uitzien volgens mij.
Hoe zouden jullie dit aanpakken? Ik hoop dat jullie een aantal argumenten kunnen aandragen voor of tegen deze oplossingen, of misschien zelfs een geniale 3de oplossing aanreiken. Als mijn uitleg onduidelijk of niet afdoende is, dan geef ik graag meer uitleg.
Momenteel ben ik bezig aan een project, waarin voor de berekeningen gebruik gemaakt wordt van formules in een excel bestand. Dit houdt in dat er een excel bestand met input geupload wordt, waarna deze waardes gekopiëerd worden naar een ander excel bestand, waarin de formules staan. Het resultaat van deze formules wordt dan weer gekopieerd naar een derde bestand, welk ter download aangeboden wordt.
Van het bestand waarin de formules zich bevinden, dient 1 regel opgeslagen te worden in een oracle database. Deze regel bestaat momenteel uit 234 kolommen, maar in de toekomst zouden dit er meer of minder kunnen worden. De waardes in deze kolommen moeten gebruikt kunnen worden om te filteren.
We komen er echter niet onmiddelijk uit wat nu de beste structuur voor onze database zou zijn.
Een mogelijkheid die ik zie is om een tabel Calculation en een tabel CalculationValues te maken, die er dan zo uit zouden zien:
Calculation | |||
ID | InputFile | OutputFile | Datum |
1 | InputFile1.xls | OutputFile1.xls | 17/06/2011 |
2 | InputFile2.xls | OutputFile2.xls | 19/06/2011 |
CalculationValues | ||
ExcelColumn | ExcelValue | CalculationID |
AA | waarde kolom AA | 1 |
AB | waarde kolom AB | 1 |
... | ... | 1 |
AA | waarde kolom AA | 2 |
... | ... | 2 |
Een andere mogelijkheid die we zien, is om alles in 1 tabel te steken, en die zou er dan zo uitzien:
Calculation | ||||||
ID | InputFile | OutputFile | Datum | KolomAA | KolomAB | ... |
1 | InputFile1.xls | OutputFile1.xls | 17/06/2011 | waarde kolom AA | waarde kolom AB | ... |
2 | InputFile2.xls | OutputFile2.xls | 19/06/2011 | waarde kolom AA | waarde kolom AB | ... |
In de eerste mogelijkheid lijkt het mij makkelijker om aanpassingen aan het aantal kolommen, maar gaat ik een aantal joins moeten doen als ik alle Calculations wil ophalen waar kolom AA de waarde X heeft en kolom AB de waarde Y. Dit gaat volgens mij wel een impact hebben op de performance.
Als ik echter alles in 1 tabel steek, dan is het weer een stuk moeilijker om een verandering in het aantal kolommen op te vangen. Ook zal de hibernate entiteit er niet zo fraai uitzien volgens mij.
Hoe zouden jullie dit aanpakken? Ik hoop dat jullie een aantal argumenten kunnen aandragen voor of tegen deze oplossingen, of misschien zelfs een geniale 3de oplossing aanreiken. Als mijn uitleg onduidelijk of niet afdoende is, dan geef ik graag meer uitleg.