Wochentag berechnen für Experten

[bvjh]

Hallo,

ich brauch da mal nen Ansatz.

Ich möchte mit MySql berechnen, wie viele Dienstage im Jahr auf den 14.
fallen - in einem x beliebigen Zeitraum - also +- 400 Jahre, Schaltjahre
usw inklusive...

Gruss

Chris

[Thomas 'PointedEars' Lahn]

1. Name zulegen.
2. E-Mail-Adresse zulegen.
3. Ernstgenommen werden.

--
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[Gregor Kofler]

Am 2012-01-06 20:06, bvjh meinte:

Hausübung?

Gregor

[Christopher Beer]

Am 11.01.2012 22:17, schrieb Thomas 'PointedEars' Lahn:
> bvjh wrote:
>
>> ich brauch da mal nen Ansatz.
>>
>> Ich möchte mit MySql berechnen, wie viele Dienstage im Jahr auf den 14.
>> fallen - in einem x beliebigen Zeitraum - also +- 400 Jahre, Schaltjahre
>> usw inklusive...
>
> 1. Name zulegen.
> 2. E-Mail-Adresse zulegen.
> 3. Ernstgenommen werden.
>

Sorry, sonst lese ich nur mit...

Also, meine Überlegung war, eine Tabelle per PHP mit Datum und Wochentag
zu füllen und dann einfach per SELECT abzufragen.

Vielleicht gibt es ja noch eine andere Lösung ?

Gruss Christopher

[Thomas 'PointedEars' Lahn]

Christopher Beer wrote:

> Also, meine Überlegung war, eine Tabelle per PHP mit Datum und Wochentag
> zu füllen und dann einfach per SELECT abzufragen.

Geht.

> Vielleicht gibt es ja noch eine andere Lösung ?

MySQL kennt Stored Procedures. Du kannst also mit MySQL auch die
(temporäre) Tabelle erstellen und diese anschliessend mit MySQL abfragen.

<http://dev.mysql.com/doc/refman/5.5/en/create-procedure.html>


HTH

[Dieter Nöth]

Christopher Beer wrote:

>>> Ich möchte mit MySql berechnen, wie viele Dienstage im Jahr auf den 14.
>>> fallen - in einem x beliebigen Zeitraum - also +- 400 Jahre, Schaltjahre
>>> usw inklusive...

...
> Also, meine Überlegung war, eine Tabelle per PHP mit Datum und Wochentag
> zu füllen und dann einfach per SELECT abzufragen.
>
> Vielleicht gibt es ja noch eine andere Lösung ?

Keine wirklich sinnvolle, nur:
statt extra für diese Fragestellung eine Tabelle zu erstellen, kann die
vorhandene Kalendertabelle verwendet werden, die es sowieso in jeder
Datenbank geben sollte.
Und da habe ich hoffentlich schon den Wochentag (neben
Feiertagen/Wochennummern/Geschäftsjahren etc.) vorberechnet oder wenn
nicht, dann eben direkt mit:
select count(*)
from kalender
where jahr = xxx
and DAYOFMONTH(datum) = 14
and DAYOFWEEK(datum) = 3

Dieter

[Thomas 'PointedEars' Lahn]

Dieter Nöth wrote:

> Christopher Beer wrote:
>>>> Ich möchte mit MySql berechnen, wie viele Dienstage im Jahr auf den 14.
>>>> fallen - in einem x beliebigen Zeitraum - also +- 400 Jahre,
>>>> Schaltjahre usw inklusive...
> ...
>> Also, meine Überlegung war, eine Tabelle per PHP mit Datum und Wochentag
>> zu füllen und dann einfach per SELECT abzufragen.
>>
>> Vielleicht gibt es ja noch eine andere Lösung ?
>
> Keine wirklich sinnvolle, nur:
> statt extra für diese Fragestellung eine Tabelle zu erstellen, kann die
> vorhandene Kalendertabelle verwendet werden, die es sowieso in jeder
> Datenbank geben sollte.

Das ist grober Unfug. In einer Datenbank sollten ausschliesslich
*Nutzdaten* gespeichert werden. Der (ewige) Kalender gehört nicht dazu,
weil den jede brauchbare Programmiersprache und jede brauchbare
Datenbankabfragesprache eingebaut hat. Anders formuliert: In einer
Termindatenbank erstellt man _nicht_ für jedes mögliche Datum einen
Datensatz und befüllt den bei Vorliegen eines Termins mit Textdaten, sondern
man erstellt für jeden *Termin* einen Datensatz mit dem entsprechenden
Datumswert. Keine Termine, keine Datensätze.

Mit einer Stored Procedure bei Bedarf eine temporäre Tabelle zu erstellen,
die die Wochentage aller 14. speichert, dauert höchstens ein Millionstel der
Zeit, und benötigt einen ebensolchen Anteil Speicherplatz, als eine wie auch
immer geartete "Kalendertabelle". BTDT.

> Und da habe ich hoffentlich schon den Wochentag (neben
> Feiertagen/Wochennummern/Geschäftsjahren etc.) vorberechnet oder wenn
> nicht, dann eben direkt mit:
> select count(*)
> from kalender
> where jahr = xxx
> and DAYOFMONTH(datum) = 14
> and DAYOFWEEK(datum) = 3

Du hast entweder nicht den Hauch der Spur einer Ahnung, worüber Du
schreibst, oder Du hast die Fragestellung schlicht nicht verstanden.

[Dieter Nöth]

Thomas 'PointedEars' Lahn wrote:
> Dieter Nöth wrote:
>
>> Christopher Beer wrote:
>>>>> Ich möchte mit MySql berechnen, wie viele Dienstage im Jahr auf den 14.
>>>>> fallen - in einem x beliebigen Zeitraum - also +- 400 Jahre,
>>>>> Schaltjahre usw inklusive...
>> ...

>> statt extra für diese Fragestellung eine Tabelle zu erstellen, kann die
>> vorhandene Kalendertabelle verwendet werden, die es sowieso in jeder
>> Datenbank geben sollte.
>
> Das ist grober Unfug. In einer Datenbank sollten ausschliesslich
> *Nutzdaten* gespeichert werden. Der (ewige) Kalender gehört nicht dazu,
> weil den jede brauchbare Programmiersprache und jede brauchbare
> Datenbankabfragesprache eingebaut hat.

Und? Wie oft soll den für 2012-01-12 berechnet werden, dass heute
Donnerstag ist in der Kalenderwoche 2012W02? Bei jeder Row mit diesem
Datum auf's Neue, falls sich da doch mal was ändert?

Die eingebauten Datumsfunktionen sind ganz nett, wenn ich nur für die
Ausgabe eine Berechnung brauche. Bei einer Bedingung wie "Alle Daten aus
der Wochen 2010W52" auf grossen Datenmengen ist ein Join auf einen
Kalender besser, der gibt vor allem dem Optimizer Info über die Anzahl
der Tage in dieser Woche, die er bei einer direkten Berechnung nicht
wissen kann. Dadurch kann er die weiteren Arbeitschritte besser planen.

> Anders formuliert: In einer
> Termindatenbank erstellt man _nicht_ für jedes mögliche Datum einen
> Datensatz und befüllt den bei Vorliegen eines Termins mit Textdaten, sondern
> man erstellt für jeden *Termin* einen Datensatz mit dem entsprechenden
> Datumswert. Keine Termine, keine Datensätze.

Du sprichst von einer Termindatenbank, ich von einem Kalender.
Ausserdem, wie erstellt du denn aus der Termindatenbank eine Ausgabe mit
allen Datumswerten (auch die, für die es kene Termine gibt) für einen
bestimmten Bereich ohne einen Left Join auf einen Kalender?

> Mit einer Stored Procedure bei Bedarf eine temporäre Tabelle zu erstellen,
> die die Wochentage aller 14. speichert, dauert höchstens ein Millionstel der
> Zeit, und benötigt einen ebensolchen Anteil Speicherplatz, als eine wie auch
> immer geartete "Kalendertabelle".

Willst du jedesmal, wenn "irgendsoeine" Datums-Berechnung gemacht werden
soll, eine entsprechende SP ausführen, die auch noch passend geschrieben
werden muss und die ich nicht joinen kann?

> BTDT.

Glaub ich dir.
Dann bin ich wohl woanders gewesen, denn da ist dieser "grobe Unfug"
Standard.

>> Und da habe ich hoffentlich schon den Wochentag (neben
>> Feiertagen/Wochennummern/Geschäftsjahren etc.) vorberechnet oder wenn
>> nicht, dann eben direkt mit:
>> select count(*)
>> from kalender
>> where jahr = xxx
>> and DAYOFMONTH(datum) = 14
>> and DAYOFWEEK(datum) = 3
>
> Du hast entweder nicht den Hauch der Spur einer Ahnung, worüber Du
> schreibst, oder Du hast die Fragestellung schlicht nicht verstanden.

Wieso? Mein Beispiel auf einer Kalendertabelle berechnet genau das
Gewünschte für ein Jahr (nur in meinem Kalender bräuchte ich die
Funktionen nicht, da das schon vorberechnet wurde):

"wie viele Dienstage im Jahr auf den 14. fallen"

-> DAYOFMONTH(datum) = 14 and DAYOFWEEK(datum) = 3

Und falls es mehr als ein Jahr sein soll, dann eben eine entsprechende
WHERE-Bedingung und "GROUP BY Jahr".

Dieter

[Thomas 'PointedEars' Lahn]

Dieter Nöth wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Dieter Nöth wrote:
>>> Christopher Beer wrote:
>>>>>> Ich möchte mit MySql berechnen, wie viele Dienstage im Jahr auf den
>>>>>> 14. fallen - in einem x beliebigen Zeitraum - also +- 400 Jahre,
>>>>>> Schaltjahre usw inklusive...
>>> ...
>>> statt extra für diese Fragestellung eine Tabelle zu erstellen, kann die
>>> vorhandene Kalendertabelle verwendet werden, die es sowieso in jeder
>>> Datenbank geben sollte.
>>
>> Das ist grober Unfug. In einer Datenbank sollten ausschliesslich
>> *Nutzdaten* gespeichert werden. Der (ewige) Kalender gehört nicht dazu,
>> weil den jede brauchbare Programmiersprache und jede brauchbare
>> Datenbankabfragesprache eingebaut hat.
>
> Und? Wie oft soll den für 2012-01-12 berechnet werden, dass heute
> Donnerstag ist in der Kalenderwoche 2012W02? Bei jeder Row mit diesem
> Datum auf's Neue, falls sich da doch mal was ändert?

Man *kann* die von der SP erstellte Tabelle natürlich für zukünftige Nutzung
bestehen lassen (d. h. kein DROP TABLE IF EXISTS und dafür ein INSERT … ON
DUPLICATE). *Im Voraus* 800 Jahre Kalenderdaten zu speichern, nur um sie
*irgendwann* *vielleicht* mal abzufragen, ist aber kompletter Blödsinn.
Zumal Kalender auch gern mal während der Lebensdauer einer Datenbank
angepasst werden (Stichworte: "Sommerzeit", "Schaltsekunde").

> Die eingebauten Datumsfunktionen sind ganz nett, wenn ich nur für die
> Ausgabe eine Berechnung brauche.

Wie kommst Du eigentlich darauf, dass hier etwas anderes gesucht war?

> Bei einer Bedingung wie "Alle Daten aus der Wochen 2010W52" auf grossen
> Datenmengen ist ein Join auf einen Kalender besser, der gibt vor allem dem
> Optimizer Info über die Anzahl der Tage in dieser Woche, die er bei einer
> direkten Berechnung nicht wissen kann. Dadurch kann er die weiteren
> Arbeitschritte besser planen.

Quatsch. JOINs sind so ziemlich die langsamsten Datenbankoperationen, die
es gibt. Insbesondere bei einer grossen Datenbasis. JOINs *vermeidet* man
(es sei denn, sie dienen der Effizienz gegenüber WHERE-Ausdrücken), und
provoziert sie nicht noch zusätzlich durch derart extremen Overhead!

>> Anders formuliert: In einer
>> Termindatenbank erstellt man _nicht_ für jedes mögliche Datum einen
>> Datensatz und befüllt den bei Vorliegen eines Termins mit Textdaten,
>> sondern man erstellt für jeden *Termin* einen Datensatz mit dem
>> entsprechenden
>> Datumswert. Keine Termine, keine Datensätze.
>
> Du sprichst von einer Termindatenbank, ich von einem Kalender.

Einen Kalender, in dem Termine gespeichert werden sollen, implementiert im
Backend üblicherweise als Termindatenbank. Einen Kalender, der "einfach nur
da" ist, implementiert man *gar* *nicht* als Datenbank.

> Ausserdem, wie erstellt du denn aus der Termindatenbank eine Ausgabe mit
> allen Datumswerten (auch die, für die es kene Termine gibt) für einen
> bestimmten Bereich ohne einen Left Join auf einen Kalender?

Gar nicht. Für den unwahrscheinlichen Fall, dass ich wissen muss, an
welchen Tagen es *keine* Termine gibt (der Normalfall ist das Gegenteil,
d. h. z. B. das Array der Termine für einen Tag an dem nichts los ist, ist
einfach leer), könnte ich zur Not immer noch einen JOIN machen.

Im Normalfall brauche ich dafür aber schon mal gar keine Datenbankabfrage,
denn wie gesagt, das Array für den jeweiligen Tag ist leer (bzw. für den Tag
gibt es gar kein Element im übergeordneten Array, was un Abhängigkeit vom
Zeitraum noch effizienter sein kann), da ich zuvor die Arrays aller Tage im
relevanten Zeitraum (z. B. aktuellen Monat) mit den gespeicherten Terminen
gefüllt habe.

>> Mit einer Stored Procedure bei Bedarf eine temporäre Tabelle zu
>> erstellen, die die Wochentage aller 14. speichert, dauert höchstens ein
>> Millionstel der Zeit, und benötigt einen ebensolchen Anteil
>> Speicherplatz, als eine wie auch immer geartete "Kalendertabelle".
>
> Willst du jedesmal, wenn "irgendsoeine" Datums-Berechnung gemacht werden
> soll, eine entsprechende SP ausführen, die auch noch passend geschrieben
> werden muss

*Einmal* schreibt man die SP, und eher *selten* führt man sie aus, ja.

> und die ich nicht joinen kann?

Wie bitte? Die SP erstellt einfach eine Tabelle. Mit der kannst Du machen
was Du willst. Die SP kann so geschrieben werden, dass die Tabelle, die sie
erstellt, mehreren Use-Cases dient (z. B. speichere ich nicht [nur] den
Wochentag, sondern [auch gleich noch] das Datum). Und für Spezialfälle
erstellt man einfach eine zweite, dritte usw. SP. Die erstellt man dann
auch nur *einmal*.

> > BTDT.
>
> Glaub ich dir.
> Dann bin ich wohl woanders gewesen, denn da ist dieser "grobe Unfug"
> Standard.

Das glaube ich Dir nicht. Nicht mal der Kalender von Rausguck (Exzess) ist
so abgrundtief bescheuert programmiert!

>>> Und da habe ich hoffentlich schon den Wochentag (neben
>>> Feiertagen/Wochennummern/Geschäftsjahren etc.) vorberechnet oder wenn
>>> nicht, dann eben direkt mit:
>>> select count(*)
>>> from kalender
>>> where jahr = xxx
>>> and DAYOFMONTH(datum) = 14
>>> and DAYOFWEEK(datum) = 3
>>
>> Du hast entweder nicht den Hauch der Spur einer Ahnung, worüber Du
>> schreibst, oder Du hast die Fragestellung schlicht nicht verstanden.
>
> Wieso? Mein Beispiel auf einer Kalendertabelle berechnet genau das
> Gewünschte für ein Jahr (nur in meinem Kalender bräuchte ich die
> Funktionen nicht, da das schon vorberechnet wurde):
> "wie viele Dienstage im Jahr auf den 14. fallen"
> -> DAYOFMONTH(datum) = 14 and DAYOFWEEK(datum) = 3
>
> Und falls es mehr als ein Jahr sein soll, dann eben eine entsprechende
> WHERE-Bedingung und "GROUP BY Jahr".

Bitte hinlesen und Gehirn einschalten! Du willst gigabyteweise
Kalenderdaten in der Datenbank speichern für den unwahrscheinlichen Fall,
dass Du mal wissen willst, wieviele 14. in diesem Jahr auf einen Dienstag
fallen (und ähnliches)? Das kann doch nicht Dein Ernst sein!


kopfschüttelnd,

[Dieter Nöth]

Thomas 'PointedEars' Lahn wrote:

> Man *kann* die von der SP erstellte Tabelle natürlich für zukünftige Nutzung
> bestehen lassen (d. h. kein DROP TABLE IF EXISTS und dafür ein INSERT … ON
> DUPLICATE).

Und für eine andere Fragestellung gibt es dann eine neue Tabelle?

> *Im Voraus* 800 Jahre Kalenderdaten zu speichern, nur um sie
> *irgendwann* *vielleicht* mal abzufragen, ist aber kompletter Blödsinn.

800 Jahre sind schon etwas viel, stimmt, das hab ich im Kalender auch
nicht immer drin. Aber die vorberechneten Daten im *meinem* Kalender
stehen da drin, *weil* ich sie immer wieder brauche und da gehört ein
Wochentag etc. dazu.

> Zumal Kalender auch gern mal während der Lebensdauer einer Datenbank
> angepasst werden (Stichworte: "Sommerzeit", "Schaltsekunde").

Bei einem Kalender mit Schaltsekunden oder der Sommerzeit zu
argumentieren ist schlicht Themaverfehlung, da ein Kalender auf der
Basis von Tagen aufgebaut ist.
Übrigens, Wochennummer u.ä. werden während der Lebensdauer einer
Datenbank nicht angepasst, ich geh davon aus, dass 2012-01-13 auch in
übersehbarer Zukunft der zweite Freitag des Monats Januar in der
KW201202 bleiben wird.

>> Die eingebauten Datumsfunktionen sind ganz nett, wenn ich nur für die
>> Ausgabe eine Berechnung brauche.
>
> Wie kommst Du eigentlich darauf, dass hier etwas anderes gesucht war?

Für mich ist "Ausgabe" = Spaltenliste im Select.
"wie viele Dienstage im Jahr auf den 14. fallen" ist aber eine Bedingung
und die gehört in's WHERE.

>> Bei einer Bedingung wie "Alle Daten aus der Wochen 2010W52" auf grossen
>> Datenmengen ist ein Join auf einen Kalender besser, der gibt vor allem dem
>> Optimizer Info über die Anzahl der Tage in dieser Woche, die er bei einer
>> direkten Berechnung nicht wissen kann. Dadurch kann er die weiteren
>> Arbeitschritte besser planen.
>
> Quatsch. JOINs sind so ziemlich die langsamsten Datenbankoperationen, die
> es gibt. Insbesondere bei einer grossen Datenbasis.

Nochmal, es ist hilfreich für den Optimizer, wenn er die Kardinalität
einer Bedingung kennt. Da Joins aufwendig sind, muss ein Optimizer aus
verschiedenen internen Möglichkeiten die auswählen, welche für diese
Datenmenge die effizienteste ist. Bei Berechnungen hat er aber Probleme,
diese Kardinalität abzuschätzen: solange er zuviele Rows annimmt, ist
das meist kein Problem, es gibt aber Jointypen, die sehr effizient bei
einer kleinen Datenmenge sind, aber bei grösseren Mengen absolut mies.
Und das ist vor allem bei grosser Datenbasis wichtig.

> JOINs *vermeidet* man
> (es sei denn, sie dienen der Effizienz gegenüber WHERE-Ausdrücken),

Meinst du WHERE mit (korrelierten) Subqueries?
Die sind je nach DBMS und Fragestellung sogar effizienter als Joins.

> und
> provoziert sie nicht noch zusätzlich durch derart extremen Overhead!
>
>>> Anders formuliert: In einer
>>> Termindatenbank erstellt man _nicht_ für jedes mögliche Datum einen
>>> Datensatz und befüllt den bei Vorliegen eines Termins mit Textdaten,
>>> sondern man erstellt für jeden *Termin* einen Datensatz mit dem
>>> entsprechenden
>>> Datumswert. Keine Termine, keine Datensätze.
>>
>> Du sprichst von einer Termindatenbank, ich von einem Kalender.
>
> Einen Kalender, in dem Termine gespeichert werden sollen, implementiert im
> Backend üblicherweise als Termindatenbank. Einen Kalender, der "einfach nur
> da" ist, implementiert man *gar* *nicht* als Datenbank.

Du sprichst von einer Termin*datenbank*, ich von einer Kalender*tabelle*.
Ein Kalender ist eine *Tabelle* und keine *Datenbank*.
Eine Termindatenbank kann allerdings ziemlich komplex sein mit diversen
Tabellen.

>> Ausserdem, wie erstellt du denn aus der Termindatenbank eine Ausgabe mit
>> allen Datumswerten (auch die, für die es kene Termine gibt) für einen
>> bestimmten Bereich ohne einen Left Join auf einen Kalender?
>
> Gar nicht. Für den unwahrscheinlichen Fall, dass ich wissen muss, an
> welchen Tagen es *keine* Termine gibt (der Normalfall ist das Gegenteil,
> d. h. z. B. das Array der Termine für einen Tag an dem nichts los ist, ist
> einfach leer), könnte ich zur Not immer noch einen JOIN machen.

Ein "Array der Termine"? Sprichst du jetzt "SQL/Datenbank" oder PHP?
Und wohin joinst du "zur Not"? Etwa zu einer Kalendertabelle?

> Im Normalfall brauche ich dafür aber schon mal gar keine Datenbankabfrage,
> denn wie gesagt, das Array für den jeweiligen Tag ist leer (bzw. für den Tag
> gibt es gar kein Element im übergeordneten Array, was un Abhängigkeit vom
> Zeitraum noch effizienter sein kann), da ich zuvor die Arrays aller Tage im
> relevanten Zeitraum (z. B. aktuellen Monat) mit den gespeicherten Terminen
> gefüllt habe.

Ok, du sprichst doch von PHP o.ä., das tangiert mich äusserst peripher,
ich dachte, hier wäre de.comp.*datenbanken*.mysql

>>> Mit einer Stored Procedure bei Bedarf eine temporäre Tabelle zu
>>> erstellen, die die Wochentage aller 14. speichert, dauert höchstens ein
>>> Millionstel der Zeit, und benötigt einen ebensolchen Anteil
>>> Speicherplatz, als eine wie auch immer geartete "Kalendertabelle".
>>
>> Willst du jedesmal, wenn "irgendsoeine" Datums-Berechnung gemacht werden
>> soll, eine entsprechende SP ausführen, die auch noch passend geschrieben
>> werden muss
>
> *Einmal* schreibt man die SP, und eher *selten* führt man sie aus, ja.

Ich kenn das eher so, dass man eine SP schreibt, weil man sie *häufig*
ausführen will.

>> und die ich nicht joinen kann?
>
> Wie bitte? Die SP erstellt einfach eine Tabelle. Mit der kannst Du machen
> was Du willst. Die SP kann so geschrieben werden, dass die Tabelle, die sie
> erstellt, mehreren Use-Cases dient (z. B. speichere ich nicht [nur] den
> Wochentag, sondern [auch gleich noch] das Datum). Und für Spezialfälle
> erstellt man einfach eine zweite, dritte usw. SP. Die erstellt man dann
> auch nur *einmal*.

Auf eine SP kann ich nicht joinen (wobei es DBMSe gibt, die das auch
können). Dass ich natürlich erstmal einen CALL machen kann und dann im
nächsten Schritt auf die gerade erzeugte Tabelle zugreifen kann, ist
aber was anderes.

Und wenn du dann für die Use-Cases die Tabelle erweitert hast und für
die Spezialfälle deine SPs weitere Tabellen angelegt haben, wirst du
vielleicht feststellen, dass ein Kalender mit dem ganzen Zeug drin gar
nicht so schlecht ist?

> BTDT.
>>
>> Glaub ich dir.
>> Dann bin ich wohl woanders gewesen, denn da ist dieser "grobe Unfug"
>> Standard.
>
> Das glaube ich Dir nicht. Nicht mal der Kalender von Rausguck (Exzess) ist
> so abgrundtief bescheuert programmiert!

Was hat der Outlook-Kalender damit zu tun?
Isch 'abe Microsoft gar nicht als Kunde.

Wenn du mir nicht glauben willst, sollen wir dann unsere Kundenlisten
rausholen und einen Längenvergleich machen?

>>>> Und da habe ich hoffentlich schon den Wochentag (neben
>>>> Feiertagen/Wochennummern/Geschäftsjahren etc.) vorberechnet oder wenn
>>>> nicht, dann eben direkt mit:
>>>> select count(*)
>>>> from kalender
>>>> where jahr = xxx
>>>> and DAYOFMONTH(datum) = 14
>>>> and DAYOFWEEK(datum) = 3
>>>
>>> Du hast entweder nicht den Hauch der Spur einer Ahnung, worüber Du
>>> schreibst, oder Du hast die Fragestellung schlicht nicht verstanden.
>>
>> Wieso? Mein Beispiel auf einer Kalendertabelle berechnet genau das
>> Gewünschte für ein Jahr (nur in meinem Kalender bräuchte ich die
>> Funktionen nicht, da das schon vorberechnet wurde):
>> "wie viele Dienstage im Jahr auf den 14. fallen"
>> -> DAYOFMONTH(datum) = 14 and DAYOFWEEK(datum) = 3
>>
>> Und falls es mehr als ein Jahr sein soll, dann eben eine entsprechende
>> WHERE-Bedingung und "GROUP BY Jahr".
>
> Bitte hinlesen und Gehirn einschalten! Du willst gigabyteweise

"gigabyteweise"
Bitte Gehirn einschalten und einfach mal grosszügig rechnen:
Ich hab also jede nur vorstellbare Berechnung für ein Datum gemacht und
den Datensatz pro Tag auf unwahrscheinliche 1000 Bytes aufgeblasen, dann
hab ich bei 2727 Jahren im Kalender *ein* GB erreicht.

> Kalenderdaten in der Datenbank speichern für den unwahrscheinlichen Fall,
> dass Du mal wissen willst, wieviele 14. in diesem Jahr auf einen Dienstag
> fallen (und ähnliches)?

Der OP wollte das wissen, ich nicht, aber mit einem Kalender kann ich
selbst sowas Hausaufgabenmässiges mit einer einfachen Abfrage rausholen.

Für mich gibt es eher Bedingungen wie
- vergleiche die Daten der beiden Wochen um Ostern der letzten drei Jahre
- duchschnittliche Umsätze am 1. Samstag des Monats des letzten halben
Jahres
- berechne die Anzahl von Geschäftstagen zwischen Start- und Endedatum
unter Einbeziehung von Feiertagen etc. Aber nicht für eine Row, sondern
zig-Millionen, weil du den Mittelwert brauchst.

> kopfschüttelnd,

kenn ich, das kommt von der lauten Musik...

Dieter

[Christopher Beer]

Hallo!

So, nun noch mal zum Thema ;-)

Frage war: An wie vielen Tagen fällt der 14. auf einen Dienstag.

Meine Idee war, eine Tabelle per PHP mit Datum und Wochentag zu füllen
und diese dann abzufragen - über Selects´s mit where usw. brauchen wir
hier nicht zu diskutieren - MySQL Abfragen können wir wohl alle.

Ich suche nach einer reinen MySQL Lösung, ohne PHP.
Meine Ansätze in PHP scheitern u.a. am 1.1.1970, Schaltjahre kennt PHP
nicht ?, der gregorianische Kalendar (
http://de.wikipedia.org/wiki/Gregorianischer_Kalender ) hat einige
"Schwachstellen" (Schaltjahre usw.).

Kennt MySQL diese ?

Kann ich per MySQL eine Tabelle mit Datum von 01.01.0000 bis 31.12.3000
füllen und dann damit arbeiten ?

Also: An wie vielen Tagen im Jahr fällt der xx. durchschnittlich auf
einen bestimmten Wochentag in einem x-beliebigen Zeitraum.

Die Lösung ist das Ziel - und wenn ich eine Tabelle mit 4.000.0000
Datensätzen dafür anlegen muss - ob temporär oder sonst wie - spielt
hier keine Rolle.

Nicht MySQL Lösungen sind auch willkommen... ;-) (Kalendar von 0 - 3000
ausdrucken und nachzählen fällt flach.)

Gruss Christopher

P.S.: Es ist keine Hausaufgabe - die Frage kam bei einer Bierlaune auf.

[Dieter Nöth]

Christopher Beer wrote:

> Meine Ansätze in PHP scheitern u.a. am 1.1.1970, Schaltjahre kennt PHP
> nicht ?, der gregorianische Kalendar (
> http://de.wikipedia.org/wiki/Gregorianischer_Kalender ) hat einige
> "Schwachstellen" (Schaltjahre usw.).

Mit PHP kenn ich mich nicht wirklich aus, aber mit Schaltjahren müsste
es doch wie jede Programmiersprache umgehen können.

> Kann ich per MySQL eine Tabelle mit Datum von 01.01.0000 bis 31.12.3000
> füllen und dann damit arbeiten ?

Du musst nur irgendwoher eine Sequenz mit der Anzahl von Tagen, die du
brauchst, bekommen: Z.B. aus irgendeiner Tabelle rausziehen, ich hab
sowas über x Cross-Joins einer kleinen Tabelle mit den Zahlen von 0 bis
9 mit sich selber erzeugt. Diese Zahl addierst du zu dem Startdatum und
erhälst die Datumswerte. Ich hab übrigens früher häufig auch eine
generische Tabelle mit den Zahlen von 1 bis x angelegt, da man die immer
wieder für die verschiedensten Abfragen gebrauchen konnte (einfach so
auf Vorrat, welch eine Platzverschwendung ;-)

> Also: An wie vielen Tagen im Jahr fällt der xx. durchschnittlich auf
> einen bestimmten Wochentag in einem x-beliebigen Zeitraum.

Das ISO-Kalendermodel, auf dem das SQL Datum basiert, ist ein
proleptischer Gregorianischer Kalender, irgendwelchen Datumsangaben aus
älteren Jahrhunderten kann man nicht einen exakten Wochentag zuordnen
(ohne genau zu wissen, in welcher Region das war), aber das scheint bei
deiner Fragestellung kein Problem zu sein.

> Die Lösung ist das Ziel - und wenn ich eine Tabelle mit 4.000.0000
> Datensätzen dafür anlegen muss - ob temporär oder sonst wie - spielt
> hier keine Rolle.
>
> Nicht MySQL Lösungen sind auch willkommen... ;-)

Dann nimm irgendeine Programmiersprache und mach eine Schleife von-bis
und zähl einfach hoch...

> P.S.: Es ist keine Hausaufgabe - die Frage kam bei einer Bierlaune auf.

Den Kopf möcht ich nicht gehabt haben :-)

Dieter

[Thomas 'PointedEars' Lahn]

Dieter Nöth wrote:

> Christopher Beer wrote:
>> Meine Ansätze in PHP scheitern u.a. am 1.1.1970, Schaltjahre kennt PHP
>> nicht ?, der gregorianische Kalendar (
>> http://de.wikipedia.org/wiki/Gregorianischer_Kalender ) hat einige
>> "Schwachstellen" (Schaltjahre usw.).
>
> Mit PHP kenn ich mich nicht wirklich aus, aber mit Schaltjahren müsste
> es doch wie jede Programmiersprache umgehen können.

So ist es.

>> Kann ich per MySQL eine Tabelle mit Datum von 01.01.0000 bis 31.12.3000
>> füllen und dann damit arbeiten ?
>
> Du musst nur irgendwoher eine Sequenz mit der Anzahl von Tagen, die du
> brauchst, bekommen: Z.B. aus irgendeiner Tabelle rausziehen,

Besser: Die Tabelle generieren und diese dann abfragen.

> ich hab sowas über x Cross-Joins einer kleinen Tabelle mit den Zahlen von
> 0 bis 9 mit sich selber erzeugt. Diese Zahl addierst du zu dem Startdatum
> und erhälst die Datumswerte.

Das ist grober Unfug.

> Ich hab übrigens früher häufig auch eine generische Tabelle mit den Zahlen
> von 1 bis x angelegt, da man die immer wieder für die verschiedensten
> Abfragen gebrauchen konnte

Das wundert mich nicht.

> (> einfach so auf Vorrat, welch eine Platzverschwendung ;-)

In der Tat. Du hast anscheinend weder von Programmierung noch von
Datenbanken eine Ahnung.

[Thomas 'PointedEars' Lahn]

Christopher Beer wrote:

> Frage war: An wie vielen Tagen fällt der 14. auf einen Dienstag.
>
> Meine Idee war, eine Tabelle per PHP mit Datum und Wochentag zu füllen
> und diese dann abzufragen - über Selects´s mit where usw. brauchen wir
> hier nicht zu diskutieren - MySQL Abfragen können wir wohl alle.

Dann sollte das für Dich ja kein Problem sein.

> Ich suche nach einer reinen MySQL Lösung, ohne PHP.
> Meine Ansätze in PHP scheitern u.a. am 1.1.1970, Schaltjahre kennt PHP
> nicht ?,

Aber sicher "kennt es" diese, soweit wie eine Programmiersprache überhaupt
etwas kennen kann.

> der gregorianische Kalendar (>
> http://de.wikipedia.org/wiki/Gregorianischer_Kalender ) hat einige
> "Schwachstellen" (Schaltjahre usw.).

Die Schaltjahre im Gregorianischen Kalender sind keine "Schwachstellen",
sondern die Lösung des durch den Julianischen Kalender ausgelösten Problems,
da die Umlaufzeit von Terra nun einmal nicht in ganzen Tagen exakt bemessen
werden kann, Lebensformen auf diesem Planeten aber einem natürlichen
Tag-/Nacht-Zyklus folgen und sich dies im Kalender wiederspiegeln soll.

> Kennt MySQL diese ?

MySQL hat unter anderem einen DATE- und einen DATETIME-Datentyp.

RTFM!

> Kann ich per MySQL eine Tabelle mit Datum von 01.01.0000 bis 31.12.3000
> füllen und dann damit arbeiten ?

Ja, aber das wäre zuviel des Guten.

> Also: An wie vielen Tagen im Jahr fällt der xx. durchschnittlich auf
> einen bestimmten Wochentag in einem x-beliebigen Zeitraum.
>
> Die Lösung ist das Ziel - und wenn ich eine Tabelle mit 4.000.0000
> Datensätzen dafür anlegen muss - ob temporär oder sonst wie - spielt
> hier keine Rolle.

Für 3'000 Jahre sind es hierfür theoretisch nur 36'000 Datensätze. Übrigens
gibt es im Gregorianischen Kalender kein Jahr 0. Auch fand die
entsprechende Kalenderreform im Jahr 1582 nach jener Zeitrechnung statt.
genaue Datumsangaben im Gregorianischen Kalender vor dem Freitag, 15.
Oktober 1582 sind daher nicht sinnvoll (es gibt die gregorianischen Daten
vom 5. bis 14. Oktober 1582 schlicht nicht).

Wie wäre es, wenn Du Dich zur Abwechslung mal *vorher* informiertest?

> P.S.: Es ist keine Hausaufgabe - die Frage kam bei einer Bierlaune auf.

Dennoch erwartest Du anscheinend irrtümlicherweise, dass das hier ohne
Eigenleistung funktioniert.

[Thomas 'PointedEars' Lahn]

Dieter Nöth wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Man *kann* die von der SP erstellte Tabelle natürlich für zukünftige
>> Nutzung bestehen lassen (d. h. kein DROP TABLE IF EXISTS und dafür ein
>> INSERT … ON DUPLICATE).
>
> Und für eine andere Fragestellung gibt es dann eine neue Tabelle?

Nicht notwendigerweise.

>> *Im Voraus* 800 Jahre Kalenderdaten zu speichern, nur um sie
>> *irgendwann* *vielleicht* mal abzufragen, ist aber kompletter Blödsinn.
>
> 800 Jahre sind schon etwas viel, stimmt, das hab ich im Kalender auch
> nicht immer drin. Aber die vorberechneten Daten im *meinem* Kalender
> stehen da drin, *weil* ich sie immer wieder brauche und da gehört ein
> Wochentag etc. dazu.

Den Wochentag lässt man ausrechnen, wenn man ihn braucht. Mit oder ohne
Datenbankabfragesprache. Das ist wesentlich effizienter, als eine riesige
Tabelle mit Kalenderdaten (aber ohne Nutzdaten) abzufragen und
möglicherweise sogar mit dieser noch jedesmal zu joinen. Sowohl was
Laufzeit als auch Speicherplatz betrifft.

>> Zumal Kalender auch gern mal während der Lebensdauer einer Datenbank
>> angepasst werden (Stichworte: "Sommerzeit", "Schaltsekunde").
>
> Bei einem Kalender mit Schaltsekunden oder der Sommerzeit zu
> argumentieren ist schlicht Themaverfehlung, da ein Kalender auf der
> Basis von Tagen aufgebaut ist.

Mein Kalender speichert die Zeit für Termine. Wenn es bei Dir nur zur
Entwicklung eines elektronischen Abreisskalenders reicht, ist das Dein
Problem.

> Übrigens, Wochennummer u.ä. werden während der Lebensdauer einer
> Datenbank nicht angepasst, ich geh davon aus, dass 2012-01-13 auch in
> übersehbarer Zukunft der zweite Freitag des Monats Januar in der
> KW201202 bleiben wird.

Das Jahr hat 52 oder 53 Kalenderwochen (KW). Was ist also "KW201202"?

>>> Die eingebauten Datumsfunktionen sind ganz nett, wenn ich nur für die
>>> Ausgabe eine Berechnung brauche.
>> Wie kommst Du eigentlich darauf, dass hier etwas anderes gesucht war?
>
> Für mich ist "Ausgabe" = Spaltenliste im Select.
> "wie viele Dienstage im Jahr auf den 14. fallen" ist aber eine Bedingung
> und die gehört in's WHERE.

Nein. Im WHERE-Ausdruck muss beim effizienten Ansatz nur der Ausdruck
stehen, der nach den Dienstagen filtert.

Meiner Frage bist Du wieder ausgewichen.

>>> Bei einer Bedingung wie "Alle Daten aus der Wochen 2010W52" auf grossen
>>> Datenmengen ist ein Join auf einen Kalender besser, der gibt vor allem
>>> dem Optimizer Info über die Anzahl der Tage in dieser Woche, die er bei
>>> einer direkten Berechnung nicht wissen kann. Dadurch kann er die
>>> weiteren Arbeitschritte besser planen.
>> Quatsch. JOINs sind so ziemlich die langsamsten Datenbankoperationen,
>> die> es gibt. Insbesondere bei einer grossen Datenbasis.
>
> Nochmal, es ist hilfreich für den Optimizer, wenn er die Kardinalität
> einer Bedingung kennt. Da Joins aufwendig sind, muss ein Optimizer aus
> verschiedenen internen Möglichkeiten die auswählen, welche für diese
> Datenmenge die effizienteste ist. Bei Berechnungen hat er aber Probleme,
> diese Kardinalität abzuschätzen: solange er zuviele Rows annimmt, ist
> das meist kein Problem, es gibt aber Jointypen, die sehr effizient bei
> einer kleinen Datenmenge sind, aber bei grösseren Mengen absolut mies.
> Und das ist vor allem bei grosser Datenbasis wichtig.

Und deshalb lässt man diesen Unfug von vornherein bleiben. Dann muss
nämlich auch nichts optimiert werden, was vorher schlecht gemacht wurde.

>> JOINs *vermeidet* man (es sei denn, sie dienen der Effizienz gegenüber
>> WHERE-Ausdrücken),
>
> Meinst du WHERE mit (korrelierten) Subqueries?

Ja.

> Die sind je nach DBMS und Fragestellung sogar effizienter als Joins.

Wir diskutieren hier aber nicht über irgendein DBMS.

>> und provoziert sie nicht noch zusätzlich durch derart extremen Overhead!
>>
>>>> Anders formuliert: In einer
>>>> Termindatenbank erstellt man _nicht_ für jedes mögliche Datum einen
>>>> Datensatz und befüllt den bei Vorliegen eines Termins mit Textdaten,
>>>> sondern man erstellt für jeden *Termin* einen Datensatz mit dem
>>>> entsprechenden
>>>> Datumswert. Keine Termine, keine Datensätze.
>>> Du sprichst von einer Termindatenbank, ich von einem Kalender.
>> Einen Kalender, in dem Termine gespeichert werden sollen, implementiert
>> im Backend üblicherweise als Termindatenbank. Einen Kalender, der
>> "einfach nur da" ist, implementiert man *gar* *nicht* als Datenbank.
>
> Du sprichst von einer Termin*datenbank*, ich von einer Kalender*tabelle*.
> Ein Kalender ist eine *Tabelle* und keine *Datenbank*.
> Eine Termindatenbank kann allerdings ziemlich komplex sein mit diversen
> Tabellen.

Eine Kalendertabelle, d. h. eine Tabelle, die für jeden Tag einen Datensatz
hat, egal ob dazu Nutzdaten erfasst wurden, ist datenbanktechnisch
kompletter Blödsinn. Ende Gelände.

>>> Ausserdem, wie erstellt du denn aus der Termindatenbank eine Ausgabe mit
>>> allen Datumswerten (auch die, für die es kene Termine gibt) für einen
>>> bestimmten Bereich ohne einen Left Join auf einen Kalender?
>>
>> Gar nicht. Für den unwahrscheinlichen Fall, dass ich wissen muss, an
>> welchen Tagen es *keine* Termine gibt (der Normalfall ist das Gegenteil,
>> d. h. z. B. das Array der Termine für einen Tag an dem nichts los ist,
>> ist einfach leer), könnte ich zur Not immer noch einen JOIN machen.
>
> Ein "Array der Termine"? Sprichst du jetzt "SQL/Datenbank" oder PHP?

Datenbanken schweben nicht im leeren Raum. Zu jeder Datenbank gibt es eine
Programmiersprache, mit der darauf zugegriffen wird. Das ist bei MySQL in
der Regel PHP (LAMP und WAMP sind Begriffe für Dich?).

> Und wohin joinst du "zur Not"? Etwa zu einer Kalendertabelle?

Ja, die ich bei Bedarf für den in Frage kommenden Zeitraum erstellen würde
und nicht etwa für Jahre, Jahrzehnte oder gar Jahrhunderte im Voraus
erstellte.

>> Im Normalfall brauche ich dafür aber schon mal gar keine
>> Datenbankabfrage, denn wie gesagt, das Array für den jeweiligen Tag ist
>> leer (bzw. für den Tag gibt es gar kein Element im übergeordneten Array,
>> was un Abhängigkeit vom Zeitraum noch effizienter sein kann), da ich
>> zuvor die Arrays aller Tage im relevanten Zeitraum (z. B. aktuellen
>> Monat) mit den gespeicherten Terminen gefüllt habe.
>
> Ok, du sprichst doch von PHP o.ä., das tangiert mich äusserst peripher,
> ich dachte, hier wäre de.comp.*datenbanken*.mysql

Das hast Du also auch nicht verstanden.

>>>> Mit einer Stored Procedure bei Bedarf eine temporäre Tabelle zu
>>>> erstellen, die die Wochentage aller 14. speichert, dauert höchstens ein
>>>> Millionstel der Zeit, und benötigt einen ebensolchen Anteil
>>>> Speicherplatz, als eine wie auch immer geartete "Kalendertabelle".
>>>
>>> Willst du jedesmal, wenn "irgendsoeine" Datums-Berechnung gemacht werden
>>> soll, eine entsprechende SP ausführen, die auch noch passend geschrieben
>>> werden muss
>>
>> *Einmal* schreibt man die SP, und eher *selten* führt man sie aus, ja.
>
> Ich kenn das eher so, dass man eine SP schreibt, weil man sie *häufig*
> ausführen will.

Aber nicht diese.

>>> und die ich nicht joinen kann?
>>
>> Wie bitte? Die SP erstellt einfach eine Tabelle. Mit der kannst Du
>> machen was Du willst. Die SP kann so geschrieben werden, dass die
>> Tabelle, die sie erstellt, mehreren Use-Cases dient (z. B. speichere ich
>> nicht [nur] den Wochentag, sondern [auch gleich noch] das Datum). Und
>> für Spezialfälle erstellt man einfach eine zweite, dritte usw. SP. Die
>> erstellt man dann auch nur *einmal*.
>
> Auf eine SP kann ich nicht joinen (wobei es DBMSe gibt, die das auch
> können). Dass ich natürlich erstmal einen CALL machen kann und dann im
> nächsten Schritt auf die gerade erzeugte Tabelle zugreifen kann, ist
> aber was anderes.

Wenn Dir an Deinen ineffizienten JOINs so viel liegt, dann nimm eben einen
View, der auf eine von einer SP generierte allgemeine Tabelle zugreift.

> Und wenn du dann für die Use-Cases die Tabelle erweitert hast und für
> die Spezialfälle deine SPs weitere Tabellen angelegt haben, wirst du
> vielleicht feststellen, dass ein Kalender mit dem ganzen Zeug drin gar
> nicht so schlecht ist?

Werde ich nicht.

>> BTDT.
>>> Glaub ich dir.
>>> Dann bin ich wohl woanders gewesen, denn da ist dieser "grobe Unfug"
>>> Standard.
>> Das glaube ich Dir nicht. Nicht mal der Kalender von Rausguck (Exzess)
>> ist so abgrundtief bescheuert programmiert!
>
> Was hat der Outlook-Kalender damit zu tun?

Billiger geht es kaum, trotzdem hat man bei M$ anscheinend verstanden
(*leere* Kalender ergeben eine *kleine(re)* Datei). Du nicht.

> Wenn du mir nicht glauben willst, sollen wir dann unsere Kundenlisten
> rausholen und einen Längenvergleich machen?

Nicht nötig, denn ich bin an dieser Stelle schon mal froh, dass ich nicht
mit/bei Dir arbeiten muss. Und es ist bedauerlich, dass Deine Kunden durch
Dich mit diesem Ausmass an Inkompetenz in punkto Software-Entwicklung,
insbesondere Datenhaltung und -verarbeitung, gestraft sind.

[Dieter Nöth]

Thomas 'PointedEars' Lahn wrote:

> Den Wochentag lässt man ausrechnen, wenn man ihn braucht. Mit oder ohne
> Datenbankabfragesprache. Das ist wesentlich effizienter, als eine riesige
> Tabelle mit Kalenderdaten (aber ohne Nutzdaten) abzufragen und
> möglicherweise sogar mit dieser noch jedesmal zu joinen. Sowohl was
> Laufzeit als auch Speicherplatz betrifft.

Würdest du bitte einmal lesen, was ich geschrieben habe

>>> Zumal Kalender auch gern mal während der Lebensdauer einer Datenbank
>>> angepasst werden (Stichworte: "Sommerzeit", "Schaltsekunde").
>>
>> Bei einem Kalender mit Schaltsekunden oder der Sommerzeit zu
>> argumentieren ist schlicht Themaverfehlung, da ein Kalender auf der
>> Basis von Tagen aufgebaut ist.
>
> Mein Kalender speichert die Zeit für Termine. Wenn es bei Dir nur zur
> Entwicklung eines elektronischen Abreisskalenders reicht, ist das Dein
> Problem.

Du sprichst von einer speziellen Termindatenbank, ich von einer
generischen Kalendertabelle.

>> Übrigens, Wochennummer u.ä. werden während der Lebensdauer einer
>> Datenbank nicht angepasst, ich geh davon aus, dass 2012-01-13 auch in
>> übersehbarer Zukunft der zweite Freitag des Monats Januar in der
>> KW201202 bleiben wird.
>
> Das Jahr hat 52 oder 53 Kalenderwochen (KW). Was ist also "KW201202"?

Du implementierst einen Terminkalender ohne zu wissen, dass KW201002
(oder offiziell 2012W02 laut ISO/Standard SQL) die zweite Kalenderwoche
des Jahres 2012 ist? Glaub ich nicht.
Oder willst du damit zeigen, dass eine Wochennummer abhängig sein kann
von bestimmten Regeln? Dann lieferst du eher ein Argument für die Woche
als Spalte im Kalender. Bist du sicher, dass deine Anwender alle die
gleiche Definition von Wochennummer verwenden (und entsprechend die
passende YEARWEEK Option)?
Bei einem generischen Kalender ist genau definiert, was die Wochennummer
bedeutet.

>>>> Die eingebauten Datumsfunktionen sind ganz nett, wenn ich nur für die
>>>> Ausgabe eine Berechnung brauche.
>>> Wie kommst Du eigentlich darauf, dass hier etwas anderes gesucht war?
>>
>> Für mich ist "Ausgabe" = Spaltenliste im Select.
>> "wie viele Dienstage im Jahr auf den 14. fallen" ist aber eine Bedingung
>> und die gehört in's WHERE.
>
> Nein. Im WHERE-Ausdruck muss beim effizienten Ansatz nur der Ausdruck
> stehen, der nach den Dienstagen filtert.

Für einen effiziente Ansatz muss ein WHERE-Ausdruck SARGable (Search
ARGument ABLE) sein, dann kann der Optimizer nämlich einen potentiell
vorhandenen Index verwenden. Das bedeutet typischerweise eine Bedingung,
bei der auf der Spalte keine Berechnung gemacht wird.
"YEARWEEK(datum) = 201202" ist nicht SARGable, aber "datum BETWEEN DATE
'2012-01-09' AND DATE '2010-01-15'".
Beim Zugriff über einen Kalender steht kann der Optimizer jetzt diese 7
Datumswerte rausziehen und über einen Index auf die grosse Tabelle
zugreifen.

>>>> Bei einer Bedingung wie "Alle Daten aus der Wochen 2010W52" auf grossen
>>>> Datenmengen ist ein Join auf einen Kalender besser, der gibt vor allem
>>>> dem Optimizer Info über die Anzahl der Tage in dieser Woche, die er bei
>>>> einer direkten Berechnung nicht wissen kann. Dadurch kann er die
>>>> weiteren Arbeitschritte besser planen.
>>> Quatsch. JOINs sind so ziemlich die langsamsten Datenbankoperationen,
>>> die> es gibt. Insbesondere bei einer grossen Datenbasis.
>>
>> Nochmal, es ist hilfreich für den Optimizer, wenn er die Kardinalität
>> einer Bedingung kennt. Da Joins aufwendig sind, muss ein Optimizer aus
>> verschiedenen internen Möglichkeiten die auswählen, welche für diese
>> Datenmenge die effizienteste ist. Bei Berechnungen hat er aber Probleme,
>> diese Kardinalität abzuschätzen: solange er zuviele Rows annimmt, ist
>> das meist kein Problem, es gibt aber Jointypen, die sehr effizient bei
>> einer kleinen Datenmenge sind, aber bei grösseren Mengen absolut mies.
>> Und das ist vor allem bei grosser Datenbasis wichtig.
>
> Und deshalb lässt man diesen Unfug von vornherein bleiben. Dann muss
> nämlich auch nichts optimiert werden, was vorher schlecht gemacht wurde.

Was meinst du jetzt mit "Unfug"?
Dass man versucht, dem Optimizer die Arbeit etwas leichter zu machen?
Oder dass man ihm einfach jede Möglichkeit zur Optimierung nimmt und er
dann unabhängig von der Anzahl der Rows einfach immer einen Full Table
Scan machen muss?

>>> JOINs *vermeidet* man (es sei denn, sie dienen der Effizienz gegenüber
>>> WHERE-Ausdrücken),
>>
>> Meinst du WHERE mit (korrelierten) Subqueries?
>
> Ja.
>
>> Die sind je nach DBMS und Fragestellung sogar effizienter als Joins.
>
> Wir diskutieren hier aber nicht über irgendein DBMS.

Nein, wir diskutieren über eine generische Kalendertabelle.

>>> und provoziert sie nicht noch zusätzlich durch derart extremen Overhead!
>>>
>>>>> Anders formuliert: In einer
>>>>> Termindatenbank erstellt man _nicht_ für jedes mögliche Datum einen
>>>>> Datensatz und befüllt den bei Vorliegen eines Termins mit Textdaten,
>>>>> sondern man erstellt für jeden *Termin* einen Datensatz mit dem
>>>>> entsprechenden
>>>>> Datumswert. Keine Termine, keine Datensätze.
>>>> Du sprichst von einer Termindatenbank, ich von einem Kalender.
>>> Einen Kalender, in dem Termine gespeichert werden sollen, implementiert
>>> im Backend üblicherweise als Termindatenbank. Einen Kalender, der
>>> "einfach nur da" ist, implementiert man *gar* *nicht* als Datenbank.
>>
>> Du sprichst von einer Termin*datenbank*, ich von einer Kalender*tabelle*.
>> Ein Kalender ist eine *Tabelle* und keine *Datenbank*.
>> Eine Termindatenbank kann allerdings ziemlich komplex sein mit diversen
>> Tabellen.
>
> Eine Kalendertabelle, d. h. eine Tabelle, die für jeden Tag einen Datensatz
> hat, egal ob dazu Nutzdaten erfasst wurden, ist datenbanktechnisch
> kompletter Blödsinn. Ende Gelände.

Kannst du nicht akzeptieren, dass es auch Umgebungen geben kann, wo das
sinnvoll ist?
Nimm z.B. den Data Warehouse Bereich.
Oder die BI-Tools (Microstrategy, Business Objects, etc.), die
*brauchen* einen generischen Kalender.

>>>> Ausserdem, wie erstellt du denn aus der Termindatenbank eine Ausgabe mit
>>>> allen Datumswerten (auch die, für die es kene Termine gibt) für einen
>>>> bestimmten Bereich ohne einen Left Join auf einen Kalender?
>>>
>>> Gar nicht. Für den unwahrscheinlichen Fall, dass ich wissen muss, an
>>> welchen Tagen es *keine* Termine gibt (der Normalfall ist das Gegenteil,
>>> d. h. z. B. das Array der Termine für einen Tag an dem nichts los ist,
>>> ist einfach leer), könnte ich zur Not immer noch einen JOIN machen.
>>
>> Ein "Array der Termine"? Sprichst du jetzt "SQL/Datenbank" oder PHP?
>
> Datenbanken schweben nicht im leeren Raum. Zu jeder Datenbank gibt es eine
> Programmiersprache, mit der darauf zugegriffen wird. Das ist bei MySQL in

> der Regel PHP.

Die primäre Programmiersprache für Datenbanken ist SQL und auch PHP
greift darüber zu.

> (LAMP und WAMP sind Begriffe für Dich?)

Fehlt da nicht noch ein "E"?

Selbst MySQL läuft nicht immer nur auf'm Webserver.

>> Und wohin joinst du "zur Not"? Etwa zu einer Kalendertabelle?
>
> Ja, die ich bei Bedarf für den in Frage kommenden Zeitraum erstellen würde
> und nicht etwa für Jahre, Jahrzehnte oder gar Jahrhunderte im Voraus
> erstellte.
>
>>> Im Normalfall brauche ich dafür aber schon mal gar keine
>>> Datenbankabfrage, denn wie gesagt, das Array für den jeweiligen Tag ist
>>> leer (bzw. für den Tag gibt es gar kein Element im übergeordneten Array,
>>> was un Abhängigkeit vom Zeitraum noch effizienter sein kann), da ich
>>> zuvor die Arrays aller Tage im relevanten Zeitraum (z. B. aktuellen
>>> Monat) mit den gespeicherten Terminen gefüllt habe.

Wieso brauchst du eigentlich noch eine Datenbank, wenn du eh alles in
PHP machst? Für einen Terminkalender reicht doch einfach ein Flatfile.

>> Ok, du sprichst doch von PHP o.ä., das tangiert mich äusserst peripher,
>> ich dachte, hier wäre de.comp.*datenbanken*.mysql
>
> Das hast Du also auch nicht verstanden.

Dass es im Usenet in der Hierarchy um bestimmte Themen geht?
...

> Nicht nötig, denn ich bin an dieser Stelle schon mal froh, dass ich nicht
> mit/bei Dir arbeiten muss. Und es ist bedauerlich, dass Deine Kunden durch
> Dich mit diesem Ausmass an Inkompetenz in punkto Software-Entwicklung,
> insbesondere Datenhaltung und -verarbeitung, gestraft sind.

Darf ich dich mal zitieren aus einem älteren Post?
"Argumentum ad hominem."
Und zwar schon mehrfach.

Schade, dass du nicht auf den Rest meines Posts geantwortet hast.

Dieter

[Dieter Nöth]

Thomas 'PointedEars' Lahn wrote:

> Für 3'000 Jahre sind es hierfür theoretisch nur 36'000 Datensätze.

Komisch, bei mir sprichst du von "gigabyteweise" Daten für 800 Jahre und
hier kommst du auf 36000 Rows für 3000 Jahre?
Das wären Monate, bei Tagen sind es > 1.000.000.

> Übrigens
> gibt es im Gregorianischen Kalender kein Jahr 0. Auch fand die
> entsprechende Kalenderreform im Jahr 1582 nach jener Zeitrechnung statt.
> genaue Datumsangaben im Gregorianischen Kalender vor dem Freitag, 15.
> Oktober 1582 sind daher nicht sinnvoll (es gibt die gregorianischen Daten
> vom 5. bis 14. Oktober 1582 schlicht nicht).

In Deutschland gibt es die schon, selbst die Katholen haben erst im
Laufe der nächsten Jahre umgestellt und die Protestanten haben noch
einiges länger gebraucht.

Dieter

[Gustaf Mossakowski]

Thomas 'PointedEars' Lahn schrieb:

> Auch fand die
> entsprechende Kalenderreform im Jahr 1582 nach jener Zeitrechnung statt.
> genaue Datumsangaben im Gregorianischen Kalender vor dem Freitag, 15.
> Oktober 1582 sind daher nicht sinnvoll (es gibt die gregorianischen Daten
> vom 5. bis 14. Oktober 1582 schlicht nicht).

Natürlich gibt es diese Daten im gregorianischen Kalender. Der 14.
Oktober 1582 im gregorianischen Kalender entspricht dem 4. Oktober 1582
im julianischen Kalender. Was Du vermutlich meinst, ist, dass es in der
Lebenswirklichkeit derjenigen Menschen, die damals in einem Land lebten,
diese Daten nicht gab, da von dem einen auf den anderen Kalender
umgestellt wurde. Das ist aber etwas anderes.

Man kann ältere Daten umrechnen, gerade wenn man solche Daten in einer
Datenbank speichern möchte. Sonst wird es sehr schwierig, Ereignisse an
gleichen Tagen abzufragen. Sinnvoll kann es sein, in einem Feld das
lokale Datum, in dem anderen ein standardisiertes gregorianisches Datum
zu speichern. Ein bekanntes Beispiel für die Abweichungen ist die
Oktoberrevolution in Rußland, die nach julianischem Kalender im Oktober,
nach gregorianischem aber erst im November stattfand.

Das Datum ist auch heute noch weltweit uneinheitlich. In Israel wird
gerade das Jahr 5772 geschrieben, in Afghanistan 1390. Man sollte daher
immer aufpassen, an welchem Ort ein Datum beschrieben wurde.

> Wie wäre es, wenn Du Dich zur Abwechslung mal *vorher* informiertest?

Glashaus, Steine?

Viele Grüße, Gustaf

[Peter J. Holzer]

On 2012-01-14 11:07, Dieter Nöth <dno...@gmx.de> wrote:
>> Übrigens
>> gibt es im Gregorianischen Kalender kein Jahr 0.

Es gibt nicht einmal ein Jahr 1581 ;-).

>> Auch fand die entsprechende Kalenderreform im Jahr 1582 nach jener
>> Zeitrechnung statt. genaue Datumsangaben im Gregorianischen Kalender
>> vor dem Freitag, 15. Oktober 1582 sind daher nicht sinnvoll (es gibt
>> die gregorianischen Daten vom 5. bis 14. Oktober 1582 schlicht

^^^^^^^^^^^^^^^^^^^^^^^^^

>> nicht).
>
> In Deutschland gibt es die schon, selbst die Katholen haben erst im
> Laufe der nächsten Jahre umgestellt und die Protestanten haben noch
> einiges länger gebraucht.

Das sind dann aber keine gregorianischen Daten, sondern julianische.
Zwischen 1582 und 1917[1] sind daher historische Datumsangaben nicht
eindeutig, weil sie vom verwendeten Kalender abhängen.

Daneben gibt es natürlich noch den proleptischen gregorianischen
Kalender, der dadurch zustandekommt, dass man den gregorianischen
Kalender rückwärtsrechnet. Genauer gesagt, es gibt zwei Varianten davon,
eine mit Jahr 0 und eine ohne. Der proleptische gregorianische Kalender
wird aber normalerweise nicht für historische Daten verwendet.

hp

[1] Irgendwie habe ich im Kopf, dass es ein europäisches Land gegeben
hat, das erst 1927 vom Julianischen auf den Gregorianischen Kalender
umgestellt hat, aber das finde ich im Moment nicht.


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org

[Dieter Nöth]

Peter J. Holzer wrote:

>> In Deutschland gibt es die schon, selbst die Katholen haben erst im
>> Laufe der nächsten Jahre umgestellt und die Protestanten haben noch
>> einiges länger gebraucht.
>
> Das sind dann aber keine gregorianischen Daten, sondern julianische.

Stimmt natürlich, das sollte sich auf die "genauen Datumsangaben vor dem
15. Oktober 1582" beziehen, und also bedeuten:

> Zwischen 1582 und 1917[1] sind daher historische Datumsangaben nicht
> eindeutig, weil sie vom verwendeten Kalender abhängen.

...

> [1] Irgendwie habe ich im Kopf, dass es ein europäisches Land gegeben
> hat, das erst 1927 vom Julianischen auf den Gregorianischen Kalender
> umgestellt hat, aber das finde ich im Moment nicht.

Das war die Türkei, zumindest ein Teil davon liegt in Europa :-)

Alles, was der nicht-Kalenderforscher vermutlich braucht
http://www.tondering.dk/claus/calendar.html

Dieter

[Gustaf Mossakowski]

Peter J. Holzer schrieb:

> Das sind dann aber keine gregorianischen Daten, sondern julianische.
> Zwischen 1582 und 1917[1] sind daher historische Datumsangaben nicht
> eindeutig, weil sie vom verwendeten Kalender abhängen.
>

> [...]

>
> [1] Irgendwie habe ich im Kopf, dass es ein europäisches Land gegeben
> hat, das erst 1927 vom Julianischen auf den Gregorianischen Kalender
> umgestellt hat, aber das finde ich im Moment nicht.

Ohne Gewähr für Richtigkeit, aber ein paar Länder nach 1917 finden sich
in dem Wikipedia-Artikel unter
<http://de.wikipedia.org/wiki/Gregorianischer_Kalender> (Türkei 1926,
Griechenland 1923). Die orthodoxe Kirche verwendet den julianischen
Kalender teilweise heute noch, daher ist dort Ostern und Weihnachten ein
paar Tage später.

> Daneben gibt es natürlich noch den proleptischen gregorianischen
> Kalender, der dadurch zustandekommt, dass man den gregorianischen
> Kalender rückwärtsrechnet. Genauer gesagt, es gibt zwei Varianten davon,
> eine mit Jahr 0 und eine ohne. Der proleptische gregorianische Kalender
> wird aber normalerweise nicht für historische Daten verwendet.

Auch nicht zum Speichern? Wir haben konkret bei einem Projekt das
Problem, dass wir Daten aus Afghanistan korrekt umrechnen müssen und
überlegen, wie wir das Datum speichern. Bei Publikationen ist es
besonders kompliziert, da hier meist nur das Jahr angegeben wird, in dem
die Publikation erscheint. Da die Jahre nicht deckungsgleich sind,
müsste man entweder recherchieren, wann genau ein Artikel oder ein Buch
etc. erschienen ist. Das ist aber oft nicht möglich. Oder man schreibt
2011/2012 für das aktuelle afghanische Jahr. Das wiederum ist schlecht
in ein Feld des Typs DATE oder YEAR einzutragen.

Viele Grüße, Gustaf

[Thomas 'PointedEars' Lahn]

Dieter Nöth wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Für 3'000 Jahre sind es hierfür theoretisch nur 36'000 Datensätze.
>
> Komisch, bei mir sprichst du von "gigabyteweise" Daten für 800 Jahre

Für einen *vollständigen* Kalender.

> und hier kommst du auf 36000 Rows für 3000 Jahre?
> Das wären Monate, bei Tagen sind es > 1.000.000.

In diesem Fall müssen nicht alle Tage in Betracht gezogen werden, sondern
nur die mit Datum 14. In jedem Jahr gibt es 12 solcher Tage, in 3000 Jahren
folglich 36'000.

>> Übrigens gibt es im Gregorianischen Kalender kein Jahr 0. Auch fand die
>> entsprechende Kalenderreform im Jahr 1582 nach jener Zeitrechnung statt.
>> genaue Datumsangaben im Gregorianischen Kalender vor dem Freitag, 15.
>> Oktober 1582 sind daher nicht sinnvoll (es gibt die gregorianischen Daten
>> vom 5. bis 14. Oktober 1582 schlicht nicht).
>
> In Deutschland gibt es die schon, selbst die Katholen haben erst im
> Laufe der nächsten Jahre umgestellt und die Protestanten haben noch
> einiges länger gebraucht.

Es heisst _Katholiken_, und Du hast keine Ahnung.

[Thomas 'PointedEars' Lahn]

Gustaf Mossakowski wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Auch fand die entsprechende Kalenderreform im Jahr 1582 nach jener
>> Zeitrechnung statt.
>> genaue Datumsangaben im Gregorianischen Kalender vor dem Freitag, 15.
>> Oktober 1582 sind daher nicht sinnvoll (es gibt die gregorianischen Daten
>> vom 5. bis 14. Oktober 1582 schlicht nicht).
>
> Natürlich gibt es diese Daten im gregorianischen Kalender.

Nein. Die päpstliche Bulle "Inter gravissimas", welche die Gregorianische
Kalenderreform kodifiziert, schreibt vor, dass auf Donnerstag, 4. Oktober
A.D. 1582 (jul.) der Freitag, 15. Oktober A.D. 1582 (greg.) folgt.

> Der 14. Oktober 1582 im gregorianischen Kalender entspricht dem 4. Oktober
> 1582 im julianischen Kalender.

Fchsal.

Es gibt das Datum "14. Oktober 1582" im Gregorianischen Kalender nicht und
genaugenommen auch *keine* Daten davor. Was Du möglicherweise meinst, ist
jenes Datum im *proleptischen* Gregorianischen Kalender. Bei diesem findet
jedoch *keine* Konvertierung von Daten statt, sondern man verwendet einfach
das Julianische Datum als proleptisches Gregorianisches Datum.

> Was Du vermutlich meinst, ist, dass es in der Lebenswirklichkeit
> derjenigen Menschen, die damals in einem Land lebten,
> diese Daten nicht gab, da von dem einen auf den anderen Kalender
> umgestellt wurde. Das ist aber etwas anderes.

Du möchtest lesen lernen und und Dich mal *wirklich* informieren gehen.

[Thomas 'PointedEars' Lahn]

Dieter Nöth wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Den Wochentag lässt man ausrechnen, wenn man ihn braucht. Mit oder ohne
>> Datenbankabfragesprache. Das ist wesentlich effizienter, als eine
>> riesige Tabelle mit Kalenderdaten (aber ohne Nutzdaten) abzufragen und
>> möglicherweise sogar mit dieser noch jedesmal zu joinen. Sowohl was
>> Laufzeit als auch Speicherplatz betrifft.
>
> Würdest du bitte einmal lesen, was ich geschrieben habe

BTDT. Ist immer noch Blödsinn.

>>>> Zumal Kalender auch gern mal während der Lebensdauer einer Datenbank
>>>> angepasst werden (Stichworte: "Sommerzeit", "Schaltsekunde").
>>>
>>> Bei einem Kalender mit Schaltsekunden oder der Sommerzeit zu
>>> argumentieren ist schlicht Themaverfehlung, da ein Kalender auf der
>>> Basis von Tagen aufgebaut ist.
>>
>> Mein Kalender speichert die Zeit für Termine. Wenn es bei Dir nur zur
>> Entwicklung eines elektronischen Abreisskalenders reicht, ist das Dein
>> Problem.
>
> Du sprichst von einer speziellen Termindatenbank, ich von einer
> generischen Kalendertabelle.

Die Blödsinn ist.

>>> Übrigens, Wochennummer u.ä. werden während der Lebensdauer einer
>>> Datenbank nicht angepasst, ich geh davon aus, dass 2012-01-13 auch in
>>> übersehbarer Zukunft der zweite Freitag des Monats Januar in der
>>> KW201202 bleiben wird.
>> Das Jahr hat 52 oder 53 Kalenderwochen (KW). Was ist also "KW201202"?
>
> Du implementierst einen Terminkalender ohne zu wissen, dass KW201002
> (oder offiziell 2012W02 laut ISO/Standard SQL) die zweite Kalenderwoche
> des Jahres 2012 ist?

"KW201202" ist lediglich Getrol^W eine Erfindung von Dir. Es wäre die
übliche Schreibweise für die 201202. Kalenderwoche, was aber Unsinn ist.
Korrekt ist entweder die von Dir jetzt nachgeschobene ISO-Schreibweise oder
"KW2(,) 2012". Daher die Frage.

>>>>> Die eingebauten Datumsfunktionen sind ganz nett, wenn ich nur für die
>>>>> Ausgabe eine Berechnung brauche.
>>>> Wie kommst Du eigentlich darauf, dass hier etwas anderes gesucht war?
>>> Für mich ist "Ausgabe" = Spaltenliste im Select.
>>> "wie viele Dienstage im Jahr auf den 14. fallen" ist aber eine Bedingung
>>> und die gehört in's WHERE.
>> Nein. Im WHERE-Ausdruck muss beim effizienten Ansatz nur der Ausdruck
>> stehen, der nach den Dienstagen filtert.
>
> Für einen effiziente Ansatz muss ein WHERE-Ausdruck SARGable (Search
> ARGument ABLE) sein, dann kann der Optimizer nämlich einen potentiell
> vorhandenen Index verwenden. Das bedeutet typischerweise eine Bedingung,
> bei der auf der Spalte keine Berechnung gemacht wird.
> "YEARWEEK(datum) = 201202" ist nicht SARGable,

Der Ansatz ist ja auch Blödsinn.

> aber "datum BETWEEN DATE '2012-01-09' AND DATE '2010-01-15'".
> Beim Zugriff über einen Kalender steht kann der Optimizer jetzt diese 7
> Datumswerte rausziehen und über einen Index auf die grosse Tabelle
> zugreifen.

Dafür braucht man aber keine Kalendertabelle, sondern nur eine
Programmiersprache, welche zu einer Kalenderwoche die Daten ausrechnet und
die Abfrage entsprechend formuliert.

>>>>> Bei einer Bedingung wie "Alle Daten aus der Wochen 2010W52" auf
>>>>> grossen Datenmengen ist ein Join auf einen Kalender besser, der gibt
>>>>> vor allem dem Optimizer Info über die Anzahl der Tage in dieser Woche,
>>>>> die er bei einer direkten Berechnung nicht wissen kann. Dadurch kann
>>>>> er die weiteren Arbeitschritte besser planen.
>>>> Quatsch. JOINs sind so ziemlich die langsamsten Datenbankoperationen,
>>>> die> es gibt. Insbesondere bei einer grossen Datenbasis.
>>>
>>> Nochmal, es ist hilfreich für den Optimizer, wenn er die Kardinalität
>>> einer Bedingung kennt. Da Joins aufwendig sind, muss ein Optimizer aus
>>> verschiedenen internen Möglichkeiten die auswählen, welche für diese
>>> Datenmenge die effizienteste ist. Bei Berechnungen hat er aber Probleme,
>>> diese Kardinalität abzuschätzen: solange er zuviele Rows annimmt, ist
>>> das meist kein Problem, es gibt aber Jointypen, die sehr effizient bei
>>> einer kleinen Datenmenge sind, aber bei grösseren Mengen absolut mies.
>>> Und das ist vor allem bei grosser Datenbasis wichtig.
>>
>> Und deshalb lässt man diesen Unfug von vornherein bleiben. Dann muss
>> nämlich auch nichts optimiert werden, was vorher schlecht gemacht wurde.
>
> Was meinst du jetzt mit "Unfug"?

Deine Kalendertabelle.

>>> Die sind je nach DBMS und Fragestellung sogar effizienter als Joins.
>> Wir diskutieren hier aber nicht über irgendein DBMS.
>
> Nein, wir diskutieren über eine generische Kalendertabelle.

Im Kontext von MySQL. Aber ich bezweifle, dass sich die Effizienz von
anderen relationalen DBMS bei diesem Ansatz wesentlich unterscheidet.

>>>>>> Anders formuliert: In einer
>>>>>> Termindatenbank erstellt man _nicht_ für jedes mögliche Datum einen
>>>>>> Datensatz und befüllt den bei Vorliegen eines Termins mit Textdaten,
>>>>>> sondern man erstellt für jeden *Termin* einen Datensatz mit dem
>>>>>> entsprechenden
>>>>>> Datumswert. Keine Termine, keine Datensätze.
>>>>> Du sprichst von einer Termindatenbank, ich von einem Kalender.
>>>> Einen Kalender, in dem Termine gespeichert werden sollen, implementiert
>>>> im Backend üblicherweise als Termindatenbank. Einen Kalender, der
>>>> "einfach nur da" ist, implementiert man *gar* *nicht* als Datenbank.
>>>
>>> Du sprichst von einer Termin*datenbank*, ich von einer
>>> Kalender*tabelle*. Ein Kalender ist eine *Tabelle* und keine
>>> *Datenbank*. Eine Termindatenbank kann allerdings ziemlich komplex sein
>>> mit diversen Tabellen.
>>
>> Eine Kalendertabelle, d. h. eine Tabelle, die für jeden Tag einen
>> Datensatz hat, egal ob dazu Nutzdaten erfasst wurden, ist
>> datenbanktechnisch
>> kompletter Blödsinn. Ende Gelände.
>
> Kannst du nicht akzeptieren, dass es auch Umgebungen geben kann, wo das
> sinnvoll ist?

Ohne überzeugendes Beispiel: Nein.

> Nimm z.B. den Data Warehouse Bereich.
> Oder die BI-Tools (Microstrategy, Business Objects, etc.), die
> *brauchen* einen generischen Kalender.

Zeig doch mal.

>>>>> Ausserdem, wie erstellt du denn aus der Termindatenbank eine Ausgabe
>>>>> mit allen Datumswerten (auch die, für die es kene Termine gibt) für
>>>>> einen bestimmten Bereich ohne einen Left Join auf einen Kalender?
>>>> Gar nicht. Für den unwahrscheinlichen Fall, dass ich wissen muss, an
>>>> welchen Tagen es *keine* Termine gibt (der Normalfall ist das
>>>> Gegenteil, d. h. z. B. das Array der Termine für einen Tag an dem
>>>> nichts los ist, ist einfach leer), könnte ich zur Not immer noch einen
>>>> JOIN machen.
>>> Ein "Array der Termine"? Sprichst du jetzt "SQL/Datenbank" oder PHP?
>>
>> Datenbanken schweben nicht im leeren Raum. Zu jeder Datenbank gibt es
>> eine Programmiersprache, mit der darauf zugegriffen wird. Das ist bei
>> MySQL in der Regel PHP.
>
> Die primäre Programmiersprache für Datenbanken ist SQL und auch PHP
> greift darüber zu.

Autsch! SQL ist _keine_ Programmiersprache, sondern eine Datenbanksprache!

> > (LAMP und WAMP sind Begriffe für Dich?)
>
> Fehlt da nicht noch ein "E"?

Du hast also tatsächlich keine Ahnung.

> Selbst MySQL läuft nicht immer nur auf'm Webserver.

q.e.d.

>>>> Im Normalfall brauche ich dafür aber schon mal gar keine
>>>> Datenbankabfrage, denn wie gesagt, das Array für den jeweiligen Tag ist
>>>> leer (bzw. für den Tag gibt es gar kein Element im übergeordneten
>>>> Array, was un Abhängigkeit vom Zeitraum noch effizienter sein kann), da
>>>> ich zuvor die Arrays aller Tage im relevanten Zeitraum (z. B. aktuellen
>>>> Monat) mit den gespeicherten Terminen gefüllt habe.
>
> Wieso brauchst du eigentlich noch eine Datenbank, wenn du eh alles in
> PHP machst?

Persistente Speicherung, effizienter Zugriff, Trennung von Logik und Daten?

> Für einen Terminkalender reicht doch einfach ein Flatfile.

Du würdest das bestimmt tun.

>>> Ok, du sprichst doch von PHP o.ä., das tangiert mich äusserst peripher,
>>> ich dachte, hier wäre de.comp.*datenbanken*.mysql
>>
>> Das hast Du also auch nicht verstanden.
>
> Dass es im Usenet in der Hierarchy um bestimmte Themen geht?

Nein, dass PHP und MySQL, oder allgemeiner Programmiersprachen und SQL
zusammengehören.

[Dieter Nöth]

Thomas 'PointedEars' Lahn wrote:

> BTDT. Ist immer noch Blödsinn.

...
> Die Blödsinn ist.
...

> Der Ansatz ist ja auch Blödsinn.

...

>>> Und deshalb lässt man diesen Unfug von vornherein bleiben.

...

> Im Kontext von MySQL. Aber ich bezweifle, dass sich die Effizienz von
> anderen relationalen DBMS bei diesem Ansatz wesentlich unterscheidet.

Das merke ich.

>>> kompletter Blödsinn. Ende Gelände.

Mit dir kann man toll diskutieren.

>> Kannst du nicht akzeptieren, dass es auch Umgebungen geben kann, wo das
>> sinnvoll ist?
>
> Ohne überzeugendes Beispiel: Nein.
>
>> Nimm z.B. den Data Warehouse Bereich.
>> Oder die BI-Tools (Microstrategy, Business Objects, etc.), die
>> *brauchen* einen generischen Kalender.
>
> Zeig doch mal.

Was? Ein Data Warehouse? Das sind einfach viele Racks voll mit Servern
und gaaanz vielen Platten tief unten im Rechenzentrum, da kommt man ohne
Genehmigung und Anmeldung meistens nicht rein:
http://www.zdnet.com/blog/storage/what-is-apples-huge-data-warehouse-for/1397

BI-Tools und DWH gehören meistens zusammen und auch wenn du es immer
noch nicht hören willst, da ist eine Kalenderdimension (date dimension)
üblich:
http://en.wikipedia.org/wiki/Dimension_%28data_warehouse%29#Common_patterns

...

>> Die primäre Programmiersprache für Datenbanken ist SQL und auch PHP
>> greift darüber zu.
>
> Autsch! SQL ist _keine_ Programmiersprache, sondern eine Datenbanksprache!

SQL ist eine deklarative Programmiersprache:
http://de.wikipedia.org/wiki/Programmiersprachen#Deklarative_Programmiersprachen

>>> (LAMP und WAMP sind Begriffe für Dich?)
>>
>> Fehlt da nicht noch ein "E"?
>
> Du hast also tatsächlich keine Ahnung.

Du brauchst da echt ein Smiley? Ich dachte die nächste Zeile reicht:

>> Selbst MySQL läuft nicht immer nur auf'm Webserver.
>
> q.e.d.

Was wäre jetzt bewiesen?
Das ich keine Ahnung habe?
Oder das MySQL nicht immer auf'm Webserver läuft?
Du hast doch mit _AMP angefangen und das heisst Webserver:
http://en.wikipedia.org/wiki/LAMP_%28software_bundle%29

Dieter

[Gustaf Mossakowski]

Thomas 'PointedEars' Lahn schrieb:

> Gustaf Mossakowski wrote:
>> Der 14. Oktober 1582 im gregorianischen Kalender entspricht dem 4.
>> Oktober 1582 im julianischen Kalender.
>
> Fchsal.
>
> Es gibt das Datum "14. Oktober 1582" im Gregorianischen Kalender nicht und
> genaugenommen auch *keine* Daten davor.

Wenn du das so siehst, verstehe ich deinen expliziten Hinweis, dass es
im Gregorianischen Kalender das Jahr 0 und die Daten vom 5. bis 14.
Oktober 1582 nicht gäbe, nicht. Kann es dann ja auch gar nicht geben.
Worüber reden wir hier denn? Über päpstliche Bullen oder die Speicherung
von Daten in Datenbanken? Erstere gehören sicher nicht in
de.comp.datenbanken.mysql. Nach ersterer gibt es diese Daten nicht, das
ist richtig. Aber:

> Was Du möglicherweise meinst, ist
> jenes Datum im *proleptischen* Gregorianischen Kalender.

Natürlich meine ich den. Wir reden ja über MySQL:

| 11.8. What Calendar Is Used By MySQL?
| MySQL uses what is known as a proleptic Gregorian calendar.
<http://dev.mysql.com/doc/refman/5.5/en/mysql-calendar.html>

> Bei diesem findet
> jedoch *keine* Konvertierung von Daten statt, sondern man verwendet einfach
> das Julianische Datum als proleptisches Gregorianisches Datum.

Nein, das hast du falsch verstanden. Weiter aus der obigen Quelle:

| Thus, if we assume there was never a cutover and Gregorian rules
| always rule, we have a proleptic Gregorian calendar. This is what is
| used by MySQL, as is required by standard SQL. For this reason, dates
| prior to the cutover stored as MySQL DATE or DATETIME values must be
| adjusted to compensate for the difference.

Dasselbe steht in DIN ISO 8601:2006-09, Seite 17:

| Der Gregorianische Kalender wurde am 15. Oktober 1582 eingeführt. Im
| Kalender, der durch die Norm festgelegt wird, ist der Kalendertag vor
| diesem Datum der 14. Oktober 1582. Im Julianischen Kalender ist dieser
| Kalendertag der 4. Oktober 1582.

Noch ein Hinweis: laß bitte deine persönlichen Kritteleien (»Du möchtest
lesen lernen«) weg.

Viele Grüße, Gustaf

[Peter J. Holzer]

On 2012-01-14 14:40, Dieter Nöth <dno...@gmx.de> wrote:

> Peter J. Holzer wrote:
>> Zwischen 1582 und 1917[1] sind daher historische Datumsangaben nicht
>> eindeutig, weil sie vom verwendeten Kalender abhängen.
> ...
>> [1] Irgendwie habe ich im Kopf, dass es ein europäisches Land gegeben
>> hat, das erst 1927 vom Julianischen auf den Gregorianischen Kalender
>> umgestellt hat, aber das finde ich im Moment nicht.
>
> Das war die Türkei, zumindest ein Teil davon liegt in Europa :-)

Nein, die hat vom islamischen auf den gregorianischen Kalender
umgestellt. Ich meinte vermutlich Griechenland (1923).

hp

[Peter J. Holzer]

On 2012-01-14 14:42, Gustaf Mossakowski <gus...@gmx.de> wrote:
> Peter J. Holzer schrieb:
>> Das sind dann aber keine gregorianischen Daten, sondern julianische.
>> Zwischen 1582 und 1917[1] sind daher historische Datumsangaben nicht
>> eindeutig, weil sie vom verwendeten Kalender abhängen.
>>
>> [...]
>>
>> [1] Irgendwie habe ich im Kopf, dass es ein europäisches Land gegeben
>> hat, das erst 1927 vom Julianischen auf den Gregorianischen Kalender
>> umgestellt hat, aber das finde ich im Moment nicht.
>
> Ohne Gewähr für Richtigkeit, aber ein paar Länder nach 1917 finden sich
> in dem Wikipedia-Artikel unter
><http://de.wikipedia.org/wiki/Gregorianischer_Kalender>

Argh, die Tabelle ist verrutscht (sie steht im Kapitel "Jahresanfang"
statt "Verbreitung"). Ich habe sie daher nicht gesehen.


> (Türkei 1926,

Vorher islamischer Kalender.

> Griechenland 1923).

Vermutlich meinte ich die.

>> Daneben gibt es natürlich noch den proleptischen gregorianischen
>> Kalender, der dadurch zustandekommt, dass man den gregorianischen
>> Kalender rückwärtsrechnet. Genauer gesagt, es gibt zwei Varianten davon,
>> eine mit Jahr 0 und eine ohne. Der proleptische gregorianische Kalender
>> wird aber normalerweise nicht für historische Daten verwendet.
>
> Auch nicht zum Speichern?

Speichern kannst Du natürlich, was Du willst (Sekunden vor/nach 1970,
Tage nach Erschaffung der Welt, Maya-Kalender, ...).

Aber wenn Du Wert darauf legst, dass die Schlacht von Hastings am 14.
Oktober 1066 stattgefunden hat, dann musst Du für die Anzeige
entsprechend umrechnen.

Bei MySQL wirst Du das ohnehin müssen, denn das verwendet intern den
proleptischen gregorianischen Kalender. (Wenn Du keine Datumsarithmetik
verwendest, kannst Du den Unterschied natürlich ignorieren)

> Wir haben konkret bei einem Projekt das Problem, dass wir Daten aus
> Afghanistan korrekt umrechnen müssen und überlegen, wie wir das Datum
> speichern. Bei Publikationen ist es besonders kompliziert, da hier
> meist nur das Jahr angegeben wird, in dem die Publikation erscheint.
> Da die Jahre nicht deckungsgleich sind, müsste man entweder
> recherchieren, wann genau ein Artikel oder ein Buch etc. erschienen
> ist. Das ist aber oft nicht möglich. Oder man schreibt 2011/2012 für
> das aktuelle afghanische Jahr. Das wiederum ist schlecht in ein Feld
> des Typs DATE oder YEAR einzutragen.

Hmm, das passt natürlich sehr schlecht. Da würde ich dann entweder
jeweils den Jahresanfang nehmen (also islamisches Jahr 1386 ==
2007-03-21) oder ein Intervall angeben (2007-03-21, 2008-03-19), oder
schlicht das islamische Datum plus Kalenderart (und rechnet dann on the
fly um, wenn notwendig). Kommt halt darauf an, was man mit dem Datum
machen will.

hp

[Peter J. Holzer]

On 2012-01-14 16:49, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> Gustaf Mossakowski wrote:
>> Thomas 'PointedEars' Lahn schrieb:
>>> Auch fand die entsprechende Kalenderreform im Jahr 1582 nach jener
>>> Zeitrechnung statt.
>>> genaue Datumsangaben im Gregorianischen Kalender vor dem Freitag, 15.
>>> Oktober 1582 sind daher nicht sinnvoll (es gibt die gregorianischen Daten
>>> vom 5. bis 14. Oktober 1582 schlicht nicht).
>>
>> Natürlich gibt es diese Daten im gregorianischen Kalender.
>
> Nein. Die päpstliche Bulle "Inter gravissimas", welche die Gregorianische
> Kalenderreform kodifiziert, schreibt vor, dass auf Donnerstag, 4. Oktober
> A.D. 1582 (jul.) der Freitag, 15. Oktober A.D. 1582 (greg.) folgt.

Korrekt.

>> Der 14. Oktober 1582 im gregorianischen Kalender entspricht dem 4. Oktober
>> 1582 im julianischen Kalender.
>
> Fchsal.
>
> Es gibt das Datum "14. Oktober 1582" im Gregorianischen Kalender nicht und
> genaugenommen auch *keine* Daten davor. Was Du möglicherweise meinst, ist
> jenes Datum im *proleptischen* Gregorianischen Kalender. Bei diesem findet
> jedoch *keine* Konvertierung von Daten statt, sondern man verwendet einfach
> das Julianische Datum als proleptisches Gregorianisches Datum.

Quelle? Meines Wissens ist das falsch. Beim proleptischen
gregorianischen Kalender ist der Tag vor dem 15.10.1582 der 14.10.1582
und der Tag vor dem 1.3.1500 der 28.2.1500.

MySQL rechnet zumindest so (um wieder on-topic zu werden).

[Thomas 'PointedEars' Lahn]

Peter J. Holzer wrote:

> On 2012-01-14 16:49, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> Gustaf Mossakowski wrote:
>>> Thomas 'PointedEars' Lahn schrieb:
>>>> Auch fand die entsprechende Kalenderreform im Jahr 1582 nach jener
>>>> Zeitrechnung statt.
>>>> genaue Datumsangaben im Gregorianischen Kalender vor dem Freitag, 15.
>>>> Oktober 1582 sind daher nicht sinnvoll (es gibt die gregorianischen
>>>> Daten vom 5. bis 14. Oktober 1582 schlicht nicht).
>>>
>>> Natürlich gibt es diese Daten im gregorianischen Kalender.

>> […]

>>> Der 14. Oktober 1582 im gregorianischen Kalender entspricht dem 4.
>>> Oktober 1582 im julianischen Kalender.
>>
>> Fchsal.
>>
>> Es gibt das Datum "14. Oktober 1582" im Gregorianischen Kalender nicht
>> und genaugenommen auch *keine* Daten davor. Was Du möglicherweise
>> meinst, ist jenes Datum im *proleptischen* Gregorianischen Kalender. Bei
>> diesem findet jedoch *keine* Konvertierung von Daten statt, sondern man

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> verwendet einfach das Julianische Datum als proleptisches Gregorianisches
>> Datum.
>
> Quelle? Meines Wissens ist das falsch. Beim proleptischen
> gregorianischen Kalender ist der Tag vor dem 15.10.1582 der 14.10.1582
> und der Tag vor dem 1.3.1500 der 28.2.1500.

Inzwischen habe ich dazu auch widersprüchliche Aussagen gefunden. Meine
erste Quelle war
<http://en.wikipedia.org/wiki/Gregorian_calendar#Proleptic_Gregorian_calendar>,
wo es unter anderem heisst:

| For ordinary purposes, the dates of events occurring prior to 15 October
| 1582 are generally shown as they appeared in the Julian calendar, with the
| year starting on 1 January, and no conversion to their Gregorian
| equivalents. The Battle of Agincourt is universally known to have been
| fought on 25 October 1415 which is Saint Crispin's Day.

Übersetzung: “Für den alltäglichen Gebrauch werden Ereignisse vor dem 15.
Oktober 1582 im allgemeinen so dargestellt, wie sie im Julianischen Kalender
erscheinen, wobei das Jahr mit dem 1. Januar beginnt, und es findet _keine
Konvertierung zum Gregorianischen Äquivalent_ statt. Von der Schlacht von
Azincourt ist allgemein bekannt, dass sie am 25. Oktober 1415 stattfand, am
Tag des Heiligen Crispian.”

Jedoch wird in <http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar>
ein proleptischer Gregorianischer Kalender beschrieben, der stark vom
Julianischen Kalender abweicht, d. h. nicht nur in den 10 ausgesparten
Daten.

> MySQL rechnet zumindest so (um wieder on-topic zu werden).

Das bestätigt das in letzterer Quelle referenzierte MySQL-Handbuch
(<http://dev.mysql.com/doc/refman/5.0/en/mysql-calendar.html>), wo es u. a.
heisst:

| MySQL uses what is known as a /*proleptic Gregorian*/ calendar.
| […]
| There are no dates between October 4 and October 15. This discontinuity is
| called the /*cutover*/. Any dates before the cutover are Julian, and any
| dates following the cutover are Gregorian. Dates during a cutover are
| nonexistent.
|
| A calendar applied to dates when it was not actually in use is called
| /*proleptic*/. Thus, if we assume there was never a cutover and Gregorian

| rules always rule, we have a proleptic Gregorian calendar. This is what is

| used by MySQL, as is required by standard SQL. […]

Übersetzung:

“MySQL benutzt, was als proleptischer Gregorianischer Kalender bekannt ist.
[…]
Es gibt keine Daten zwischen 4. Oktober und 15. Oktober. Diese
Diskontinuität wird ‘cutover’ (Umstellung; Anm. d. Übers.) genannt. Alle
Daten vor dem ‘cutover’ sind julianisch und alle Daten nach dem ‘cutover’
sind gregorianisch. Daten wärend des ‘cutover’ sind nicht existent.

Ein Kalender, der auf Daten angewendet wird, bevor er im Gebrauch war, wird
proleptisch genannt. Wenn wir also annehmen, dass es niemals einen
‘cutover‘ gegeben hat und Gregorianische Regeln immer gelten, haben wir
einen proleptischen Gregorianischen Kalender. Ein solcher wird von MySQL
benutzt, so wie es Standard-SQL erfordert.”

mysql> SELECT DATE_FORMAT(DATE_SUB('1582-10-15', INTERVAL 1 DAY), '%Y-%m-%d
%W') AS proleptic, VERSION();
+---------------------+--------------+
| proleptic | VERSION() |
+---------------------+--------------+
| 1582-10-14 Thursday | 5.1.58-1-log |
+---------------------+--------------+
1 row in set (0.00 sec)

Vgl. auch <http://dev.mysql.com/doc/refman/5.1/en/mysql-calendar.html>.

[Thomas 'PointedEars' Lahn]

Dieter Nöth wrote:

> Thomas 'PointedEars' Lahn wrote:

>>> Kannst du nicht akzeptieren, dass es auch Umgebungen geben kann, wo das
>>> sinnvoll ist?
>>
>> Ohne überzeugendes Beispiel: Nein.
>>
>>> Nimm z.B. den Data Warehouse Bereich.
>>> Oder die BI-Tools (Microstrategy, Business Objects, etc.), die
>>> *brauchen* einen generischen Kalender.
>>
>> Zeig doch mal.
>

> Was? Ein Data Warehouse? […]

Nein, gefragt war nach einem *konkreten*, Deiner Meinung nach sinnvollen
(und optimal überzeugenden) Anwendungsfall für eine Kalendertabelle, d. h.
(so habe ich Dich verstanden) eine Tabelle, die für jeden Tag einen
Datensatz mit einem eindeutigen Datum enthält, ohne dass für dieses Datum
irgendwelche Nutzdaten gespeichert werden.

>>> Die primäre Programmiersprache für Datenbanken ist SQL und auch PHP
>>> greift darüber zu.
>> Autsch! SQL ist _keine_ Programmiersprache, sondern eine
>> Datenbanksprache!
>
> SQL ist eine deklarative Programmiersprache:
>
http://de.wikipedia.org/wiki/Programmiersprachen#Deklarative_Programmiersprachen

Der Beleg fehlt, und ganz oben steht "Dieser Artikel oder Abschnitt bedarf
einer Überarbeitung". Ich würde dieser Aussage also nicht allzuviel Gewicht
beimessen.

Eine mögliche und gängige Definition für eine Programmiersprache ist, dass
sie Turing-vollständig ist, d. h. sich mit ihr alle möglichen Algorithmen
implementieren lassen. Das trifft auf SQL aber nicht zu.

,-<http://en.wikipedia.org/wiki/Programming_language>
|
| A programming language is a notation for writing programs, which are
| specifications of a computation or algorithm.[1] Some, but not all,
| authors restrict the term "programming language" to those languages that
| can express all possible algorithms.[1][2] Traits often considered
| important for what constitutes a programming language include:
| […]
| * Expressive power: The theory of computation classifies languages by the
| computations they are capable of expressing. All Turing complete
| languages can implement the same set of algorithms. ANSI/ISO SQL and
| Charity are examples of languages that are not Turing complete, yet
| often called programming languages.[10][11]

>>> Selbst MySQL läuft nicht immer nur auf'm Webserver.
>>
>> q.e.d.
>
> Was wäre jetzt bewiesen?
> Das ich keine Ahnung habe?

Ja.

> Oder das MySQL nicht immer auf'm Webserver läuft?
> Du hast doch mit _AMP angefangen und das heisst Webserver:

Nein, das heisst, dass Linux/Windows, Apache, MySQL und PHP zusammen benutzt
werden. Über den Ort der Ausführung ("auf'm Webserver") wird dabei keine
Aussage gemacht.

> <http://en.wikipedia.org/wiki/LAMP_%28software_bundle%29>

Du solltest Dir referenzierbare Quellen suchen.

[Thomas 'PointedEars' Lahn]

Peter J. Holzer wrote:

> On 2012-01-14 14:42, Gustaf Mossakowski <gus...@gmx.de> wrote:
>> Wir haben konkret bei einem Projekt das Problem, dass wir Daten aus
>> Afghanistan korrekt umrechnen müssen und überlegen, wie wir das Datum
>> speichern. Bei Publikationen ist es besonders kompliziert, da hier
>> meist nur das Jahr angegeben wird, in dem die Publikation erscheint.
>> Da die Jahre nicht deckungsgleich sind, müsste man entweder
>> recherchieren, wann genau ein Artikel oder ein Buch etc. erschienen
>> ist. Das ist aber oft nicht möglich. Oder man schreibt 2011/2012 für
>> das aktuelle afghanische Jahr. Das wiederum ist schlecht in ein Feld
>> des Typs DATE oder YEAR einzutragen.
>
> Hmm, das passt natürlich sehr schlecht. Da würde ich dann entweder
> jeweils den Jahresanfang nehmen (also islamisches Jahr 1386 ==
> 2007-03-21)

Das kann nicht stimmen. Mit

C =~ H * (32 / 33) + 622 [1]

und H := 1386:

C =~ 1386 * (32 / 33) + 622
=~ 1966

"2007 war das Hidschri-qamari-Jahr 1427 und 1428 im islamischen Kalender."
[1]

> oder ein Intervall angeben (2007-03-21, 2008-03-19), oder
> schlicht das islamische Datum plus Kalenderart (und rechnet dann on the
> fly um, wenn notwendig). Kommt halt darauf an, was man mit dem Datum
> machen will.

Der islamische Kalender ist ein Mondkalender, bei dem die Monate entweder
29 oder 30 Tage lang sind [1]. Man hat also hier zusätzlich das Problem,
die Monate und Tage umzurechnen.

[1] <http://de.wikipedia.org/wiki/Islamischer_Kalender>

[Thomas 'PointedEars' Lahn]

Ich sehe gerade, dass in Afghanistan seit 1957 der *iranische* (persische)
Kalender, ein Sonnenkalender, verwendet wird (Typo?).

Somit ist 2007-03-21 CE für den Anfang des *iranischen/persischen*
(hidschri-schamsi-)Jahres 1386 korrekt.

<http://de.wikipedia.org/wiki/Iranischer_Kalender>

[Peter J. Holzer]

Pfuh, Glück gehabt. Ich habe einfach den vorletzten Absatz in
http://de.wikipedia.org/wiki/Islamischer_Kalender#Jahreszahlen
abgeschrieben ohne auf den Unterschied zwischen Hidschri-qamari und
Hidschri-schamsi zu achten.

[Michael Meyer]

*** Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> Dieter Nöth wrote:
> > Thomas 'PointedEars' Lahn wrote:

> >> Autsch! SQL ist _keine_ Programmiersprache, sondern eine
> >> Datenbanksprache!
> >
> > SQL ist eine deklarative Programmiersprache:
> >
> http://de.wikipedia.org/wiki/Programmiersprachen#Deklarative_Programmiersprachen
>
> Der Beleg fehlt, und ganz oben steht "Dieser Artikel oder Abschnitt bedarf
> einer Überarbeitung". Ich würde dieser Aussage also nicht allzuviel Gewicht
> beimessen.
>
> Eine mögliche und gängige Definition für eine Programmiersprache ist, dass
> sie Turing-vollständig ist, d. h. sich mit ihr alle möglichen Algorithmen
> implementieren lassen. Das trifft auf SQL aber nicht zu.
>
> ,-<http://en.wikipedia.org/wiki/Programming_language>

| The 4GLs are examples of languages which are domain-specific, such
| as SQL, ...

http://en.wikipedia.org/wiki/Fourth-generation_programming_language

Micha

[Dieter Nöth]

Thomas 'PointedEars' Lahn wrote:

> Nein, gefragt war nach einem *konkreten*, Deiner Meinung nach sinnvollen
> (und optimal überzeugenden) Anwendungsfall für eine Kalendertabelle, d. h.
> (so habe ich Dich verstanden) eine Tabelle, die für jeden Tag einen
> Datensatz mit einem eindeutigen Datum enthält, ohne dass für dieses Datum
> irgendwelche Nutzdaten gespeichert werden.

Wie gesagt, die Date/Calendar Dimension in jedem Data Warehouse.
Und natürlich sind da auch Nutzdaten: Wochennummer, Geschäftsjahr,
Feiertage wie Ostern, und alles, was man im Unternehmen sonst noch
brauchen könnte an Datumsberechnungen.

In einem meiner ersten Posts hatte Beispiel, die du gesnipt hast:
"Für mich gibt es eher Bedingungen wie
- vergleiche die Daten der beiden Wochen um Ostern der letzten drei Jahre
- duchschnittliche Umsätze am 1. Samstag des Monats des letzten halben
Jahres
- berechne die Anzahl von Geschäftstagen zwischen Start- und Endedatum
unter Einbeziehung von Feiertagen etc. Aber nicht für eine Row, sondern
zig-Millionen, weil du den Mittelwert brauchst."

>>>> Die primäre Programmiersprache für Datenbanken ist SQL und auch PHP
>>>> greift darüber zu.
>>> Autsch! SQL ist _keine_ Programmiersprache, sondern eine
>>> Datenbanksprache!
>>
>> SQL ist eine deklarative Programmiersprache:
>>
> http://de.wikipedia.org/wiki/Programmiersprachen#Deklarative_Programmiersprachen
>
> Der Beleg fehlt, und ganz oben steht "Dieser Artikel oder Abschnitt bedarf
> einer Überarbeitung". Ich würde dieser Aussage also nicht allzuviel Gewicht
> beimessen.
>
> Eine mögliche und gängige Definition für eine Programmiersprache ist, dass
> sie Turing-vollständig ist, d. h. sich mit ihr alle möglichen Algorithmen
> implementieren lassen. Das trifft auf SQL aber nicht zu.

"Eine mögliche und gängige Definition" ist natürlich die, die dir passt.

> ,-<http://en.wikipedia.org/wiki/Programming_language>
> |
> | A programming language is a notation for writing programs, which are
> | specifications of a computation or algorithm.[1] Some, but not all,

Du bist "some" und ich scheinbar "not all".

> | authors restrict the term "programming language" to those languages that
> | can express all possible algorithms.[1][2] Traits often considered
> | important for what constitutes a programming language include:
> | […]
> | * Expressive power: The theory of computation classifies languages by the
> | computations they are capable of expressing. All Turing complete
> | languages can implement the same set of algorithms. ANSI/ISO SQL and
> | Charity are examples of languages that are not Turing complete, yet
> | often called programming languages.[10][11]
>
>>>> Selbst MySQL läuft nicht immer nur auf'm Webserver.
>>>
>>> q.e.d.
>>
>> Was wäre jetzt bewiesen?
>> Das ich keine Ahnung habe?
>
> Ja.
>
>> Oder das MySQL nicht immer auf'm Webserver läuft?
>> Du hast doch mit _AMP angefangen und das heisst Webserver:
>
> Nein, das heisst, dass Linux/Windows, Apache, MySQL und PHP zusammen benutzt
> werden. Über den Ort der Ausführung ("auf'm Webserver") wird dabei keine
> Aussage gemacht.

Ok, du hast schon wieder gewonnen, du bist mir sprachlich einfach
überlegen, von mir kommt ja eh immer nur "Blödsinn".

>> <http://en.wikipedia.org/wiki/LAMP_%28software_bundle%29>
>
> Du solltest Dir referenzierbare Quellen suchen.

Ach so, wenn ich Wikipedia zitiere, dann ist das nicht referenzierbar,
bei aber natürlich schon.

Dieter

[Thomas 'PointedEars' Lahn]

Und?

[Harald Stowasser]

Am 15.01.2012 17:32, schrieb Dieter Nöth:
> Thomas 'PointedEars' Lahn wrote:
>
>> Nein, gefragt war nach einem *konkreten*, Deiner Meinung nach
>> sinnvollen (und optimal überzeugenden) Anwendungsfall für eine
>> Kalendertabelle, d. h. (so habe ich Dich verstanden) eine Tabelle,
>> die für jeden Tag einen Datensatz mit einem eindeutigen Datum
>> enthält, ohne dass für dieses Datum irgendwelche Nutzdaten
>> gespeichert werden.
> Wie gesagt, die Date/Calendar Dimension in jedem Data Warehouse. Und
> natürlich sind da auch Nutzdaten: Wochennummer, Geschäftsjahr,
> Feiertage wie Ostern, und alles, was man im Unternehmen sonst noch
> brauchen könnte an Datumsberechnungen.

Das ist schlichtweg falsch. Natürlich ist das Datum eine Dimension.
Allerdings werden auch für Star/Snowflake-schemas keine bezuglosen
Datumseinträge geschrieben.

Natürlich kann man das Datum in eine extra Tabelle normalisieren und
damit auch inventarisieren. Das rechtfertigt jedoch nicht das vorhalten
von nutzlosen Daten.
Wochentag, Woche etc. ist hochgradig redundant uns sollte zudem von
jedem halbwegs gut arbeitenden xLAP aggregiert werden können.

>>>>> Die primäre Programmiersprache für Datenbanken ist SQL und
>>>>> auch PHP greift darüber zu.
>>>> Autsch! SQL ist _keine_ Programmiersprache, sondern eine
>>>> Datenbanksprache!
>>> SQL ist eine deklarative Programmiersprache:
>>>
>> http://de.wikipedia.org/wiki/Programmiersprachen#Deklarative_Programmiersprachen
>>
>>
>> Der Beleg fehlt, und ganz oben steht "Dieser Artikel oder
>> Abschnitt bedarf einer Überarbeitung". Ich würde dieser Aussage
>> also nicht allzuviel Gewicht beimessen.
>>
>> Eine mögliche und gängige Definition für eine Programmiersprache
>> ist, dass sie Turing-vollständig ist, d. h. sich mit ihr alle
>> möglichen Algorithmen implementieren lassen. Das trifft auf SQL
>> aber nicht zu.
> "Eine mögliche und gängige Definition" ist natürlich die, die dir
> passt.

Nein. SQL ist keine Programmiersprache! Thomas hat mit 'gängige
Definition' ein wenig Untertrieben. "Usus" oder "allgemein gültig" wäre
korrekter.

Allerdings ist die Implementation von SQL in MySQL durchaus
Turing-vollständig. Somit ist die in MySQL verwendete Sprache eine
Programmiersprache.

[Dieter Nöth]

Harald Stowasser wrote:

>> Wie gesagt, die Date/Calendar Dimension in jedem Data Warehouse. Und
>> natürlich sind da auch Nutzdaten: Wochennummer, Geschäftsjahr,
>> Feiertage wie Ostern, und alles, was man im Unternehmen sonst noch
>> brauchen könnte an Datumsberechnungen.
>
> Das ist schlichtweg falsch. Natürlich ist das Datum eine Dimension.
> Allerdings werden auch für Star/Snowflake-schemas keine bezuglosen
> Datumseinträge geschrieben.
>
> Natürlich kann man das Datum in eine extra Tabelle normalisieren und
> damit auch inventarisieren. Das rechtfertigt jedoch nicht das vorhalten
> von nutzlosen Daten.
> Wochentag, Woche etc. ist hochgradig redundant uns sollte zudem von
> jedem halbwegs gut arbeitenden xLAP aggregiert werden können.

Ok, das wird mein letztes Post, könnten wir uns drauf einigen, dass
einer der bekanntesten Autoren im DWH-Bereich Ralph Kimball ist?

Ralph Kimball, The Data Warehouse Toolkit, 2nd Edition:
"Some designers pause at this point to ask why an explicit date
dimension tableis needed. They reason that if the date key in the fact
table is a date-type field, then any SQL query can directly constrain on
the fact table date key and use natural SQL date semantics to filter on
month or year while avoiding a supposedly expensive join. This reasoning
falls apart for several reasons. First of all, if our relational
database can’t handle an efficient join to the date dimension
table, we’re already in deep trouble. Most database optimizers are quite
efficient at resolving dimensional queries; it is not necessary to avoid
joins like the plague. Also, on the performance front, most databases
don’t index SQL date calculations, so queries constraining on an
SQL-calculated field wouldn’t take advantage of an index.
In terms of usability, the typical business user is not versed in SQL
date semantics, so he or she would be unable to directly leverage
inherent capabilities associated with a date data type. SQL date
functions do not support filtering by attributes such as weekdays versus
weekends, holidays, fiscal periods, seasons, or major events. Presuming
that the business needs to slice data by these nonstandard date
attributes, then an explicit date dimension table is essential. At the
bottom line, calendar logic belongs in a dimension table, not in the
application code." (S. 40/41)

"Data warehouses always need an explicit date dimension table. There are
many date attributes not supported by the SQL date function, including
fiscal periods, seasons, holidays, and weekends. Rather than attempting
to determine these nonstandard calendar calculations in a query, we
should look them up in a date dimension table." (S.41)


oder
Immhof/Galemmo/Geiger, Mastering Date Warehouse Design, Relational and
Dimensional Techniques:
"This chapter examines the role of dates in the data warehouse. It
explains why it is important to maintain calendar information and not
rely on database supplied functions to interpret dates. The calendar is
probably the most important, yet least appreciated, component of a data
warehouse." (S. 157)

Und (nicht nur) für mich gehört das einfach auch in nicht-DWHs.

Dieter

[Gustaf Mossakowski]

Peter J. Holzer schrieb:

> On 2012-01-14 14:42, Gustaf Mossakowski <gus...@gmx.de> wrote:
>> Wir haben konkret bei einem Projekt das Problem, dass wir Daten aus
>> Afghanistan korrekt umrechnen müssen und überlegen, wie wir das Datum
>> speichern. Bei Publikationen ist es besonders kompliziert, da hier
>> meist nur das Jahr angegeben wird, in dem die Publikation erscheint.
>> Da die Jahre nicht deckungsgleich sind, müsste man entweder
>> recherchieren, wann genau ein Artikel oder ein Buch etc. erschienen
>> ist. Das ist aber oft nicht möglich. Oder man schreibt 2011/2012 für
>> das aktuelle afghanische Jahr. Das wiederum ist schlecht in ein Feld
>> des Typs DATE oder YEAR einzutragen.
>
> Hmm, das passt natürlich sehr schlecht. Da würde ich dann entweder
> jeweils den Jahresanfang nehmen (also islamisches Jahr 1386 ==

(persisches Jahr)

> 2007-03-21) oder ein Intervall angeben (2007-03-21, 2008-03-19), oder
> schlicht das islamische Datum plus Kalenderart (und rechnet dann on the
> fly um, wenn notwendig). Kommt halt darauf an, was man mit dem Datum
> machen will.

Das finde ich arg umständlich, da man in einer Publikationsliste
normalerweise nur das Jahr haben will (also meinetwegen vom Datentyp
YEAR), so aber zwei Spalten vom Typ DATE bräuchte. Daneben sind
Jahresanfang und -ende nicht trivial zu bestimmen. Ein Autor kann ja
sowohl in Afghanistan als auch woanders publizieren. Für eine Sortierung
nach Jahr wäre es dann hilfreich, diese direkt in MySQL durchzuführen,
sonst würde ich auch einfach das persische Datum plus Kalender in die
Datenbank schreiben ...

Es gibt wohl keine einfache Lösung.

Viele Grüße
Gustaf

[Peter J. Holzer]

Das das ist wohl wahr. Prinzipiell hat man solche Probleme natürlich
schon bei unvollständigen Angaben innerhalb des gleichen Kalenders. Wenn
eine Publikation "2008" erschienen ist und die andere "August 2008", wie
soll ich die sortieren? Bei verschiedenen Kalendern wird es noch ein
bisschen komplizierter. Darum auch mein Hinweis, dass es darauf ankomme,
was man mit dem Datum machen will. Wenn es nur um eine Publikationsliste
geht, ist die exakte Reihenfolge wahrscheinlich nicht so wichtig, wenn
man aber z.B. die Ausbreitung eines Mems untersuchen will, kann es sehr
wohl wichtig sein, ob Publikation A vor Publikation B erschienen ist
oder umgekehrt. Dann will man auch Unsicherheiten genau erfasst haben.