10.19.2005

Listen in Datenbanken

Klassischer Fall: Der Benutzersoll in einem Feld Werte erfassen, die aus einer Liste ausgesucht werden.
Sei es, das danach später gesucht werden soll und daher die anzahl der Einträge nicht endlos ausufern soll, sei es, dass nur bestimmte Werte erlaubt sein sollen.




Die klassische Lösung: Die Werte werden in einer eigenen Tabelle hinterle und in der ursprünglichen Tabelle wird die ID gespeichert.




Vorteil: Wird die Screibweise eines Eintrags geändert, ändert sich der Wert für alle - es ist ja die ID hinterlegt.
Nachteil: Jeder Wert, der eventuell verwendet werden soll, muss gepflegt werden - also muss eine Datenpflege geschaffen werden und wenn ein neuer Wert zulässig sein soll, muss dieser erst in der Domain-Tabelle erfast werden. Wurde die Eingbe über eine Liste gewählt, weil nur bestimte, vorgegebene Werte erwünscht sind, ist diese Lösung mt Sicherheit die richtige.




Erfolgt die verwendung der Liste dagegen aus Gründen der Komforsteigerung, so ist die reflexible bzw. selbtfüllende Liste eine bedenkenswerte Alternative: Hierbei wird die Liste mit einer Anweisung im Stile von "Select DiesesFeld from MeineTabelle group by DiesesFeld order by DiesesFeld" gefüllt. Somit stehen immer alle schon erfasten Werte zur Auswahl zur Verfügung.




Was aber nun, wenn über das Feld eine 1:n -Verknüpfung befüllt werden soll? Bei der klassischen, egen Koppelung ist es notwendig, erst alle Einträge zu erzeugen, auf die dann über de Liste referenziert werden soll.




Handelt es sich bei der Eingabe - die ja auch der Schlüssel der n-Seite ist - um einen Wert, der einen realen Bezug hat und an sich schon eindeutig ist, wie z.B. eine Raumnummer, so wäre doch auch ein Verfahren denkbar, dass ich mal die "verzögerte Tabellenbindung"nennen möchte.




Hierbei ist es möglich, die Raumnummer zu erfassen, auch wenn der Raum selber in der Raumtabelle noch nicht angelegt ist. Die Liste füllt sich mit den schon angelegten und den in der Tabele erfasten Raumnummern, also der UNION aus reflexibler Liste und echter Verweisliste.
In einem anderen Bearbeitungsschrit, auf einer anderen Maske, bekommt man dann die Raumnummern angezeigt, die zwar verwendet werden, aber in der Raumtabelle noch nicht angelget sind.




Alternativ kann bei jedem neuen Wert erst mal der Benutzer nach den restlichen Informationen gefragt werden und diese Daten dann in der Raumtabelle gespeichert werden. Der Nachteil dieser Vorgehensweise ist zum einen das Zerreißen der Datenerfassung und zm Anderen besteht die Möglichkeit, dass der Benutzer, der aktuell die Daten erfast, über die abgefragten Zusatzdaten nicht verfügt.




Die Auswahl der "richigen" Vorgehensweise ist von der konkreten Aufgabenstellung abhängig.

10.04.2005

Werktage in gegebenen Zeitraum

Prinzipiell ist dies mit einer Abfrage zu erledigen:
select count(*)
from (
select rownum rnum
from all_objects
where rownum <= mEnd - mStart + 1 )
where to_char(mStart + rnum - 1, 'D' ) not in ( '6', '7' ) ;

Dies funktioniert immer dann, wenn Ende und Start "richtig" herum liegen.
Daher ist das Verpacken in eine kleine Funktione ratsam.

Diese lautet für Oracle:


CREATE OR REPLACE FUNCTION FU_Number_Work_Days(
StartDate date,
EndDate date)
RETURN NUMBER IS
Ret number;
Signum number;
mStart date;
mEnd date;
BEGIN
IF EndDate < StartDate
THEN
mEnd := StartDate;
mStart := EndDate;
Signum := -1;
ELSE
mStart := StartDate;
mEnd := EndDate;
Signum := 1;
END IF;

select count(*) into ret
from (
select rownum rnum
from all_objects
where rownum <= mEnd - mStart + 1 )
where to_char(mStart + rnum - 1, 'D' ) not in ( '6', '7' ) ;

return Ret * Signum;
END FU_Number_Work_Days;
/

9.30.2005

Dynamisches Einbinden von ODBC-Tabellen

Das dynamische Einbinden hat so seine Tücken:
Je nach verwendetem ODBC-Treiber und Art der Änderung (z.B. bei ORACLE nur anderer User auf selber ODBC) kann es sein, dass die Einbindung nicht wirklich erneuert wird.
Erst ein Löschen der eingbundenen Tabellen, komprimieren und reparieren der DB und Neueinbinden führt dann zum Erfolg.
Und das Gemeine: Die Anzeige im Tooltip zeigt die neue Verbindung, die Tabelle "recycled" aber die alte Verbindung!!

9.29.2005

MS Access und Outer-Join

Eine kleine Eigenheit, die ich bis jetzt nur von ORACLE kannte:
Werden zwei Felder in einer Abfrage über einen Outer-Join verbunden und das "Quell"-Feld ist NULL, dann wird diese Zeile im Ergebnis nicht gezeigt! Es werden also nicht alle Zeilen der einen Seite angezeigt und nur die der anderen, die gefunden werden!