Daten bitweise in Feld ablegen und später aggregieren?

[Shivan]

Ich suche nach einer Möglichkeit, Daten bitweise in einen Datensatz zu schreiben.

Bisher kam mir nur die Idee, einen 64bit integer zu nehmen, womit ich jedoch nur 64 bits setzen kann.
Mehrere Integer-Felder verwenden ist auch nicht sonderlich schön. Optimal wäre 1440 Bit in einem Datensatz ablegen zu können (optimalerweise in einem Feld).

Eine andere Idee wäre, das ganze in einem VarChar zu "codieren". Jedoch gibt es spätestens dann ein Problem mit dem Aggregieren der Bits mittels bitweisem "AND". Auch mit Integern ist ein bitweises And-Aggregat nicht sonderlich einfach.

Eine Hilfslösung wäre, den SQL-Server-Funktionsumfang mit einer DLL zu erweitern, so dass dieser vielleicht bitweise mit VarChars hantieren könnte...

Vielleicht hat ja einer von euch noch eine bessere/einfacherere Lösung?

[marabu]

Hallo Markus,

warum greifst du mittels BDE auf einen MS SQL Server zu? Ist 1440 nur zufällig 24 * 60?

Das Speichern von bitcodierten Feldern kann dir niemand verbieten, aber da du später bestimmte Bits aggregieren möchtest sind deine Daten natürlich nicht normalisiert. Du kannst die fehlenden Operatoren als UDF implementieren - ganz ohne DLL, aber vielleicht gibt es eine deinem Problem angemessenere Lösung, wenn du etwas über die Natur deiner Daten und die benötigten Operatoren mitteilst.

Grüße vom marabu

[Shivan]

BDE leider aufgrund des verwendeten Frameworks... aber es ist bereits ein Umstieg auf ADO angedacht... Ich weiss, sogar Borland ratet eigentlich von der Verwendung der BDE mittlerweile ab...

Yep, 24 Std. * 60 Min = 1440 Min.
Es geht dabei um die minutenbasierte Verplanung eines Tages.
Bitweise deswegen, weil ich denke dass damit ein einfacheres übereinanderlegen von Zeitleisten mit bitweisem AND möglich ist, um somit herauszufinden, ob in diesem Zeitraum eine Überlappung existiert.

Bsp:

Delphi-Quellcode:

0 0 0 1 1 1 1
0 1 1 1 1 0 0
-------------
0 0 0 1 1 0 0

Das ganze sollte eben performant sein, und deswegen mengenorientiert, so dass die Datenbank dabei möglichst die Arbeit erledigen kann und nicht alles auf Clientseite einzelsatzorientiert abläuft.

UDF kenne ich bisher noch nicht... werd ich mir mal genauer anschaun.

[marabu]

Hallo Markus,

Zitat von Shivan:

Das ganze sollte eben performant sein, und deswegen mengenorientiert, so dass die Datenbank dabei möglichst die Arbeit erledigen kann und nicht alles auf Clientseite einzelsatzorientiert abläuft.

deine Motive sind gut und richtig, aber die Folgerung ist nicht zwingend. Einzelsatzverarbeitung im Client darf man nicht pauschal verurteilen - teuer wird es nur wenn für jeden Satz eine Anfrage an den Server gerichtet wird.

Deine Zeitleisten kannst du auch als Zeitintervalle begreifen. Nehmen wir an die Tabelle "Zeiten" hat die Spalten "Start" und "Ende". Beide Spalten sind vom Typ float (smalldatetime kann für Zeitarithmetik als Float-Wert interpretiert werden). Deine Schnittmenge mit dem rechts offenen Intervall [pstart, pende) ergibt sich dann etwa so:

SQL-Code:

/* p-code */

select 
  MaxFloat(pstart, start) as cstart, 
  MinFloat(pende, ende) as cende 
from zeiten 
where MinFloat(pende, ende) >= MaxFloat(pstart, start)

Dabei kann die Schnittmenge eine Menge von Intervallen sein. Eine passende UDF könnte so aussehen:

SQL-Code:

CREATE FUNCTION dbo.MaxFloat (
  @value1 as float,
  @value2 as float
)
RETURNS float
AS
BEGIN
  DECLARE @result AS float
  IF (@value1 > @value2)
    set @result = @value1
  ELSE
    set @result = @value2
  return @result
END

Grüße

marabu

[Shivan]

Hallo Marabu,

mit Hilfe deiner Idee, sowie einigen Erweiterungen:
- Erweiterung der Funktion auf 3 Werte (für 3 Dimensionen)
- direkter Vergleich von "datetime" anstatt float
- bei der Ermittlung die Verwendung eines Inner Joins unter Herausfilterung der Termine, welche sich erst garnicht berühren können

...bin ich nun ziemlich weit gekommen.

Danke!