Normalisierung Datum/KW/Timestamp

Status
Für weitere Antworten geschlossen.

Doomenik

Benutzer
Beiträge
7
Guten Tag zusammen,

ich bin neu hier und auch "wieder" neu im Bereich des Datenbankdesigns und habe einige kleine Fragen. Grundsätzlich bin ich für Verbesserungen am Aufbau aber auch offen :D


Mein größtes Problem ist momentan der Umgang mit der Zeit. Derzeitig benutze ich für fehler.zeitpunkt eine Kombination(JahrxKW). Das klappt sehr gut, aber ich habe dadurch sehr oft die selben Daten.

Die Fehler werden bei uns übrigens nur einmal pro Woche gemeldet, wodurch eine genauere Angabe als KW nicht möglich ist.

Jetzt meine Frage, sollte ich es so lassen oder wäre es vlt. sinvoll das ganze in eine extra Tabelle auszulagern und jeder KW + Jahr eine unique id zuzuweisen ?

In anderen Tabellen wie geschaute.meter hatte ich vor die selbe Kombination zu nutzen. In einigen anderen werde ich wohl einen timestamp nutzen müssen. Fällt euch spontan ein wie man anhand eines timestamps/Monats/Jahrs die passenden KWs herausfinden kann ? Idealerweise per Sql.
 

Anhänge

  • database.pdf
    29,4 KB · Aufrufe: 1
Werbung:
Code:
[local]:test=# select extract('week' from current_date);
date_part
-----------
  26
(1 row)

[local]:test=*#

Du könntest das Datum bzw. die Kalenderwoche auch als Datenrange angeben, entweder in 2 Spalten in Datenbanken, die es nicht besser können, oder direkt als DATERANGE in PostgreSQL. Das erspart extra Plausibilitätsprüfungen und ermöglich Dir, weiterhin mit Zeit- und Datumsfunktionen rechnen zu können.
 
Zuletzt bearbeitet von einem Moderator:
Datenrange werde ich direkt probieren, mal schauen was MariaDb hergibt.

Mal gleich eine weitere Frage, ich möchte derzeit den Produktionsablauf speichern. Bei uns erhalten die Produkte je nach Schritt eine leicht veränderte Artikelnummer(letzten 3 Ziffern). Mein erster Gedanke war in der Artikel Tabelle den Zustand einzutragen, leider ist dies nur die halbe Lösung da ich dadurch nicht ermitteln kann welcher der nächste/vorhergehende Artikel ist/war.

Code:
Zustand 1   | Zustand 2      | Zustand 3 | ...
XY-3912-75| XY-3912-T78 | XY-3912-39 | ...

Eine Kreuztabelle mit den Artikelnummern (bzw. dann natürlich den artikel.ids) scheint mir die beste Lösung, da aber viele Artikel, verschiedene Endzustände haben können, hätte ich viele doppelte Einträge.
 
Recht viele, die kann ich hier gar nicht alle aufzählen (bessere Indexe wie funktionale und partielle, GiST, GIN, BRIN, ...), bessere Abfragemöglichkeiten (Common Table Expressions), lateral JOIN, cost-based Optimizer, Tablespaces und costs-per-tablespace und so weiter. Einfacher ist es daher, die Nachteile aufzuzählen, hier die vollständige Liste:



Andreas
 
Gut habe jetzt 2 Tage versucht Postgress zum laufen zu bekommen, keine Chance. Weder in Xampp noch Wampp, ich bekomme immer: could not find driver. Und die Treiber sind laut phpinfo/php.ini aktiviert.
 
Dann suche Dir bitte ein passendes Forum dazu. Und zeige *dort*, was Du genau getan hast und was genau nicht funktioniert. 'Leider kein Erfolg' ist leider keine sinnvolle Problembeschreibung, und 'die ersten 3 Seiten hab ich durch' beschreibt auch nicht wirklich, was Du getan hast.
 
Entschuldige hatte nen schlechten Tag, nach vielen Stunden versuchen ist man etwas ...

Für alle die einmal nicht weiterkommen, wenn ihr einen phplinter installiert habt, ist in der Regel eine lokale Version von PHP gesichert(außerhalb des Webservers) in meinem Fall wurde die PHP.ini dieser Installation geladen obwohl unter phpinfo der korrekte Pfad angegeben wurde.

Dort einfach die extension installieren und es klappt.

Postgress läuft nun und ich bin von den Möglichkeiten überwältigt. Leider wirklich nicht Anfängerfreundlich, und obwohl es sehr bekannt ist, ist keine gute GUI vorhanden. Zumindest keine die phpMyAdmin oder auch Workbench das Wasser reichen könnte. Trotz allem vielen Dank für den Tipp, kann vieles nun effizienter gestalten.

Thread kann geschlossen werden.
 
Werbung:
Als GUI wird oft PGAdmin empfohlen, kommt demnächst in Version 4. Schön, daß es nun geht, ich wünsch Dir Erfolg. Bei Fragen im PG-Teil hier fragen - oder mich direkt, ich gebe auch InHouse-Schulungen und so ;-)

PS.: PostgreSQL ist sehr, sehr mächtig. Schon klar, daß das einem als Anfänger erst einmal sehr komplex und kompliziert erscheint. Ist es aber eigentlich nicht, und wir haben nicht nur eine sehr gute Doku (allerdings ist diese eher als Referenz geeignet, weniger als Anfängerlektüre) und wir haben auch eine super Community mit eigenen Mailinglisten, Foren und so weiter.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben