Wanneer gebruik je een database of een object-serializatie

[Verwijderd]

Hoi allemaal,

Ik vraag me af, wanneer moet je nu in een standalone applicatie, een database
als paradox of access gebruiken. Ik ben op dit moment bezig een app. te maken in C++Builder 6.0. Deze app. moet gegevens opslaan, editen en deleten van honkbal wedstrijden. Naast dit opslaan enzo, moet de app. ook in staat zijn om alle data te sorteren. Dit sorteren moet tie doen met verschillende stats. Deze stats moeten per seizoen, wedstrijd, team en speler worden bijgehouden, zodat de app. in staat is om allerlei overzichten te genereren. Overzichten zoals, hoe goed is team A van club A tegen team A van club B.

Persoonlijk heb ik het gevoel, dat dit heel goed gemaakt kan worden zonder een database. Zolang er natuurlijk maar een goede datastructuur wordt ontwikkeld.
Er zijn 2 eisen aan deze app. die het misschien iets ingewikkelder maken om op mijn vraag een antwoord te geven. De app. moet upgradable zijn per onderdeel en het moet mogelijk zijn, dat zodra C++Builder een linux compiler uitbrengt het gelijk voor linux te compilen. Het OS waar het zeker op moet werken is Windows.

Nu heeft C+Builder verschillende componenten die al gebruikt kunnen worden onder windows en linux, namelijk de CLX objecten, hier hebben ze ook een dbExpres object. Dit object zou in staat zijn om zowel onder windows als linux een db te benaderen.

Alvast bedankt voor het lezen

[Alarmnummer]

Het voordeel aan een database tov 'normale' files is dat een database zaken zoals bv transacties, concurrency control heeft en er verder eenvoudig informatie uit gehaald kan worden.

[ Voor 8% gewijzigd door Alarmnummer op 30-01-2003 11:36 ]

[KnoppenSpook]

Als ik het zo lees is het aardig gecompliceerde data die moet opslaan/combineren/sorteren. En dat is nou net iets waar een database goed in is. Als je het zelf zou doen, ben eigenlijk een aangepaste database aan het schrijven...
Ik zou kiezen voor koppeling met een DB.

[Alarmnummer]

Je doet er trouwens wel verstandig aan om een aparte data laag aan te maken die ervoor zorgt dat je domein objecten met een database (of iets anders) kan communiceren. Hierdoor krijg je een scheiding van functionaliteit en het is eenvoudiger om er een andere datalaag achter te zetten zonder dat je je hele systeem moet omgooien.

[Verwijderd]

Jullie hebben gelijk, misschien moet ik voor deze app. een DB. gebruiken. Alhoewel het met een goed object model en goed gemaakte datastructureren denk ik ook te doen is. Bovendien is het mijn afstudeerproject, ik moet er dus wel goed over nadenken voordat ik beslis iets te doen.

[Alarmnummer]

Tuurlijk is het met de hand ook te doen, maar de vraag is of dat zo verstandig is. Een database is getest en bezit veel meer kennis dan jij ooit over dat domein zal bezitten. Dan doe je er toch verstandig aan om dat te gebruiken ipv zelf zo`n structuur te maken? En verder kan je bij een database veel eenvoudiger gegevens ophalen zodat je eventueel allerlei rapport generator tools erop los kan laten (die je wederom niet zelf hoeft te schrijven).

En verder moet je je eerst concentreren op je business (domein) laag en interfaces opstellen voor je datalaag. Hierdoor kan je later altijd nog van datalaag wisselen.

De toverwoorden zijn: interfaces en lagen

[ Voor 5% gewijzigd door Alarmnummer op 30-01-2003 11:45 ]

[whoami]

Verwijderd schreef op 30 januari 2003 @ 11:41:
Jullie hebben gelijk, misschien moet ik voor deze app. een DB. gebruiken. Alhoewel het met een goed object model en goed gemaakte datastructureren denk ik ook te doen is. Bovendien is het mijn afstudeerproject, ik moet er dus wel goed over nadenken voordat ik beslis iets te doen.

Het hebben van een goed object model is geen argument om een eigen 'serializatie-methode' te verkiezen tov een databank.

Het object model voor de business-laag (de business of domein logica dus), is complementair met uw data-laag (database, xml-files, of whatever je gebruikt voor data-persistence).
Zoals Alarmnummer al aanhaalde, is het best dat je met verschillende lagen werkt die niet te sterk met elkaar gekoppeld zijn. (Presentatie-laag, domein-laag, data-laag).
Als je een presentatie-laag en domein - laag hebt geschreven, kan je een data-laag schrijven die bv. zorgt voor persistentie van uw objecten in een databank. Vind je later dat die databank echt overkill is (maar ik vermoed van niet), dan kan je nog altijd een andere data-laag schrijven die gebruik maakt van files bv om uw gegevens in op te slaan, zonder dat je uw andere lagen hoeft aan te passen.

Ikzelf zou ook kiezen om de gegevens in een database op te slaan. Je zult minder werk hebben, en minder aandacht moeten besteden aan specifieke details aangezien een databank die functionaliteit reeds bezit die je anders zelf moet implementeren. Een database is uitermate geschikt voor het beheren van de data zoals jij die beschreven hebt.

Kortom, een database is hier imo de beste optie.

Welkom op GoT trouwens.

[ Voor 15% gewijzigd door whoami op 30-01-2003 12:11 ]

[Verwijderd]

ta, allemaal bedankt voor hun antwoord, ik ga een db gebruiken. Nu moet ik alleen nog een DB vinden die zowel werkt onder windows en linux en van de grootte als paradox is. Ik bedoel de databases die je kan maken met de database desktop van CBuilder

[Alarmnummer]

Ik denk dat het vrij gevaarlijk is als je aan een bepaalde desktop oplossing vast komt te zitten en je je applicatie op meerdere platformen wilt runnen. Door een datalaag te maken is het een stuk eenvoudiger om te wisselen, maar als je ook dezelfde datalaag wilt gebruiken, dan kan dit denk ik wel problemen opleveren. Dus pas op met IDE specifieke oplossingen.

[whoami]

[nohtml]

Alarmnummer schreef op 30 januari 2003 @ 12:28:
Door een datalaag te maken is het een stuk eenvoudiger om te wisselen, maar als je ook dezelfde datalaag wilt gebruiken, dan kan dit denk ik wel problemen opleveren.

Dat valt wel mee denk ik.
Als je die data-laag zo implementeert dat ze enkel doet waarvoor ze bedoeld is (), ttz het updaten, ophalen, inserten, deleten van gegevens, dan kan je die datalaag ook wel redelijk generiek maken voor alle types databanken (let wel, databanken, niet data-sources). De beste methode is eigenlijk om alle queries via stored procedures te laten verlopen (als je dbms dat aankan natuurlijk).
Bij het veranderen van databank (bv. van SQL Server naar Oracle), dan moet je natuurlijk wel ook die SP's in die Oracle databank implementeren, maar dan hoef je wel niet meer aan uw data-laag te komen.

[Alarmnummer]

Als je het op die manier aanpakt dan levert dat geen problemen op, maar als je dus gaat werken met allerlei objecten van een omgeving die niet standaard zijn, dan krijg je problemen.

[ProgrammerX]

Verwijderd schreef op 30 January 2003 @ 12:16:
ta, allemaal bedankt voor hun antwoord, ik ga een db gebruiken. Nu moet ik alleen nog een DB vinden die zowel werkt onder windows en linux en van de grootte als paradox is. Ik bedoel de databases die je kan maken met de database desktop van CBuilder

Als ik me niet vergis is de BDE (Borland Database Engine) vereist voor de databases die je kan gebruiken i.c.m. de database desktop. En van die BDE is dacht ik geen linux versie van te vinden.

Dan wil ik je liever mysql aan raden, want deze db is:

- gratis (www.mysql.org)
- te gebruiken op windows en linux (en nog veel meer)
- relatief eenvoudig als je wat van sql afweet (en er is veel informatie over te vinden)
- daarnaast is de performance denk ik beter

Neem gewoon een paar dagen de tijd om je keuze te maken, want zoals je zelf al aangaf is deze keuze zeer belangrijk. Bedenk goed wat je eisen zijn aan je database en neem aan de hand daarvan je keuze

[whoami]

ProgrammerX schreef op 30 januari 2003 @ 12:48:
[...]


Als ik me niet vergis is de BDE (Borland Database Engine) vereist voor de databases die je kan gebruiken i.c.m. de database desktop. En van die BDE is dacht ik geen linux versie van te vinden.

Ik dacht dat die BDE componenten niet meer gebruikt werden in de nieuwste versies? Maken Delphi en C++ Builder nu geen gebruik van ADO of van dbExpress?

Dan wil ik je liever mysql aan raden, want deze db is:

Ik wil hier niet flamen enzo, maar MySQL is imho geen DB. De redenen zijn gekend lijkt me.

Neem gewoon een paar dagen de tijd om je keuze te maken, want zoals je zelf al aangaf is deze keuze zeer belangrijk. Bedenk goed wat je eisen zijn aan je database en neem aan de hand daarvan je keuze

Het is in 1ste instantie gewoon belangrijk dat de topicstarter de goede keuze maakt: database of geen database. Als hij kiest voor een DB (wat imho wel de beste keuze is), dan pas moet hij een specifiek DBMS gaan kiezen, maar daar gaat dit topic dus niet over.

[Alarmnummer]

*heeft van horen zeggen*

MySQL kan je geloof ik niet onder de categorie serieze db plaatsen. Als je een gratis oplossing wilt moet je eens kijken naar Interbase ofzo. Dit is tenminste een database die alles doet wat een database moet doen.

En verder hoort je database keuze niet (of nauwelijks) in je ontwerp terug te komen. Dus als het serieus gebruikt gaat worden kan je altijd nog voor zo`n monster als SQL Server, Sybase, Oracle gaan.

[Exar]

Ander goed (uitgebreid) Open-Source (gratis) (O)RDBMS: PostgreSQL.

[whoami]

Exar_Kunn schreef op 30 januari 2003 @ 13:09:
Ander goed (uitgebreid) Open-Source (gratis) (O)RDBMS: PostgreSQL.

Mag ik er nogmaals op wijzen dat dit topic daar helemaal niet over gaat.
Het is hier geen opsomtopics voor verschillende DBMS'en, daar hebben hadden we de HK voor.
De topicstarter geeft aan dergelijke antwoorden dus ook echt niets.
Het gaat er hier om, of je hier beter gebruik maakt van een DBMS of van een andere manier om de data op te slaan.

Trouwens een ODBMS en een RDBMS zijn wel 2 fundamentele verschillende DBMS'en, dus moet je wel goed weten welke term je gebruikt.

[ Voor 11% gewijzigd door whoami op 30-01-2003 13:13 ]

[Exar]

Whoami: Als je de thread gelezen hebt, kan je zien dat de keuze voor het gebruiken van een DBMS al gemaakt is....
Enne.... PostgreSQL is dus geen ODBMS....

Maar sorry voor het 'opsommen' hoor, maar ik denk dus dat topicstarter er wel iets aan heeft als ie wil gaan nadenken welk DBMS hij gaat gebruiken.

Edit: lees zijn post van 12:16 maar eens na....

[ Voor 11% gewijzigd door Exar op 30-01-2003 13:27 ]

[ProgrammerX]

whoami schreef op 30 January 2003 @ 12:50:

Ik dacht dat die BDE componenten niet meer gebruikt werden in de nieuwste versies? Maken Delphi en C++ Builder nu geen gebruik van ADO of van dbExpress?

Nee, dat klopt inderdaad maar ik noemde de BDE eigenlijk (althans dat was mijn bedoeling) maar als voorbeeld dat je imo beter niet paradox kunt gebruiken omdat je dan volgens mij altijd afhankelijk blijft van borland. En aangezien borland nog geen cbuilder heeft voor linux denk ik niet dat dat gaat werken zo (of er moet natuurlijk iets zijn voor linux waar ik niet van op de hoogte ben ).

Ik wil hier niet flamen enzo, maar MySQL is imho geen DB. De redenen zijn gekend lijkt me.

Mijn bedoeling was ook niet om een flame te beginnen Kun je die redenen dan toch nog even kort opnoemen want die zijn bij mij onbekend (heb persoonlijk zelfs betere ervaringen met mysql dan met interbase dat hier ook wordt genoemd).

Het is in 1ste instantie gewoon belangrijk dat de topicstarter de goede keuze maakt: database of geen database. Als hij kiest voor een DB (wat imho wel de beste keuze is), dan pas moet hij een specifiek DBMS gaan kiezen, maar daar gaat dit topic dus niet over.

Ik dacht dat de topicstarter al de keuze had gemaakt voor een database. Toen ik zag dat ie met paradox/dbase aan de gang wou gaan leek het me beter om hem een ander alternatief te geven dat wel goed kan omgaan met linux.

[whoami]

[nohtml]

ProgrammerX schreef op 30 januari 2003 @ 14:54:
[...]


Nee, dat klopt inderdaad maar ik noemde de BDE eigenlijk (althans dat was mijn bedoeling) maar als voorbeeld dat je imo beter niet paradox kunt gebruiken omdat je dan volgens mij altijd afhankelijk blijft van borland. En aangezien borland nog geen cbuilder heeft voor linux denk ik niet dat dat gaat werken zo (of er moet natuurlijk iets zijn voor linux waar ik niet van op de hoogte ben ).

Je kunt iedere database toch via die BDE aanspreken? Ook een paradox database.

Kun je die redenen dan toch nog even kort opnoemen want die zijn bij mij onbekend

Misschien moet je ff gebruik maken van de GoT search.
Enkele redenen: ontbreken van referentiële integriteit, subqueries, union's, stored procedures, ...

ProgrammerX schreef op 30 januari 2003 @ 14:54:
[...]


Ik dacht dat de topicstarter al de keuze had gemaakt voor een database. Toen ik zag dat ie met paradox/dbase aan de gang wou gaan leek het me beter om hem een ander alternatief te geven dat wel goed kan omgaan met linux.

Als je gebruik maakt van een database server en een client, dan maakt het niet uit of die databank nu op een Windows server of op een Unix server draait.
Ik heb al verschillende applicaties ontwikkeld die draaien op Windows en die een databank benaderen die op een Unix server staat.

[ Voor 28% gewijzigd door whoami op 30-01-2003 14:59 ]

[Alarmnummer]

Maar zullen we weer gezellig verder kletsen over die mooie datalaag ipv die eigelijk niet zo interesante databases?

[whoami]

Alarmnummer schreef op 30 januari 2003 @ 15:18:
Maar zullen we weer gezellig verder kletsen over die mooie datalaag ipv die eigelijk niet zo interesante databases?

* whoami agrees.
Ik denk ook dat de topicstarter daar meer mee zal geholpen zijn dan dat hier alle verschillende soorten dbms'en genoemd worden.

Die datalaag is dus eigenlijk niets anders dan een 'mapper' die uw business-logic objecten gaat gaan opvullen met gegevens uit uw databank.
Als je echter een redelijk eenvoudig business-logica/domain-model hebt, dan kan je die datalaag ook wel in die business-objecten kwijt. Dan heb je wel het nadeel dat uw business logica gebonden is aan die ene datasource die je gebruikt, nl. een databank.

[ Voor 34% gewijzigd door whoami op 30-01-2003 15:32 ]

[ProgrammerX]

whoami schreef op 30 January 2003 @ 15:23:

[...]


* whoami agrees.
Ik denk ook dat de topicstarter daar meer mee zal geholpen zijn dan dat hier alle verschillende soorten dbms'en genoemd worden.

Die datalaag is dus eigenlijk niets anders dan een 'mapper' die uw business-logic objecten gaat gaan opvullen met gegevens uit uw databank.
Als je echter een redelijk eenvoudig business-logica/domain-model hebt, dan kan je die datalaag ook wel in die business-objecten kwijt. Dan heb je wel het nadeel dat uw business logica gebonden is aan die ene datasource die je gebruikt, nl. een databank.

Als je toch een eenvoudig model hebt, kun je misschien beter je data-laag en je business laag gescheiden houden. Levert nu misschien wat meer werk op, maar je hebt er later veel profijt van. Daarnaast is je school denk ik meer "onder de indruk" als je alles in aparte lagen plaatst, dan wanneer je lagen combineert (ze zien het liever denk ik, althans dat was bij ons wel altijd zo)

offtopic:
Whoami : het punt was dat je met de bde aan windows gebonden bent en de applicatie moet ook op linux kunnen draaien en dat voorkom je misschien als je nu een andere keuze maakt.

Trouwens mysql 4 + innodb lost veel van mijn "problemen" op

[ Voor 3% gewijzigd door ProgrammerX op 30-01-2003 15:53 . Reden: Typo ]

[whoami]

ProgrammerX schreef op 30 januari 2003 @ 15:52:
[...]


Als je toch een eenvoudig model hebt, kun je misschien beter je data-laag en je business laag gescheiden houden. Levert nu misschien wat meer werk op, maar je hebt er later veel profijt van.

Idd, da's waar. Maar als je zowiezo al weet dat je er 'later' geen profijt mee haalt, dan kan het wel.

offtopic:
Trouwens mysql 4 + innodb lost veel van mijn "problemen" op

offtopic:
MySQL 4, is die al stabiel? Echt stabiel-stabiel dan?

[ProgrammerX]

whoami schreef op 30 januari 2003 @ 15:55:
Idd, da's waar. Maar als je zowiezo al weet dat je er 'later' geen profijt mee haalt, dan kan het wel.

Als je het van te voren weet dan is het zeker makkelijker ja, maar toch zijn schoolbegeleider geneigd om voor meerdere lagen te gaan

MySQL 4, is die al stabiel? Echt stabiel-stabiel dan?

Nee, hij is nog niet officieel uitgebracht als zijnde stabiele versie

[Verwijderd]

jongens,

nogmaals allemaal erg bedankt voor de aandacht en "extra" uitleg.
Ondertussen ben ik wat wezen googlen, (zoekterm: "borland windows and linux compatible databases"). Hier uitkomen inderdaad een aantal beschikbare databases naar voren. Databases als interbase en mysql.

De database die ik kies, moet voldoen aan de volgende eisen:
zodra mijn app. geinstalleerd wordt, moet de gebruiker totaal niets zelf configureren, moet allemaal al gedaan zijn, de database moet ongeveer het niveau als access en paradox hebben. Verder moet een client/server omgeving vermeden worden, hier kan teveel misgaan tijdens een installatie vanaf cd door een "domme" gebruiker.

De simpelste en denk ik meest handige oplossing is gebruik maken van de SQLClientDataSet uit de dbExpres serie van de borland componenten. Deze dataset kan je vorm geven en stelt dus per component in je project 1 tabel voor.
De dataset kan worden opgeslagen naar een file en kan worden ingelezen vanuit een file. Dit betekent dus dat zodra je app. start de bijbehorende data uit de database in feite in het geheugen staat en niet persisent is, totdat het als file wordt weggeschreven.

Btw zodra kylix uitkomt van borland, kan ik mijn hele code onder linux compilen. Het is dus al mogelijk om linux compatible code te schrijven.Het testen ervan is echter nog niet mogelijk.

Als jullie advies kunnen geven over welke database er gebruikt kan worden graag.
Opties zijn: interbase(misschien licentie problemen zodra dit product in de winkel ligt), cds(clientdataset) files(geen licentie problemen, maar ook geen "stevige database, eigen geen database")

Als jullie nog meer opties weten, hoor ik het graag. Op dit moment gaat mijn eigen voorkeur uit naar cds files, gewoon vanwege de simplicity ervan. Er zijn gewoon query's op te gebruiken het is alleen niet persistent totdat je het zelf naar een stream of file laat wegschrijven.

[Verwijderd]

De theorie achter de applicatie is, dat het linux en windows compatible is, zonder dat er veel meer gedaan moet worden als opnieuw compilen. Daarom besteed ik zoveel aandacht aan de database keuze, zodra ik alleen objecten opsla is dat namelijk geen probleem. Terwijl bij een database weer gekeken moet worden of die beschikbaar is onder windows en linux, en hoe simpel die mee te installeren is. Verder krijgt deze app. een soort plug en pray model. Er kan dus later dmv plug en pray functionaliteit simpel worden toegevoegd of verwijderd, tevens wordt het een multitalig iets(engels, duits, frans, nederlands, plus wat andere europese talen)... Ik weet het, beetje offtopic, maar misschien is het nuttige info voor het eventuele advies dat jullie me kunnen geven

groetjes Druchii

[Creepy]

ProgrammerX schreef op 30 January 2003 @ 14:54:
[...]


Nee, dat klopt inderdaad maar ik noemde de BDE eigenlijk (althans dat was mijn bedoeling) maar als voorbeeld dat je imo beter niet paradox kunt gebruiken omdat je dan volgens mij altijd afhankelijk blijft van borland. En aangezien borland nog geen cbuilder heeft voor linux denk ik niet dat dat gaat werken zo (of er moet natuurlijk iets zijn voor linux waar ik niet van op de hoogte ben ).
[...]

Kylix 3 Daarin kan je zowel in pascal als in C++ je code schrijvenl.

De BDE word vanaf Delpi 6 afgeraden (o.a. omdat het niet platform onafhankelijk is). Ter vervanging zijn er de dbExpres objecten die ook nog eens mooi source-code compatible zijn met Kylix. En voor de meeste DBMS'en is wel een dbexpres driver te vinden.

[whoami]

[nohtml]

Verwijderd schreef op 04 February 2003 @ 17:34:

De database die ik kies, moet voldoen aan de volgende eisen:
zodra mijn app. geinstalleerd wordt, moet de gebruiker totaal niets zelf configureren, moet allemaal al gedaan zijn, de database moet ongeveer het niveau als access en paradox hebben. Verder moet een client/server omgeving vermeden worden, hier kan teveel misgaan tijdens een installatie vanaf cd door een "domme" gebruiker.

Hoezo?
Als je installatie-script alles doet, wat zou er dan nog kunnen fout gaan door toedoen van een "domme" gebruiker?

Btw zodra kylix uitkomt van borland, kan ik mijn hele code onder linux compilen. Het is dus al mogelijk om linux compatible code te schrijven.Het testen ervan is echter nog niet mogelijk.

Kylix is toch al uit?

[Creepy]

whoami schreef op 04 February 2003 @ 19:39:
[nohtml]
[...]
Kylix is toch al uit?

Kylix 3 is al een poosje uit, en wordt zelfs bij Delphi 7 geleverd (bij de enterprise en architect versie uit m'n hoofd)

[Verwijderd]

oh... dat wist ik niet... vast verkeerd gelezen... sorry, sorry...
En ik ben er nog niet uit wat voor DB ik ga gebruiken, heb wel m'n ontwerp voor de tabellen af enzo. Nu moet ik maar eens een DB gaan kiezen...