Ergebnis 1 bis 9 von 9

Thema: Codierung, Optimierung, Indizierung

  1. #1
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.935
    Renommee
    283

    Codierung, Optimierung, Indizierung

    Hoi,

    finde leider nur wenig Material in Sachen Datenbank-_Codierung_ etc.

    Bislang bin ich so weit, dass ich die Logik der Binärbäume auf die Codierung der Datenbank-Elemente bringe, indem ich je nach aktueller "Größe" entscheide,
    ob die nächsten Suchläufe in positiver Richtung gegen Datei-Ende oder in negativer Richtung rückwärts hin zum Anfang laufen (angenommen, alles ist sortiert).

    Ich frage mich nun v.a., welche Indizierungs- und/oder Optimierungs-Möglichkeiten noch für Datenbank(en/-Codierungen) bestehen?

    Klar, Bäume sind die eine Sache ... dadurch schränkt sich der Suchbereich mit jeder Sub-Ebene weiter ein - so dass umso weniger Elemente zu durchsuchen
    sind. Aber wenn ich eine Datenbank mit nur einer einzigen Ebene von Schlüssel-Indices hätte, wie könnte ich hier weiter optimieren (oder auch passende Hash-
    Funktionen finden), damit nicht (im schlechtesten Falle) alle Einträge erstmal durchlaufen werden müssen?

    Meine Überlegung war schon, von o.g. Anwendung der Binärbaum-Logik in ternäre, quaternäre etc. Bäume zu gehen. Und ich habe auch überlegt, dass ich eine
    Ameisen-Zell-Automation verwende, um auf Basis der DB-Queries jeweils quasi (Ameisen-)"Duftspuren" zu hinterlassen, also eine weitere Form von Indizierung,
    so dass kommende Suchläufe entsprechend schneller zu Ergebnissen führen könnten.

    Bin nicht sicher, aber vermutlich hat jede schon verfügbare Datenbank unzählige Algorithmen/Strukturen zum effizienten Finden von Einträgen, oder? Gibt's hier-
    zu evtl. eine Übersicht oder so (wie gesagt, finde im Web dazu nur schwierig etwas konkretes)?

    Grüßle;

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  2. #2
    Registered User
    Registriert seit
    Aug 2002
    Beiträge
    2.207
    Renommee
    622

    AW: Codierung, Optimierung, Indizierung

    Es kommt maßgeblich darauf an, wie die Daten persistent gespeichert und gepuffert werden.
    Mehr Infos dazu würden mich auch sehr interessieren.

    Als Anregungen:

    Die meiste Performance kann man sicherlich durch die Verwendung von möglichst primitiven Datentypen und beim parallelen Zugriff rausholen.
    Aus deiner Sicht aber mit Verlaub vor allem das verwenden von nativen Funktionen (Systembibliotheken) die von den Compilern gut optimiert werden können.
    Man sollte auch bedenken das Daten schnell geschrieben und auch schnell wieder gelesen werden müssen.
    Jeder Overhead beim Speichern bedeutet also auch Verluste beim Lesen.
    Ich will aber nicht Wissen wie oft bei dem Thema schon: "könnte" gesagt wurde.
    Wenn ich was sage, will das was heißen.

  3. #3
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.935
    Renommee
    283

    AW: Codierung, Optimierung, Indizierung

    Mehr Infos dazu würden mich auch sehr interessieren.
    Ich sage mal was zu mir: neben einer direkten Sortierung und dem Ameisen-Automaten-Routing (mit hinein codieren der QUERY-Pfade in die DB)
    war noch eine Idee, dass ich bspw. mindestens(!) je Datensatz/Record mit einer LENGTH-Codierung beginne, die also die Größe jedes Records
    direkt mit angibt. Dadurch kann ich ganz schnell von Offset zu Offset springen, ohne weiter nach eventuellen Extra-Markierungen suchen zu müssen.

    Der Vorteil an "LENGTH" ist auch - im Gegensatz zur Codierung _absoluter_ Werte (alles liegt im Relativismus!!) - dass man dann auch nur den einen
    Wert zu verändern hätte. Also bei absoluten Offsets müsste man direkt eine größere Werte-Anzahl direkt mit anpassen. Der Relativismus - der somit
    weg vom Absoluten führt - ist auch ein "Leitsatz" bei mir (in meinem Q-Projekt) - sogar die Codierungen selbst sollten bestenfalls in relative Differenz-
    Werte gelegt werden.

    Aber gut. Ich bin sicher, ich muss einfach meine eigene DB verwenden. Wird mir aber Spaß machen (so wenig Web-Links es auch gibt), mir da noch
    selbst weitere, eigene Gedanken zu machen. (^_^).

    OffTopic:

    Eine andere "Skalierung" verwende ich auch noch ... geht in Richtung NoSQL (fast?) usw. ... während MySQL für jedes Attribut eine eigene Tabellen-
    Spalte benötigt, würde ich nur (erstmal ca.) eine einzige verwenden, in welcher man selbst variable Attribute angeben kann. Das hieße dann zwar, im
    Falle eines gesuchten "Object" o.ä. gäbe es mehrere Ergebnis-Datensätze statt nur einem - aber dafür kann dann dynamisch mit den Spalten/Attrib.
    umgegangen werden. Keine festgelegte Ordnung also (fast schon Dokumente-basiert o.ä.).

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  4. #4
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.935
    Renommee
    283

    AW: Codierung, Optimierung, Indizierung

    Database.jpg

    Es kommt maßgeblich darauf an, wie die Daten persistent gespeichert und gepuffert werden. Mehr Infos dazu würden mich auch sehr interessieren.
    Ist mir klar ... interessante Betrachtung liegt ja m.E. darin, dass man mit (selbst erfundenen *g*) Datenstrukturen innerhalb der Software agier und diese dann nur
    noch zu (de-)serialisieren habe. Aber das Problem ist halt eben auch die Codierung selbst, wie du schon schriebst.

    Deine Idee des parallelen Zugriffs ist natürlich *super*! Wie meinst du das aber mit den primitiven Datentypen? Warum sollte das insgesamt effizienter sein - und
    geht das nicht sowieso in die Richtung "atomar", also möglichst kleine Einheiten zu bilden?

    Aus deiner Sicht aber mit Verlaub vor allem das verwenden von nativen Funktionen (Systembibliotheken) die von den Compilern gut optimiert werden können.
    Man sollte auch bedenken das Daten schnell geschrieben und auch schnell wieder gelesen werden müssen.
    Nope, das möchte ich doch nur ungerne. ... ich muss eigenhändig eigene Optimierungen finden. ... Daten(sätze) schnell lesen und schreiben ist auch klar - ich habe
    auch daran gedacht, den RAM zu nutzen, um dann aus Zugriffs-Zählungen heraus die "akutesten" Daten so schneller erreichbar zu halten.

    Jeder Overhead beim Speichern bedeutet also auch Verluste beim Lesen.
    Ich würde aber am liebsten direkt mit dem Einfügen neuer Datensätze "alphabetisch" in die DB hinein sortieren - und denke, das ist zwar der von dir genannte Overhead,
    aber es würde sich später IMHO rentieren - oder!?

    OffTopic:
    Bei mir ist die Datenbank essentiell, da ich hier alle meine Software-Objekt-Instanzen und ihre Werte etc. in der Datenbank "virtualisiere" - d.h. auch, dass sie somit
    persistent bleiben, selbst wenn die Software mal endet. Außerdem kann man so eine schier unzählbare Menge von Instanzen etc. verwalten, ohne dass jemals der RAM
    leer geht ...

    Bis jetzt weiß ich jedenfalls, dass _Indizierung_ *das* entscheidende Merkmal bei Datenbanken ist ... aber wenn ich selbst eine Volltext-Indizierung gestalten wollte, so
    bliebe das Problem, dass unzählig viele Wörter (in diesem Falle) auf einer Dimension lägen - und somit nicht so effizient wie in Bäumen zugreifbar wären - und wie dann
    v.a. optimal indiziert werden kann, das ist nochmal 'ne andere Frage ...


    Aber danke, Enchanter, schön "nicht allein zu sein" (mit seiner Problematik/Fragestellung) *g*. Grüße dich btw., hoffe, es geht dir gut? Schreib mir doch mal wieder in Facebook. :-)

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  5. #5
    Registered User
    Registriert seit
    Aug 2002
    Beiträge
    2.207
    Renommee
    622

    AW: Codierung, Optimierung, Indizierung

    Die bekannten Datenbanken arbeiten imho fast nur in einem Puffer im RAM.
    Das Problem ist aber die Abbildung auf dem persistenten Speicher.
    Was mich daran immer interessierte ist, wie die Relationen auf tieferer Ebene zustande kommen.
    Den Zugriff auf einen Index, stelle ich mir immer wie eine Schleife vor.
    Ich glaub aber das es viel tiefer gehen kann.

    Das der Volltext Index nicht weit verbreitet ist hat imo auch seinen Grund.
    Eine Schleife von 0-15 wird ein Computer immer schneller durchlaufen als von a-z. Genauso verhält es sich mit dem Speichern.
    Wenn du in deiner "LENGTH" am Ende 22:Spalte:wert in einer Datei stehen hast, hast du es dir definitiv zu einfach gemacht.
    Wenn du nach einem bspw. fgets, einem Cast und zwei Substraktionen, schon weißt wo der Wert zu finden ist und wie lang dieser vorraussichtlich ist, bist du wahrscheinlich schon dichter dran.
    Alles was das Programm vorher evaluieren muss ist halt ein Performance Killer.
    Mich interessiert vor allem die Implementierung von Relationen und die Speicher Formate der bekannten Engines.
    Einen Binär Dump kann ich zb. nicht lesen.
    Eine KI die voraussehen kann, wo zuvor fragmentierter Speicher zu finden ist, Kann ich mir ohne unbegrenzten Speicherplatz auch nicht vorstellen.
    Wenn ich was sage, will das was heißen.

  6. #6
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.935
    Renommee
    283

    AW: Codierung, Optimierung, Indizierung

    Das Problem ist aber die Abbildung auf dem persistenten Speicher.
    JA, das auch! Immerhin, wenn ich direkt auf's "Block Device" (/dev/sd*) zugreife, habe ich mit der ganzen Fragmentierung zu kämpfen. Wozu ich mir aber überlegt hatte,
    ich verwende eine (einstellbare) "BlockSize", die dann aber ständig auf's ganze Dateisystem wirkt, damit ich am einfachsten die Bytes hin und her verschieben kann. So
    gedacht, wenn alle Blöcke gleiche Länge haben, dann kann ich sie theoretisch absolut beliebig verschieben - also wenn ich meine Blöcke in ihrer Daten-Kausalität
    von Offset zu Length verfolgen würde.

    Andererseits, der Vorteil im direkten Zugriff ist - zumindest kann man daraus IMHO Vorteile ziehen und Potentiale nutzen - dass man beliebig weiter auf die HDD-"Offsets"
    zugreifen kann - sprich, es müssen keine Lücken gefüllt werden. Da denke ich bspw. direkt an eine Segmentierung o.ä. so weit, dass z.B. je höher der Offset wird (also
    je weiter es in Richtung "Ende" der Festplatten-Größe geht), umso größere, zusammenhängende Datenmengen könnte ich hier speichern. Während alles in einer Nähe
    zum Anfang der HDD für kleinere Datensätze verwendbar wäre. Bspw. ...

    Was mich daran immer interessierte ist, wie die Relationen auf tieferer Ebene zustande kommen. Den Zugriff auf einen Index, stelle ich mir immer wie eine Schleife vor.
    Bin nicht ganz sicher, was du meinst - aber klingt "nett". ... Relationen sind m.E. eine Form der "Abbildung". Wir müssen also bspw. zwei Zeiger verwenden, nennen wir sie [0] und [1]
    (als Alternative zu "A → B", damit wir hier bei anderen Zahlen-Indices direkt weitere Dimensionen (und "Wertigkeiten") ersichtlich hätten. Und damit "ist schon definiert", dass der Wert
    des ersten Zeigers eine Abbildung auf den Wert beim zweiten Zeiger ist. Somit entsteht eine (hier erstmal direkte) Zuweisung - ob nun betrachtet wie "key = value" oder auch Zeit/Kausalität,
    also die Veränderung von Wert "A → B". So setze ich mal an, um das besser zu verstehen und evtl. noch ausweiten zu können (kloar!! ;-)´ Bspw. kann man jetzt direkt unterscheiden zwischen
    einfacher Daten-Abbildung, wo die Werte alle Ergebnisse bzw. Veränderungen mit definieren - oder wir könnten statt oder auch zusätzlich zur einfachen, e.g. Form in dynamische Funktionalität
    gehen - hier wäre z.B. ein Ansatzpunkt, um ... (a) mathematische Zeiger-Adressen- oder Werte-Zuweisungen zu manipulieren (bis hin zum "Map()" der Ergebnis-Views) ... (b) direkt neuronale
    Übergangsfunktion (von mir aus altbekanntes Sigmoid) mit zu platzieren ... wozu ich übrigens überlege, dass Neuronen wie Transistoren einfach nur "Schalter" sind, jedoch mit mehr als nur 2x
    Zuständen und bewertend/gewichtend verbindend, was zusammenhängend platziert ist (sozusagen *omg*). Quanten-(zustands-)system eben. :-)´

    Wie aber stellst du dir deine Index-Schleife vor!? Du meinst, die Datensätze müssen immer wieder quer durchlaufen werden, um zum Query passende Ergebnis-VIEWs zurück zu geben!?? Joa;
    so wirkt das auch für mich, gerade mit logischen Verknüpfungen; hier denke ich direkt auch noch an (erwähnte) "Abbildung" - meine Form von DB-Zugriffen sähe so aus, dass ich zu-
    erst die gewünschten Attribute in einzelne Querys (bis hin zum "Statement", wie beim Scripting) logisch verknüpfe, um eine Datensatz-Filterung ablaufen zu lassen - und dazu definiere ich quasi
    als (rechte) Zuweisungs-Seite meine "Map()-"Filter"-Abbildungen - also bloß eine Adaption einzelner Attribute nach wiederum logischen Regeln. Aber gut, so denke ich (irgendwie.....) xD´ ... hier
    wirste wohl kaum weiter kommen; aber interessant ist das Thema allemal, fast sogar das interessanteste Überhaupt - mindestens aber eine Denksport-Aufgabe, die es in sich hat. Ich mach ganz
    viel noch weiter in diesem Gebiet! :-D°

    Wenn du in deiner "LENGTH" am Ende 22:Spalte:wert in einer Datei stehen hast, hast du es dir definitiv zu einfach gemacht.
    Wenn du nach einem bspw. fgets, einem Cast und zwei Substraktionen, schon weißt wo der Wert zu finden ist und wie lang dieser vorraussichtlich ist, bist du wahrscheinlich schon dichter dran.
    Alles was das Programm vorher evaluieren muss ist halt ein Performance Killer.
    Ich werde mir dieses beizeiten nochmal gut durch denk Kopf gehen lassen. Mal sehen, wohin mich das noch führt.

    Mich interessiert vor allem die Implementierung von Relationen und die Speicher Formate der bekannten Engines.
    Einen Binär Dump kann ich zb. nicht lesen.
    Eine KI die voraussehen kann, wo zuvor fragmentierter Speicher zu finden ist, Kann ich mir ohne unbegrenzten Speicherplatz auch nicht vorstellen.
    Unbegrenzter Speicher entsteht in (meinem) Quantensystem erst aus der Verwendung von immer mehr Speicher. Das ist genau das Gleiche wie beim Gehirn: je mehr man weiß (also Daten bis-
    lang gesichert hat), umso effizienter kann man denken. Und umso mehr freier Speicher entsteht auch, weil man auf bereits vorhandener ... ich sage mal "Entropie" ... aufbauen kann. "Zwischen"
    den Werten liegt der (ewige) freie Platz - man muss im Prinzip nur Differenzen codieren/indizieren/... und dabei Abstraktions-Denkprozesse beschreiben, wo Gemeinsamkeiten zu gemeinsamen
    Codierungen zusammen gelegt werden (neuer Speicher entsteht hier also, weil weniger Platz benötigt wird - weniger Redundanz dabei auch), während die Konkretion (als der entgegen gesetzte
    Denkprozess) nur noch die Differenzen zwischen den beiden/mehreren "hoch abstrahierten" Logiken beschreiben muss - die lassen sich als kleinste "Überbleibsel" noch mit hinein codieren. So
    entsteht im Prinzip ewiger Speicherplatz.

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  7. #7
    Registered User
    Registriert seit
    Aug 2002
    Beiträge
    2.207
    Renommee
    622

    AW: Codierung, Optimierung, Indizierung

    Der Theorie nach müsste man die Daten in mehrere Hash Tables ( oder wie hieß das auf low Level? ) einlesen, dessen Typen Definition in einer Art Meta Daten Header pro Tabelle oder Liste bei Laufzeit bestimmt wird.
    Eine gepflegte Relation wär dann sowas wie Zeiger auf eine Sammlung von Adress Informationen dessen Länge durch den Typ bekannt ist...
    Den Gedanken könnte man jedenfalls weiter spinnen.
    Wenn die Streuung der Daten durch den Index bekannt ist, könnten diese so organisiert werden, daß die wieder einlesbar gespeichert werden.
    Voraussetzung wäre das allein durch die Abfrage und Metadaten ein Satz Daten kommt, der wieder perfekt in die Definition passt...
    10 Bytes hier und 10 Bytes dort => in typedef...
    Imho kein schlechter Ansatz.
    Geändert von Enchanter (06.06.2017 um 20:16 Uhr)
    Wenn ich was sage, will das was heißen.

  8. #8
    Quantenmechaniker
    Registriert seit
    Aug 2002
    Beiträge
    1.935
    Renommee
    283

    AW: Codierung, Optimierung, Indizierung

    Der Theorie nach müsste man die Daten in mehrere Hash Tables ( oder wie hieß das auf low Level? ) einlesen, [...]
    Nya~ problematisch, weil wir ja erst selbst solche Hashtables erzeugen müssten - da kann man nicht einfach bestehende Klassen verwenden, sondern man muss die Daten-Zugriffe
    und ihre Bewegungen selbst IM CODE koordinieren. Ich muss einfach davon ausgehen, dass am Anfang quasi *nichts* schon fertig besteht, auf das man aufbauen könnte. In diesem
    Sinne bräuchte man wohl ein Codierungs-/Austausch-"Protokoll/Format" mit _codierten_ Strukturen, die man im Wert direkt auseinander bricht, um so die Zugriffe auf einzelne (Sub-)
    Elemente zu regulieren.

    Am meißen würde mich eine vollständig auf sich selbst aufbauende Konstruktion reizen, wo schrittweise immer mehr Code-"Teilungen" (in sich selbst hinein ...) geschehen, um damit
    immer mehr nutzbare, "echte" Strukturen(-Interfaces) aufzubauen. Die dann gewissermaßen auf "rekursiven" Code-(Energie-/Werte-)Einteilungen basieren (das ist der komplette Plan).

    In dem Sinne wäre ein denkbarer Einstieg, in etwa ... nehmen wir eine <Interface>-Klasse. Dort hinein eine "getAttribute(key)"-Funktion bspw., deren Aufgabe es nun ist, viele Daten-
    sätze zu durchlaufen, um eine passende (Hash-)Signatur o.ä. zu finden. Der DB-Code (und/oder Query-Code) gibt dann erst alles weitere, was nun zur ersten, vollständigen "Klasse"
    führen kann, wenn sich bei der gefundenen DB-Code-Stelle bspw. ein Zuweisungs-Token oder eine (vorher im Protokoll festgelegte) Pointer-/Sprung-Anweisung o.ä. befindet. Dann ist
    die dort vorzufindende Werte-Zuweisung auszulesen und kann nun im Interface erst zur "echten" Rückgabe führen. etc. pp.

    Ich tendiere momentan zu meinem Konstrukt "CodeMAP" - es geht darum, dass ich zu sämtlichen "Elementen" vor allem Koordinaten- bzw. Längen-Angaben hinzu ziehe, welche im
    direkten Bezug zu den DB-Codierungen stehen - so dass es letztlich darum geht, effizient zwischen den Werten logisch hin und her zu schalten, indem diese Werte wiederum selbst
    weitere Pointer-Adressierungen sind erstmal.

    Das ähnelt dem Gedanke, dass ich quasi eine eigene DOM-Implementation verwende, wo der String-XML-Code schonmal als DB-/Datei-Code vorliegt, während ich meine (hier zuerst
    noch übergangsweise verwendeten, damit's einfacher wird) JS-"Object" mit den "Klartext"-DB-Schlüsseln füllen kann, während im Wert die LENGTH-/Offset-Bezüge bestehen, so dass
    wir bei der nötigen XML-String-Verwendung direkt zu den passenden Offsets springen können. So dachte ich mir das ... nur eben rekursiv und ohne Zuhilfenahme fertiger Strukturen. ...

    Eine gepflegte Relation wär dann sowas wie Zeiger auf eine Sammlung von Adress Informationen.
    Eine "gepflegte" Relation ist m.E. so weit - wenn ich so sagen darf - "normalisiert" und "atomarisiert" (*g*), dass für jede Informations-Einheit quasi eigene "Tabellen" (um von diesen zu
    sprechen hier) verwendet werden - und letztlich alle Berechnung sowie Abbildung allein in Adress-Indices besteht (am Ende Raumzeit-Koordinaten). Ich denke hier auch daran, dass im
    besten Falle einfach eine "LinkedList" o.ä. verwendet wird, wo jeder "Eintrag" mit dessen jew. Länge beginnt, um schrittweise von Eintrag zu Eintrag zu springen. Dabei werden nun alle
    Sprünge mit gezählt, was eine Art "multiplizierten Offset" ergibt (Multiplikation im Sinne der (hier variablen) Block-/Record-Längen). Zum Schluss werden die Zählungen nur noch QUER
    zugewiesen zu denen der anderen Attribute/Tabellen/Objekte/..., um zu sagen, dass nach +(11) Sprüngen in einer Reihe eine QUER-Verbindung zu Position/Daten einer zweiten Reihe
    hergestellt wird. Das wäre sehr virtuell und effizient. Denke ich. Falls du verstehe, was ich überhaupt meine. xD´

    Voraussetzung wäre das allein durch die Abfrage und Metadaten ein Satz Daten kommt, der wieder perfekt in die Definition passt... [...] 10 Bytes hier und 10 Bytes dort => in typedef... imho kein schlechter Ansatz.
    Kannst du das bitte kurz erläutern, was du genau meinst?

    1 2 3 4 5 6 7 8
    2 1 4 3 6 5 8 7
    3 4 1 2 7 8 5 6
    4 3 2 1 8 7 6 5
    5 6 7 8 1 2 3 4
    6 5 8 7 2 1 4 3
    7 8 5 6 3 4 1 2
    8 7 6 5 4 3 2 1

  9. #9
    Registered User
    Registriert seit
    Aug 2002
    Beiträge
    2.207
    Renommee
    622

    AW: Codierung, Optimierung, Indizierung

    Ich hätte dir Morgen jetzt ein bsp. wie [0] gebracht.
    Er macht es zwar falsch und in seinem bsp. ist die Definition bekannt aber ungefähr so:

    [0] https://stackoverflow.com/questions/...ures-to-file-c

    Wenn hier die Definition dynamisch abzulesen wäre könnten:
    10 Bytes aus der einen Ecke und 10 Bytes aus der anderen Ecke eine sinnvolle Struktur ergeben, die Felder aus der Relation enthält. Nur das die Position der Daten eben nur durch den Index bekannt ist.
    Wenn ich was sage, will das was heißen.

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. Googlebot - Indizierung von FTP-Dateien?
    Von RFC822 im Forum Technisches Off-Topic
    Antworten: 16
    Letzter Beitrag: 06.03.2005, 14:07
  2. IP Codierung
    Von kRoNoS im Forum (In)Security allgemein
    Antworten: 10
    Letzter Beitrag: 09.12.2002, 20:33
  3. Huffman Codierung ?
    Von Format C: im Forum Algorithmen und sonstige Programmiersprachen
    Antworten: 5
    Letzter Beitrag: 30.07.2002, 19:32
  4. UTF-8 (de)codierung mit C++
    Von bigerr0r im Forum C / C++
    Antworten: 1
    Letzter Beitrag: 24.06.2002, 17:26

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •