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.