mikrocontroller.net

Forum: PC Hard- und Software Programm für große Datenbanken


Autor: Pocahontas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich arbeite an einem Projekt, bei dem über einen längeren Zeitraum Daten 
aufegzeichnet werden sollen.
Jeder Datensatz besteht aus Datum und Uhrzeit sowie verschiedenen 
Sensorendaten- Der einzelne Datensatz ist etwa 300 byte groß. 
Aufgezeichnet wird sekündlich.
Das heißt im Jahr fällt einen Datenmenge von über 9GB an.

Welche Software kann solche großen Datenmengen bzw so viele Datensätze 
verarbeiten? Ich möchhte die Daten anschließend nach verschiedenen 
Kriterien sortieren können, Datensätze filtern bzw. succhen, Statistiken 
und Diagramme erstellen

Autor: karadur (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
SQL-Datenbanken. z.B. Postgres.

Autor: René H. (Firma: Herr) (hb9frh)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Oracle.

Grüsse,
René

Autor: HyperMario (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
SQlite kann bis 140 TB, ist open source, weit verbreitet und sehr 
ausgereift.

Autor: Jörg B. (jbernau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So lange Entitäten keine Rolle Spiele XBase, BerkleyDB ...

Autor: Gurgl (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
MariaDB !

Autor: ozo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
InfluxDb ist auf Zeitreihen optimiert und eventuell einen Blick wert.

Autor: rrdtools (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn die Auswertungen schon bekannt sind: 
https://oss.oetiker.ch/rrdtool/ wurde genau für diese Aufgabe 
konzipiert.

Wenn du erst mal Daten sammeln willst, und später festlegst, welche 
Auswertungen du brauchst, ist eine Relationale Datenbank besser.

Autor: c-hater (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Pocahontas schrieb:

> Ich arbeite an einem Projekt, bei dem über einen längeren Zeitraum Daten
> aufegzeichnet werden sollen.
> Jeder Datensatz besteht aus Datum und Uhrzeit sowie verschiedenen
> Sensorendaten- Der einzelne Datensatz ist etwa 300 byte groß.
> Aufgezeichnet wird sekündlich.
> Das heißt im Jahr fällt einen Datenmenge von über 9GB an.
>
> Welche Software kann solche großen Datenmengen bzw so viele Datensätze
> verarbeiten?

Jede ernstzunehmende relationale Datenbank kann das.

> Ich möchhte die Daten anschließend nach verschiedenen
> Kriterien sortieren können, Datensätze filtern bzw. succhen

Das alles ist Job einer solchen Datenbank. Das können die richtig gut.

> Statistiken
> und Diagramme erstellen

Das allerdings nicht. Das ist Sache der Anwendung. Zur Not: Excel. Das 
kann auf jede gängige relationale DB ohne großen Sackstand zugreifen und 
bietet dann Unmassen Möglichkeiten für eine interaktive Auswertung und 
Repräsentation der Daten. Du muss nur ein bissel Code schreiben, um die 
DB-Aufgaben Filtern und Sortieren auch tatsächlich an die DB zu 
delegieren.

Autor: Hans W. (rummses) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier im Forum hat einer ein Programm geschrieben, mit dem große 
CSV-Dateien visualisiert werden können. Ich sehe mir damit in Kurvenform 
die Dateien an, die mein Datenlogger von der Lüftungsanlage aufzeichnet.
Beitrag "Re: Visualisierung von geloggten Daten"
Ist zwar nur ein Viewer, aber vielleicht trotzdem nützlich für deine 
Aufgabe.

Autor: Name H. (hacky)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Wenn die Eintraege gleich gross sind macht eine Datenbank sowieso keinen 
Sinn, dann nimmt man besser ein flaches typisiertes File. Oder mehrere 
davon, zB jeden Tag ein neues.

Autor: rh-doc (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der TO erwartet jährlich ca. 9 GByte Daten mit 300 Byte langen Zeilen.

Das werden 30 Millionen Datensätze.
Ich habe testweise eine 9 Gybyte große csv-Tabelle mit einer knappen 
Milliarde Zellen generiert.
Genau 30 Millionen Zeilen x 33 Spalten = 990.000.000 Zellen.
Spalte 1 enthält einen UNIX Zeitstempel, die Spalten 2 - 32 enthalten 
8-stellige Zufallswerte.

Beim Versuch, diese CSV-Tabell in Excel 2017 unter Windows 10 zu laden 
meldete das System nach etwa 30 Sekunden:
"Die Datei enthält mehr als 1.048.576 Zeilen oder 16.384 Spalten."

Also ist Excel für die geforderte Aufgabenstellung ungeeignet.

Dann habe ich die CSV Daten unter LINUX in eine MySQL Datenbank 
importiert.
Dort hatte ich Spalte 1 als Primärschlüssel definiert. Als 
Storage-Engine wählte ich MyISAM.

Der Import klappte problemlos:

mysql> \. importcsv.sql
Query OK, 30000000 rows affected (5 min 15.50 sec)

Nach etwas mehr als 5 Minuten konnte die Datenbank verwendet werden.
Eine einfach Abfrage wie z.B. Zeige die Datensätze 29999970 - 29999999 
dauert nun 2 Sekunden)
Das Sortieren der gesamten Tabelle nach dem Spalteninhalt einer Zeile 
dauert 12,5 Sekunden.

Zum zuverlässigen Ablegen der Daten und schnellen Auswerten der Inhalte 
aus 30 Millionen Datenzeilen scheint mir die Abfrage einer SQL Datenbank 
eine geeignete Lösung zu sein.

Das Durchsuchen aller Tabellenwerte nach 55497575 dauerte 25 Sekunden.

Die selbe Suche in der CSV-Datei mit Grep dauerte 38 Sekunden.

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie lange dauert nach Tag gruppieren & min/max/avg/count von jedem 
berechnen?
Ungetestet:
select timestamp, count(*) as samples, min(value), max(value), avg(value) from my_table GROUP BY DATE(timestamp) ORDER BY timestamp;

Autor: georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Name H. schrieb:
> macht eine Datenbank sowieso keinen
> Sinn, dann nimmt man besser ein flaches typisiertes File

Ja, aber dann muss man Abfragen, Sortieren usw. selbst programmieren, 
das dürfte die Fähigkeiten des TO erheblich übersteigen.

Georg

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Wie lange dauert nach Tag gruppieren & min/max/avg/count von jedem
> berechnen?

Zu lange. Für Zeitreihen (time series data) gibt es spezialisierte 
Datenbanken, die das besser können. InfluxDB wurde schon genannt. 
RRDtool dito. Google findet mit dem genannten Suchwort noch mehr.

Autor: Udo K. (udok)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
9 GB kostet ein müdes Lächeln, ungefähr
so lange dauert es
die von einer SSD ins RAM zu befördern...

Schreibe es einfach in ein (binary) File, und
mach dann ein memory map ins RAM.

Beitrag #5723507 wurde von einem Moderator gelöscht.
Autor: rh-doc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Wie lange dauert nach Tag gruppieren & min/max/avg/count von jedem
> berechnen?

Ich habe folgende Abfrage für 4 der 32 Spalten erstellt:

SELECT FROM_UNIXTIME(Zeitstempel),
count(*) as Samples,
MIN(Wert1), MAX(Wert1), AVG(Wert1),
MIN(Wert2), MAX(Wert2), AVG(Wert2),
MIN(Wert3), MAX(Wert3), AVG(Wert3),
MIN(Wert4), MAX(Wert4), AVG(Wert4)
FROM testwerte
GROUP BY DATE(FROM_UNIXTIME(Zeitstempel))

Je nach sonstiger Rechnerlast dauerte die Abfrage bei meinen 30 Mio. 
Datensätzen zu verschiedenen Zeiten zwischen 1 Minute und 8 Minuten

Soeben z.B.
Meldung des verwendeten HeidiSQL Clients:
Dauer der Abfrage: 00:01:19.6 (+ 0,094 Sek. Netzwerk)

Ich denke, dass man MySQL oder MariaDB für die Datenmenge verwenden 
kann.

Vermutlich wird eine spezialisierte Datenbank wie InfluxDB, die zur 
Verarbeitung und Auswertung von zeitbasierenden Daten entwickelt wurde, 
eine noch bessere Wahl sein.

Autor: Name H. (hacky)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
>Ich habe folgende Abfrage für 4 der 32 Spalten erstellt:

Die Zeiten sind doch voellig ueberzogen. Bei einem flat File bringt die 
Platte gegen 500MByte pro Sekunde, daher sollten die Zeiten in den 
Sekunden liegen. Aber man kann sich's auch schwer machen.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Name H. schrieb:
> flat File

LOL, man kann sichs auch schwer machen.

SQL-Datenbank ist schon das richtige für den Job (filtern, sortieren, 
gruppieren, etc), alles andere wäre umständlicher aufwendiger Krampf 
hoch 3.

Autor: rh-doc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Name H. schrieb:
> Die Zeiten sind doch voellig ueberzogen. Bei einem flat File bringt die
> Platte gegen 500MByte pro Sekunde, daher sollten die Zeiten in den
> Sekunden liegen. Aber man kann sich's auch schwer machen.


Mag sein, dass die Verwendung einer SQL Datenbank überzogen ist.

Ich benötigte etwa 7 Minuten um die nach Tagen sortiereten Werte in 
einer scrollbaren Tabelle zu betrachten.

Davon 5 Minuten für den csv Import in die Datenbank. Etwa 20 Sekunden 
zur Formulierung und Eingabe der Abfrage und 1,5 Minuten Warten auf das 
Ergebnis.

Meine Festplatten können derzeit noch nicht von selst Ergebisse 
ausgeben.
Ich muss, wenn ich die Platte bzw. Files direkt nutzen will, ein 
Programm für diese Aufgabe schreiben.

SQL Abfragen formulieren kann ich besser, als Programme schreiben.

Ich befürchte, die wenigsten von uns werden es innerhalb von 8 Minuten 
schaffen eine funktionierende Routine für die Aufgabe zu schreiben.

Autor: Schrauberking (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rh-doc schrieb:
> Davon 5 Minuten für den csv Import in die Datenbank. Etwa 20 Sekunden
> zur Formulierung und Eingabe der Abfrage und 1,5 Minuten Warten auf das
> Ergebnis.

Jetzt probier InfluxDB dagegen.

Da geht das ohne fühlbare Verzögerung "in Echtzeit".
Im grafana die Zeiteinstellung angeklickt, Maus losgelassen, blinzel, 
graph ist aktualisiert. Sicher weniger als ½ Sekunde.

Und davon vergeht noch die meiste Zeit im Webbrowser, nicht in der 
Datenbank.

Autor: rh-doc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schrauberking schrieb:
> Jetzt probier InfluxDB dagegen.

Hört sich gut an,
das werde ich bestimmt mal ausprobieren.

Autor: c-hater (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
rh-doc schrieb:

> Mag sein, dass die Verwendung einer SQL Datenbank überzogen ist.

Das ist doch Schwachsinn.

Es gibt kostenlose, gut getestete SQL-Datenbanken, in die viele 100000 
(wenn nicht Millionen) Stunden Entwicklerzeit geflossen ist, mit dem 
einzigen Ziel, sie so zuverlässig und effizient wie möglich zu machen.

Nur Vollidoten kämen zu dem Entschluß, diese nicht zu benutzen.

Natürlich kann man für eine sehr konkrete Aufgabe immer auch einen 
effizienteren Code schreiben als für den allgemeinen Fall, den 
generische SQL-DBs abbilden wollen. Aber kann man ihn auch so gut und 
umfassend testen, wie es bei diesen geschieht? Und was passiert, wenn 
sich die Anforderungen ändern? Dann ist man schnell in der Situation, 
dass eine kompletter Neubau erforderlich wird.

Wie gesagt: Nur Vollidoten kämen zu dem Entschluß, diese nicht zu 
benutzen...

Autor: AbcAbc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei 9GB im Jahr kann man sogar ein Textfile verwenden.
Nicht dass eine Datenbank dafür nicht doch eine bessere Lösung wäre, 
aber 9GB im Jahr ist echt nicht viel.

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Das Werkzeug sollte sich am Problem orientieren. Was aber voraussetzt, 
dass man das Problem kennt. Bisher ist Pocahontas allerdings nicht mit 
sonderlich viel Information zum Problem rüber gekommen, so dass die 
Antworten manches von einem Rorschach-Test haben und jeder das 
empfiehlt, was er kennt.

So ist beispielsweise bisher völlig offen, ob die Daten in vollem Detail 
auf ewig vorliegen müssen und beliebige Abfragen auf eine beliebige 
Auswahl davon möglich sein müssen, oder ob eine Zwischenkondensation der 
Daten oder der Abfragen erfolgen kann. Eine spezielle Form davon wurde 
kurz über die rrdtools erwähnt.

Wie der Name schon sagt, sind relationale Datenbanken auf Relationen 
spezialisiert. Wo keine Relationen sind, sondern einfach bloss ein 
grosser Haufen einfachst strukturierter Daten, können sie ebenfalls 
geeignet sein, müssen aber nicht die bestmögliche Lösung darstellen.

So hängt es auch ein wenig davon ab, was für Abfragen man macht. Sind 
die recht simpel über SQL abdeckbar, oder wird da ohnehin jedesmal der 
Datenbestand per Programm abgegrast? Für letzteres ist neben schlichten 
Files auch sowas wie die Berkeley DB einsetzbar.

: Bearbeitet durch User
Autor: M.A. S. (mse2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
глупний форентроль schrieb im Beitrag #5723507:
> Wenn der Poster kein tyisiertes file zugreifen und die Werte sortieren
> kann, soll er's eh sein lassen und vielleicht was anderes machen.
> Foerster, Kindergaertner, Jurist Banker, ..

Das ist eine richtig gute Idee: Jeder, der irgend etwas nicht kann, soll 
es einfach lassen.
Wenn sich alle Menschen daran halten, leben wir bald wieder alle in 
Höhlen und das globale Ökosystem kann sich erholen.

Autor: c-hater (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
A. K. schrieb:

> Wie der Name schon sagt, sind relationale Datenbanken auf Relationen
> spezialisiert.

Hähä. Du hast offensichtlich das Konzept und dessen Implikationen völlig 
missverstanden.

Natürlich kann ein RDBM auch mit einer einzelnen verschissenen flachen 
Tabelle optimal umgehen. Das ist nämlich einfach nur der einfachste 
Spezialfall des allgemeinen Falls.

Die DB stellt auch hier alles zur Verfügung, was nötig ist, um auch mit 
dieser einen verschissenen Tabelle für jede damit auszuführende 
Operation die bestmögliche Lösung zu finden. Und: man muss den Kram 
nicht selber implementieren. Die DB stellt hochoptimierte 
Implementierungen bereits zu Verfügung, man muss sie einfach nur nutzen. 
Typischer Fall für den trivialen Scheiss, der hier als quasi 
"Gegenanzeige" zu lesen war: Da richtet man einfach einen B-Tree-Index 
auf den Spaltenteil ein und die Abfrage wird gleich um Größenordnungen 
schneller ausgeführt.

Man muss halt einfach nur wissen, wie man das konkrete Abfrageproblem am 
effizientesten lösen könnte (das muss man sowieso), braucht das dann 
aber nicht selbst implementieren, sondern delegiert es einfach mittels 
einer einzigen Zeile Quelltext an die SQL-DB, denn die kann das schon...

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Hähä. Du hast offensichtlich das Konzept und dessen Implikationen völlig
> missverstanden.

Und du hast meinen Betrag nicht verstanden. Unstrittig ist, dass man 
auch mit Kanonen auf Spatzen schiessen kann. Weshalb ich hauptsächlich 
auf die offene Frage hinaus wollte, oder das eher Spatz oder eher 
Elefant ist, auf das man hier schiesst. Wenn beispielsweise mit rrdtools 
sowohl Speicherung als auch grafische Darstellung fix und fertig 
abgedeckt werden kann, wozu dann SQL?

Weshalb ich es für sinnvoll halte, erst das Problem zu analysieren, und 
dann das Werkzeug auszusuchen. Manche machen das umgekehrt.

: Bearbeitet durch User
Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schrauberking schrieb:
> rh-doc schrieb:
>> Davon 5 Minuten für den csv Import in die Datenbank. Etwa 20 Sekunden
>> zur Formulierung und Eingabe der Abfrage und 1,5 Minuten Warten auf das
>> Ergebnis.
>
> Jetzt probier InfluxDB dagegen.

Das klingt irgendwie nicht so, als ob in der Tabelle der richtige Index 
angelegt wäre.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:

> Das klingt irgendwie nicht so, als ob in der Tabelle der richtige Index
> angelegt wäre.

Genau. Hier hat jemand nicht die gigantischen Optimierungsmöglichkeiten 
verstanden, die ihm absolut kostenlos zu Verfügung stehen, die er 
einfach nur für seine konkrete Anwendung nutzbar machen muss.

Wahnsinn: eine einzige Zeile Befehl an die DB und alle zukünftigen 
(gleichgestrickten) Abfragen laufen um viele Größenordnungen schneller.

Wer diese Vorteile nicht begreift, ist echt arm dran...

Autor: глупний форентроль (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Nun. Wenn man in einer Datenbank Minimum und Maximum sucht, muss man 
alle Records anschauen. Da bringt ein Index gar nichts. Da ist ein 
flaches File am schellsten

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
глупний форентроль schrieb:
> Nun. Wenn man in einer Datenbank Minimum und Maximum sucht, muss man
> alle Records anschauen. Da bringt ein Index gar nichts. Da ist ein
> flaches File am schellsten

Hä? Wenn ich eine sortierte Liste aller Werte habe, kann ich das zum 
Beispiel in konstanter Zeit und muss genau 2 Einträge anschauen.

: Bearbeitet durch User
Autor: rh-doc (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Wahnsinn: eine einzige Zeile Befehl an die DB und alle zukünftigen
> (gleichgestrickten) Abfragen laufen um viele Größenordnungen schneller.

Welche Zeile muß ich denn Deiner geschätzten Erfahrung nach eingeben, 
damit die einzelnen Spalten noch besser als B-Tree indiziert werden?

c-hater schrieb:
> Hier hat jemand nicht die gigantischen Optimierungsmöglichkeiten
> verstanden

Kennst Du mich?

Autor: Peter M. (r2d3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo глупний форентроль,

глупний форентроль schrieb:
> Nun. Wenn man in einer Datenbank Minimum und Maximum sucht, muss man
> alle Records anschauen. Da bringt ein Index gar nichts. Da ist ein
> flaches File am schellsten

Die Suche in einem flachen File kostet Dich O(n).
Die Suche in einer Datenbank mit Indexierung an der richtigen Stelle 
liegt eher in der Größe O(log(n)).

Ich würde auf diesen Vorteil nicht verzichten.

Beispiel:

Flat-File mit 9GB, 4 Byte/Wert, macht dan 2,25E9 Werte in der Datei.

Im Schnitt bedeutet das 1,125E9 Werte anfassen, schlimmstenfalls 2,25E9 
Werte.

Ein einfach Binärbaum, der natürlich Speicherplatz kostet, braucht 
log2(2,25E9) = ~31 Zugriffe.

Überzeugt? :)

: Bearbeitet durch User
Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
c-hater schrieb:
> Es gibt kostenlose, gut getestete SQL-Datenbanken, in die viele 100000
> (wenn nicht Millionen) Stunden Entwicklerzeit geflossen ist, mit dem
> einzigen Ziel, sie so zuverlässig und effizient wie möglich zu machen.

Das ist richtig. Trotzdem gibt es für spezielle Daten auch wieder 
spezialisierte Datenbanken, die es schneller und besser können. 
Zeitreihen-Daten sind ein klassisches Beispiel. DNA wäre ein weiteres.

Und glaub mir, ich weiß wovon ich rede. SQL Datenbanken sind mein 
tägliches Brot.

> Nur Vollidoten kämen zu dem Entschluß, diese nicht zu benutzen.

Nur Vollidioten verwenden für jedes Problem den Hammer. Fortgeschrittene 
haben einen besser ausgestatteten Werkzeugkasten und verwenden das für 
die jeweilige Aufgabe am besten geeignete Werkzeug.

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rh-doc schrieb:
> Welche Zeile muß ich denn Deiner geschätzten Erfahrung nach eingeben,
> damit die einzelnen Spalten noch besser als B-Tree indiziert werden?

In Deinem Fall wären es wohl zwei Zeilen:
DROP INDEX 'Zeitstempel';
CREATE INDEX `Zeitstempel` ON `testwerte` (DATE(FROM_UNIXTIME(`Zeitstempel`)));

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
>> Mag sein, dass die Verwendung einer SQL Datenbank überzogen ist.
>
> Das ist doch Schwachsinn.
>
> Es gibt kostenlose, gut getestete SQL-Datenbanken, in die viele 100000
> (wenn nicht Millionen) Stunden Entwicklerzeit geflossen ist, mit dem
> einzigen Ziel, sie so zuverlässig und effizient wie möglich zu machen.
>
> Nur Vollidoten kämen zu dem Entschluß, diese nicht zu benutzen.

Aber die sind in C geschrieben, wie verträgt sich das mit Deinen 
Überzeugungen?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
A. K. schrieb:
> Wie der Name schon sagt, sind relationale Datenbanken auf Relationen
> spezialisiert.

Ja, die sind auf Tabellen spezialisiert. Daher der Name.

> Wo keine Relationen sind, sondern einfach bloss ein
> grosser Haufen einfachst strukturierter Daten

Klingt für mich aber durchaus wie eine Tabelle. Warum soll das keine 
Tabelle sein?

Ein anderes Wort für Tabelle ist übrigens Relation. Es gibt Datenbanken 
die Daten in Tabellen verwalten, diese bezeichnet man als "Relationale 
Datenbanken", ein gleichwertiger Begriff dafür wäre "Tabellenbasierte 
Datenbanken". Scheint mir eigentlich der perfekte Ort zu sein um eine 
große Tabelle fester Struktur aufzubewahren und damit zu arbeiten.

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:

> Aber die sind in C geschrieben, wie verträgt sich das mit Deinen
> Überzeugungen?

Sehr gut. Denn natürlich: wirkliche kritische Teile gibt's dann doch 
wieder in der ultimativen Sprache der jeweiligen Zielhardware, also in 
Assembler. Weil's halt garnicht anders geht.

Du hast vermutlich einfach nur nicht richtig verstanden, was meine 
Überzeugungen und Intententionen sind, obwohl ich das schon mehrfach 
relativ ausführlich dargestellt habe...

Autor: db6 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurde schon DB2 für win/linux empfohlen?
Leider TEUER, sonst sehr gut.

Autor: Clemens L. (c_l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
db6 schrieb:
> Wurde schon DB2 für win/linux empfohlen?

Gibt es nicht mehr. Es heißt jetzt nicht "DB2", sondern "Db2".

> Leider TEUER

Db2 Developer-C ist bis 100 GB kostenlos. (Oracle XE: 12 GB; SQL Server 
Express: 10 GB)

Autor: глупний форентроль (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Überzeugt?

Eine Suche in einem Binaerbaum bringt ja erst etwas wenn ich diesen 
Binaerbaum habe ... und er muss sortiert sein.

Ich bin davon ausgegangen, man hat die Daten in zetlicher Abfolge, sucht 
Min & Max und weg damit. Dann muss ich auch nicht sortieren.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Über die Art der Abfragen im Startbeitrag ist exakt nichts bekannt. Die 
min/max-Abfrage war ein Beispiel einer anderen Person. Deshalb ja mein 
Hinweis auf die Sinnlosigkeit bekannter Lösungen für völlig unbekannte 
Probleme.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.