Calendar table sql script Firebird 3

[jobo]

Den Monatsnamen, KW und viele andere bekommt man schon durch die Formatierungsmöglichkeiten des Datums geschenkt.

Feiertage sind regional Unterschiedlich und gehören wohl eher nicht in diese Liste eindeutige Datums. Sie entsprechen im Wesen echten (individuellen) Kalenderdaten.

Relevant ist im Unternehmen wahrscheinlich eher eine Liste von Arbeitstagen. Also alle Tage minus Wochenende, minus lokale Feiertage, minus Betriebsurlaub.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1448615)

Relevant ist im Unternehmen wahrscheinlich eher eine Liste von Arbeitstagen. Also alle Tage minus Wochenende, minus lokale Feiertage, minus Betriebsurlaub.

Kommt wohl auf das Unternehmen an. Die DB z.B. arbeitet immer. Da wäre esgut zu wissen wie die konkreten Anforderungen sind.

Gruß
K-H

[jobo]

Ja, aber solche Dimensionen liegen hier wohl nicht vor.

Es ging mir darum, die Idee von Arbeitstagen vorzustellen. Für sehr viel Unternehmen mit einem regionalen Standort dürfte das schon passen. Wer keine Betriebsferien hat, macht es dem Programmierer ja eher leichter.

Und die genauen Anforderungen sind vielleicht streng geheim, darum ging ja meine erste Frage und auch weitere Anmerkungen.

[MyRealName]

Wieso soll es denn mit Daten befüllt werden ?
Daten fallen doch nur an, wenn Du einem Mitarbeiter eine Schicht zuweist, ansonsten gibt es kein Datum.
Außerdem muss ja für jedes Datum wohl eher mehrere Register da sein, da ja mehrere Leute auch Arbeiten, eventuell auch Schichten, eventuell auch 2x am Tag, zum Bsp. eine Frühschicht und dann gleich nachts nochmal etc.

Von daher denke ich, Du brauchst wenigstens Start-/EndZeit (mit Datum) + Mitarbeiter-Id

Alles andere in Deiner Tabelle brauchst eigentlich nicht, da man das ja in Delphi einfach mit der DateUtils.pas rausfinden kann.
Das Grid füllst dann einfach generisch über StartOfTheMonth(Now) bis EndOfTheMonth(Now) und danach trägst Du die Daten aus der Tabelle ein.

[jobo]

Zitat:

Zitat von MyRealName (Beitrag 1448677)

Wieso soll es denn mit Daten befüllt werden ?
Daten fallen doch nur an, wenn Du einem Mitarbeiter eine Schicht zuweist..
Alles andere in Deiner Tabelle brauchst eigentlich nicht, da man das ja in Delphi einfach mit der DateUtils.pas rausfinden kann.

Hier liegt glaube ich irgendwie das Missverständnis.
Die vom TE dargestellte Tabelle ist nichts weiter als ein Basiskalender mit Hilfsattributen. Und an der Stelle kann/könnte man tatsächlich argumentieren, dass eine klassische DB Abfrage mit so einer Tabelle einige Dinge sehr umkompliziert macht. Dateutils im Client bringen da bei einer SQL Abfrage nicht unbedingt so einen Effekt.

Aber der TE scheint damit sowieso nicht so einen Streß zu haben wie die Helfer.

[mkinzler]

Die DateUtils könnten aber bei der Erzeugunfg der Tabelle helfen. Es gibt diverse UDFs, welche ähnliche Funktionen für FireBird liefern (größenteils auch ohne UDF).

[MyRealName]

Zitat:

Zitat von jobo (Beitrag 1448769)

Zitat:

Zitat von MyRealName (Beitrag 1448677)

Wieso soll es denn mit Daten befüllt werden ?
Daten fallen doch nur an, wenn Du einem Mitarbeiter eine Schicht zuweist..
Alles andere in Deiner Tabelle brauchst eigentlich nicht, da man das ja in Delphi einfach mit der DateUtils.pas rausfinden kann.

Hier liegt glaube ich irgendwie das Missverständnis.
Die vom TE dargestellte Tabelle ist nichts weiter als ein Basiskalender mit Hilfsattributen. Und an der Stelle kann/könnte man tatsächlich argumentieren, dass eine klassische DB Abfrage mit so einer Tabelle einige Dinge sehr umkompliziert macht. Dateutils im Client bringen da bei einer SQL Abfrage nicht unbedingt so einen Effekt.

Aber der TE scheint damit sowieso nicht so einen Streß zu haben wie die Helfer.

Naja, ich denke, das war schon richtig verstanden insoweit, dass er einen Kalender haben will und die Schichten zuweisen will.
Warum er sich die Tage aus der DB holen will wäre zu klären, da man diese ja recht schnell für den anzuzeigenden Zeitraum kurz berechnen kann, allemal schneller als die DB zu fragen.

[Frickler]

Zitat:

Zitat von MyRealName (Beitrag 1448774)

Naja, ich denke, das war schon richtig verstanden insoweit, dass er einen Kalender haben will und die Schichten zuweisen will.
Warum er sich die Tage aus der DB holen will wäre zu klären, da man diese ja recht schnell für den anzuzeigenden Zeitraum kurz berechnen kann, allemal schneller als die DB zu fragen.

Ich denke, was er sucht ist eine Hilfstabelle wie in diesem Beitrag beschrieben.

[MyRealName]

Zitat:

Zitat von Frickler (Beitrag 1448780)

Zitat:

Zitat von MyRealName (Beitrag 1448774)

Naja, ich denke, das war schon richtig verstanden insoweit, dass er einen Kalender haben will und die Schichten zuweisen will.
Warum er sich die Tage aus der DB holen will wäre zu klären, da man diese ja recht schnell für den anzuzeigenden Zeitraum kurz berechnen kann, allemal schneller als die DB zu fragen.

Ich denke, was er sucht ist eine Hilfstabelle wie in diesem Beitrag beschrieben.

Ich habe das schon verstanden :)
Nur wie gesagt, das ist halt nicht wirklich notwendig. Aber egal, wenn er es mit Tabelle lösen möchte.. :)

[IBExpert]

ich bin mal ein wenig provokant, aber wenn das von dir vorgestellte create table Modell Grundlage für deine Anwendung sein soll, dann ist nicht nur die feste Zuweisung der ganzen Attribute problematisch. Ich glaub, dein Chef scheint da seltsame Vorstellungen zu haben, mit welchem Aufwand am Ende ein kommerziell sinnvoll nutzbares Schichtplan Modell aufzubauen. Ich schmeiss mal ein paar Stichworte in den Raum, die das beeinflussen und auf die unsere Kunden sehr viel Wert legen:

-Wechselschicht Modell innerhalb der Woche (montag-mittwoch 3 schichten, donnerstag-freitag 2 Schichten, on demand aber auch dann mal mit 3 Schichten)
-Schichtwechselzeiten Standortabhängig (wechsel von früh zu spät am Standort x 15 uhr, sonst 16 uhr)
-Pausenzeiten über Mitternacht den richtigen Tag zuweisen
-Feiertage, regionale Feiertage, Brückentage, mehrtägiger Komplettausfall in Köln wegen Karneval, usw.
-Feiertage und Wochenendtage, an denen trotzdem gearbeitet wird
-Schichtbezogene Zuschläge bei schichtüberschneidende Tätigkeiten
-Schichtwechsel an Tagen mit Sonnerzeit/Winterzeitumstellung

Die grundlegende Kalender Tabelle ist dazu völlig albern einfach:

Code:

CREATE TABLE KALENDER (
    ID          BIGINT NOT NULL,
    DATUM       DATE
);

ALTER TABLE KALENDER ADD CONSTRAINT PK_KALENDER_1 PRIMARY KEY (ID);

CREATE UNIQUE INDEX KALENDER_IDX1 ON KALENDER (DATUM);

Wie du daran festellen wirst,löst das die grundlegende Problematik aber gar nicht, füllen ist extrem einfach
(der id wert kommt via trigger von einem generator)

Code:

create or alter procedure BRP_KALENDER_FUELLEN
as
declare variable DATUM date;
begin
  datum='1.1.2000';
  while (datum<'1.1.2050')
  do
  begin
    update or insert into KALENDER (DATUM)
    values (:DATUM)
    matching (datum);
    datum=datum+1;
  end
end

Wie andere aber schon geschildert haben, kannst du andere Attribute aber nur Standortbezogen ergänzen, wenn in Köln alle besoffen sind, dann ist das in Hamburg noch lange kein Feiertag.
Daher haben die Information auch nicht in der Tagestabelle zu suchen, das diese immer nur einen Tag pro Datensatz darstellt. Mit einer Feiertagstabelle mit fremdschlüssel zu feiertag, standort und datumstabelle wäre dafür der erste schritt schon mal gemacht ...

Selbst information wie die Kalenderwoche ist Standortbezogen, weil die Amis da in bestimmten Jahren anders anfangen zu zählen, und auch scheinbar banaler Kram wie Sommerzeit/Winterzeit ist nicht ohne, siehe Nordkorea, bei denen die Uhrzeit nicht um 60 Minute verschoben ist, sondern um 30 Minuten, auch wenn man sicherlich relativ selten mit Kunden oder Produktionsstandorten in Nordkorea zu tun hat.

Aber nur so als Hinwies: Früher haben Programmierer auch mal geglaubt, das ein 16 Bit Integer für das deutsche Postleitzahlensystem ganz toll geeignet ist. Als dann die 5 stelligen Postleitzahlen kamen, wurde das eng und kurzsichtige haben auf 32 Bit umgeschaltet, um dann leider beim ersten Kunden in UK festzustellen, das dort Postleitzahlen auch Buchstaben und Leerzeichen enthalten können.

Und wer ganz clever war hat dann gleich noch den Ort über die PLZ als Fremdschlüssel in sein Datenmodell integriert, ist damit dann aber auch gleich wieder auf die Schnauze gefallen, wenn der erste Kunde in Irland angelegt werden musste, wo es nämlich gar kein PLZ System gibt. Italienische Softwarehersteller fanden bei der Euroeinführung auch neue Problem, weil man mit der Lira vorher noch nie was mit Nachkommastellen zu tun hatte.

Es gibt sehr viele Aspekte, die man im Datenbankdesign einplanen sollte, später dranfrickeln ist fast immer doof.

Ich will dich nicht verunsichern, aber wenn dein Chef das Thema ernst nimmt und nicht nur für dich als Beschäftigungstherapie, dann sollte er mit dir mal zusammen abstecken, welche Varianten denn in deinem Unternehmen für die Lösung relevant sind. Das dann in einem SQL Script in die Datenbank zu bekommen, sollte dann wirklich nicht problematisch sein, vorher aber eine Idee zu haben, was am Ende erforderlich ist und welche Datensatzkombinationen dann die Anforderungen abdecken, ist wesentlich entscheidener als einfach nur einen unbrauchbaren, aber funktionierenden create table SQL zusammenzuklöppeln, geschweige denn, sich einen SQL von irgendjemand bauen zu lassen, der vielleicht o.a. Attribute verwalten kann, von denen dir aber dir Vorstellung fehlt, was das jeweils soll. Das würde dich frustrieren und das ist das schlimmste, was ein Programmierer in seiner vermutlich jungen Karriere erleben kann. Etwas programmieren ohne das zu verstehen bringt nix.

ich hab nicht genau gezählt, aber in unserer brp software sind mindestens 25 Tabellen betroffen, die über verschiedene Faktoren Schichten, Termine, Maschinenzeiten und Arbeitszeiten sowie Kapazitätsplanung dafür beeinflussen.

Daher versuch noch mal mit deine Chef darüber zu sprechen, was er denn von dir verlangt, schreib dir die Stichworte, die er sagt auf, und wenn du bestimmte Begriffe nicht kennst, dann lass dir erklären, was das bedeutet oder versuche das über quelle wie wikipedia oder sonstwo nachzuvollziehen.