Hallo und guten Tag, > Direkt gestreut? Was ist das, eine Mischung aus Direktzugriff und Hashing? Das ist ein Fachbegriff der Informatik um ca. 1970, also von den ersten Bandanlagen bis hin zum IBM XT mit 10MB-Festplatte. Der scheint so _alt_ und etabliert zu sein (in meinen Fachbüchern steht er drin), dass sogar Google ihn nicht kennt. Die Amis nannten das wohl "Random Access File", was es aber nicht genau trifft. Google ist ja auch erst ca. 35 Jahre später erfunden worden! > Du wirst wohl eher eine Datei mit direktem Zugriff meinen (d.h. die Speicherposition wird eineindeutig und kollisionsfrei aus den Dateninhalten bestimmt, bei Hashing kann es Kollisionen geben). Mit Dateninhalten hat die Position nichts zu tun, sondern nur mit der (festen) Blockgröße des Datensatzes. Ob da etwas drinsteht, oder die Datenfelder leer sind, ist unerheblich. Aber jeder Datensatz hat eine feste Größe und damit auch einen festen Aufsetzpunkt in der Datenspeicherung. Ob die Felder darin auch eine feste Größe haben, oder sich die Gesamtgröße des Datensatzes teilen, ist dann die nächste Entwicklungsstufe. > Aber warum brauchst Du überhaupt eine Fragentabelle? Wenn User A gegen User B spielt und gleichzeitig irgendwo anders der User C gegen User D, spricht doch nichts dagegen, wenn beide die gleiche Frage bekommen. Die Aufgabenstellung stammt nicht von mir. Wenn es Bedingung ist, dass jede Frage nur genau einmal gespielt werden darf, reicht die direkt gestreute Datei dafür aus. Wenn dann auch noch Historie für die User, für das Spiel usw. geschrieben werden soll, benötigt man ggf. weitere Dateien. > Der Fragengenerator muss ein paar Fragen auswürfeln und dann für A UND B (bzw. für C UND D) prüfen, ob ihnen diese Fragen neu sind. Um das zu prüfen, brauche ich keine übergreifende Fragentabelle, nur die gespielten Fragen pro User. Wenn die Fragen öfter gespielt werden dürfen, reicht das aus. Wenn jede Frage nur einmal gespielt werden darf, benötigt man auch eine Eigenschaftentabelle für die Fragen. Eine einwertige Eigenschaft kann man dann selbstverständlich direkt in der Fragentabelle mit unterbringen. Für mehrwertige Eigenschaften benötogt man ggf. zusätzliche Tabellen. > Allerdings haben wir ja mittlerweile auch gelernt, dass sich die Fragen in der App wiederholen Das ist aber so in der ursprünglichen Aufgabenstellung noch nicht geändert worden. Grüße TS -- es wachse der Freifunk <http://freifunk-oberharz.de>

Hallo und guten Tag, > Direkt gestreut? Was ist das, eine Mischung aus Direktzugriff und Hashing? Das ist ein Fachbegriff der Informatik um ca. 1970, also von den ersten Bandanlagen bis hin zum IBM XT mit 10MB-Festplatte. Der scheint so _alt_ und etabliert zu sein (in meinen Fachbüchern steht er drin), dass sogar Google ihn nicht kennt. Die Amis nannten das wohl "Random Access File". Google ist ja auch erst ca. 35 Jahre später erfunden worden! > Du wirst wohl eher eine Datei mit direktem Zugriff meinen (d.h. die Speicherposition wird eineindeutig und kollisionsfrei aus den Dateninhalten bestimmt, bei Hashing kann es Kollisionen geben). Mit Dateninhalten hat die Position nichts zu tun, sondern nur mit der (festen) Blockgröße des Datensatzes. Ob da etwas drinsteht, oder die Datenfelder leer sind, ist unerheblich. Aber jeder Datensatz hat eine feste Größe und damit auch einen festen Aufsetzpunkt in der Datenspeicherung. Ob die Felder darin auch eine feste Größe haben, oder sich die Gesamtgröße des Datensatzes teilen, ist dann die nächste Entwicklungsstufe. > Aber warum brauchst Du überhaupt eine Fragentabelle? Wenn User A gegen User B spielt und gleichzeitig irgendwo anders der User C gegen User D, spricht doch nichts dagegen, wenn beide die gleiche Frage bekommen. Die Aufgabenstellung stammt nicht von mir. Wenn es Bedingung ist, dass jede Frage nur genau einmal gespielt werden darf, reicht die direkt gestreute Datei dafür aus. Wenn dann auch noch Historie für die User, für das Spiel usw. geschrieben werden soll, benötigt man ggf. weitere Dateien. > Der Fragengenerator muss ein paar Fragen auswürfeln und dann für A UND B (bzw. für C UND D) prüfen, ob ihnen diese Fragen neu sind. Um das zu prüfen, brauche ich keine übergreifende Fragentabelle, nur die gespielten Fragen pro User. Wenn die Fragen öfter gespielt werden dürfen, reicht das aus. Wenn jede Frage nur einmal gespielt werden darf, benötigt man auch eine Eigenschaftentabelle für die Fragen. Eine einwertige Eigenschaft kann man dann selbstverständlich direkt in der Fragentabelle mit unterbringen. Für mehrwertige Eigenschaften benötogt man ggf. zusätzliche Tabellen. > Allerdings haben wir ja mittlerweile auch gelernt, dass sich die Fragen in der App wiederholen Das ist aber so in der ursprünglichen Aufgabenstellung noch nicht geändert worden. Grüße TS -- es wachse der Freifunk <http://freifunk-oberharz.de>

Hallo und guten Tag, > Direkt gestreut? Was ist das, eine Mischung aus Direktzugriff und Hashing? Das ist ein Fachbegriff der Informatik um ca. 1970, also von den ersten Bandanlagen bis hin zum IBM XT mit 10MB-Festplatte. Der scheint so _alt_ und etabliert zu sein (in meinen Fachbüchern steht er drin), dass sogar Google ihn nicht kennt. Google ist ja auch erst ca. 35 Jahre später erfunden worden! > Du wirst wohl eher eine Datei mit direktem Zugriff meinen (d.h. die Speicherposition wird eineindeutig und kollisionsfrei aus den Dateninhalten bestimmt, bei Hashing kann es Kollisionen geben). Mit Dateninhalten hat die Position nichts zu tun, sondern nur mit der (festen) Blockgröße des Datensatzes. Ob da etwas drinsteht, oder die Datenfelder leer sind, ist unerheblich. Aber jeder Datensatz hat eine feste Größe und damit auch einen festen Aufsetzpunkt in der Datenspeicherung. Ob die Felder darin auch eine feste Größe haben, oder sich die Gesamtgröße des Datensatzes teilen, ist dann die nächste Entwicklungsstufe. > Aber warum brauchst Du überhaupt eine Fragentabelle? Wenn User A gegen User B spielt und gleichzeitig irgendwo anders der User C gegen User D, spricht doch nichts dagegen, wenn beide die gleiche Frage bekommen. Die Aufgabenstellung stammt nicht von mir. Wenn es Bedingung ist, dass jede Frage nur genau einmal gespielt werden darf, reicht die direkt gestreute Datei dafür aus. Wenn dann auch noch Historie für die User, für das Spiel usw. geschrieben werden soll, benötigt man ggf. weitere Dateien. > Der Fragengenerator muss ein paar Fragen auswürfeln und dann für A UND B (bzw. für C UND D) prüfen, ob ihnen diese Fragen neu sind. Um das zu prüfen, brauche ich keine übergreifende Fragentabelle, nur die gespielten Fragen pro User. Wenn die Fragen öfter gespielt werden dürfen, reicht das aus. Wenn jede Frage nur einmal gespielt werden darf, benötigt man auch eine Eigenschaftentabelle für die Fragen. Eine einwertige Eigenschaft kann man dann selbstverständlich direkt in der Fragentabelle mit unterbringen. Für mehrwertige Eigenschaften benötogt man ggf. zusätzliche Tabellen. > Allerdings haben wir ja mittlerweile auch gelernt, dass sich die Fragen in der App wiederholen Das ist aber so in der ursprünglichen Aufgabenstellung noch nicht geändert worden. Grüße TS -- es wachse der Freifunk <http://freifunk-oberharz.de>

Hallo und guten Tag, > Direkt gestreut? Was ist das, eine Mischung aus Direktzugriff und Hashing? Das ist ein Fachbegriff der Informatik um ca. 1970, also von den ersten Bandanlagen bis hin zum IBM XT mit 10MB-Festplatte. Der scheint so _alt_ und etabliert zu sein (in meinen Fachbüchert steht er drin), dass sogar Google ihn nicht kennt. Google ist ja auch erst ca. 35 Jahre später erfunden worden! > Du wirst wohl eher eine Datei mit direktem Zugriff meinen (d.h. die Speicherposition wird eineindeutig und kollisionsfrei aus den Dateninhalten bestimmt, bei Hashing kann es Kollisionen geben). Mit Dateninhalten hat die Position nichts zu tun, sondern nur mit der (festen) Blockgröße des Datensatzes. Ob da etwas drinsteht, oder die Datenfelder leer sind, ist unerheblich. Aber jeder Datensatz hat eine feste Größe und damit auch einen festen Aufsetzpunkt in der Datenspeicherung. Ob die Felder darin auch eine feste Größe haben, oder sich die Gesamtgröße des Datensatzes teilen, ist dann die nächste Entwicklungsstufe. > Aber warum brauchst Du überhaupt eine Fragentabelle? Wenn User A gegen User B spielt und gleichzeitig irgendwo anders der User C gegen User D, spricht doch nichts dagegen, wenn beide die gleiche Frage bekommen. Die Aufgabenstellung stammt nicht von mir. Wenn es Bedingung ist, dass jede Frage nur genau einmal gespielt werden darf, reicht die direkt gestreute Datei dafür aus. Wenn dann auch noch Historie für die User, für das Spiel usw. geschrieben werden soll, benötigt man ggf. weitere Dateien. > Der Fragengenerator muss ein paar Fragen auswürfeln und dann für A UND B (bzw. für C UND D) prüfen, ob ihnen diese Fragen neu sind. Um das zu prüfen, brauche ich keine übergreifende Fragentabelle, nur die gespielten Fragen pro User. Wenn die Fragen öfter gespielt werden dürfen, reicht das aus. Wenn jede Frage nur einmal gespielt werden darf, benötigt man auch eine Eigenschaftentabelle für die Fragen. Eine einwertige Eigenschaft kann man dann selbstverständlich direkt in der Fragentabelle mit unterbringen. Für mehrwertige Eigenschaften benötogt man ggf. zusätzliche Tabellen. > Allerdings haben wir ja mittlerweile auch gelernt, dass sich die Fragen in der App wiederholen Das ist aber so in der ursprünglichen Aufgabenstellung noch nicht geändert worden. Grüße TS -- es wachse der Freifunk <http://freifunk-oberharz.de>