SQL satz mit größtem datum

[Robi]

Hi,

ich habe eine Datei mit 'gültig ab' Datum und somit mehreren Sätzen.
a 19990501
a 20000105
a 20010407
a 20070706

ich brauche den gültigen.

bisher mache ich
select * from datei where feld = 'a' and Datum = (select max(Datum) from datei where feld = 'a')

(Da das Datum auch in der Zukunft liegen kann, und der Satz dann noch nicht gültig ist, selektiere ich manchmal noch im 2. select die raus, deren datum > heute ist )

da häufig nicht nur "feld = 'a' " abgefragt wird, ist das teilweise echt komplex

geht das einfacher ?
wenigstens wenn man die Zukunft nicht berücksichtigen muß ?

Danke
Robi

[Fuerchau]

Da ist SQL tatsächlich etwas schwierig.
In RPG/LE kann ich einfach mit SETLL/READE schnell zugreifen.
Da SQL aber immer mehrere Sätze verarbeitet ist die Einschränkung nur auf die von dir beschriebene Weise möglich, auch wenn es da noch so komplex ist.

select * from datei where feld = 'a' and Datum = (select max(Datum) from datei where feld = 'a' and Datum < year(current date)*10000 + month(current date)*100 + day(current date))

[B.Hauser]

Hallo,

man kann das Ganze höchstens mit Common Table Expressions lesbarer machen:

Vielleicht so:

with x as (Select Year(Current_Date)  * 10000 +
                  Month(Current_Date) *   100 +
                  Day(Current_Date)  as TagesDatum
              From SysIBM/SysDummy1),
     y as (Select Max(MyNumDate) as MaxDate, Feld1
              From MyTable cross join x 
              Where MyNumDate < TagesDatum and Feld1 = 'a' ...)
Select a.*
   from MyTable a join y on MyNumDate = MaxDate 
   Where Feld1 = 'a' .... 

Das Problem liegt darin, dass das Datum numerisch ist, und die Verarbeitung von numerischen Datumswerten mit SQL etwas komplizierter ist.

Um den Source-Code noch etwas einfacher zu machen, könnte man für die Ermittlung des numerischen Tagesdatum eine UDF (User Defined Function) schreiben und diese einbinden.

Beispiel:

CREATE FUNCTION MySchema/AktDatNum ( ) 
       RETURNS DECIMAL(8, 0)   
       LANGUAGE SQL 
       NOT DETERMINISTIC 
       CONTAINS SQL 
       CALLED ON NULL INPUT 
       NO EXTERNAL ACTION 
       DISALLOW PARALLEL 
       NOT FENCED 
BEGIN 
       DECLARE CURDATE DATE ; 
       SET CURDATE = CURRENT_DATE ; 
       RETURN(YEAR(CURDATE) * 10000 + MONTH(CURDATE) * 100 + DAY(CURDATE )); 
END  ; 

Damit kann man dann das SQL-Statement wie folgt vereinfachen

with y as (Select Max(MyNumDate) as MaxDate 
              From MyTable  
              Where MyNumDate < AktDatNum() and Feld1 = 'a' ....)
Select a.* 
   from MyTable a join y on MyNumDate = MaxDate  
   Where Feld1 = 'a' ... 

[BenderD]

Hallo,

wieder mal ein Fall davon, dass "interessantes" Design "spezielle" Probleme nach sich zieht. Ich kenne dass eigentlich so:
- statt irgendwelchen Huddel-Datum Feldern nimmt man die dafür vorgesehenen Date Typen
- zusätzlich zu dem gültig ab hat man ein gültig bis Feld
und dann fragt man mit between und dem Referenzdatum ab. (in Worten Punkt)

mfg

Dieter Bender

Hi,

ich habe eine Datei mit 'gültig ab' Datum und somit mehreren Sätzen.
a 19990501
a 20000105
a 20010407
a 20070706

ich brauche den gültigen.

bisher mache ich
select * from datei where feld = 'a' and Datum = (select max(Datum) from datei where feld = 'a')

(Da das Datum auch in der Zukunft liegen kann, und der Satz dann noch nicht gültig ist, selektiere ich manchmal noch im 2. select die raus, deren datum > heute ist )

da häufig nicht nur "feld = 'a' " abgefragt wird, ist das teilweise echt komplex

geht das einfacher ?
wenigstens wenn man die Zukunft nicht berücksichtigen muß ?

Danke
Robi

[B.Hauser]

Hi,

wieder mal ein Fall davon, dass "interessantes" Design "spezielle" Probleme nach sich zieht. Ich kenne dass eigentlich so:
- statt irgendwelchen Huddel-Datum Feldern nimmt man die dafür vorgesehenen Date Typen
- zusätzlich zu dem gültig ab hat man ein gültig bis Feld
und dann fragt man mit between und dem Referenzdatum ab. (in Worten Punkt)

Das mag ja so sein, wenn man auf der grünen Wiese mit neuem Datenbanken-Design anfangen kann. Wenn man allerdings mit physischen Dateien arbeiten muss, die entstanden sind lange bevor ein Date-Datentyp bekannt war bzw. bevor RPG echte Datumsfelder verarbeiten konnte, muss man halt das eine oder andere "drumrumstricken".

[BenderD]

nur wenn man in Kauf nimmt ewig rumzuhuddeln!
Der saubere Weg ist hier:
- neue Tabelle mit vernünftiger Struktur wie oben anlegen (nebenbei bemerkt: das habe ich nicht erfunden, das kann man abgucken, überall da, wo man schon lange Zeit abhängige Daten speichert, oder nachlesen)
- die momentane Tabelle als View von der alten ableiten (geht für RLA auch per DDS LF)
- die neue Tabelle kann per Trigger gepflegt werden, vornedran laufen immer noch die "gewachsenen" (sind die nicht eher geschrumpft?) Programme
e voila: man ist aus dem Sumpf draußen und baut seine neuen Programme auf stabile Fundamente

d*b

[Fuerchau]

Trotzdem geht das leider an dem Wunsch vorbei, dass ich genau 1 Satz haben will, aber SQL mir halt manchmal mehrere Sätze liefert.
Da hilft auch gerade kein between oder ähnliches, sondern leider nur so komplizierte Konstrukte mit Subselect u.ä. (CTE's sind ja auch nichts anderes) und der Optimizer stößt da immer wieder auf Probleme, die ich da leider nicht nachvollziehen kann (trotz vorgschlagener Zugriffswege immer noch Tablescan).

SQL ist da halt nicht immer von Vorteil, da RPG/LE da einfach kürzer ist.
Die Rahmenbedingung bei Gültigkeit ist häufig so:

setll (Key: Datum) MyFile;
reade (Key) MyFile;
if not %found();
setll (Key: Datum) MyFile;
readpe (Key) MyFile;
endif;
if not %found();
// wirklich ungültig.
endif;

Also nimm den 1. gültigen, wenn nicht da, nimm den letzten gültigen.

Dies in einem Resultset mit SQL gestaltet sich als ziemlich schwierig (natülich nicht unlösbar) und mitunter wenig performant.

[Robi]

Danke für die Antworten und für die Design unterstützung.
Es geht ja, ich finde es in SQL nur etwas umständlich und habe gedacht fehlende Kentnisse meinerseits sind schuld.

Huddeldatum Felder sind immer dann gut, wenn es a leer sein kann (gülltig bis 0.0.00 = immer gültig = Wunsch des KUNDEN dort nicht den 31.12.39 zu sehen, und natürlich gewachsene Struckturen sowie die fähigkeiten die auf der ASs400 früher zur Verfügung standen. Gelobt seien alle die, die sofort wenn es was neues ( besseres ?) gibt die in ihr System komplett einarbeiten können

Danke
Robi