Calendar table sql script Firebird 3

[Gandimann]

Liebe Freunde,
kann jemand mir mit SQL Script helfen, womit ich eine Tabelle im bestehende Firebird 3 Datenbank erzeugen kann.

In other Words :
gibt es einen SQL-Script für Firebird-3 womit ich eine Tabelle für den Calendar erzeugen kann ?

Thanx in advance :-)

[jobo]

Ich denke, Du müsstest in Deiner Fragestellung noch etwas präziser werden.
Welcher calendar? Z.B, TCalendar, .. ?
Und welcher Calendar auch immer, vermutlich eher eine Tabelle für die darin enthaltenen Termine?

[Gandimann]

Danke Jobo für deine Rückmeldung,

wie im Beschreibung steht "zu eine bestehende Datenbank" hinzufügen. Ich bin gerade dabei ein Dienstplan Programm für mehrere Schichten und Abteilungen zu entwickeln dafür benötige ich eine Tabelle mit tägliche Datumsspalte für mehrere Jahre (Daily-Date). Kommerzielle Komponente wie TMS-Planner darf ich nicht benützen.

Gruß
Gandimann

[hoika]

Hallo,
das geht auch mit einem normalen TStringGrid.

[Gandimann]

Danke Hoika,
richtig..... mit Stringgrid geht es auch aber für die Sonderfunktionen die von mein Chef erwünscht sind,dafür eine solche Tabelle ist leider nötig. Mit Microsoft Server SQL geht es per SQL-Script aber ich benutze leider Firebird 3 und da komme ich ohne Script leider nicht weiter.

[haentschman]

Moin...8-)

Zitat:

Ich denke, Du müsstest in Deiner Fragestellung noch etwas präziser werden.

...ich habe es auch noch nicht verstanden. Was bitteschön hat ein SQL Script (was hällst du dafür?) mit einer Ausgabe (TMS, Stringgrid) zu tun haben? :gruebel:

1. ist leider eine Tabelle nötig, "zu eine bestehende Datenbank" - besteht die Tabelle schon? Mit den Feldern die du benötigst?
2. Geht es nur um die Darstellung?
3. Zeige mal das MSSQL Script womit es funktionieren soll.
4. Sonderfunktionen die von mein Chef erwünscht - Was sind die Sonderfunktionen?

:wink:

[Lemmy]

Zitat:

Zitat von Gandimann (Beitrag 1448417)

Danke Hoika,
Mit Microsoft Server SQL geht es per SQL-Script aber ich benutze leider Firebird 3 und da komme ich ohne Script leider nicht weiter.

Dann zeig das Scrip für M-SQL Server, dann wird vielleicht klar, wo dein Problem ist.

[jobo]

Zitat:

Zitat von Gandimann (Beitrag 1448404)

..
wie im Beschreibung steht "zu eine bestehende Datenbank" hinzufügen. ..

Also "präziser" meint nicht wiederholen.

Könntest Du vielleicht einfach mal den Namen der Komponente hinschreiben?
Oder vielleicht sogar die Attribute dieser Calendar Klasse, die Dir Probleme bereiten?

Und das Stück Code, was Du in Verbindung mit MS SQL Server und dieser Komponente nutzt?

[hoika]

Hallo,

Zitat:

Mit Microsoft Server SQL geht es per SQL-Script

IBExpert Personal (nur für Privatzwecke) hat eine Script-Funktionalität.

Script sollte aber auch jede Zugriffskomponente für Firebird haben.

Welche benutzt Du?

[IBExpert]

Zitat:

Zitat von hoika (Beitrag 1448464)

IBExpert Personal (nur für Privatzwecke) hat eine Script-Funktionalität.

Einspruch euer Ehren ;-)

hat zwar nix mit dem Topic zu tun, aber die IBExpert Personal Einschränkung von uns bezieht
sich darauf, das der Benutzer, der das mit seinem Account herunterlädt, das nur selber benutzen
darf, aber nicht z.B. an Kunden weitergeben darf, damit der das benutzt. Gerne aber darf er
das den Kunden bei Bedarf selber downloaden und installieren lassen.

Wem die Personal Edition auch im kommerziellen Umfeld ausreicht, ist herzlich willkommen,
die auch für seinen Job zu benutzen. Ein Chef muss dann aber seinen Mitarbeiter ebenfalls
das mit jeweils einem eigenen Account pro Mitarbeiter herunterladen und installieren lassen.

Es darf nicht vorinstalliert sein.

[hoika]

Hallo,
Einspruch ist doch mein Spruch :)

[Gandimann]

Mein Ziel ist so eine Tabelle mit script generieren und mit entsprechende Daten zu befüllen:
Z.B : Ab 01.01.2020 bis 31.12.2050 ( es ist klar es gibt auch bewegliche Feiertage die werde ich anders regeln)

/

SQL-Code:

/ If not exists then create it



CREATE TABLE Dates_ready
(
  DateKey             BIGINT         NOT NULL PRIMARY KEY,
  [Date]              DATE        NOT NULL,
  [Day]               INT     NOT NULL,
  DaySuffix           VARCHAR(3)  NOT NULL,
  [Weekday]           INT         NOT NULL,
  WeekDayName         VARCHAR(10) NOT NULL,
  IsWeekend           INT         NOT NULL,
  IsHoliday           INT         NOT NULL,
  HolidayText         VARCHAR(64) NOT NULL,
  DOWInMonth          INT         NOT NULL,
  [DayOfYear]         INT         NOT NULL,
  WeekOfMonth         INT         NOT NULL,
  WeekOfYear          INT         NOT NULL,
  ISOWeekOfYear       INT         NOT NULL,
  [Month]             INT         NOT NULL,
  [MonthName]         VARCHAR(10) NOT NULL,
  [Quarter]           INT         NOT NULL,
  QuarterName         VARCHAR(6)  NOT NULL,
  [Year]              INT         NOT NULL,
  MMYYYY              VARCHAR(6)  NOT NULL,
  MonthYear           VARCHAR(7)  NOT NULL,
  FirstDayOfMonth     DATE        NOT NULL,
  LastDayOfMonth      DATE        NOT NULL,
  FirstDayOfQuarter   DATE        NOT NULL,
  LastDayOfQuarter    DATE        NOT NULL,
  FirstDayOfYear      DATE        NOT NULL,
  LastDayOfYear       DATE        NOT NULL,
  FirstDayOfNextMonth DATE        NOT NULL,
  FirstDayOfNextYear  DATE        NOT NULL
);

[hoika]

Hallo,
dazu brauchst Du nur eine normale Query.

[Lemmy]

Zitat:

Zitat von Gandimann (Beitrag 1448573)

[COLOR="Black"][COLOR="Black"]Mein Ziel ist so eine Tabelle mit script generieren und mit entsprechende Daten zu befüllen:
Z.B : Ab 01.01.2020 bis 31.12.2050 ( es ist klar es gibt auch bewegliche Feiertage die werde ich anders regeln)

Tabelle in DB anlegen und ein kleines Programm schreiben, das diese mit Leben füllt und anschließend exportieren, oder direkt das insert-Script erzeugt.

Und bist Du sicher, dass die Struktur so Sinn macht?

Zitat:

FirstDayOfYear DATE NOT NULL,
LastDayOfYear DATE NOT NULL,

[Gandimann]

Thanx für Hilfe.
Das Problem: ich möchte gern , dass tägliches Datum ab 01.01.20 bis 31.12.50 im Column "Date" bereits steht. 01.01.2020,02.01.2020,03.01.2020....bis 31.12.2050 und "WeekOfYear" auch 01 bis 52 bereits drin steht.
Jeweils ein Datensatz (per Row)

[mkinzler]

Dies scheint mit wenig sinnvoll, da die Daten sich einfach berechnen lassen. Zudem gibt es fertige Kalenderkomponenten, welche dies schon machen.

[ConstantGardener]

...naja kommt drauf an. Wenn du das zum joinen mit anderen Tabellen nutzt kann es schon einiges erleichtern. Ich würde die beweglichen Feiertage allerdings dann auch gleich in die Tabelle schreiben.

[Lemmy]

Zitat:

Zitat von Gandimann (Beitrag 1448590)

Thanx für Hilfe.
Das Problem: ich möchte gern , dass tägliches Datum ab 01.01.20 bis 31.12.50 im Column "Date" bereits steht. 01.01.2020,02.01.2020,03.01.2020....bis 31.12.2050 und "WeekOfYear" auch 01 bis 52 bereits drin steht.
Jeweils ein Datensatz (per Row)

das ist mir klar. Daher: Programm schreiben und die Daten füllen, script exportieren fertig. Alternativ das Script von Hand schreiben (wird wohl eher nicht das Ziel sein). Per StoredProcedure und co dürfte das recht aufwändig sein. Und Rest:

Zitat:

Zitat von mkinzler (Beitrag 1448591)

Dies scheint mit wenig sinnvoll, da die Daten sich einfach berechnen lassen. Zudem gibt es fertige Kalenderkomponenten, welche dies schon machen.

FÜr eine sinnvolle Anwendung sehe ich ebenfalls keinen Sinn, schon gar nicht für einen Dienstplan.

[p80286]

Zuerst: Der Plural von Mopp ist Mopps

Dann Du solltest Deine Tabelle zunächst normalisieren. Also z.B. die Monatsnamen in eine eigene Tabelle auslagern.

Weiterhin wo konkret liegt das Problem ein für Firebird verständliches Script zu erstellen? Fehlt Dir die entsprechende Dokumentation?

Und Du solltest dir wirklich Gedanken über den Sinn der enthaltenen Daten machen.

Gruß
K-H

[mkinzler]

Monatsnamen haben aber nichts in der Datenbank verloren. Man kann in diesem Fall auf Normalisierung verzichten.
Wie gesagt sind dass aber alles Informationen, die berechnet werden können.

[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.

[p80286]

Zitat:

Zitat von IBExpert (Beitrag 1448887)

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.

Bring mal die führende Null in der ex-DDR in integern unter. da kommt dann ganz schnell ein Erfassugsfehler vorbei. Und wenn Du dann die vierstelligen Werte als korrekt interpretierst, dann sind die alten Westdeutschen Werte auch in Ordnung!?
PLZ sind nun mal nicht numerisch.

Gruß
K-H