Tabellen für viele kleine Datensätze optimieren

[Medium]

Hallo,

ich bin gerade dabei, mir Vorüberlegungen zu einem Energie-Monitoring System zu machen. Bei unserem Kunden sollen diverse Strom/Gas/Wasser-Messgeräte verbaut werden, die via Modbus an Gateways übers Ethernet an unseren Server gehen. Die Messwerte sollen auch über Jahre gespeichet werden, um langfristige Betriebsoptimierungen darauf stützen zu können. Überschlagen fallen dabei etwa 150000 Messwerte pro Tag an, verteilt auf knapp 650 Messstellen.

Diese Werte sollen später sowohl als Liste gedruckt, aber auch grafisch betrachtet werden. Der Art "male mir bitte auf, wie sich die Spannung an Messstellen a, b und c zwischen dem 15.01.2014 und dem 15.02.2014 verhielt".

Meine Frage ist jetzt, wie ich mein Archiv am besten anlege. Bisher war ich von einer einzigen großen Tabelle ausgegangen, mit folgender Struktur:

SQL-Code:

CREATE TABLE `history` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `vdate` timestamp NOT NULL default '0000-00-00 00:00:00',
  `valueID` smallint(5) unsigned NOT NULL default '0',
  `maxValue` float NOT NULL default '0',
  `meanValue` float NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `Index_2` (`valueID`),
  KEY `Index_3` (`vdate`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='InnoDB free: 6144 kB; InnoDB free: 53248 kB; InnoDB free: 92'

(Es werden häufiger als gespeichert Werte abgerufen, und dann nur minütlich bis stündlich Maxima und Durchschnitte in die Tabelle geschrieben. Sonst wäre das beim tatsächlichen Leseintervall ein Datenaufkommen von grob gerechneten 4,5GB/Tag, was etwas üppig würde.)

"valueID" ist ein Fremdschlüssel auf eine Liste der rund 650 Messstellen mit ihren Klartextnamen und anderen Infos.

Ich hatte jetzt die Idee, dieses eine Monster-Archiv in mehrere Tabellen zu splitten. Dabei wäre eine Aufteilung nach Messstellen interessant, da ich mir dann das Feld "valueID" sparen kann, was der Datenmenge ganz gut tut. Da sicherlich aber auch hier und da Betrachtungen von Werten mehrerer Messstellen in einer Liste bzw. in einem Diagramm gefragt sind, würden dann ggf. größere UNION-Konstrukte nötig. Und es entstünden halt auch 650 Tabellen.
Alternativ wäre auch eine Teilung nach Datum denkbar, so dass man vielleicht pro Monat ein neues Archiv beginnt, das dann aber alle Messstellen beinhaltet. Dann gibt es die UNIONs bei Monatsgrenzüberschreitenden Auswertungen.

Da ich mit derart üppigen Satz-Mengen nicht die größte Erfahrung habe, würde ich gerne euch fragen, ob sich abschätzen lässt, welche Strategie die bessere wäre. Da nur maximal pro Minute neue Eintragungen sind (dann aber potenziell für alle 650 Messstellen am Stück), ist denke ich vor allem die Performance bei der Auswertung der Knackpunkt. Ich will die Leute nicht dazu verdammen, eine Grafik die Mittags gebraucht wird, vor der Frühstückspause abzufragen.

Ein paar Erfahrungswerte würden mir hier viel helfen. Vielen Dank schon mal!

[mkinzler]

Imho machst Du Dir durch die Aufteilung nur mehr Probleme als Du damit behebst. Die Anzahl der Datensätze in einer ist eigentlich egal, wenn die Indizes stimmen.

[himitsu]

Beim MySQL gibt es verschiedene Speicher-Engines, welche für bestimmte Zwecke optimaler sind.

So weit ich mich noch erinnere, gibt es Eine die speziell für's Logging gedacht ist und welche da auch weniger Speicherplatz benötigt.
Aber man sollte dann auch beachten, daß dort einige Features nicht vorhanden oder nur Teilweise unterstützt sind.
- eventuell keine Indize und daher keine/langsame Sortierung/Filterung/...
- eventuell keine (geprüften) Fremdschlüssel
- (möglicht) kein verändern vorhandener Daten
- selten/garnicht löschen (wenn dann eher alles nur nicht nur Teile)


Nja, bei den Datenmengen könnte man sich schon überrlegen, ob man Diese aufteilt.
- entweder die Tabelle von der DB partitionieren lassen
- oder vielleicht doch mehrere "kleine" Tabellen, für jeden Sensor, wo dann die spalten mit der immer gleichen Sensor-ID entfällt.

Auf jeden Fall sollte in die Tabellen keine sinnlose Record-ID-Spalte mit enthalten sein. (automatischer PrimaryKey)
Und die Datumswerte sollten durch eine fortlaufende ID ersetzt werden.
- entweder das Datum als Integer darstellen, so wie z.B. GetTickCount, wo dann je 5 Minuten ab einem bestimmten Datum um 1 hochgezählt wird
- oder es gibt eine extra Zeittabelle, wo eine Integer-ID für jedenen Datums/Zeit-Wert generiert wurde.



PS: Klingt das nicht nach einem Fall für ein Data-Warehouse?
Für die, welche auf den letzten Delphi-Tagen der Daniela zugehört haben. :stupid:

[jobo]

Die Aufteilung in Tabellen je Meßstelle halte ich für schlecht.
Dafür gibt es im zweifel Partitioning (weiß nicht ob mySQL das kann)

Physikalisch kann man auch ein paar Dinge regulieren, wenn z.B. nie ein Update erfolgt, kann man den Füllgrad von daten und index pages auf 100 % setzen (auch hier weiß ich nicht, wie es bei mySQL genau ist)

ggF könnte man sich den PK Schlüssel sparen. Hier werden sowieso kumulierte Werte abgelegt, ein eigenständiger PK macht da wohl nicht viel Sinn. Dann eher einen kombinierten PK Schlüssel plus Index auf MessStation plus Datum, sollte ja bei 1 Minuten Intervallen reichen.
Diesen Index sollte man dann manuelle anlegen nicht automatisch per Konstraint.
Damit kann man etwas spielen/ausprobieren, ggF 2 separate Indizes mit Unique Constraint und verfügbare Indexvarianten testen.

[himitsu]

Wenn du schon Indize verwendest, dann eventuell so, daß sie sich schneller nutzen lassen?
Du greifst ja bestimmt entweder nur über die ValueID auf (alle) Werte eines Sensors zu, oder auf alle Sensorwerte in einem bestimmten Zeitraum und dementsprechen sollten dann doch die Indize gewählt werden. :gruebel:

Das ID-Feld in der Wertetabelle ist jedenfalls nutzlose Platzverschwendung.

SQL-Code:

CREATE TABLE Zeittabelle (
  `id` INT AUTO_INCREMENT PRIMARY KEY,
  `time` TIMESTAMP NOT NULL UNIQUE
)

CREATE TABLE Quelltabelle (
  `id` SMALLINT AUTO_INCREMENT PRIMARY KEY,
  `name` VARCHAR(50) NOT NULL UNIQUE,
  ...
)

CREATE TABLE WertTabelle (
  `valueID` SMALLINT NOT NULL REFERENCES Quelltabelle,  -- vielleicht doch INT, das wären dann schöne 4*4 = 16 Byte pro Datensatz plus den Index
  `timeID` INT NOT NULL REFERENCES Zeittabelle,
  `maxValue` FLOAT NOT NULL, --DEFAULT 0,
  `meanValue` FLOAT NOT NULL, --DEFAULT 0,
  PRIMARY KEY (`valueID`, `timeID`),
  KEY Index_2 (`timeID`)
)

Um die Größe der WertTabelle aufzuteilen:
http://dev.mysql.com/doc/refman/5.7/...titioning.html

Und noch etwas zu den Engines:
http://dev.mysql.com/doc/refman/5.1/...e-engines.html



Man könnte auch Werte zusammenfassen, was zwar Speicherplatz sparen würde, aber beim Auslesen und Auswerten gibt das erhöhten aufwand, da man dann die Spalten wieder auf mehrere Zeilen auftrennen/drehen müsste.
Also ich glaub nicht, daß es den Aufwand wert wäre.

z.B. die Werte für je 10 Sensoren pro Datensatz.
0 = valueID=0 bis valueID=9
1 = valueID=10 bis valueID=19
...

SQL-Code:

CREATE TABLE WertTabelle (
  `valueIndex` SMALLINT NOT NULL REFERENCES Quelltabelle,
  `timeID` INT NOT NULL REFERENCES Zeittabelle,
  `maxValue0` FLOAT NOT NULL DEFAULT 0,
  `meanValue0` FLOAT NOT NULL DEFAULT 0,
  `maxValue1` FLOAT NOT NULL DEFAULT 0,
  `meanValue1` FLOAT NOT NULL DEFAULT 0,
  ...
  `maxValue9` FLOAT NOT NULL DEFAULT 0,
  `meanValue9` FLOAT NOT NULL DEFAULT 0,
  PRIMARY KEY (`valueIndex`, `timeID`),
  KEY Index_2 (`timeID`)
)

[p80286]

Zitat:

Zitat von Medium (Beitrag 1264972)

Überschlagen fallen dabei etwa 150000 Messwerte pro Tag an, verteilt auf knapp 650 Messstellen.

Gehen wir mal von 100 Byte pro Datensatz aus (ich halte aber nicht viel von dieser Byte-Klauberei) dann sind das 150 MByte / Tag. wie Du auf 4,5 GByte kommst ist mir da schleierhaft.
Die Struktur Deiner Tabelle ist meiner Meinung nach durchaus in Ordnung, nur würde ich der ValueID den gleichen Typ verpassen wie der ID.

Gruß
K-H

[himitsu]

Bei den genannten 16 Byte sind es nur 2,2 MB ... vielleicht meinte er ja 4,5 MB und nicht GB? :angel:

[Dejan Vu]

Eins vorneweg: Nachdenken und sich einen abbrechen ist teurer als jedes TB.

Bei der Frage nach der Auswertung wirst Du wohl oder übel auf (Zeitraum in Tagen)x150k Daten kommen. Die Frage ist, ob das irgend eine Sau in der Auflösung benötigt....

Hier ist der Einsatz eines Datastores (also ein Teil eines DWH) imho die bessere Wahl. In einem Datastore sind die Daten (redundant) in der für Auswertungen notwendigen minimalen Granularität abgelegt. Braucht ihr die Daten auf die Sekunde genau?

Angenommen, ihr benötigt Auswertungen über mehrere Monate: Da wäre eine Granularität von 5 Minuten sicherlich vollkommen ausreichend, wenn Du mit Livedaten spielen willst, vielleicht noch gröber, also so alle 10-15 Minuten. Dann saugst Du dir pro Query ein paar 1000 Werte und kannst die in Memory in Echtzeit verarbeiten, auch mit nem iPad ;-)

Wenn Du Peaks innerhalb der Minute trotzdem sehen willst, dann enthält ein Datensatz der verdichteten Auswertungstabelle nicht nur die Anzahl der Messdaten, Mittelwert, Min,Max, etc., sondern auch Informationen über cpk, mean etc., vielleicht ein paar Splinekoeefizienten, eben alles was man so braucht, um Daten bewerten zu können.

Diese Tabelle fütterst Du in Echtzeit mit deinen Messdaten z.B. per Trigger oder Zeitgesteuert alle 5 Minuten...

Was Du also machst, ist (1) auf Speicherplatz zu pfeifen und lieber ne Platte mehr kaufen und (2) verdichtete und optimal gepimpte Tabellen für die jeweilige Fragestellung bez. den Auswertungskomplex zu erstellen. Der Trick dabei ist, eigentlich gar nichts mehr zur Queryzeit zu suchen oder zu aggregieren, sondern gleich 1:1 aus den Tabellen zu laden (wohlgemerkt: Die Archivdaten fässt Du gar nicht an)

Deine Archivdaten kannst Du dann ruhig so ablegen, wie Du Dir das vorgenommen hast. Das ist ja zweitrangig, wie genau das geht und ob das 100% optimal ist, denn deine Auswertetabellen sind um ein vielfaches schneller.

Wenn man bei der Übersicht in die Verläufe reinzoomen will, kannst Du dann einfach ab einer bestimmten Granularität einfach auf die Einzeldatensätze gehen. Da ziehst Du dir dann nur ein paar 1000 und bist wieder ratzfatzschnell.

Bei den verdichteten Auswertetabellen kommt das Star-Design zum Einsatz (im Gegensatz zum Snowflake-Design bei 3NF Produktionsdatenbanken). Alles redundant abgelegt, verbrät viel Speicher, ist aber performancetechnisch optimal.

[Blup]

Aufteilung in mehrere Datentabellen und Dateien:

1.Tabelle nimmt nur fortlaufend die aktuellen Daten entgegen.
Ein Prozess verarbeitet stündlich diese Daten für die Agregattabellen.
Damit entfallen unnötige Lesezugriffe, jeder Datensatz wird in dieser Tabelle genau einmal erzeugt, gelesen und gelöscht.

2.Tabelle mit stündlich zusammengefassten Werten
Ausreichend für grobe Auswertungen.

3.Tabelle mit minutengenau zusammengefassten Werten
Für Detailauswertungen.

Eventuell jedes Jahr eine neue Datenbankdatei, um Platz bei der Datensicherung zu sparen.

[Medium]

Uiui, viel Lesestoff, sehr fein! Danke euch schon mal! Morgen werde ich mich mit dem Thema hoffentlich wieder konzentriert befassen können, heute kam leider etwas dazwischen. (Daher bis jetzt keine Rückmeldung.)

Nur schon mal schnell, weil's mir beim Überfliegen auffiel: Die 4,5GB (ja, giga) waren bezogen auf den ganz ursprünglichen Plan vom Kunden, wirklich alle Messstellen sekündlich aufzunehmen. Zwar ist ein Datensatz nur 16 Byte groß, ich habe aber mal zum Test ein paar 100000 erzeugt, und geschaut was der alte MySQL Administrator als Tabellen- und Indexgröße ausgespuckt hat. Das war in Summe pro Datensatz dann ca. 82 Byte - warum auch immer. (Ich bin mir auch fast sicher, dass die Messmethode Käse ist, ich wollte es nur ein Mal schnell ganz grob über'n Daumen peilen.)
Da hieß es dann eben für sekündlich: 650*82*24*60*60 = 4392 GB, aber das ist nicht mehr relevant! Mit den revidierten Intervallen komme ich jetzt auf die o.g. 150000 Sätze pro Tag, was nach der genannten "Messmethode" rund 12MB am Tag füllt. Das ist denke ich völlig okay.

Mehr morgen!

[Sir Rufo]

Wofür benötigst du denn

SQL-Code:

`id` int(10) unsigned NOT NULL auto_increment,

?

Eigentlich ist die doch für nix gut ...

• Ein PK würde sich anbieten auf valueID und vdate.
• Statt InnoDB eher MyISAM nehmen.
• Partitions auf die Jahre legen (eine monatliche Unterteilung geht auch mit
  SQL-Code:

  Extract( YEAR_MONTH FROM vdate )

  )

SQL-Code:

CREATE TABLE `history` (
  `valueID` smallint(5) unsigned NOT NULL,
  `vdate` datetime NOT NULL,
  `maxValue` float NOT NULL,
  `meanValue` float NOT NULL,
  PRIMARY KEY (`valueID`,`vdate`)
) 
PARTITION BY RANGE(YEAR(valueDate)) 
PARTITIONS 3 (
  PARTITION `p2012` VALUES LESS THAN (2013) ENGINE=MyISAM , 
  PARTITION `p2013` VALUES LESS THAN (2014) ENGINE=MyISAM , 
  PARTITION `pCurrent` VALUES LESS THAN (MAXVALUE) ENGINE=MyISAM ) 
ENGINE=MyISAM

Um für das nächste Jahr eine neue Partition anzufügen einfach diesen Befehl ausführen

SQL-Code:

ALTER TABLE `values` REORGANIZE PARTITION pCurrent INTO
( PARTITION p2014 VALUES LESS THAN (2015),
   PARTITION pCurrent VALUES LESS THAN MAXVALUE )

Mit den Partitions hat sich dann das Problem mit der Datensicherung auch erledigt, denn nun gibt es pro Partition separate Dateien und wenn nur aktuelle Datensätze angefügt werden, dann bleiben die alten Dateien unberührt und müssen eben nicht mehr gesichert werden.

[Dejan Vu]

Zitat:

Zitat von Sir Rufo (Beitrag 1265022)

Wofür benötigst du denn

SQL-Code:

`id` int(10) unsigned NOT NULL auto_increment,

?

Weil es allgemein gesehen besser ist, für einen Datensatz einen eindeutigen anonymen Schlüssel zu haben. Ob es hier besser ist? Wenn man -wie vermutlich hier- die Daten nie ändert, sondern nur anfügt, braucht man das tatsächlich nicht. Da wird dann aber auch überhaupt kein PK benötigt.

Da man nur über vDate und ValueID abfragt, sollte ein Index reichen: ValueID+vDate (das meint Sir Rufo vermutlich mit 'PK über ValueID und vDate'. Hier steht jedoch nicht der Primary Key im Vordergrund, sondern ein nonunique index. Denn: Falls vDate in der Granularität nicht pikosekundengenau ist, wäre es denkbar, zwei Messwerte zum gleichen Zeitpunkt zu haben. Zumindest ausschließen kann man das nicht.

MySQL kennt vermutlich keinen Clustered Index, so wie MS SQL-Server. Gäbe es jedoch ein ähnliches Konzept, wäre ein Clustered Index über vDate+ValueID noch schneller, da bei den Abfragen nur ein Clustered Index-Seek/Scan ausgeführt wird.

Wenn man beim Auswerten über einen Zeitraum auch 'nur Morgens zwischen 8-10' abfragen will, dann Datum und Uhrzeit getrennt, sonst als Timestamp.

Grundsätzlich würde ich trotzdem das Konzept mit den redundanten Aggregationstabellen verfolgen, es macht einfach Spaß, in Echtzeit in die Daten zu zoomen und zu scrollen, ohne irgendwelche Last zu produzieren. Man sollte ja auch bedenken, das man entweder eine separate Auswerte-DB erstellt, oder -wenn man das nicht macht- den Server mit Auswertungen nicht zu sehr belastet. Das wäre dann ziemlich blöd, wenn er gerade wie ein blöder Daten fressen soll, aber nicht kann, weil eine Tabelle wegen einer Auswertung gelocked ist.

Zitat:

Mit den Partitions hat sich dann das Problem mit der Datensicherung auch erledigt,...

Top.

[Medium]

Södale, ihr habt mich ganz gut davon überzeugen können, dass eine Spaltung in mehrere Tabellen nicht das Gelbe vom Ei ist. Den aktuellen PK, also das autoinc Feld, kann ich hier tatsächlich weg lassen. Hab mir das angewöhnt, weil ich es für unsere Hauptanwendung zwingend brauche, das hier ist aber ausser der Reihe. Der fliegt also schon mal.

Partitioning klingt sehr praktisch, danke auch für das Beispiel als Code. Gelesen habe ich ein wenig drüber, genutzt bisher nicht. Das einzige was mich an der gezeigten Variante stört ist, dass ich quasi jedes Jahr ein "Pflege-Statement" ausführen muss, was mit Sicherheit spätestens nach dem 2. Jahr im Tagesgeschäft unter geht. Kann man es so deichseln, dass mit Beginn eines neuen Jahres automatisch eine neue Partition begonnen wird?

Bezüglich Index: Hier fehlt mir auch noch ein wenig Erfahrung um genau sagen zu können, welche Indizes ich hier wirklich brauche. Einen PK braucht es glaube ich wirklich nicht, aber wenn, dass wäre vdate+valueID ein guter Kandidat. Die kürzesten Intervalle von Einträgen mit derselben valueID sind 1 Minute, also garantiert verschiedene Timestamps.
Bisher habe ich recht naiv immer über die einzelnen Felder einen Index angelegt, die ich nachher in meinen WHERE-Klauseln benutze. Das wäre in diesem Fall vdate und valueID, auch in Kombination. Es wird nachher sicherlich ein Statement der folgenden Struktur genutzt um die Daten zu holen:

SQL-Code:

SELECT
  h.vdate, h.valueID, h.maxValue, h.meanValue, v.valueName 
FROM 
  history h JOIN valueList v 
    ON h.valueID = v.id 
WHERE 
  (h.vdate BETWEEN :sDate AND :eDate) AND 
  (v.valueID IN ({idListe}))

Edit: Der Join macht eigentlich kaum Sinn, da ohnehin bei der Ausgabe nach valueID, vdate sortiert werden sollte. Die Messstellennamen kann ich mir also auch billiger in einem separaten Statement holen und als Überschrift/Legende einsetzen. Die müssen nicht bei jedem Datensatz einzeln bei stehen.

Ist es da besser einen kombinierten Index auf vdate und valueID zu legen, oder jedes Feld seinen eigenen? Oder gar beides? Welche Art von Index eigenet sich hier? (Beide Felder sind für sich genommen non-unique, in Kombi aber unique.) Mein MySQL Tabellen-Tool bietet mir hier die Optionen:
Index Kind: Index, Primary, Unique, Fulltext, Spatial
Index Type: Default, BTree, Hash, RTree
Ich habe mich bisher schämlich wenig damit befasst, welche Index-Arten für welche Fälle geeignet sind :oops:

Die angesprochene Trennung von Datum und Uhrzeit wird nicht nötig sein. Wenn, dann werden immer komplette Zeiträume am Stück abgefragt.

Eine separate Tabelle mit Daten zur Anzeige, und Umschaltung bei Zoom klingt zunächst sehr nett, aber ich weiss nicht, ob ich es mir leisten kann auf Dauer mehrere Granularitäten vollständig vorzuhalten. Klar ist, dass ich bei einem Zoom, der pro Pixel im Graphen z.B. 30min entspricht nicht alle minütlichen Werte übers Netzwerk jagen lassen wollen würde. Das Problem habe ich mir bisher nicht genauer angesehen, und hatte gehofft eine Möglichkeit zu finden vielleicht angeben zu können, dass ich nur jeden 2. oder 3. Datensatz einer Ergebnismenge vom Server bekomme. Gibt es sowas?
Wenn nicht, werden redundante Tabellen leider doch wieder interesant, weil vermutlich die letzte Möglichkeit dann.

Danke zwischendurch schon mal für die rege und produktive Teilnahme! :dp:

[Sir Rufo]

Du kannst beim MySQL Events definieren, die zu einem bestimmten Zeitpunkt laufen, also erstellst du dir einen Event, der einmal im Jahr losläuft und die entsprechende Partition neu erstellt.

Hier auch ein entsprechender SO-Beitrag

Der Pflegeaufwand geht also auch gegen Null :)

[Dejan Vu]

Zitat:

Zitat von Medium (Beitrag 1265045)

Ist es da besser einen

Es wird nur ein Index verwendet, ergo dürfte der kombinierte Index der richtige sein. In welcher Reihenfolge? ich würde ValueID+vDate nehmen, wenn Du nur von wenigen der 650 Stationen Werte über einen Zeitraum haben möchtest. Aber *wetten* würde ich nicht.

Zitat:

... Gibt es sowas? Wenn nicht, werden redundante Tabellen leider doch wieder interesant, weil vermutlich die letzte Möglichkeit dann.

Wieso eigentlich 'leider'? Das ist mit ein paar Triggern oder cron-Jobs gemacht (also alle paar minuten die Daten der letzten paar Minuten aggregieren und in die Reporttabellen schubsen)

[Jasocul]

Bei den Datenmengen würde ich mit dem automatischen Partitioning vorsichtig sein. Es wird wohl in der Regel problemlos funktionieren, aber ich würde das lieber auf Termin legen und unter eigener Aufsicht laufen lassen. Ist aber Geschmackssache.

Was für dich auch interessant sein könnte, sind Indexed Views. Dort hast du dann automatisch deine aggregierten Werte und brauchst keine Trigger oder Events. Es gibt aber wohl ein paar Einschränkungen, soweit ich das auf die schnelle gelesen habe. Ich kenne das unter Oracle unter dem Begriff "Materialized Views" und habe damit gute Erfahrungen gemacht. Allerdings habe ich die nicht automatisch aktualisieren lassen, da ich entsprechende Auswertungen nur monatsweise benötigt habe. Da bot sich ein Refresh einmal im Monat an.

[Dejan Vu]

Zitat:

Zitat von Jasocul (Beitrag 1265056)

... sind Indexed Views. Dort hast du dann automatisch deine aggregierten Werte und brauchst keine Trigger oder Events. Es gibt aber wohl ein paar Einschränkungen, ...

Achtung! mySQL... nicht SQL-Server

[Jasocul]

Zitat:

Zitat von Dejan Vu (Beitrag 1265060)

Achtung! mySQL... nicht SQL-Server

Ups. Sorry.

[p80286]

Da ich bisher nur gute Erfahrungen mit views gemacht habe, würde ich diese auch bevorzugen (oracle).
Jedesmal wenn ich irgendwelche kumulierten Daten in die Finger bekomme, gibt es ein paar Abweichungen, weil immer der eine oder andere Job nicht gelaufen ist oder einen Fehler hatte oder...
(Es kommt immer auf die Daten - die gespeicherten und die gefragten - an)

Gruß
K-H

[himitsu]

Aber bei vielen Daten ist ein View doch auch nicht so gut, wenn er erst stundenlang rumrechnen würde, bei jeder Abfrage.

Drum auch der Vorschlag mit dem Data-Warehouse.
Die Dinger sind erstmal für viele Daten ausgelegt und sie bieten auch sowas wie Views, nur daß Diese job-/zeitgesteuert die Daten der Ansichten vorberechnen, was dann die Abfragen schneller macht.

[Medium]

Jetzt machst du mich aber spontan unglücklich, p80286. Ich habe soeben folgende Prozedur im Testlauf, die da alle 10 Sekunden* vom selben Programm ausgeführt wird, dass auch die originale Historie schreibt, und für das Pollen meiner Energiewerte sorgt:

Delphi-Quellcode:

procedure TForm1.MakeGranularValues;
  procedure ProcessGranularity(aTableName, aPriorGranularityTableName: String; aTimeDeltaInMinutes: Integer);
  var
    d1, d2: TDateTime;
  begin
    // Einen Zeitpunkt finden, zu dem der End-Zeitpunkt d2 in der Vergangenheit liegt, und
    // dessen Start-Zeitpunkt dem Raster gehorcht, dass entsteht, wenn man ab 00:00:00 des Tages an
    // in "aTimeDeltaInMinutes" Schritten hochgezählt hat. Beginne mit 0 Uhr des gestrigen Tages, da
    // 24 Stunden das größte Raster sind, und der gestrige Tag somit noch erfasst wird.
    d1 := Trunc(Now)-1;
    d2 := IncMinute(d1, aTimeDeltaInMinutes);
    while (d2 < Now) do
    begin
      d1 := d2;
      d2 := IncMinute(d1, aTimeDeltaInMinutes);
    end;
    d1 := IncMinute(d1, -aTimeDeltaInMinutes);
    d2 := IncMinute(d2, -aTimeDeltaInMinutes);

    Qry.SQL.Text := 'SELECT COUNT(valueID) FROM '+aTableName+' WHERE vdate BETWEEN :d1 AND :d2';
    Qry.ParamByName('d1').AsDateTime := d1;
    Qry.ParamByName('d2').AsDateTime := d2;
    Qry.Open;
    if Qry.Fields[0].AsInteger = 0 then
    begin
      Qry.Close;
      Qry.SQL.Text :=
        'INSERT INTO '+aTableName+' (vdate, valueID, maxValue, meanValue) '+
        '(SELECT :d1, valueID, MAX(maxValue), SUM(meanValue)/COUNT(meanValue) '+
        'FROM '+aPriorGranularityTableName+' '+
        'WHERE (vdate BETWEEN :d1 and :d2) '+
        'GROUP BY valueID)';
      Qry.ParamByName('d1').AsDateTime := d1;
      Qry.ParamByName('d2').AsDateTime := d2;
      Qry.Execute;
    end
    else
    begin
      Qry.Close;
    end;
  end;
begin
  ProcessGranularity('history_g10min', 'history',          10);
  ProcessGranularity('history_g30min', 'history_g10min',   30);
  ProcessGranularity('history_g1h',    'history_g30min',   60);
  ProcessGranularity('history_g6h',    'history_g1h',     360);
  ProcessGranularity('history_g24h',   'history_g6h',    1440);
end;

Klar ist, dass wenn diese irgendwo mal auf einen Hammer läuft, dann kummulierte Daten fehlen. Jedoch werde ich da noch diverse Schutzblöcke einarbeiten, und es spricht nichts dagegen im Bedarfsfall eine komplette Rekunstruktion der kummulierten Tabellen von der originalen Historie an zu bilden. Oder gar nur punktuelle für fehlende Zeiträume.

Bei Views wüsste ich jetzt nicht so genau, wie ich die Anforderung erfüllen sollte, die in dem längeren Kommentar beschrieben ist. Und Views werden doch auch dynamisch ausgeführt oder? Die Abfrage auf die originalen "feinen" Daten würde damit ja trotzdem nötig werden. Zwar dann verdichtet über's Netzwerk gehen, aber der Server hätte dennoch die volle Arbeit zu tragen. Bin da skeptisch.


*) Alle 10min sollte genügen, zum testen und schauen wie es sich auf die Performance auswirkt hab ich's mal schneller gemacht

[Dejan Vu]

jasocul meinte 'materialized views' oder 'indexed views', wie sie bei SQL-Server heißen. Das sind keine Views im klassischen Sinn, also einfach nur kompilierte Queries, sondern wirkliche Tabellen (weswegen sie bei Oracle eben 'materialized' heißen). Bei Oracle muss man die Aktualisierung selbst anstubsen, soweit ich mich erinnere, bei SQL-Server nicht.

Da das normale Tabellen sind, kann man eben auch einen Index draufpacken, was bezüglich der Auswertungen wirklich eine tolle Sache ist.

Ich sehe gerade, das geht auch irgendwie mit mySQL:
http://www.fromdual.com/mysql-materialized-views

PS: Kennt mySQL kein 'AVG' (als Ersatz zu SUM(**)/COUNT(**))? Wobei das eben auch in die Hose gehen kann, wenn Count(*) = 0 ist...

[Medium]

Wenn COUNT() 0 ist, werden keine Sätze selektiert, also auch die Funktion nicht ausgeführt. Gut möglich, dass es AVG() gibt - ich schaue mal. Hab nicht daran gedacht, dass es das ja schon fertig geben könnte :)

Die materialized Views schaue ich mir mal an, klingt "spacig".

[p80286]

Zitat:

Zitat von Medium (Beitrag 1265065)

Jetzt machst du mich aber spontan unglücklich, p80286.

War nicht meine Absicht. Ich kann Dir nur sagen, das ich mit Datawarehouse bisher nur Ärger habe, was auch daran liegt, das die DatenAnforderer sich nicht darüber im klaren sind, daß die Daten -in meinem Fall- vom Vortag sind. Sogar bei statistischen Auswertungen ist das schon aufgefallen.

Darum
1. es kommt darauf an
2. solange es läuft ist es in Ordnung
3. Ein Patentrezept gibt es nicht.

Gruß
K-H

[Namenloser]

Mal ganz ketzerisch gefragt: Braucht man da überhaupt SQL? Ich meine, bei Webservern und generell unter Unix ist es ja auch Gang und Gäbe, Zugriffslogs (das können auch gerne mal mehrere Eintrage pro Sekunde werden) einfach als Textdatei mit einem Datensatz pro Zeile abzuspeichern und in regelmäßigen Abständen, z.B. einmal am Tag, ein neues Logfile anzufangen und das alte ggf. zu komprimieren. So hat man dann eine Reihe von Logfiles, für jeden Tag eins.

Wenn man eigentlich eh nur den Verlauf plotten will und nicht wirklich komplizierte relationale Abfragen hat, dann reicht das doch im Grunde.

[Dejan Vu]

Die Frage ist gar nicht ketzerisch, denn man soll ja immer den einfachsten und kürzesten Weg gehen: jede Form der Abfrage, sogar das speichern selbst, ist per Textdatei mit einem höheren Aufwand verbunden, als ein RDBMS damit zu beauftragen.

[Namenloser]

Ich habe mich halt nur gefragt, ob SQL wirklich das richtige Werkzeug ist... meiner Meinung nach glänzt SQL, wenn man komplexe Beziehungen, auch über verschiedene Tabellen hinweg, auswerten will. Für einfache Messreihen sehe ich nicht so den Vorteil.

NoSQL wurde in den letzten Jahren ja sehr gehyped, aber ich denke das hier könnte mal ein echter Anwendungsfall für so etwas sein. Allerdings, bevor man sich den ganzen Overhead antut, vielleicht tut es ja auch schon eine einfache, bewährte Log-Datei, so ganz KISS. Das war so mein Gedankengang.

[mkinzler]

NoSQL eignet sich imho eher für uneinheitliche Daten. In diesem Fall sind diese ja sehr standardisiert.

Textdateien sind schwerer auszuwerten.

[DSP]

Moin Medium,

weisst du welches Datenvolumen du da im Jahr generierst?

Ich würde hier eine rollierende Datenhaltung aufbauen mit passenden Summentabellen. Die Details, einfach im Verzeichnis ablegen und bei bedarf einlesen. Hier reicht eine CSV bei weiten :)

Innerhalb eines Jahres würde ich 12 Monatsummentabellen aufbauen, welche jedes Jahr wieder neu überschrieben werden. Das Datum würde ich einfach einen Verweis auf eine Datumstabelle setzen und den PK als Integer ausgestalten.

Eine rollierende Monatstabelle hätte dabei wohl in etwa die folgende Definition:

{@zähler, @Tag; @Zeitinkrement; MaxV, MeanV}

Wobei ein Zeitinkrement einfach ein Zähler ist, der einen Tag zerteilt, als bspw. 10 Minuten inkrement von 0 bis 24 Uhr. Wenn Du dann ein Jahr durch hast, wird dann einfach die Monatstabelle ausgelagert und initialisiert... dann gehts wieder von vorne los. Werden Details benötigt oder ältere Zeiträume als ein Jahr benötigt, wird eben im File Archiv nachgelesen. Wenns nicht mehr interessiert, kann das von der Platte geputzt werden und wenn deine Auswerteroutine da nichts mehr findet, gibts einfach eine Meldung, keine weiteren Daten verfügbar. Das kann dann so die nächsten hundert Jahre, wartungsarm, laufen.

Grüssle
DSP

[Dejan Vu]

Wieso wollt ihr bloß immer irgendwelche eigenen Datenformate, bei denen man Aggregierung und Filterung wieder von Hand programmieren muss? :wall:

[DSP]

Weil das Progy sonst nach n paar Monaten verdamt wird und nach einen Jahr nicht mehr läuft ...

Grüssle
DSP

[himitsu]

Gerade wenn man sich auf bestehende/bekannte Strukturen bezieht, wird es nicht schnell Probleme geben.

Es ist ja nicht so, daß man unbedingt jedes mögliche Bit einsparen muß.
Lieber ein paar Byte mehr und dafür sind die Daten wenigstens gut verarbeitbar.

Natürlich kann man im Spezialfall auch mal alles extrem auf größe optimiert in binären Rinspeichern ablegen, aber wozu alles neu erfinden,
wenn man sich auch eine der vielen vorhandenen und voallem leicht anpassbaren und erweiterbaren Lösungen auswählen kann.

[Dejan Vu]

Zitat:

Zitat von DSP (Beitrag 1265093)

Weil das Progy sonst nach n paar Monaten verdamt wird und nach einen Jahr nicht mehr läuft ...

Äh, eigentlich nicht. Das 'Progy' wird auch in 20 Jahren noch genauso schnell laufen, wie am ersten Tag. Du solltest Dich mal eingehend mit RDBMS beschäftigen. Meinst Du denn im Ernst, Google, Amazon & Co verwenden rollierenden Text-Dateien? Was ist denn mit deinem Ansatz, wenn Du doch noch in den Summentabellen das Windsormittel oder den harmonischen Median haben willst? Wie lange sitzt Du denn daran? Wie regelst Du das mit graphischen Auswertungen in, sagen wir, EXCEL? Schreibst Du dir dann eine Schnittstelle, oder einen Ole-DB Provider, um an deine Summentabellen zu kommen? Ach nein, Du öffnest die Summentabelle und c&p'st das Zeugs in Excel. Aber -blöd- nun wollten wir doch die Werte der letzten drei Monate jeweils zwischen 8 und 10 Uhr, immer Dienstags, weil der Kunde meint, wenn der Bäcker die Brötchen bringt (immer Dienstags zwischen 8-10 Uhr), spinnen die Messpunkte.

[DSP]

Wüsste nicht was da unbekannte Strukturen sind? Es ist einfach ein Compound Key, das wars. Alle Daten liegen in der Datenbank und können Problemlos gelesen werden. Und dass man die Zeit normalisieren muss, liegt auf der Hand, warum dann nicht die 650 Stationen auf einen Zeitstempel vereinheitlichen? Wenn details nötig sind, muss sowieso nachgelesen werden.

Auch hier mit dem rollierenden und wartungsarmen verfahren, dürften mehrere Gigs im Jahr überschritten werden und es ist nur eine Frage der Zeit, mis da noch weitere Stationen dazu kommen und ehrlich, wenn schon dieser Detailgrad gefordert wirs, wenn interessierts in n paar Jahren noch welche Station n paar Jahre zuvor einen höheren value hatte als die andere Station n paar millisekunden davor?

Grüssle
DSP

[DSP]

Zitat:

Zitat von Dejan Vu (Beitrag 1265095)

Zitat:

Zitat von DSP (Beitrag 1265093)

Weil das Progy sonst nach n paar Monaten verdamt wird und nach einen Jahr nicht mehr läuft ...

Äh, eigentlich nicht. Das 'Progy' wird auch in 20 Jahren noch genauso schnell laufen, wie am ersten Tag. Du solltest Dich mal eingehend mit RDBMS beschäftigen. Meinst Du denn im Ernst, Google, Amazon & Co verwenden rollierenden Text-Dateien? Was ist denn mit deinem Ansatz, wenn Du doch noch in den Summentabellen das Windsormittel oder den harmonischen Median haben willst? Wie lange sitzt Du denn daran? Wie regelst Du das mit graphischen Auswertungen in, sagen wir, EXCEL? Schreibst Du dir dann eine Schnittstelle, oder einen Ole-DB Provider, um an deine Summentabellen zu kommen? Ach nein, Du öffnest die Summentabelle und c&p'st das Zeugs in Excel. Aber -blöd- nun wollten wir doch die Werte der letzten drei Monate jeweils zwischen 8 und 10 Uhr, immer Dienstags, weil der Kunde meint, wenn der Bäcker die Brötchen bringt (immer Dienstags zwischen 8-10 Uhr), spinnen die Messpunkte.

Sorry Dejan Vu, das ist schlichtweg blödsinn. Einmal kann Excel keine Terra an Zeilen halten und zweitens intessiert dies kein Schwein. Auch bei weiteren statistischen daten, min fehlt mir bspw im Datenformatt, muss man irgendwann sagen ab wann man berechen will. Es interessier auch niemanden, welchen Wert hier bspw Station Null vor dreihundert Jahren hatte, der war schöicht und einfach Null! Es interessiert also immer ein bestimmter Zeitraum, wenn man will, kann man die Historischen Werte auch getrennt aufzeichnen, wie gesagt, Min ist schon mal Null :twisted:

Grüssle
DSP

[Dejan Vu]

Zitat:

Zitat von DSP (Beitrag 1265098)

Sorry Dejan Vu, das ist schlichtweg blödsinn.

Ist es nicht. Ich will aus EXCEL heraus die 3 Stunden vom Januar 1980 in meiner Auswertung darstellen, wegen der Anomalie. Wie geht das mit deinen rollierenden Tabellen? Das sind übrigens auch keine Terra(?) an Daten, sondern z.B. ähm, warte 3x60=180 Datenpunkte pro Station, soweit ich das richtig verstanden habe.

Dessenungeachtet könnte es ja sein, das z.B. die Messdaten in einem Atomkraftwerk(darum geht es hier nicht, aber egal) oder in einer Fabrik über mehrere Jahre aufbewahrt werden müssen und ich möchte bitte nicht erst Stundenlang im Archiv irgendwelche Zipdateien entpacken, um mir die Aufzeichnungen anzuschauen. Muss ich auch nicht, ich habe ja mein RDBMS mit meinen Archivdaten: Kurz gemounted, Auswertung gestartet, fertig.

Zitat:

und zweitens intessiert dies kein Schwein.

Das stimmt. Die meisten Schweine interessieren sich nicht dafür, aber Kontrolleure und Ingenieure z.B. Das nennt sich Tracing und ist im ISO-Prozess zwingend. Bei bestimmten Produkten beträgt die Aufbewahrungsfrist für Messprotokolle 10 Jahre und mehr und wenn Reklamationsmanagement ernstgenommen wird oder -wie Medium das angedeutet hat- Qualitätsmanagement gelebt wird, sollte man sich schon auch mal die Daten von vor ein paar Jahren anschauen können. Sogar einzelne Werte.

Zitat:

Min ist schon mal Null :twisted:

Den Rest deiner Argumentation habe ich nicht verstanden (wie das z.B.), das war zu konfus.
So, nun komm wieder runter.

[jobo]

Zitat:

Zitat von Medium (Beitrag 1265045)

Ist es da besser einen kombinierten Index auf vdate und valueID zu legen, oder jedes Feld seinen eigenen? Oder gar beides? Welche Art von Index eigenet sich hier? (Beide Felder sind für sich genommen non-unique, in Kombi aber unique.) Mein MySQL Tabellen-Tool bietet mir hier die Optionen:
Index Kind: Index, Primary, Unique, Fulltext, Spatial
Index Type: Default, BTree, Hash, RTree
Ich habe mich bisher schämlich wenig damit befasst, welche Index-Arten für welche Fälle geeignet sind :oops:

Ich würde es mit getrennten Indizes machen. Das ist flexibler. Ein kombinierte Index greift u.U. nicht, wenn weitere Bedingungen ins Spiel kommen.
Die uniqueness kannst Du separat per constraint definieren. NOrmalerweise tuen RDBMS einem den "Gefallen" abhängig vom Constraint direkt auch einen Index zu bauen, aber das kann man unterbinden, löschen, ändern.

Zitat:

Zitat von himitsu (Beitrag 1265063)

Aber bei vielen Daten ist ein View doch auch nicht so gut, wenn er erst stundenlang rumrechnen würde, bei jeder Abfrage.

Das kann man pauschal nicht sagen. Ein View ändert per se nichts an der Abfragegeschwindigkeit.
Ausnahme wäre bspw. wenn ein Abfrage Paramter besser "innerhalb eines Views" aufgehoben ist, weil er dort eine größere Selektivität entfaltet (stärkere Datenreduktion bringt, Folgekosten spart, ..)

Zitat:

Zitat von Medium (Beitrag 1265065)

Jetzt machst du mich aber spontan unglücklich,
..
Bei Views wüsste ich jetzt nicht so genau, wie ich die Anforderung erfüllen sollte, die in dem längeren Kommentar beschrieben ist. Und Views werden doch auch dynamisch ausgeführt oder? Die Abfrage auf die originalen "feinen" Daten würde damit ja trotzdem nötig werden. Zwar dann verdichtet über's Netzwerk gehen, aber der Server hätte dennoch die volle Arbeit zu tragen. Bin da skeptisch.

Ein Materialized View, der für kumulierte Daten verwendet werden könnte ist m.E. auch nicht unbedingt effizient. Kommt drauf an, wie das Refresh arbeitet. In Deinem Fall ist klar, es müssen immer nur Daten nachgetragen werden, nicht eine ganzer Mat.View refreshed werden.
Das kann man auch gezielt je Tag oder so manuell in eine eigene Tabelle kippen. Falls dort Indizes definiert sind, dann eben die Indizes disablen und nachher wieder aktualisieren, ist etwas schneller.

[Namenloser]

Zitat:

Zitat von Dejan Vu (Beitrag 1265095)

Meinst Du denn im Ernst, Google, Amazon & Co verwenden rollierenden Text-Dateien?

Die verwenden aber auch nicht MySQL...

Zitat:

Zitat von Dejan Vu (Beitrag 1265095)

Aber -blöd- nun wollten wir doch die Werte der letzten drei Monate jeweils zwischen 8 und 10 Uhr, immer Dienstags, weil der Kunde meint, wenn der Bäcker die Brötchen bringt (immer Dienstags zwischen 8-10 Uhr), spinnen die Messpunkte.

Bedenke aber, dass dir der MySQL-Index dort keine Vorteile bringt. Die Datensätze sind dann zwar schön nach Timestamp sortiert, aber was bringt dir das, wenn du von jedem Tag die Datensätze zwischen 8 und 10 Uhr brauchst. Läuft dann eh auf einen Full/Partial Table Scan hinaus. Kann dadurch schon sein, dass bestimmte Abfragen mit der Zeit langsamer werden.

Und eigentlich sind alle Abfragen, die mir einfallen, derart, dass sie vom Index nicht profitieren. Auch wenn man z.B. den Durchschnitts-/Max-/Minwert in einem Zeitabschnitt bestimmen will. Das RDBMS findet über den Index zwar recht schnell den ersten Datensatz im Zeitabschnitt, aber muss dann doch alle Datensätze in diesem Abschnitt durchscannen, was den Großteil der Zeit ausmachen wird.

Und durch den Index auf der Zeitspalte (den man natürlich trotzdem braucht) wird natürlich auch das Einfügen mit der Zeit langsamer, zwar „nur“ logarithmisch zur Anzahl der Datensätze, aber bei sekündlichem Logging über Jahre hinweg ist das vielleicht auch nicht zu unterschätzen.

Ich finde du übertreibst auch was den Aufwand von Textdateien angeht. Das ist doch wirklich die simpleste Form, Daten zu speichern und zu lesen überhaupt. Ich finde auch nicht, dass man damit das Rad neu erfindet, ganz im Gegenteil.

[Dejan Vu]

Zitat:

Zitat von jobo (Beitrag 1265102)

Ich würde es mit getrennten Indizes machen. Das ist flexibler.

Erklär mal bitte. Ist der kombinierte Index über den Zeitraum und Messstationen nicht besser, als nur über den Zeitraum? Den Index über die ValueID wird man imho nie benutzen, oder irre ich mich?

Bei SQL-Server kann man auch einzelne Felder in den Index mit aufnehmen, sozusagen Huckepack, dann spart man sich den Zugriff auf den Datensatz komplett. Geht das hier auch? Ok, der Index ist dann so groß wie die Daten, aber WTF.

Zitat:

Zitat von Namenloser (Beitrag 1265103)

Die verwenden aber auch nicht MySQL...

Bitte den Trollfaktor nicht noch weiter erhöhen. ;-)

Zitat:

Bedenke aber, dass dir der MySQL-Index dort keine Vorteile bringt. Die Datensätze sind dann zwar schön nach Timestamp sortiert, aber was bringt dir das, wenn du von jedem Tag die Datensätze zwischen 8 und 10 Uhr brauchst. Läuft dann eh auf einen Full/Partial Table Scan hinaus. Kann dadurch schon sein, dass bestimmte Abfragen mit der Zeit langsamer werden.

Bitte lies meinen vorherigen Post noch. Dessenungeachtet bringt der Index sehr wohl etwas. Denn ich will ja nicht (hab ich das nicht geschrieben) vom gesamten Betrachtungszeitraum (dann hättest Du Recht), sondern von einer Zeitspanne und innerhalb der dann mit weiteren Kriterien. Und wenn nicht, kommt mein Vorschlag zum Tragen, Datum und Uhrzeit zu trennen.

Man macht meistens von einem relativ kleinen Zeitraum eine Auswertung und da bringt der Index schon eine ganze Menge. Weiterhin gibt es noch andere Index-Arten, die eine Aggregierung drastisch beschleunigen, weil ja nicht der Record einzeln, sondern gleich der ganze Index geladen wird: So wird ein kluger Optimizer kombinierten Index vDate+ValueID+Messwert verwenden, um die Messwerte zu aggregieren.

Zitat:

Und durch den Index auf der Zeitspalte (den man natürlich trotzdem braucht) wird natürlich auch das Einfügen mit der Zeit langsamer, zwar „nur“ logarithmisch zur Anzahl der Datensätze, aber bei sekündlichem Logging über Jahre hinweg ist das vielleicht auch nicht zu unterschätzen.

Bei einem Btree vielleicht, aber die Log-Basis ist ca. 2000, sodaß das echt ne Weile braucht.

Zitat:

Ich finde du übertreibst auch was den Aufwand von Textdateien angeht. Das ist doch wirklich die simpleste Form, Daten zu speichern und zu lesen überhaupt. Ich finde auch nicht, dass man damit das Rad neu erfindet, ganz im Gegenteil.

War ein wenig übertrieben, aber ich muss Code schreiben, um die Dateien zu erstellen und zu laden, zum Auswerten auch. Kommt eine Spalte hinzu, muss ich das Programm ändern, an vielen Stellen, Ändere ich die Aggregierung, auch. Ich muss also laufend an der Software rumfummeln. Bei einem RDBMS brauch ich das alles nicht. Die Query anpassen, die Tabellenstruktur vielleicht: 1000x schneller, sicherer etc.
Zudem ist diese Text-Lösung weder skalierbar noch allgemeingültig. Das Prinzip vielleicht, aber nicht der Code.

Und auch in Messdaten werde ich mal mit SQL herumstochern wollen. Mit Textdateien lege ich mir da die Karten.

[DSP]

Ach Du argumentierst wie n Programmierer aus Indien, der nichts von dem Business versteht, daher stife ich dich jetzt auch mal so ein, als jemanden dem man alles in jeden Schritt erklären muss. Dazu habe ich keine Lust und zweitens hängst vom spezifischen Kunden B, und da ist Medium gefordert mit ihm zusammen zu sitzen und erst mal ein requirements Engeniering durchzuführen. Damit erledigen sich die meisten Punkte, natürlich, wenn der Kunde bereit ist, die nächsten Jahre für diese minifunktionalität mit äußerst beschränkten Nutzen n paar Millionen, mit steigender tendenz, loszumachen, dann ist das auch in Ordnung, nur ich bezweifle dies. Aber wenn, dann sollt er HANA zulegen und jährlich n paar Gig draufsatteln, sonst wird das nix mehr ;)

Wusste nicht, dass hier mittlerweile Systemanalyse, DB Design und Best Practice, zwischenzeitlich verpönt sind ...

... Aber ist mir auch egal ...