Verwendung von Typen II ( Datenstruktur )
Übersicht
BlitzBasic FAQ und Tutorials
2paulBetreff: Verwendung von Typen II ( Datenstruktur ) |
 Fr, Okt 01, 2004 9:00Antworten mit Zitat 
|
|
|---|---|---|
|
wie es ja zum guten ton gehört,
zu beginn der literaturhinweis... Dr. Prof. Matthiessen "Relationale Datenbanken und SQL" Addision Wessley ( dekan der HS Bremerhaven, mein Kryptologie, C++, Datenbank und Theoretische Informatik Prof übrigens supercooler typ ) ok, warum verweise ich auf ein datenbank-buch ??? typen ( oder wie in C++ struct ) und tabellen von datenbanken sind eigentlich das selbe, lassen sich auf jeden fall genauso verwenden. und da es bei meinem heutigen tutorial eher um struktur als um programmier-techniken gehen soll, ist dieses buch sicher eine bereicherung in vielerlei bereichen, nicht nur für datenbanken, sondern auch für die organisation einer datenstruktur. ich werde das mal wieder an einem beispiel machen, diesmal der fussball-manager, der hat klar hierachisch organisierte daten. ich habe ligen, die enthalten vereine und ich habe vereine die enthalten spieler spieler können vereine welchseln, verändern aber nicht ihre grundsätzlichen attribute ( name, geburtsdatum, bild, ....) vereine können ligen welchseln, aufsteigen oder absteigen, verändern aber auch nicht ihre attribute ( logo, name, stadion,...) eine liga hat erstmal keine grundsätzlichen attribute, es ist einfach ein zusammenschluss von 18 vereinen. wie bau ich das nun am besten auf ???? fangen wir bei den spielern an. ich schaffe einen typ (tabelle) SPIELER, der bekommt eben die felder , NAME, GEB_DATUM,BILD,usw..., eben genau die werte, die mit dem spieler fest verbunden sind, z.b. auch ANGRIFFSSTÄRKE oder TORE genauso mach ich das mit den VEREINEN. die bekommen eben NAME, STADION_NAME, MITGLIEDER,usw.... auch nur die Daten, die fest mit dem verein verbunden sind. so, und dann brauch ich nur noch 2 verknüfungs-tabelle(typen). einmal LIGA_VEREIN und einmal VEREIN_SPIELER beide brauchen nur 2 datenfelder (fields) LIGA_VEREIN bekommt LIGA und VEREIN VEREIN_SPIELER bekommt VEREIN und SPIELER so....und um das ganze professionell zu gestalten, nehmen wir nicht irgendwelche namen als verweise, sondern wir vergeben nummern (ID´s) jeder SPIELER, VEREIN, LIGA erhält eine ID, eine eindeutige nummer. diese ID muss zusätzlich zu den unveränderlichen attributen hinzugefügt werden, und dient als hilfsmittel für die verweis-tabellen(typen) ok, machen wir das ganze mal mit ein wenig syntax 4 vereine mit jeweils einem spieler in 2 ligen, jede liga 2 vereine Code: [AUSKLAPPEN] Typ LIGA_VEREIN Field LIGA Field VEREIN End Type Type VEREIN_SPIELER Field VEREIN Field SPIELER End Type Type SPIELER Field ID Field NAME Field GEB_DATUM End Type Type VEREIN Field ID Field NAME Field STADION_NAME End Type soooo, die SPIELER und VEREINE fülle ich mal nicht mit daten, jeder wird sicher genug spieler und vereine kennen, bleiben die verweise und ID´s jeder spieler erhält eine ID, sagen wir 1,2,3,4 jeder verein erhält eine ID, sagen wir 1,2,3,4 jede liga erhält eine ID, sagen wir 1,2 der SPIELER mit der ID 1 spielt in VEREIN mit der ID 1, SPIELER ID 2 in VEREIN ID 2, usw VEREIN ID 1 und 2 spielen in der LIGA 1 und VEREIN ID 3 und 4 spielen in LIGA 2 ich schreibs mal in tabellenform LIGA_VEREIN : LIGA VEREIN 1 1 1 2 2 3 2 4 VEREIN_SPIELER : VEREIN SPIELER 1 1 2 2 3 3 4 4 damit ist dann alles klar, jeder spieler ist in einem verein und verein hat eine liga, welchselt nun ein spieler den verein, brauch ich nur die verweistabelle(type) VEREIN_SPIELER ändern #### abfragen : nehmen wir also mal an, irgendwann möchte ich die namen aller spieler der 1. liga finden dann muss man mit verschachtelten For-schleifen arbeiten. Code: [AUSKLAPPEN] For l_v.LIGA_VEREIN = Each LIGA_VEREIN If l_v\LIGA = 1 For v_s.VEREIN_SPIELER = Each VEREIN_SPIELER If v_s\VEREIN = l_v\VEREIN For s.SPIELER = Each SPIELER If v_s\SPIELER = s\ID Print s\NAME Endif Next Endif Next Endif Next ok, naürlich wäre is in diesem kleinen beispiel einfacher die ligen in dem vereins-type zu speichern und dort zu verändern. jedoch macht sich dieses stukturierte arbeiten bei grösseren projekten und grösserer anzahl von attributen(Fields) bezahlt. einmal natürlich dadurch, dass sich die geschwindigkeit der abfragen erhöht (kleinere listen,tabellen). andererseits ist es mir durch diese struktur überhaupt erst möglich gewisse abfragen zu machen. nehmen wir dazu mal als schlechtes gegenbeispiele, einen Typen -> SPIELER, geht auch.... Code: [AUSKLAPPEN] Type SPIELER Field LIGA Field VEREIN_NAME Field STADION_NAME Field SPIELER_NAME usw... ihr merkt schon (hoffe ich) wie sich das in alle ewigkeit weiterziehen würde, und ich 1000 mal (für jeden spieler einzeln) den vereinsnamen und stadionnamen usw aufführen müsste, obwohl diese info nur einmal gebraucht wird... sowas nennt sich "redundate datenhaltung" und sollte vermieden werden sooo, um das ganze vielleicht auch noch mal auf die spitze zu treiben, sagen wir, ich möchte in meinen Typen auch noch festhalten, in welcher partie welcher spieler ein tor geschossen hat.... nach dem oben erklärten aufbau würde wir nur einen verweis-typen schaffen. Code: [AUSKLAPPEN] Type SPIELTAG_SPIELER_TOR Field SESSION Field SPIELTAG Field PARTIE Field SPIELER End Type und bei jedem tor einen neuen eintrag generieren nehmen wir nun unser denkbar schlechtes beispiel mit einer tabelle(typen) ich müsste entweder ein maximum definieren, 40 tore pro sessions als beispiel, um diese felder frei zu halten und dann müsste ich noch die sessions definieren, wenn ich das dann für 20 sessions machen wollen würde, hätte man 2400 datenfelder pro spieler, die zu 90% während der gesamten spielzeit leer blieben.... 3 datenfelder für jeden eintrag (SESSION,SPIELTAG,PARTIE) und das für 20 session mit maximal 40 toren, sind 3 * 20 * 40 = 2400 datenfelder das wäre die eine möglichkeit.... oder ich bin ganz clever und nehme diesen datensatz nur einmal SESSION,SPIELTAG,PARTIE, und generiere jedesmal einen neuen eintrag bei den SPIELERN, wenn einer ein tor geschossen hat. dann müsste ich aber jedesmal wieder all die anderen dinge wieder speichern, wie NAME, GEB_DATUM,usw... ich weiss, das is am anfang ziemlich starker tobak, aber wenn das prinzip dieser struktur einmal klar ist, macht es das arbeiten mit grösseren datensätzen erheblich einfacher... ( zum teil überhaupt erst möglich ) ich würde mich über rückfragen freuen, obwohl ich ja auch nicht mehr allzu oft hier bin, ( muss mich um mein projekt kümmern ) also bitte ein wenig geduld, ich werde auf alle fälle antworten... okisens paule |
||
Übersicht
BlitzBasic FAQ und Tutorials
Powered by phpBB © 2001 - 2006, phpBB Group