Archief - [Prog]Database en OO design

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Hellsgamerz

Legacy Member
Ik ben een programma aan het schrijven waarbij ik met een database werk icm met java. Nu vraag ik mij af hoe ik die database best benader. Ik dacht:

  • Hoofdklasse om connectie te maken met de database
  • Een klasse per table die de databaseklasse meekrijgt in de constructor
  • Een klasse per object. Iedere table slaat 1 soort objecten op
  • Iedere table klasse een interface laten implementeren met basisfuncties (add, remove, retrieve)

Vb:
  • Database: hoofdklasse, connectie met database, SQL-query's intern opgeslagen
  • Users-class: klasse die add(), remove() en retrieve() doet op de table users. Implementeerd hiervoor de interface DatabaseTable. Krijgt Database mee in de constructor als bron/doel voor de methodes
  • User-class: klasse die een user voorstelt

Hoe zouden jullie hierbij tewerk gaan?

dJeez

Legacy Member
Het hangt ervan af of je echt iets zeer simpel wil of de gesofisticeerde (nu ja, het gebruik ervan is echt niet zo moeilijk, de achterliggende code is wel gesofisticeerd :p) toer op wil gaan. In het eerste geval kan je idd zelf iets schrijven, in het 2e geval zou ik een beroep doen op Hibernate of 1 van de andere Java ORM projecten.

.Acku.

Legacy Member
Bij het eerste ga je het wiel wat heruitvinden. Hibernate lijkt me gewoon de juiste keuze hier, het doet wat jij planned te doen en meer.
Het gebruik ervan kan vrij straightforward zijn als je tabellen simpel zijn.

SlasZ

Legacy Member
Ah ook al vind je het wiel opnieuw uit, het is altijd leerzaam zelf iets te maken in plaats van altijd voorgemaakte dingen te gebruiken die je niet altijd 100% begrijpt.
Het is zo dat je leert programmeren!

Hellsgamerz

Legacy Member
Het zal zelf maken worden :) Ik was aan het kijken naar embedded derby als database (wat me wel aanstaat), maar hibernate ondersteund dit niet. Maar als ik ooit es een grote ("volwassen") database gebruik zal ik nog es hibernate opzoeken.

wlibaers

Legacy Member
SlasZ zei:
Ah ook al vind je het wiel opnieuw uit, het is altijd leerzaam zelf iets te maken in plaats van altijd voorgemaakte dingen te gebruiken die je niet altijd 100% begrijpt.
Het is zo dat je leert programmeren!

Bovendien: als niemand ooit geprobeerd had het wiel opnieuw uit te vinden zouden we nu nog met ronde stenen schijven onder onze wagens zitten. :p

dJeez

Legacy Member
Hellsgamerz zei:
Het zal zelf maken worden :) Ik was aan het kijken naar embedded derby als database (wat me wel aanstaat), maar hibernate ondersteund dit niet. Maar als ik ooit es een grote ("volwassen") database gebruik zal ik nog es hibernate opzoeken.
Voldoet HSQLDB dan niet aan uw wensen? Die kan ook embedded opgestart worden.

.Acku.

Legacy Member
dJeez zei:
Voldoet HSQLDB dan niet aan uw wensen? Die kan ook embedded opgestart worden.

Quoted for truth en ik zie niet in hoeveel simpeler een database in gebruik kan zijn dan HSQL of MySQL.

Dat argument daar dat het wiel heruitvinden goed is om van bij te leren is heel wankel. Dan kan je net zo goed in Assembly gaan werken, om echte voeling te krijgen met PC logica ;)
Nu goed, een abstractieniveau lager kan zeker geen kwaad, eens werken met pure SQL is zeker en vast een nuttige bezigheid. Ermee blijven werken echter is niet rendabel.

wlibaers

Legacy Member
.Acku. zei:
Dat argument daar dat het wiel heruitvinden goed is om van bij te leren is heel wankel. Dan kan je net zo goed in Assembly gaan werken, om echte voeling te krijgen met PC logica ;)

Wat trouwens een goed idee is als je er de tijd voor hebt ;)

SlasZ

Legacy Member
In mijn opinie is iemand die altijd voorgemaakte libraries gebruikt en nooit iets zelf probeert te maken (ook al bestaat het al) geen goede programmeur.
Ik heb vroeger weken gespendeerd in het maken van matrix/vector & transformatieklassen voor een 3d programma, zelfs ook met assembler bezig geweest daarvoor.

.Acku.

Legacy Member
Een goede programmeur is iemand die resultaat geeft binnen de omlijnde verwachtingen.
Ik ga niet zagen als iemand in FLash iets maakt waar ik in Java GUI driemaal langer aan zou werken. Of iemand die in Visual Basic met drag en drop een degelijk client/server systeem ineenflanst.

We hebben al te vaak de neiging wroeging te voelen als anderen hetzelfde kunnen zonde rminder inspanning. Het lijkt oneerlijk, maar dat is evolutie.

Hellsgamerz

Legacy Member
Het zal trouwens vaak genoeg gebeuren dat je in een bedrijf *moet* met bepaalde libraries werken, hoe slecht ze ook zijn. Dus af en toe jezelf verplichten om ermee te werken kan ook geen kwaad.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan