Suche Datenbank "Paten-Onkel"

Raeven

Raeven

Aktiver Benutzer
Beiträge
29
Moin in die Runde,

eigentlich suche ich schon seid Ewigkeiten eine vernünftige Datenbanklösung für mich, weil ich immer wieder über Probleme stolper, die prädestiniert für eine Datenbank sind.

Nu wärs mal wieder so weit, wegen des Auswertung eines Projektes :-/

Könnte mich da jemand dann und wann etwas an die Hand nehmen un mir helfen?

Verfügbar (bisher) wäre hier:
Ubuntu 14.04, PostgreSQL/-GIS, LibreOffice, MySQL,...

Gruss
Chris
 
Werbung:
Projekt-Hintergrund:
Über 6 Wochen hinweg haben unterschiedlichste Personen bei unterschiedlicher Aufendhaltsdauer in einer simulierten / praktizierten Vergangenheit gelebt, wobei unterschiedlichste Experimente durchgeführt würden.
Eines der ersten aus zu wertenden betrifft die Ernährung.

Datenbestand der im ersten Schritt erfasst werden soll:
- Personen: Wer war wann da
- Personen: Wann waren die Personen da (es gibt auch mehrfaches von-bis)
- Lebensmittel: Welche wurden der Gruppe geliefert (Händler, Gut, Nährwerte)
- Lebensmittel: Nährwert Tabelle + Preis der Einzelkomponenten je Lieferant (mit von-bis gültig)
 
Zuerst einmal zu deinem ersten Post: Ubuntu ist keine DB, PostGIS ist eine PostgreSQL-Erweiterung für Geo-Anwendungen.

Dann: prinzipiell ist sowas nicht eben schnell aus der Handgeschüttelt, die DB ist auch 'nur' das Speicher-Backend. Da brauchst in jedem Fall auch noch eine Oberfläche zum bedienen.

Ich würde aber persönlich zu PostgreSQL raten, z.B. deine Preise mit von-bis gültig ließen sich da z.B. sehr elegant mit DATERANGE abbilden.
 
akretschmer schrieb:
deine Preise mit von-bis gültig ließen sich da z.B. sehr elegant mit DATERANGE abbilden.
Zum Vergrößern anklicken....
Weil zwei Spalten "datum_von" und "datum_bis" auch so unelegant sind :)

akretschmer schrieb:
PostgreSQL
Zum Vergrößern anklicken....
Tendenziell würde ich aber auch dazu raten... Kenne keine andere freie DB, die einen so großen Funktionsumfang abdeckt.

Ohne jetzt wieder einen Glaubenskrieg anstoßen zu wollen, wäre das einzig... ich nenne es mal "funktionsreichere" DBS... wahrscheinlich Oracle... Das kostet aber :)
Dazu kommt noch, das du die Funktionen die Postgres nichtmehr unterstützt, mit ziemlicher Sicherheit nicht brauchen.
 
Distrilec schrieb:
Weil zwei Spalten "datum_von" und "datum_bis" auch so unelegant sind
Zum Vergrößern anklicken....

Nicht nur. Ein Constraint, der verhindert, daß für einen Artikel und einen Zeitpunkt unterschiedliche Preise verhindert ist doch auch was nettes, oder? Das bekommst mit 2 Spalten nicht mehr elegant hin. Und Suche, in welchen Zeitraum ein Datum liegt, geht IMHO so auch einfacher, zumal passende Indexe dafür existieren.
 
Also da waren ja jetzt schon zahlreiche interessante Tips dabei, obgleich mi das mit den CONSTRAINTS anstelle zwei Datums-Spalten noch nicht klar ist. Denn gemäß dem, was ich las, werden diese doch direkt in der Tabellen Definition fest gelegt, oder ?

Und wie stelle ich es "sinnvoll" an, wenn Teilnehmer aus der Gruppe mehrfach über einen Zeitraum da waren?
ich mein, ok, ich könnte einen 1st - 3rd stay in die Tabelle nehmen, aber ich will ja auch das System sinnvoll verstehen & nutzen.

Alternativ, wenn ich eine Datums-Tabelle über das Projekt hinweg habe, das wären ja nur 42 Zeilen, gäbe es da die möglichkeit in einem Feld (was für ein Typ?) die jeweiligen Teilnehmer des Tages zu listen? Also zb als Value "1,4,6,10,11,13"
Oder muss ich dann wirklich den Weg gehen und für jeden Teilnehmer für jeden Tag, den er Teil nahm, in einer "Anwesendheits-Tabelle" einen Eintrag machen ?

Gruß
Chris
 
Wenn ich das richtig verstehe....

Wäre es dann die kürzeste/knappeste Alternative für mich, wenn ich "Aufenthalte" in einer Tabelle festhalte?
Damit müsste ich doch die Zahl der Einträge maximal reduzieren dürfen.
 
Also ganz so leicht ist das hinein-fuchsen in (postgre)SQL ja nicht.... :-/
Fürs erste kommt mir recht gelegen, dass man sowohl die Struktur, wie
auch die Daten super per Script abarbeiten kann. Da lassen sich Fehler
gut ausbügeln (weg und neu!).

Nun meine Frage im Hinblick auf intermittierende Aufendhalte und Nähr-
werte der Verpflegung....

Wie legt man sowas wie "virtuelle Tabellen" an ?
Mir würde es darum gehen einfach unnötig viele Abfragen zu vermeiden,
denn ich würde auch gern die "benötigten" Abfragen vom Prompt aus oder
per Script machen.
 
Was meinst Du mit "virtuelle Tabelle"? Vielleicht einen VIEW? Damit kann man in der Tat komplexe Abfragen quasi vordefiniert in der DB ablegen. Bei einem Zugriff a la "select * from view" wird dann transparent die eigentliche, komplexere Abfrage ausgeführt.

In dieser Form ist der View lediglich ein Platzhalter für die komplexe Abfrage, mittels materialized Views kannst Du aber auch das Resultat lang laufender Abfragen quasi cachen.
 
Könntest Du mir mal ein einfaches Praxis-Beispiel geben, wenn ich zB
(für meine Untersuchung begleitend) das Wetter mal heran ziehe, wo ich
in anderen Tabellen zB Regen- und Temperatur-Meßwerte habe.
Regenwerte liegen nur bei Niederschlag vor, dann aber oft mehrfach pro
Tag. Ein VIEW scheint mir gemäß Schilderung perfekt eine Quasi-Tabelle
erzeugen zu können, in welcher ich die kumulierten Tageswerte abfragen
kann.
 
Läuft dies quasi hinaus auf...

CREATE VIEW wth_rainsum AS
SELECT date, sum(rainfall) FROM wth_rain GROUP BY date;

...und wie frage ich dort Werte ab? Einfach als wärs ne Tabelle ?
Einfach als "SELECT * from wth_rainsum"
 
Werbung:
Zurück
Oben