SQL Abfrage nach Mustern statt fixen Werten

[Jana Vorodna]

Hallo zusammen,

bei mir vor der Tür stürmt's grad mächtig und ich brüte über einem Problem ...

habe hier eine Datenbank wo sich drin eine Tabelle befindet:

Messung,MesswertA,MesswertB,MesswertC,MesswertD,MesswertE,...
[(numeric(19,0),numeric(10,2),numeric(10,2),numeric(10,2),numeric(10,2),numeric(10,2)]

welches Feld der PK ist brauch ich sicher nicht weiter zu erklären

da kommen täglich hunderte neue Meßwerte (=Messungen) hinzu
von denen sind einige gültig andere ungültig

jetzt wird sicher einem Spezi unter euch der Spruch auf den Lippenliegen: Definiere gültig und ungültig :-)
ja, tu ich ja, nich so hastig :-)

ungültig heißt, es liegen zuviele Ergebnisse in zu engem Rahmen bzw. der Unterschied zwischen den Werten global oder in abgesteckten Rahmen ist irgendwie konstant. Gleiche (identische) Meßwerte können praktisch und theoretisch nicht auftreten.

Ich suche jetzt nach einem Algorithmus welcher mir a) entweder alle ungültigen Meßreihen rauswirft oder b) alle gültigen ausgibt. Ich möchte dabei angeben, wie hoch die Minimum-Differenz sein muß und die jeweiligen Rahmengrenzen in numerischer Form. Beispiel:
in einem Rahmen 100 -(=bis) 1000 dürfen nur max. 3 Messwerte liegen, welche aber mindestens jeweils 20 Punkte auseinander sein müssen ... usw.

Ich hoffe, das ist verständlich formuliert :-)

Kann ich dies allein in SQL lösen oder benötige ich einen Zusatz wie PHP oder C++. PL/SQL stünde auch zur Verfügung. Wichtig ist, daß die Operation dauerhaft serverseitig laufen soll und die Ergebnisse als XML Ausgaben via Webserver bereitstellen soll.

Hab momentan 0 Schimmer wo ich überhaupt anfangen soll und hoffe mal auf die gesammelte Geisteskraft des Forums, mir irgendwie auf die Sprünge zu helfen.

Hatte schon versucht, die Tabelle zu traversieren:

Messung_ID   |Meßwert
-------------|--------
100001       |103,87
100001       |112,01
100001       |112,16
....
100002       |104,12
100002       |116,92
100002       |123,55
....

Aber auch da komme ich nicht weiter bzw. weiß nicht ob mir das etwas nutzt.

Würde mich riesig freuen, wenn mich jemand helfen könnte.

byebye - JV

P.S. Die Meßwerte sind immer aufsteigend bereits in der DB Tabelle gespeichert --- MeßwertA = kleinster Wert ....

[Lude]

Hi,

habe hier eine Datenbank wo sich drin eine Tabelle befindet:

Messung,MesswertA,MesswertB,MesswertC,MesswertD,MesswertE,...
[(numeric(19,0),numeric(10,2),numeric(10,2),numeric(10,2),numeric(10,2),numeric(10,2)]

welches Feld der PK ist brauch ich sicher nicht weiter zu erklären

das kann ja nur das erste DF, also 'Messung' sein. Ist doch klar.   ;-)

da kommen täglich hunderte neue Meßwerte (=Messungen) hinzu
von denen sind einige gültig andere ungültig

"Ungueltige" Werte kann man auch daran hindern in die DB zu gelangen.

ungültig heißt, es liegen zuviele Ergebnisse in zu engem Rahmen bzw. der Unterschied zwischen den Werten global oder in abgesteckten Rahmen ist irgendwie konstant. Gleiche (identische) Meßwerte können praktisch und theoretisch nicht auftreten.

Diese Definition fuer "ungueltig" kann man in SQL formulieren. Entweder in der WHERE-Klausel oder indem Du einen Cursor aufmachst und diesen durchlaeufst.

Ich suche jetzt nach einem Algorithmus welcher mir a) entweder alle ungültigen Meßreihen rauswirft oder b) alle gültigen ausgibt. Ich möchte dabei angeben, wie hoch die Minimum-Differenz sein muß und die jeweiligen Rahmengrenzen in numerischer Form. Beispiel:
in einem Rahmen 100 -(=bis) 1000 dürfen nur max. 3 Messwerte liegen, welche aber mindestens jeweils 20 Punkte auseinander sein müssen ... usw.

Ja, hoert sich doch ganz gut an. Hast Du es in SQL codiert? Was hat nicht geklappt?

Ich hoffe, das ist verständlich formuliert :-)

Jaja, gut.   ;-)

Kann ich dies allein in SQL lösen oder benötige ich einen Zusatz wie PHP oder C++. PL/SQL stünde auch zur Verfügung. Wichtig ist, daß die Operation dauerhaft serverseitig laufen soll und die Ergebnisse als XML Ausgaben via Webserver bereitstellen soll.

Geht allein in SQL. Datenserver koennen manchmal auch die Datensatzmenge gleich "in XML" ausgeben.

P.S. Die Meßwerte sind immer aufsteigend bereits in der DB Tabelle gespeichert --- MeßwertA = kleinster Wert ....

Bist Du sicher, dass die Datensaetze in der DB "aufsteigend sortiert" abgelegt sind? - Die Sortierung erfolgt doch erst beim Zugriff.

Gruss,
Lude

[Jana Vorodna]

Halli Lude!

"Ungueltige" Werte kann man auch daran hindern in die DB zu gelangen.

Nicht die Werte sind ungültige sondern die Messung, sorry wenn ich mich da verwirrend geäußert hab.

ungültig heißt, es liegen zuviele Ergebnisse in zu engem Rahmen bzw. der Unterschied zwischen den Werten global oder in abgesteckten Rahmen ist irgendwie konstant. Gleiche (identische) Meßwerte können praktisch und theoretisch nicht auftreten.

Diese Definition fuer "ungueltig" kann man in SQL formulieren. Entweder in der WHERE-Klausel oder indem Du einen Cursor aufmachst und diesen durchlaeufst.

Genau das ist der Haken .. wie in SQL ... ich kenne die Verwendung von WHERE Klauseln schon, aber halt mit fixen Werten und die habe ich nicht, da sich das Kriterium gültig/ungültig nur aus der gesamtreihe des Messwerte ergibt. Wie ich ja geschrieben hab ... mehrere Meßwerte in einer Messung liegen zu nahe zusammen, usw.

Ja, hoert sich doch ganz gut an. Hast Du es in SQL codiert? Was hat nicht geklappt?

-> das war meine Frage ... wie kann bzw. kann man sowas überhaupt in SQL ausdrücken

Kann ich dies allein in SQL lösen oder benötige ich einen Zusatz wie PHP oder C++. PL/SQL stünde auch zur Verfügung. Wichtig ist, daß die Operation dauerhaft serverseitig laufen soll und die Ergebnisse als XML Ausgaben via Webserver bereitstellen soll.

Geht allein in SQL. Datenserver koennen manchmal auch die Datensatzmenge gleich "in XML" ausgeben.

Ja, das die Ausgabe in XML auch schon im DBMS laufen kann "FOR XML" etc das weiß ich, das ist aber nicht der Kernpunkt, ich möchte die Meßreihen haben die gültig bzw. ungültig sind.

P.S. Die Meßwerte sind immer aufsteigend bereits in der DB Tabelle gespeichert --- MeßwertA = kleinster Wert ....

Bist Du sicher, dass die Datensaetze in der DB "aufsteigend sortiert" abgelegt sind? - Die Sortierung erfolgt doch erst beim Zugriff.

nicht die Datensätze ... die Meßwerte innerhalb eines Datensatzes

Messung | MeßwertA | MeßwertB | MeßwertC | MeßwertD
--------|----------|----------|----------|----------
1       | 1000     | 2000     | 3000     | 4000
2       |  500     | 2500     | 4000     | 4001

hab ich ja auch nicht anders geschrieben ... ich weiß das es keine native Sortierung von Datensätzen gibt ...  :-)

byebye - JV

[Michael Schröpl]

Hi Jana,

Bist Du sicher, dass die Datensaetze in der DB "aufsteigend sortiert" abgelegt sind? - Die Sortierung erfolgt doch erst beim Zugriff.

nicht die Datensätze ... die Meßwerte innerhalb eines Datensatzes

Messung	MeßwertA	MeßwertB	MeßwertC	MeßwertD
1	1000	2000	3000	4000
2	500	2500	4000	4001

so etwas wollte ich sehen.

Und Du meinst nun also vermutlich, daß die Meßwerte C und D in Messung 2 zu nahe beieinander liegen, so daß diese Zeile eine ungültige Messung darstellt?
Falls dies der Fall ist, solltest Du diesen Test in der Tat _vor_ dem Einfügen des Datensatzes in die Tabelle durchführen (offensichtlich mußt Du die Meßwerte vor dieser Einfügung bereits irgendwo sortiert haben - an dieser Stelle wäre Dein Gültigkeitstest relativ trivial durchführbar).

Wenn Deine Meßwerte semantisch gleichrangig sind, dann halte Dein Datenmodell übrigens für fragwürdig. Ein Datenmodell mit einem zweistufigen primary key (Messung, MeßwertNR) und einer dritten Spalte für den jeweiligen Wert würde der Natur Deiner Daten eher entsprechen ... aber dies ist eine eher ästhetische Anmerkung, solange Du sicherstellen kannst, daß jede Messung exakte dieselbe Anzahl von Werten liefert.

Viele Grüße
      Michael

[Michael Schröpl]

Hi Jana,

ja, tu ich ja, nich so hastig :-)

<smile />

ungültig heißt, es liegen zuviele Ergebnisse in zu engem Rahmen bzw. der Unterschied zwischen den Werten global oder in abgesteckten Rahmen ist irgendwie konstant. Gleiche (identische) Meßwerte können praktisch und theoretisch nicht auftreten.

Das ist aber leider keine Definition dafür, wann _ein_ Wert gültig ist, vermute ich. Es ist lediglich eine Definition, wann eine _Menge_ von Werten gültig ist. Deshalb läßt sich auf dieser Beschreibung kein Algorithmus aufbauen, der _einen_ Wert als ungültig erkennt und aus der Menge entfernt.

in einem Rahmen 100 -(=bis) 1000 dürfen nur max. 3 Messwerte liegen, welche aber mindestens jeweils 20 Punkte auseinander sein müssen ... usw.
Ich hoffe, das ist verständlich formuliert :-)

Mach mal ein konkretes Beispiel - ich bin mir nicht sicher, ob ich verstanden habe, welche Bedeutung die "Werte" haben.
Insbesondere habe ich nicht verstanden, was in Deinem ursprünglichen Datenmodell die Zeilen und die Spalten bedeuten - sind die Meßwerte einer Zeile irgendwie "zusammengehörig" (und die Gültigkeit also auf einer Zeile definiert) oder nicht (wieso dann nicht gleich Dein alternatives Datenmodell)?

Kann ich dies allein in SQL lösen oder benötige ich einen Zusatz wie PHP oder C++.

Momentan ist Dein Problem IMHO noch unterdefiniert, d. h. ohne Berücksichtigung der Programmiersprache generell unlösbar.
Sobald Du die entsprechenden Angaben nachlieferst, wird es von der Komplexität des Algorithmus abhängen, ob er sich in einer nichalgorithmischen Sprache wie SQL ausdrücken läßt oder ob Du eine algorithmische Sprache wie PHP oder C++ benötigen wirst.

PL/SQL stünde auch zur Verfügung. Wichtig ist, daß die Operation dauerhaft serverseitig laufen soll und die Ergebnisse als XML Ausgaben via Webserver bereitstellen soll.

Dein Modell scheint darauf zu beruhen, zunächst alle Werte in die Tabelle zu pumpen und anschließend zwischen gültigen und ungültigen Werten zu unterscheiden - und wenn die "Gültigkeit" nur auf Mengenbasis definiert ist, dann wäre das auch ein vernünftiger Ansatz.
Wäre "Gültigkeit" aber anhand des Inhaltes eines einzelnen Datensatzes unterscheidbar, dann würde ich vorschlagen, diese Unterscheidung bereits vor dem Einfügen durchzuführen (falls dies nicht gegen andere Teile Deiner Aufgabenstellung verstößt).

Viele Grüße
      Michael

[Jana Vorodna]

Halli zurück!

okay ... Werte (ein Meßwert als Eintrag in einem Datenfeld eines Datensatzes) sind so immer "valid" ...  das will ich ja nicht prüfen, weil das kann ich davor prüfen, ob der Wert ansich gültig ist. Aber mich deucht, ich habe nicht von gültigen/ungültigen Meßwerten geredet sondern von gültigen/ungültigen Messung_en_

Ich habe gültig/ungültig als Signifikante Unterscheidung gewählt für den Unterschied ob ich ein bestimmten Datensatz haben will oder gerade nicht haben will.

Deshalb läßt sich auf dieser Beschreibung kein Algorithmus aufbauen, der _einen_ Wert als ungültig erkennt und aus der Menge entfernt.

Ich will auch keinen Wert aus einer Menge entfernen ... ich will die ganze Menge (von Meßwerten) wegwerfen.

konkretes Beispiel:  ;-)

M_ID = Messungs-(Mengen)-Nummer
MW_? = Meßwert in dieser Menge

M_ID | MW_A   | MW_B   | MW_C   | MW_D   | MW_E   |
-----|--------|--------|--------|--------|--------|
1    | 100    | 101    | 2000   | 2500   | 3000   |
2    | 100    | 159    | 167    | 2800   | 2900   |
3    | 200    | 400    | 600    | 1100   | 2200   |
4    | 150    | 180    | 400    | 900    | 3000   |

in einem Rahmen 100 -(=bis) 1000 dürfen nur max. 3 Messwerte liegen, welche aber mindestens jeweils 20 Punkte auseinander sein müssen ... bzw.

und alle Meßwerte müssen generell 20 Punkte mind. auseinander sein

Messung 1 will ich nicht haben, weil halt MW_A und MW_B zu nah aneinander sind
Messung 2 will ich nicht, weil MW_B und MW_C zu nah aneinander sind
Messung 4 hat 4 Meßwerte zwischen 100 und 1000 ... passt also nicht auf mein o.d. Schema

Messung 3 ist okay

was in Deinem ursprünglichen Datenmodell die Zeilen und die Spalten bedeuten - sind die Meßwerte einer Zeile irgendwie "zusammengehörig" (und die Gültigkeit also auf einer Zeile definiert) oder nicht (wieso dann nicht gleich Dein alternatives Datenmodell)?

genau ... MW_A bis MW_E gehören zu einer Meßlatte .. äh .. Messreihe

alternatives Datenformat ... hmmm ... sagt sich leicht, weil das Gerät mit 3rd Party-SW bestückt ist, die nicht geändert werden darf und die pusht eben die Werte in genauso eine Tabelle ... dürfte also schwerfallen, da etwas zu ändern

_aber_ man kann ja auch aus dieser Tabelle ein anderes Modell bauen, dank Views, SPs usw.

Momentan ist Dein Problem IMHO noch unterdefiniert, ...

ich hoffe, ich hab diesem Problem meines Problems etwas Abhilfe geschafffen ;-) ???

byebye - JV

[Michael Schröpl]

Hi Jana,

ich hoffe, ich hab diesem Problem meines Problems etwas Abhilfe geschafffen ;-) ???

ja, hast Du (sauber definierte Begriffe wie "Messung" und "Meßwert" sind eben doch Gold wert).

Ich rate immer noch dazu, Deine Tabellen-Inhalte schon vor der Einfügung zu filtern (bzw. auf zwei Tabellen zu verteilen, die Du ggf. mit einer "View" lesend gemeinsam ansprechen kannst, falls Du dies für andere Queries benötigst - und Dein RDBMS das unterstützt, natürlich).

Bei einer konstanten Anzahl von Spalten hast Du zwar eine Chance, die Gültigkeit einer Zeile als algebraischen Ausdruck zu beschreiben, aber dieser Ausdruck wird riesengroß, weil Du in SQL elementare algorithmische Features wie Schleifen und Variablen nicht zur Verfügung hast.

Viele Grüße
      Michael

[Jana Vorodna]

Okay,

danke für den Hinweis, daß es mit einer separaten Programmlogik, welche Datensatz für Datensatz überprüft und ggf rauslöscht bzw. mit einem Tag versieht ... performanter funktionieren würde. War ja ansich auch Teil meiner Frage, ob ich SQL allein vergewohltätigen kann oder halt Externa benötige.

Gut, da brauch ich mir nicht den Kopf über SQL zu zerbrechen :-)

Danke euch Jungs vielmals!!

byebye - JV

[Lude]

Hi,

Bei einer konstanten Anzahl von Spalten hast Du zwar eine Chance, die Gültigkeit einer Zeile als algebraischen Ausdruck zu beschreiben, aber dieser Ausdruck wird riesengroß, weil Du in SQL elementare algorithmische Features wie Schleifen und Variablen nicht zur Verfügung hast.

nur noch die kleine Anmerkung, dass beispielsweise T-SQL ueber eine Programmflusskontrollsprache mit Schleifen und Variablen und allem, was das Herz begehrt, verfuegt.

Die Oracle-Konkurrenz mit ihrem SQL-Dialekt auch. - Die Notwendigkeit das der "umgebenden Programmlogik" anzuvertrauen vesteht m.E. also nicht. Ausserdem waere das m.E. dann auch "fragwuerdig".

Gruss,
Lude

[Michael Schröpl]

Hi Lude,

nur noch die kleine Anmerkung, dass beispielsweise T-SQL ueber eine Programmflusskontrollsprache mit Schleifen und Variablen und allem, was das Herz begehrt, verfuegt.

mag sein - aber dann ist die Portabilität wieder unnötig eingeschränkt.

Dann schon lieber algorithmische Logik in die andere (algorithmische) Sprache verlagern, die vor der Einfügung der Werte in die Datenbank ja ohnehin irgendwo verwendet werden muß ... man _kann_ einen Nagel mit einem Schraubenzieher in die Wand schlagen, aber die Verwendung eines Hammers hat sich auf die Dauer sehr bewährt.

Viele Grüße
      Michael

[Lude]

Hi, Michael,

nur noch die kleine Anmerkung, dass beispielsweise T-SQL ueber eine Programmflusskontrollsprache mit Schleifen und Variablen und allem, was das Herz begehrt, verfuegt.

mag sein - aber dann ist die Portabilität wieder unnötig eingeschränkt.

man bekommt immerhin etwas fuer die eingeschraenkte Portabilitaet. Ausserdem muesste man, wenn man Deiner Logik folgt, dazu tendieren alles im "92er-SQL" schreiben.

Dann schon lieber algorithmische Logik in die andere (algorithmische) Sprache verlagern, die vor der Einfügung der Werte in die Datenbank ja ohnehin irgendwo verwendet werden muß ... man _kann_ einen Nagel mit einem Schraubenzieher in die Wand schlagen, aber die Verwendung eines Hammers hat sich auf die Dauer sehr bewährt.

Ich habe das Gleichnis nicht verstanden. Es ist doch m.E. der konsequente Gebrauch von "92er-SQL", der einem um einen Nagel bemuehten Schraubenzieher gleicht. - Der Gebrauch des Hammers ist doch aus Portabilitaetsgruenden moeglicherweise suboptimal.

Gruss,
Lude

[Michael Schröpl]

Hi Lude,

Ich habe das Gleichnis nicht verstanden. Es ist doch m.E. der konsequente Gebrauch von "92er-SQL", der einem um einen Nagel bemuehten Schraubenzieher gleicht. - Der Gebrauch des Hammers ist doch aus Portabilitaetsgruenden moeglicherweise suboptimal.

Das Problem (der Nagel) ist algorithmischer Natur; der Hammer ist die 3GL (welche auch immer), der Schraubenzieher die 4GL (SQL).

Viele Grüße
      Michael

[Lude]

Hi, Michael,

Ich habe das Gleichnis nicht verstanden. Es ist doch m.E. der konsequente Gebrauch von "92er-SQL", der einem um einen Nagel bemuehten Schraubenzieher gleicht. - Der Gebrauch des Hammers ist doch aus Portabilitaetsgruenden moeglicherweise suboptimal.

Das Problem (der Nagel) ist algorithmischer Natur; der Hammer ist die 3GL (welche auch immer), der Schraubenzieher die 4GL (SQL).

<maulgestopft>
Sorry, aber was ist denn '3GL' und '4GL'?
</maulgestopft>

Gruss,
Lude

[Michael Schröpl]

Hi Lude,

<maulgestopft>
Sorry, aber was ist denn '3GL' und '4GL'?
</maulgestopft>

hast Du das Archiv befragt?

Viele Grüße
      Michael

[Lude]

Hi,

Dann schon lieber algorithmische Logik in die andere (algorithmische) Sprache verlagern, die vor der Einfügung der Werte in die Datenbank ja ohnehin irgendwo verwendet werden muß ... man _kann_ einen Nagel mit einem Schraubenzieher in die Wand schlagen, aber die Verwendung eines Hammers hat sich auf die Dauer sehr bewährt.

Ich habe das Gleichnis nicht verstanden. Es ist doch m.E. der konsequente Gebrauch von "92er-SQL", der einem um einen Nagel bemuehten Schraubenzieher gleicht. - Der Gebrauch des Hammers ist doch aus Portabilitaetsgruenden moeglicherweise suboptimal.

Das Problem (der Nagel) ist algorithmischer Natur; der Hammer ist die 3GL (welche auch immer), der Schraubenzieher die 4GL (SQL).

"algorythmische Logik" also in eine algorythmische Sprache (3GL ;-) platzieren. Denn das hat sich "sehr bewaehrt". Wer moechte sich einer so orthogonalen Denkweise nicht anschliessen?

Gruss,
Lude

PS: Der sich dafuer interessieren wuerde, ob Du schon mal eine Stored Procedure geschrieben hast.

[Michael Schröpl]

Hi Lude,

"algorythmische Logik" also in eine algorythmische Sprache (3GL ;-) platzieren. Denn das hat sich "sehr bewaehrt". Wer moechte sich einer so orthogonalen Denkweise nicht anschliessen?

<posting class="chat">Seh'nsewohl?</posting>

PS: Der sich dafuer interessieren wuerde, ob Du schon mal eine Stored Procedure geschrieben hast.

Ja. (Vor vielen Jahren ... für irgendwas brauchten wir damals mal einen Trigger, weil die entsprechende Konsistenzeigenschaften einer Historischen Datenbank sich durch DDL allein nicht geschickt ausdrücken ließen und wir deren Prüfung nicht in die Anwendungen verlagern wollten, weil wir wußten, daß wie selbst via SQLplus/Kommandozeile auf die Tabellen zugreifen würden ...)

Viele Grüße
      Michael

[Lude]

Hi, Michael,

"algorythmische Logik" also in eine algorythmische Sprache (3GL ;-) platzieren. Denn das hat sich "sehr bewaehrt". Wer moechte sich einer so orthogonalen Denkweise nicht anschliessen?

<posting class="chat">Seh'nsewohl?</posting>

Du chattest auch gelegentlich, weisst Du das?   ;-)

PS: Der sich dafuer interessieren wuerde, ob Du schon mal eine Stored Procedure geschrieben hast.

Ja. (Vor vielen Jahren ... für irgendwas brauchten wir damals mal einen Trigger, weil die entsprechende Konsistenzeigenschaften einer Historischen Datenbank sich durch DDL allein nicht geschickt ausdrücken ließen und wir deren Prüfung nicht in die Anwendungen verlagern wollten, weil wir wußten, daß wie selbst via SQLplus/Kommandozeile auf die Tabellen zugreifen würden ...)

Da meine ich doch herauszuhoeren (und aus einer "historischen" Diskussion zum Thema objektorientierter Datenzugriff auf ein RDBMS nachtraeglich ebenfalls), dass Du dem Einsatz von sog. Stored Procedures grundsaetzlich skeptisch gegenueberstehst. Zumindest aus Portabilitaetsgruenden. Moechtest Du vielleicht dazu einen kleinen Vortrag halten? Welche Gruende Dich zu Deinem von mir vermuteten Verhalten bewegen?

Viele Gruesse,
Lude

[Michael Schröpl]

Hi Jana Vorodna,

M_ID = Messungs-(Mengen)-Nummer
MW_? = Meßwert in dieser Menge

M_ID	MW_A	MW_B	MW_C	MW_D	MW_E
1	100	101	2000	2500	3000
2	100	159	167	2800	2900
3	200	400	600	1100	2200
4	150	180	400	900	3000

Messung 1 will ich nicht haben, weil halt MW_A und MW_B zu nah aneinander sind
Messung 2 will ich nicht, weil MW_B und MW_C zu nah aneinander sind
Messung 4 hat 4 Meßwerte zwischen 100 und 1000 ... passt also nicht auf mein o.d. Schema

Du kannst eine WHERE-Klausel als OR-Konstrukt aller möglichen Fehlersituationen schreiben; wenn Du dieses anschließend negierst, bleiben die gültigen Datensätze übrig.

Bisher habe ich zwei Fehlerursachen gelernt:
a) Wert (n+1) - Wert (n) < epsilon;
b) Wert (n+3) <= 1000 AND Wert (n) >= 100;

Für eine endliche Anzahl von Spalten kannst Du das komplett hinschreiben. Ich nehme mal sechs Spalten, um das Prinzip zu zeigen (allfällige Tippfehler bitte selbst entfernen ;-):

SELECT * FROM table_name
 WHERE NOT (    (MW_B - MW_A < epsilon)
             OR (MW_C - MW_B < epsilon)
             OR (MW_D - MW_C < epsilon)
             OR (MW_E - MW_D < epsilon)
             OR (MW_F - MW_E < epsilon)
             OR (MW_A >= 100 AND MW_D <= 1000)
             OR (MW_B >= 100 AND MW_E <= 1000)
             OR (MW_C >= 100 AND MW_F <= 1000));
Das sieht schrecklich aus und ist zudem nur bei bekannter Spaltenzahl und bei Verwendung Deines konkreten Datenmodells überhaupt machbar. Aber vielleicht ist es das, was Du suchst?

Eine Lösung in einer algorithmischen Sprache würde eine entsprechende Logik sowohl performanter als auch übersichtlicher mit zwei Schleifen darstellen können.

Viele Grüße
      Michael