[Databasestructuur] hoe te doen voor on-line spel

[Verwijderd]

Ik ben samen met een paar anderen een on-line spel aan het maken (zoiets als dominion). het is eigenlijk een verzameling van php scripts met een achterliggende mysql-database (wat dus het belangrijkste in het ontwerpen van het spel is). nu zijn we al een redelijk eind op weg maar het is erg moeilijk (omdat ieder een ander script maakt) een goede database-structuur te maken, terwijl mij dit toch echt belangrijk lijkt voor het verdere verloop.
Het probleem hierbij is dat het tekenen op papier al snel onoverzichtelijk word (en ook niet echt compleet omdat iedereen weer andere tabellen nodig heeft en die steeds word aangepast naarmate we verder komen in de ontwikkeling).

de vraag is nu: hoe moeten we dit aanpakken? (zijn er programmas die dit bij kunnen houden oid)


Is het trouwens aan te raden om de gegevens zo veel mogelijk gescheiden te houden? bijvoorbeeld als ik gegevens die gebonden zijn aan een username (bijvoorbeeld berichten) op te slaan in een database waarin elke username een tabel is, of kan ik beter 1 tabel maken waarin de username in een kolom staat?

[cosmoOo]

ms visio ? eerste versies zijn wat buggie maar ik geloof dat het nu best redelijk is.

een nieuwe tabel per user is zeker niet aan te raden, je hoort geen tabellen bij te maken als er meer users komen oid.

[JaQ]

Kijk eens naar cvs, ik denk dat je daar blij van wordt.

[Verwijderd]

ik zal eens kijken naar visio

en ik dacht dat cvs alleen voor het correct bijhouden van source was? (dus als meerdere mensen aan dezelfde source werken) ik heb me er nooit echt in verdiept maar ik zal ook hier eens naar kijken.

[brokenp]

Visio zou je moeten gebruiken, maar zorg ervoor dat je eerst met je hele ontwikkelteam een duidelijke databasestructuur heb, nog voor dat iemand een regel code geschreven heeft.
anders blijf je bezig, en ga je misschien allerlei data dubbel opslaaan enzo

[Verwijderd]

brokenp schreef op 19 juli 2003 @ 18:45:
Visio zou je moeten gebruiken, maar zorg ervoor dat je eerst met je hele ontwikkelteam een duidelijke databasestructuur heb, nog voor dat iemand een regel code geschreven heeft.
anders blijf je bezig, en ga je misschien allerlei data dubbel opslaaan enzo

ja, dat probleem hebben we dus nu al. maar dat visio ziet er inderdaad goed uit . alleen moet ik dan zorgen dat er 1 centraal bestand komt waar iedereen in kan werken maar dat zal niet zo moeilijk zijn denk ik. bedankt voor de reacties tot zover

[alienfruit]

Jezou kunnen kijken naar xCase of dat andere programma PL/SQL designer ofzo Zelf vind ik xCase wel lekker werken. Zelf gebruik ik Visio niet omdat het zo traag als *** van de makke beer was.

[ Voor 25% gewijzigd door alienfruit op 19-07-2003 19:32 ]

[Kogelvis]

dr schijnt ook een programma (java programma) te zijn die dmv UML een database structuur kan creeeren ik weet echter de naam ervan niet meer

[JaQ]

Verwijderd schreef op 19 juli 2003 @ 18:41:
en ik dacht dat cvs alleen voor het correct bijhouden van source was? (dus als meerdere mensen aan dezelfde source werken) ik heb me er nooit echt in verdiept maar ik zal ook hier eens naar kijken.

Als ik het zo goed lees is dat een van de problemen waar je mee zit. Meerdere mensen werken met de source van de database (de tabellen). Door cvs te gebruiken kan je er voor zorgen dat iedereen altijd met dezelfde databasestructuur werkt.

Uiteraard moet je daarnaast goed nadenken over een ontwerp. Denk alleen dat je dat moet doen voordat je gaat bouwen. Als ik je ontwikkelproces zo aanhoor, dan wordt de database ad-hoc ontworpen. Persoonlijk vind ik dat niet zo heel slim (dikke kans dat je er straks achter komt dat je om database-ontwerp-fouten heen gaat zitten programmeren). Het is echter een manier van werpen en daar wil ik verder niet over flamen of zo.

[Verwijderd]

DrFrankenstoner schreef op 19 juli 2003 @ 20:19:
[...]


Als ik het zo goed lees is dat een van de problemen waar je mee zit. Meerdere mensen werken met de source van de database (de tabellen). Door cvs te gebruiken kan je er voor zorgen dat iedereen altijd met dezelfde databasestructuur werkt.

Uiteraard moet je daarnaast goed nadenken over een ontwerp. Denk alleen dat je dat moet doen voordat je gaat bouwen. Als ik je ontwikkelproces zo aanhoor, dan wordt de database ad-hoc ontworpen. Persoonlijk vind ik dat niet zo heel slim (dikke kans dat je er straks achter komt dat je om database-ontwerp-fouten heen gaat zitten programmeren). Het is echter een manier van werpen en daar wil ik verder niet over flamen of zo.

je hebt helemaal gelijk we hebben van tevoren wel over een aantal dingen nagedacht (qua databasestructuur) maar zoals met alle projecten gaat de gedachte in het begin vooral uit naar features enzo

heb het er even met anderen over gehad maar ik denk dat we toch gaan overstappen op cvs. en voor database-structuur moet ik nog even afwachten hoe visio bevalt.

(qua programmas is er maar weinig te vinden op internet, of ik zoek gewoon verkeerd )

edit: op download.com wel wat gevonden --> http://www.chillisource.com/
edit: of http://www.datanamic.com/dezign/index.html

[ Voor 8% gewijzigd door Verwijderd op 19-07-2003 22:11 ]

[Verwijderd]

nog een vraag:
is het beter om 1 database te hebben met erin alle tabellen. of meerdere databases met elk een aantal tabellen? (zou dit in snelheid schelen?)

[Verwijderd]

Waarom niet een generieke oplossing?

object table, attributes table, instances table, data table

[Soultaker]

Qua database modelling tools vind ik CASE Studio prima werken. Samenwerken wordt niet echt ondersteund, maar het is in ieder geval erg makkelijk om tabellen en relaties tussen tabellen te realiseren. Het werkt ook redelijk vlot en met een redelijk handige interface; twee redenen waarom ik een hekel heb aan Visio.

Andere database modelling tools (zoals hier in de thread genoemd) ken ik eigenlijk niet, maar die zouden ook goed geschikt kunnen zijn. Wellicht zit daar ook een gratis tool tussen.

Verwijderd schreef op 20 July 2003 @ 00:07:
Waarom niet een generieke oplossing?

object table, attributes table, instances table, data table

Ik mag hopen dat jij nog nooit een relationeel databaseontwerp hebt hoeven maken, want als je hiermee aan zou komen zetten zou ik je direct terug naar school sturen. Als je deze vraag nog durft te stellen, heb je er duidelijk niets van begrepen! _/NOFI

Verwijderd schreef op 20 July 2003 @ 00:05:
nog een vraag:
is het beter om 1 database te hebben met erin alle tabellen. of meerdere databases met elk een aantal tabellen? (zou dit in snelheid schelen?)

Rule of thumb: als je verschillende databases hebt met dezelfde soorten tabellen erin, ben je waarschijnlijk verkeerd bezig, tenzij je goede redenen hebt om die databases op te splitsen. In het algemeen kun je deze situatie namelijk oplossen door een extra kolom toe te voegen aan enkele relevante tabellen om de rijen die nu bij elkaar in een aparte database zitten aan elkaar te koppelen.

Als je echter klanten die gescheiden gegevens hebben en niet bij elkaars gegevens mogen kunnen, lijkt me dat een goede reden om aparte databases te maken. Wanneer je een ontwikkelversie en een productieversie van een applicatie naast elkaar draait, is dat ook een goede reden om databases te scheiden. Wanneer je echter databases dynamisch (in je programmacode) moet aanmaken of verwijderen, dan is dat duidelijk een indicatie dat je eigenlijk die databases samen had moeten voegen.

[ Voor 37% gewijzigd door Soultaker op 20-07-2003 01:06 ]

[Verwijderd]

Soultaker schreef op 20 July 2003 @ 01:01:
Ik mag hopen dat jij nog nooit een relationeel databaseontwerp hebt hoeven maken, want als je hiermee aan zou komen zetten zou ik je direct terug naar school sturen. Als je deze vraag nog durft te stellen, heb je er duidelijk niets van begrepen! _/NOFI

Ik vind je opmerking nogal dom en behoorlijk grof. Met een dergelijk database model draait hier een CMS systeem op een groot aantal klanten, razend snel, stabiel en ontzettend flexibel voor de toekomst. Alle soorten data kan ik op deze manier opslaan, bewerken en uitlezen ongeacht de soort applicatie. Dit database model IS dus relationeel.

Als jij mij naar school denkt te sturen, moet je ook eens wat meer uitleg geven over jou motivatie van je post. Anders moet jij denk ik maar eens een cursus subtiele communicatie volgen.

[ Voor 3% gewijzigd door Verwijderd op 20-07-2003 01:26 ]

[alienfruit]

Uh Gordijnstok, klonkt slim indeed

Moet ik dan denken aan zoiets:
Dus je definieert in je objects en attributes tabellen bepaalde objecten (bijv. een tekstcomponent met titel en plaatje en uitklapmenu) in object wat handige informatie en in attributes property en value in de data tabel met koppeling naar object en attribute. en vervolgens hou je in de instances tabel de instantie van de mogelijke objecten bij ofzo?

[ Voor 8% gewijzigd door alienfruit op 20-07-2003 01:37 ]

[Soultaker]

Verwijderd schreef op 20 July 2003 @ 01:25:
Ik vind je opmerking nogal dom

Jij vind mijn opmerking dom?!

en behoorlijk grof.

Granted.

Met een dergelijk database model draait hier een CMS systeem op een groot aantal klanten, razend snel, stabiel en ontzettend flexibel voor de toekomst. Alle soorten data kan ik op deze manier opslaan, bewerken en uitlezen ongeacht de soort applicatie. Dit database model IS dus relationeel.

Het kan voor jouw klanten wel prima werken, maar dat maakt het nog geen goed relationeel databaseontwerp. Sterker nog, je gebruikt een relationale database als simpele data object storage. Vind ik prima, maar dat is slechts een heel beperkt deel van de mogelijkheden van een relationele database.

Als jij mij naar school denkt te sturen, moet je ook eens wat meer uitleg geven over jou motivatie van je post. Anders moet jij denk ik maar eens een cursus subtiele communicatie volgen.

Begin maar eens met het lezen van wat een relationale database precies is. Ik kan de belangrijkste stukken (voor deze discussie) wel even quoten:

A relational database is a set of tables containing data fitted into predefined categories. Each table (which is sometimes called a relation) contains one or more data categories in columns. Each row contains a unique instance of data for the categories defined by the columns.
[...]
When creating a relational database, you can define the domain of possible values in a data column and further constraints that may apply to that data value.

Het hele idee van een relationele database, is dat je de gegevens die je op kunt slaan beperkt en de relaties tussen gegevens expliciet aangeeft door verschillende soorten gegevens in aparte tabellen te modelleren. Het voordeel hiervan is dat je een zekere consistentie van de gegevens in de database kunt garanderen aan de hand van het databaseontwerp.

Jouw databaseontwerp categoriseert geen gegevens en brengt geen constraints aan op de mogelijke waarden. In jouw databaseontwerp kan niets gegarandeerd worden, behalve misschien dat een object attributen zou kunnen hebben, maar welke attributen dat zijn en welke types die hebben, is onbekend.

Nu moet ik zeggen dat ik je specifieke ontwerp niet ken (ik baseer mijn oordeel dus op wat aannames) maar het zou me verbazen als je ueberhaupt queries kunt doen waarbij je de relaties tussen gegevens kan uitbuiten, zoals met een normaal relationeel ontwerp gebruikelijk is.

[alienfruit]

"Relational Databases: A collection of normalized relations. A Relation database consists of relations that are appropriately structured." Database Systems, 1995, Thomas Connolly et al. Pag. 77.

Dat quot-en van je is naatje

[Soultaker]

alienfruit schreef op 20 July 2003 @ 02:47:
"Relational Databases: A collection of normalized relations. A Relation database consists of relations that are appropriately structured." Database Systems, 1995, Thomas Connolly et al. Pag. 77.

Dat quot-en van je is naatje

Care to explain? In hoeverre verschilt jouw citatie van de definitie die ik aanhaalde? (En wie is die meneer Connolly dat hij schijnbaar de wijsheid in pacht heeft?)

Wel prettig trouwens dat je nog even de term "normalized" erbij haalt, dat ondersteund mijn kritiek op Gordijnstok's aanpak weer.

[alienfruit]

Was een toevoeging Geen idee wie Connoly maar het boek was dik....

[justmental]

Heren Gordijnstok en Soultaker: het is duidelijk dat jullie gepassioneerde standpunten in deze materie hebben en de discussie is ook welkom, maar ik ben bang dat het uit de hand gaat lopen op deze manier.

Misschien is het handig als de discussie naar een nieuw topic verplaatst word, temeer omdat deze eigenlijk meer over de inrichting van een development traject ging.

Dus graag iets meer 'dat zie ik toch anders' en iets minder 'dom' en 'naar school sturen'

[Verwijderd]

ok dan hier nog een voorbeeld:

Het is de bedoeling dat users dingen kunnen researchen.
dit script heb ik al grotendeels klaar, maar ik twijfel hoe het zit met database-structuur. zoals het nu is:

[Database ResearchData]
[Tabel ResearchData]
<ReseachID><Name><Description><requirs><costs><timerequired>


[Database Researches]
[Tabel <UserName>]
<ID><Researched><Timeleft>

(de kolom-namen zullen denk ik voor zich spreken). ik heb dus in de database ResearchData alle mogelijke researches staan met elk een unieke ID, de kosten etc... (aan deze database word tijdens het spel weinig aan veranderd)

De database researches bevat een tabel voor elke user (nu met username, maar kan ook met een id) met daarin voor elke mogelijke research een rij.

(elk uur word dus gekeken of de research gestart is en zoja, dan word er een uur van de timeleft afgehaalt)

positief punt: -het werkt

negatief punt: -elke nieuwe user --> nieuwe tabel
-performance ?


de andere optie zou dus zijn 1 tabel met de researchdata (niet veel anders dan nu)
en dan 1 tabel met bijvoorbeeld : <userID><research1Completed><research1Timeleft> <research2...>

[ Voor 7% gewijzigd door Verwijderd op 20-07-2003 12:42 ]

[JaQ]

Soultaker schreef op 20 juli 2003 @ 04:03:
[...]

Care to explain? In hoeverre verschilt jouw citatie van de definitie die ik aanhaalde? (En wie is die meneer Connolly dat hij schijnbaar de wijsheid in pacht heeft?)

Wel prettig trouwens dat je nog even de term "normalized" erbij haalt, dat ondersteund mijn kritiek op Gordijnstok's aanpak weer.

Meneer Connolly heeft samen met mevrouw Begg en mevrouw Strachan het studieboek der studieboeken over database systemen geschreven. (Database systems, a practical approach to design, implementation and management). Ga niet blaten over mensen naar school sturen etc. als je dat boek niet kent. (of ben jij dan een zelfgeschoolde IT-er?) Goed, genoeg geflamed.

Op zich is het natuurlijk helemaal niet verkeerd om te kiezen voor een oplossing met metadata (object, attribute table structure). Zeker in het geval van een cms is dat over het algemeen een goede oplossing. Om te kunnen roepen of een dergerlijke generieke oplossing (zoals gordijnstok dat noemde) in deze van toepassing is, kan denk ik niet bepaald worden met de hoeveelheid data die we hier hebben gekregen van de TS.

Een case-tool, of design tool kan het database-ontwerp in deze duidelijker maken (een plaatje zegt meer dan duizend woorden was het toch?). Eventuele foutjes kan je gemakkelijker ontdekken dan door je blind te staren op een lijstje met tabellen. Of je nou voor Visio, ERWin, CASE of mijn part Oracle Designer kiest, moraal blijft dat je goed moet denken over je model. Het kan dus handig zijn om iemand met een beetje ontwerp-ervaring bij je groep van ontwikkelaars te gaan betrekken.


nog een stukje extra:
1 tabel per user is natuurlijk niet echt schaalbaar. Waarom voeg je niet gewoon de user-id of usernaam toe aan zo'n tabel als onderdeel van je primare sleutel. Dan heb je een schaalbare oplossing. Performance is echt niet zo'n probleem in deze (als je je indexen maar een beetje redelijk legt)

[ Voor 10% gewijzigd door JaQ op 20-07-2003 17:02 ]

[Soultaker]

Ok, jullie mogen het met mij oneens zijn, maar ik weiger een ontwerp dat alle constraints buiten de database specificeert te accepteren als relationeel database ontwerp. Het lijkt me niet echt zinnig om hier verder nog over te discussiëren, zeker aangezien ik zelf niet bereid ben om enige concessies te doen die er toe leiden dat ik het standpunt van Gordijnstok als "verschil van mening" zou moeten erkennen; ik vind zijn standpunt gewoon verkeerd.

Wie denkt dat zijn aanpak een zinnige manier is om een relationeel databasemodel in te richten moet vooral zijn gang gaan en die aanpak volgen, maar als dat de insteek is kan ik in ieder geval geen suggesties meer leveren waarvan ik zelf het idee heb dat ze zinnig zijn. No hard feelings, verder, maar discussieer gerust verder zonder mij. Ik hoor wel wat het eindresultaat is.

[Verwijderd]

Soultaker schreef op 20 July 2003 @ 17:59:
Ok, jullie mogen het met mij oneens zijn, maar ik weiger een ontwerp dat alle constraints buiten de database specificeert te accepteren als relationeel database ontwerp.

Ik wil hier gewoon vriendelijk op ingaan Ik ben het niet oneens met jouw voorstellen, alleen met de wijze waarop je mijn suggestie afkraakte.

Het ontwerp wat ik gebruik voor het CMS heeft zijn constraints niet buiten de database liggen, maar in de database zelf. Je mist denk ik ook de nodige informatie over dit model, aangezien je het niet hebt gezien.

Het model wat ik voorstelde kun je naar gelieven definieren icm contraints, triggers, wat je maar wilt. In mijn geval zitten er ook overal constraints op. Niets wordt buiten de database gecontroleerd.

[ Voor 42% gewijzigd door Verwijderd op 20-07-2003 18:34 ]

[Verwijderd]

Lauwe, ik merk aan je eerste post gelezen te hebben dat jullie ieder zijn eigen gedeelte ontwerpt en daarna proberen alles aan elkaar te plakken. Jullie beginnen dus met de kleine details en bouwen dat dan uit. Dat klinkt bij mij als een bottom-up approach. Ik zelf heb daar slechte ervaringen mee en ik raad het je ook af om op die manier verder te gaan. Zoals anderen al gezegd hebben zal je als je zo doorgaan later in de problemen komen dat alles niet goed meer op elkaar aansluit en loop je dus vast.
Ik zelf gebruik bijna altijd de top-down approach, ik begin met het grote beeld van het ontwerp en dan ga ik langzaam alles invullen (van de belangrijke tabellen, relaties, primary identifiers, attributen, e.d.). Zoals eerder ook al is gezegd is het handig om iemand met een beetje ontwerp ervaring bij je groep te betrekken.

Off topic:
Ik ben het met soultaker eens dat het ontwerp dat gordijnstok aangeeft niet echt als een correct ontwerp klinkt. Het is in gordijnstok's database mogelijk om een data entry aan een verkeerde instance entry en attribute entry wordt verbonden, de database zal dit gerust accepteren, dus dat dit niet gebeurd wordt niet door de database in de gaten gehouden (voor de database ziet het er helemaal correct uit) maar door de applicatie die de database gebruikt. Dit is hetzelfde geval als bij de relatie tussen instance en object en tussen attribute en object (dit alles als ik de relaties correct heb). Wat ik hiermee duidelijk probeer te maken is dat de integriteit van de database HELEMAAL NIET aanwezig is en dus in mijn ogen een compleet verkeerd ontwerp is. Het is een ontwerp met metadata en dat geeft wel de flexibiliteit die jij wilt hebben, maar ik zou liever een correct relationeel ontwerp met een correcte integriteit hebben. Als je extra functionaliteiten aan het CMS systeem wilt toevoegen dan mag je heus wel extra tabellen aanmaken die de data van die extra functionaliteit vasthoud. Je moet immers ook extra programmacode ontwikkelen.

Dit alles gebeurd tijdens het ontwikkelen van het system (ook al is de basis van het CMS systeem al aanwezig), maar als het systeem eenmaal in gebruik is dan is het niet de bedoeling om aan het database ontwerp te sleutelen. On topic: En dit sluit weer aan bij het idee om voor iedere gebruiker een aparte talen toe te voegen, dit is naar mijn idee geen goede methode. Het advies wat DrFrankenstoner geeft is wat ik ook aanraadt.

[Verwijderd]

allereerst bedankt voor alle replys

we zijn inderdaad een beetje onbezonnen begonnen. maar dit komt misschien ook omdat we toen we begonnen nog geen php en ook geen mysql kenden. we maken het met een groepje vrienden en het is tevens voor een project voor school.
we gaan het roer nu een beetje omgooien hoop ik en gaan toch cvs gebruiken en nog eens een keer goed praten voordat we weer gaan coden

[Verwijderd]

Iedereen schijnt te vergeten dat de 10 regels van meneer Codd geleid hebben tot datgene wat wij nu een relationeel ontwerp noemen, en niet meneer Conolly or whatever is name is. Codd werkte bij IBM in de '70 er jaren en zocht een oplossing voor de hierarchische tabellen structuur of zelfs de flatfile structuren die in die tijd gebruikt werden. Daarnaast is het normaliseren geen doel op zich, maar dient het voorkomen van redundantie, en in die tijd was schijfruimte zéér kostbaar. Wil je een grote database een redelijke performance laten houden is het toevoegen van redundantie vaak een goede oplossing.

Daarnaast zocht Codd naar een logische presentatie van data, die los zou staan van de fysieke opslagstructuur. Het correct toepassen van normalisatieregels dwingt wél een gestructureerd ontwerp af, iets dat zeker beginnende databaseknutselaars nogal eens overslaan, om later tegen problemen aan te lopen. En vaak liggen deze problemen op het gebied van referentiële integriteit.

Trouwens: hét boek over database dat op mijn universiteit (Liverpool) gebruikt wordt is:

'Database Systems: design, implementation and management', door P. Rob en C. Coronel.

[Verwijderd]

Ik heb het gevoel dat de TS nog niet zo heel veel ervaring heeft van software designen en alles wat daarom heen hangt. Relationele Databases inclusief.

Vandaar dat ik even met MS Access een klein figuurtje heb gemaakt over hoe je de relatie tussen users en, bijvoorbeeld, berichten in een messaging systeem moet zien. Het is namelijk niet gebruikelijk dat er per user een aparte tabel gemaakt wordt. Dit levert zelfs nog problemen op, omdat je dan zelf voor het beheer van die dynamisch aangemaakte tabellen moet zorgen.

Dit is de meest gangbare en makkelijke way to go:


Een user tabel komt er dan zo uit te zien:


Een message tabel komt er dan zo uit te zien:


Ik hoop dat je begrijpt wat ik bedoel. Het is in weze niet zo moeilijk denk ik, de plaatjes spreken voor zich.

Even voor de critici: nee, de database klopt niet overal en is niet volledig. Het is slechts een snel voorbeeld.

[Verwijderd]

bedankt voor de (mooi geillustreerde) uitleg

maar deze relaties had ik inderdaad ook al bedacht (is eigenlijk gekomen met het maken van een klein forum, iets dat ik gedaan heb na het messagesystem )

het virtuele land is opgedeeld in regios, elke regio heeft zijn eigen messageboard. een eerste design:



(hierbij zijn bij de Messages de MessageID en de TopicID een index en bij de Topics de TopicID en RegionID een index)

[ Voor 15% gewijzigd door Verwijderd op 21-07-2003 13:37 ]

[Verwijderd]

Lijkt me een prima ontwerp wat je hierboven schetste.

Eerst met het hele ontwikkelteam de database (volledig) ontwerpen (checken, checken en nog eens dubbel checken!) En dan met ze allen de grove lijnen uitzetten en detailleren (zoals al eerder gezegd, top-down benadering). Mocht je ondertussen de database nog een keer om moeten gooien dan moet je dat wel weer uitgebreid met je ontwikkelteam door spreken zodat iedereen met dezelfde database werkt en je geen wildgroei van gegevens krijgt.

Dus.... Wat is eigenlijk je vraag nog?

[SPee]

zoals het nu is:


quote:
--------------------------------------------------------------------------------

[Database ResearchData]
[Tabel ResearchData]
<ReseachID><Name><Description><requirs><costs><timerequired>


[Database Researches]
[Tabel <UserName>]
<ID><Researched><Timeleft>


--------------------------------------------------------------------------------


(de kolom-namen zullen denk ik voor zich spreken). ik heb dus in de database ResearchData alle mogelijke researches staan met elk een unieke ID, de kosten etc... (aan deze database word tijdens het spel weinig aan veranderd)

De database researches bevat een tabel voor elke user (nu met username, maar kan ook met een id) met daarin voor elke mogelijke research een rij.

Ik zou proberen zo weinig mogelijk databases te maken. Het zou wel mogelijk/handig zijn om de databases voor het spel en voor de users apart te houden. Maar dan moet je wel de relaties goed in de gaten blijven houden.

Maar ik zou die tabellen voor users gewoon in 1 tabel stoppen.
Zoals:

code:

[Database gebruikers]
[tabel users]
<id><naam>enz...

[Database gebruikers]
[tabel research]
<userid><[Database Researchdata]researchID><researched><timeleft>

En dan een grote unieke sleutel. Als je maar 1 keer kan researchen dan is alleen voor de eerste 2 genoeg. Anders over meer velden. Misschien dat je er ook een datum/tijdveld tussen kunt doen, zodat je die ook als primaire key kunt gebruiken. En evt. als checkpunt mocht je spel toch een keer stil komen te liggen.

[Verwijderd]

SPee schreef op 21 July 2003 @ 14:46:
[...]


Ik zou proberen zo weinig mogelijk databases te maken. Het zou wel mogelijk/handig zijn om de databases voor het spel en voor de users apart te houden. Maar dan moet je wel de relaties goed in de gaten blijven houden.

Maar ik zou die tabellen voor users gewoon in 1 tabel stoppen.
Zoals:

code:

[Database gebruikers]
[tabel users]
<id><naam>enz...

[Database gebruikers]
[tabel research]
<userid><[Database Researchdata]researchID><researched><timeleft>

En dan een grote unieke sleutel. Als je maar 1 keer kan researchen dan is alleen voor de eerste 2 genoeg. Anders over meer velden. Misschien dat je er ook een datum/tijdveld tussen kunt doen, zodat je die ook als primaire key kunt gebruiken. En evt. als checkpunt mocht je spel toch een keer stil komen te liggen.

waarschijnlijk komt alles in 1 of 2 databases inderdaad.

Verwijderd schreef op 21 July 2003 @ 14:22:
Lijkt me een prima ontwerp wat je hierboven schetste.

Eerst met het hele ontwikkelteam de database (volledig) ontwerpen (checken, checken en nog eens dubbel checken!) En dan met ze allen de grove lijnen uitzetten en detailleren (zoals al eerder gezegd, top-down benadering). Mocht je ondertussen de database nog een keer om moeten gooien dan moet je dat wel weer uitgebreid met je ontwikkelteam door spreken zodat iedereen met dezelfde database werkt en je geen wildgroei van gegevens krijgt.

Dus.... Wat is eigenlijk je vraag nog?

het "probleem" is opgelost