NULL oder "0000-00-00 00:00:00"

Hallo,

ich hatte eben eine aufregende Diskussion darüber, ob man in einer
Datenbank (in diesem Fall MySQL) den Wert NULL auch dann verwenden sollte,
wenn es nicht zwingend notwendig ist.

Zwingend notwendig ist es ja z.B., wenn ich das Feld als FOREIGN KEY in
einem CONSTRAINT verwenden will und es möglich sein soll, dass Datensätze
keine Referenz auf die andere Tabelle haben. Ein weiterer Fall wäre, wenn
ich z.B. in einem INTEGER-Feld zwischen 0 (die Zahl) und NULL (kein
Eintrag) unterscheiden will.

In anderen Fällen kann ich ja auch z.B. bei einem INTEGER-Feld einfach die
Zahl 0 oder bei einem Textfeld einen leeren String als "kein Eintrag" ansehen.

Konkret ging es dabei um ein Datumsfeld. Macht es Sinn, hier NULL
zuzulassen und für "kein Eintrag" zu verwenden, oder sollte man lieber das
Feld auf NOT NULL setzen und als Wert für "kein Eintrag" "0000-00-00
00:00:00" verwenden?

Da es hier keinen Constraint gibt und das Datum "0000-00-00 00:00:00" auch
für nichts anderes verwendet wird, würde ich hier letzteres verwenden,
weil es damit einfach zu programmieren ist und soviel ich weiß auch
weniger Speicherplatz braucht.

Gibt es da eine allgemeine Regel oder wie macht Ihr das?

Schöne Grüße,
Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

Re: NULL oder "0000-00-00 00:00:00"

"Magnus Rosenbaum" schrieb
> Gibt es da eine allgemeine Regel oder wie macht Ihr das?

Also so weit ich das in Erinnerung habt (korrigiert mich bitte) hat eine
NULL Spalte negative Auswirkungen auf die Performance der MySQL Datenbank.
Persönlich hab ich das allerdings noch nicht wirklich gemerkt (meine
Messungen genügten jetzt allerdings auch keinen wissenschaftlichen
Standards).

Ich benutzte eigentlich immer NULL wenn ein Feld keinen Wert hat, dann ist
es einheitlich und für mich einfacher zu erkennen dass das Feld keinen Wert
hat. Ich mach das einfach nur der Übersichtlichkeit, alles andere finde ich
dabei eher nebensächlich (wenn ihr mir jetzt natürlich eine repräsentative
Studie über Performanceunterschiede liefert lass ich mich gerne überzeugen)

mfg Xion

Re: NULL oder "0000-00-00 00:00:00"

Magnus Rosenbaum schrieb:
> Hallo,
>=20
[..]
> Gibt es da eine allgemeine Regel oder wie macht Ihr das?

Wir fragen dann in "de.comp.datenbanken.mysql" nach.

Gruss
Joerg

--=20
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Re: NULL oder "0000-00-00 00:00:00"

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: NULL oder "0000-00-00 00:00:00"

Magnus Rosenbaum schrieb:
> Hallo,
>
> ich hatte eben eine aufregende Diskussion darüber, ob man in einer
> Datenbank (in diesem Fall MySQL) den Wert NULL auch dann verwenden sollte,
> wenn es nicht zwingend notwendig ist.

*JA* Wenn die Spalte Null haben darf solltest du auch NULL verwenden.
Dazu ist NULL da. Mach nicht den Fehler und fange an rum zu tricksen. In
der Vergangenheit haben solche 'Spielereien' viel Ärger bei Migrationen
verursacht!

Wenn die Spalte "Not Null" definiert ist setze ich folgende default werte:
const MINDATE = '1970-01-01 00:00';
const MAXDATE = '2038-01-19 03:00';

Weil dies den grenzen von Unix-timestamp entspricht.

Beispiel:
mysql> show create table map_piece_timerange\G
*************************** 1. row ***************************
Table: map_piece_timerange
Create Table: CREATE TABLE `map_piece_timerange` (
`map_piece_id` int(10) unsigned NOT NULL,
`changed` timestamp NOT NULL default CURRENT_TIMESTAMP
on update CURRENT_TIMESTAMP,
`date_from` datetime NOT NULL default '1970-01-01 00:00:00',
`date_to` datetime NOT NULL default '2038-01-19 03:00:00',
`day_match` int(10) unsigned NOT NULL,
PRIMARY KEY (`map_piece_id`),
KEY `map_piece_timerange_1` (`changed`),
KEY `map_piece_timerange_3` (`date_to`,`date_from`),
KEY `map_piece_timerange_2` (`day_match`,`date_from`,`date_to`),
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci

> In anderen Fällen kann ich ja auch z.B. bei einem INTEGER-Feld einfach die
> Zahl 0 oder bei einem Textfeld einen leeren String als "kein Eintrag" ansehen.

Diese Aussage ist Falsch.
"kein Eintrag" ist definiert mit NULL.
0 ist ein integer wo (mehr oder weniger) zufällig alle Bits LO sind!

Was die Applikation aus den Werten für Informationen generiert ist
erstmal egal.

> Konkret ging es dabei um ein Datumsfeld. Macht es Sinn, hier NULL
> zuzulassen und für "kein Eintrag" zu verwenden, oder sollte man lieber das
> Feld auf NOT NULL setzen und als Wert für "kein Eintrag" "0000-00-00
> 00:00:00" verwenden?

NULL.

> Da es hier keinen Constraint gibt und das Datum "0000-00-00 00:00:00" auch
> für nichts anderes verwendet wird, würde ich hier letzteres verwenden,
> weil es damit einfach zu programmieren ist und soviel ich weiß auch
> weniger Speicherplatz braucht.

Mach es nicht. Sobald du auf ein Framework triffst das "0000-00-00
00:00:00" nicht als Datum verarbeiten kann bekommst du Schwierigkeiten.
NULL geht immer. Da es ein gültiger (nicht) Wert ist.

> Gibt es da eine allgemeine Regel oder wie macht Ihr das?

so.

Gruß Harald.


P.S. ich Fupe die Diskussion nach de.comp.datenbanken.mysql um. Da es
dort besser passt, und nix mit PHP zu tun hat.


P.P.S Meine Rechtschreibkorrektur wollte gerade aus Rosenbaum
Bierdosenbaum machen. Gibt es einen Gärtner der sowas hat? Eventuell
frage für de.rec.garten? (SCNR :-)

Re: NULL oder "0000-00-00 00:00:00"

Magnus Rosenbaum schrieb:
> Hallo,
>
> ich hatte eben eine aufregende Diskussion darüber, ob man in einer
> Datenbank (in diesem Fall MySQL) den Wert NULL auch dann verwenden sollte,
> wenn es nicht zwingend notwendig ist.

*JA* Wenn die Spalte Null haben darf solltest du auch NULL verwenden.
Dazu ist NULL da. Mach nicht den Fehler und fange an rum zu tricksen. In
der Vergangenheit haben solche 'Spielereien' viel Ärger bei Migrationen
verursacht!

Wenn die Spalte "Not Null" definiert ist setze ich folgende default werte:
const MINDATE = '1970-01-01 00:00';
const MAXDATE = '2038-01-19 03:00';

Weil dies den grenzen von Unix-timestamp entspricht.

Beispiel:
mysql> show create table map_piece_timerange\G
*************************** 1. row ***************************
Table: map_piece_timerange
Create Table: CREATE TABLE `map_piece_timerange` (
`map_piece_id` int(10) unsigned NOT NULL,
`changed` timestamp NOT NULL default CURRENT_TIMESTAMP
on update CURRENT_TIMESTAMP,
`date_from` datetime NOT NULL default '1970-01-01 00:00:00',
`date_to` datetime NOT NULL default '2038-01-19 03:00:00',
`day_match` int(10) unsigned NOT NULL,
PRIMARY KEY (`map_piece_id`),
KEY `map_piece_timerange_1` (`changed`),
KEY `map_piece_timerange_3` (`date_to`,`date_from`),
KEY `map_piece_timerange_2` (`day_match`,`date_from`,`date_to`),
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci

> In anderen Fällen kann ich ja auch z.B. bei einem INTEGER-Feld einfach die
> Zahl 0 oder bei einem Textfeld einen leeren String als "kein Eintrag" ansehen.

Diese Aussage ist Falsch.
"kein Eintrag" ist definiert mit NULL.
0 ist ein integer wo (mehr oder weniger) zufällig alle Bits LO sind!

Was die Applikation aus den Werten für Informationen generiert ist
erstmal egal.

> Konkret ging es dabei um ein Datumsfeld. Macht es Sinn, hier NULL
> zuzulassen und für "kein Eintrag" zu verwenden, oder sollte man lieber das
> Feld auf NOT NULL setzen und als Wert für "kein Eintrag" "0000-00-00
> 00:00:00" verwenden?

NULL.

> Da es hier keinen Constraint gibt und das Datum "0000-00-00 00:00:00" auch
> für nichts anderes verwendet wird, würde ich hier letzteres verwenden,
> weil es damit einfach zu programmieren ist und soviel ich weiß auch
> weniger Speicherplatz braucht.

Mach es nicht. Sobald du auf ein Framework triffst das "0000-00-00
00:00:00" nicht als Datum verarbeiten kann bekommst du Schwierigkeiten.
NULL geht immer. Da es ein gültiger (nicht) Wert ist.

> Gibt es da eine allgemeine Regel oder wie macht Ihr das?

so.

Gruß Harald.


P.S. ich Fupe die Diskussion nach de.comp.datenbanken.mysql um. Da es
dort besser passt, und nix mit PHP zu tun hat.


P.P.S Meine Rechtschreibkorrektur wollte gerade aus Rosenbaum
Bierdosenbaum machen. Gibt es einen Gärtner der sowas hat? Eventuell
frage für de.rec.garten? (SCNR :-)

Re: NULL oder "0000-00-00 00:00:00"

Christian Franzen wrote:
> Also so weit ich das in Erinnerung habt (korrigiert mich bitte) hat eine
> NULL Spalte negative Auswirkungen auf die Performance der MySQL Datenbank.

Ich habe nun zwei Stellen in der MySQL Doku gefunden, die das bestätigen:

http://dev.mysql.com/doc/refman/5.1/de/date-and-time-types.h tml
---8<---
MySQL gestattet ferner die Speicherung von '0000-00-00' als "Pseudodatum"
(hierfür darf der SQL-Modus NO_ZERO_DATE jedoch nicht aktiv sein). Dies
ist in bestimmten Fällen bequemer (und benötigt zudem weniger Speicher für
Daten und Indizes) als die Verwendung von NULL-Werten.
---8<---

http://dev.mysql.com/doc/refman/5.1/de/data-size.html
---8<---
Wenn möglich, deklarieren Sie Spalten als NOT NULL. Hierdurch wird alles
schneller, und Sie sparen ein Bit je Spalte. Wenn Sie NULL in Ihrer
Anwendung wirklich benötigen, sollten Sie es natürlich benutzen; Sie
sollten lediglich verhindern, dass alle Spalten vorgabeseitig so
eingestellt sind.
---8<---

cu, Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

Re: NULL oder "0000-00-00 00:00:00"

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: NULL oder "0000-00-00 00:00:00"

..oO(Andreas Kretschmer)

>Nein, '0000-00-00' ist kein Datum:
>test=*# select '0000-00-00'::date;
>ERROR: date/time field value out of range: "0000-00-00"
>
>Es gibt weder einen Monat noch einen Tag 00.

Es gibt aber sehr wohl Situationen, in denen auch solch unvollständige
Daten (z.B. mit Tag = 0) gespeichert werden wollen. Insofern kommt es
mir durchaus sehr gelegen, wenn mein DBMS diese Möglichkeit bietet.

Micha

Re: NULL oder "0000-00-00 00:00:00"

..oO(Andreas Kretschmer)

>Nicht alles, was MySQL dokumentiert, ist damit automatisch gut und
>richtig. Oft genug ist deren Doku lediglich die Doku für deren
>Unfähigkeit:

Und? Wissen und Meinungen können sich ändern. Früher dachte man auch,
die Erde wäre eine Scheibe. Sowas von unfähig die Menschen ...

>,----[ MySQL Reference Manual for version 3.23.37. ]
>| 5.4.5.1 Reasons NOT to Use Foreign Keys constraints

Könntest du bitte endlich mal mit diesem Blödsinn aufhören? Nach 3.23
kräht heute kein Hahn mehr.

Micha

Re: NULL oder "0000-00-00 00:00:00"

Michael Fesser schrieb:

> ..oO(Andreas Kretschmer)
>
>> ,----[ MySQL Reference Manual for version 3.23.37. ]
>> | 5.4.5.1 Reasons NOT to Use Foreign Keys constraints
>
> Könntest du bitte endlich mal mit diesem Blödsinn aufhören? Nach 3.23
> kräht heute kein Hahn mehr.

Vermutlich ist das die Version, bei der unser PostgreSQL-Oberguru
aufgehört hat, die Entwicklung von MySQL weiter zu verfolgen. Das würde
auch seine merkwürdige Meinung zu MySQL erklären.

Es erklärt allerdings nicht, warum er hier immer noch mitliest.

Gruß. Claus

Re: NULL oder "0000-00-00 00:00:00"

Michael Fesser schrieb:

> ..oO(Andreas Kretschmer)
>
>> Es gibt weder einen Monat noch einen Tag 00.
>
> Es gibt aber sehr wohl Situationen, in denen auch solch unvollständige
> Daten (z.B. mit Tag = 0) gespeichert werden wollen.

Dann ist DATE(TIME) aber definitiv der falsche Datentyp dafür.

Gruß. Claus

Re: NULL oder "0000-00-00 00:00:00"

..oO(Claus Reibenstein)

>Michael Fesser schrieb:
>
>> ..oO(Andreas Kretschmer)
>>
>>> Es gibt weder einen Monat noch einen Tag 00.
>>
>> Es gibt aber sehr wohl Situationen, in denen auch solch unvollständige
>> Daten (z.B. mit Tag = 0) gespeichert werden wollen.
>
>Dann ist DATE(TIME) aber definitiv der falsche Datentyp dafür.

Jein. Konkret hab ich hier eine Personendatenbank mit (u.a.) Geburts-
daten. Nur sind da aber durchaus ein paar Leute dabei, bei denen zwar
Geburtsjahr und -monat bekannt sind, nicht aber der Tag. Da kommt mir
die Form YYYY-MM-00 sehr entgegen, da ich dadurch dennoch im großen und
ganzen die Datumsfunktionen der DB nutzen kann und lediglich bei der
Ausgabe in meiner Applikation eine kleine Fallunterscheidung brauche.

Micha

Re: NULL oder "0000-00-00 00:00:00"

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

Re: NULL oder "0000-00-00 00:00:00"

Claus Reibenstein schrieb:

> Vermutlich ist das die Version, bei der unser PostgreSQL-Oberguru
> aufgehört hat, die Entwicklung von MySQL weiter zu verfolgen. Das wü=
rde
> auch seine merkwürdige Meinung zu MySQL erklären.
>=20
> Es erklärt allerdings nicht, warum er hier immer noch mitliest.

Hier geht es um PHP in Verbindung mit Datenbanken.
Dazu gehört im weitesten Sinne sogar MS Access. Ein PostgreSQL-Anhäng=
er
ist hier prinzipiell genauso richtig wie ein MySQL-Nutzer. Wenn du
findest, dass er nur flamed, pack ihn ins Killfile und gut ist.

MfG
Nie - leben und leben lassen - ls

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: NULL oder "0000-00-00 00:00:00"

Andreas Kretschmer schrieb:

> Wenn es Dir reicht, daß die Daten im großen und ganzen halbwegs kor=
rekt
> sind, dann ist ja gut (und MySQL auch eine gute Wahl).

MySQL ist in jeder Hinsicht eine gute Wahl. Ich habe noch keine
(DB-bezogene) Problemstellung gefunden, die sich nicht auf Anhieb damit
lösen ließ.

> Ist ja auch
> ausreichend, zu wissen, daß $Kollege am 6. Geburtstag hat. Jahr und
> Monat spielen keine Rolle, mag er doch jeden Monat zum 6. einen
> ausgeben, gell?

Daten liegen nicht immer in der gewünschten Genauigkeit vor. MySQL
erlaubt hier ohne große Umstände, dem Rechnung zu tragen. Ein Riesen-=
Plus.

> end
> Andreas

Du sagst es. Mach weiter so - du bist einen Mausklick von der roten
Karte entfernt.

MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: NULL oder "0000-00-00 00:00:00"

Niels Braczek schrieb:

> Claus Reibenstein schrieb:
>
>> Es erklärt allerdings nicht, warum er hier immer noch mitliest.
>
> Hier geht es um PHP in Verbindung mit Datenbanken.

Mea culpa. Ich wähnte mich in einer der MySQL-Gruppen.

Gruß. Claus

Re: NULL oder "0000-00-00 00:00:00"

..oO(Andreas Kretschmer)

>Michael Fesser wrote:
>
>> Jein. Konkret hab ich hier eine Personendatenbank mit (u.a.) Geburts-
>> daten. Nur sind da aber durchaus ein paar Leute dabei, bei denen zwar
>> Geburtsjahr und -monat bekannt sind, nicht aber der Tag. Da kommt mir
>> die Form YYYY-MM-00 sehr entgegen, da ich dadurch dennoch im großen und
>> ganzen die Datumsfunktionen der DB nutzen kann und lediglich bei der
>
>Wenn es Dir reicht, daß die Daten im großen und ganzen halbwegs korrekt
>sind, dann ist ja gut (und MySQL auch eine gute Wahl). Ist ja auch
>ausreichend, zu wissen, daß $Kollege am 6. Geburtstag hat. Jahr und
>Monat spielen keine Rolle, mag er doch jeden Monat zum 6. einen
>ausgeben, gell?

Ich schrieb, daß Jahr und Monat i.d.R. bekannt sind, der Tag hingegen
nicht immer. Du darfst natürlich gerne einen besseren Vorschlag machen,
wie eine solche Situation zu handhaben ist.

Micha

Re: NULL oder "0000-00-00 00:00:00"

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: NULL oder "0000-00-00 00:00:00"

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: NULL oder "0000-00-00 00:00:00"

Andreas Kretschmer schrieb:
> begin Niels Braczek schrieb:

>> MySQL ist in jeder Hinsicht eine gute Wahl. Ich habe noch keine
>> (DB-bezogene) Problemstellung gefunden, die sich nicht auf Anhieb dami=
t
>> lösen ließ.
>=20
> Das bedeuted exakt was?

MySQL hat und kann alles, was man braucht.

>> Daten liegen nicht immer in der gewünschten Genauigkeit vor. MySQL
>> erlaubt hier ohne große Umstände, dem Rechnung zu tragen. Ein Ries=
en-Plus.
>=20
> Ich weiß. Aus Deinem Blickwinkel ist das absolut richtig. Andere
> Anwender legen halt mehr Wert auf Datenintegrität als Du.

Eher unwahrscheinlich. Du weißt entschieden zu wenig von mir und meiner=

Arbeit, um das beurteilen zu können.

> Akzeptiere es.

Dass du dich für den Datenbank-Gott hältst? Niemals.

MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: NULL oder "0000-00-00 00:00:00"

Niels Braczek schrieb:

> Andreas Kretschmer schrieb:
>
>> begin Niels Braczek schrieb:
-----^^

Er kann's nicht lassen ...

>>> MySQL ist in jeder Hinsicht eine gute Wahl. Ich habe noch keine
>>> (DB-bezogene) Problemstellung gefunden, die sich nicht auf Anhieb damit
>>> lösen ließ.
>>
>> Das bedeuted exakt was?
>
> MySQL hat und kann alles, was man braucht.

Was _Du_ brauchst.

Ich bin zwar auch ein absoluter MySQL-Fan und konnte bisher alle
datenbanktechnischen Probleme damit lösen. Das heißt aber nicht, dass es
nicht auch andere und vielleicht sogar bessere Wege für das eine oder
andere gibt oder dass es keine Probleme gäbe, die sich nicht mit MySQL
lösen lassen würden.

Mit solchen Generalaussagen wäre ich also vorsichtig.

Gruß. Claus

Re: NULL oder "0000-00-00 00:00:00"

Michael Fesser schrieb:
> .oO(Andreas Kretschmer)
>
>> Michael Fesser wrote:
>>
>>> Jein. Konkret hab ich hier eine Personendatenbank mit (u.a.) Geburts-
>>> daten. Nur sind da aber durchaus ein paar Leute dabei, bei denen zwar
>>> Geburtsjahr und -monat bekannt sind, nicht aber der Tag. Da kommt mir
>>> die Form YYYY-MM-00 sehr entgegen, da ich dadurch dennoch im großen und
>>> ganzen die Datumsfunktionen der DB nutzen kann und lediglich bei der
>> Wenn es Dir reicht, daß die Daten im großen und ganzen halbwegs korrekt
>> sind, dann ist ja gut (und MySQL auch eine gute Wahl). Ist ja auch
>> ausreichend, zu wissen, daß $Kollege am 6. Geburtstag hat. Jahr und
>> Monat spielen keine Rolle, mag er doch jeden Monat zum 6. einen
>> ausgeben, gell?
>
> Ich schrieb, daß Jahr und Monat i.d.R. bekannt sind, der Tag hingegen
> nicht immer. Du darfst natürlich gerne einen besseren Vorschlag machen,
> wie eine solche Situation zu handhaben ist.

Schreibe ein korrektes Datum und benutzte ein Merkmal das dieses Daten
nicht genau sind:

`datum_intakt` enum('Gesichert','Tag unbekannt','Monat
unbekannt','geschätzt' )

Re: NULL oder "0000-00-00 00:00:00"

Claus Reibenstein schrieb:
> Niels Braczek schrieb:

>> MySQL hat und kann alles, was man braucht.
>=20
> Was _Du_ brauchst.

Sowieso.

> Ich bin zwar auch ein absoluter MySQL-Fan und konnte bisher alle
> datenbanktechnischen Probleme damit lösen. Das heißt aber nicht, da=
ss es
> nicht auch andere und vielleicht sogar bessere Wege für das eine oder=

> andere gibt oder dass es keine Probleme gäbe, die sich nicht mit MySQ=
L
> lösen lassen würden.
>=20
> Mit solchen Generalaussagen wäre ich also vorsichtig.

Dass andere RDBMS in dem einen oder anderen Punkt vielleicht andere
Lösungswege eingeschlagen haben, ist unbenommen, ebenso, dass diese
anderen Wege dem einen oder anderen vielleicht intuitiver zugänglich
sind als die von MySQL. Das ist insofern Geschmackssache.

Die Mächtigkeit - also die Fähigkeit, für alle Probleme, die sich e=
inem
RDBMS stellen können, eine Lösung anzubieten - ist allerdings beweisb=
ar
(dazu habe ich allerdings weder Zeit noch Lust). Daher finde ich nicht,
dass ich mich mit der Generalaussage[tm] sehr weit aus dem Fenster
gelehnt hätte.

MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: NULL oder "0000-00-00 00:00:00"

Niels Braczek meinte:
> Andreas Kretschmer schrieb:
>> begin Niels Braczek schrieb:
>
>>> MySQL ist in jeder Hinsicht eine gute Wahl. Ich habe noch keine
>>> (DB-bezogene) Problemstellung gefunden, die sich nicht auf Anhieb damit
>>> lösen ließ.
>> Das bedeuted exakt was?
>
> MySQL hat und kann alles, was man braucht.

Naja, Pivot-Tabellen und so OLAP-Datamining-Bullshit-Bingo-Zeugs geht
eher wenig elegant bis garnicht.

> Dass du dich für den Datenbank-Gott hältst?

Ist er nicht. Sonst würden so MySQL-Aficionados wie wir schon längst im
Fegefeuer schmoren. Oder müssten 10.000x "Meine DB kann keine
Volltextsuche unter Wahrung referentieller Integrität. Pfui!" schreiben.

Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: NULL oder "0000-00-00 00:00:00"

Harald Stowasser schrieb:

> `datum_intakt` enum('Gesichert','Tag unbekannt','Monat
> unbekannt','geschätzt' )

Das müsste ein SET sein; es können zB. Tag *und* Monat unbekannt sein=


MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: NULL oder "0000-00-00 00:00:00"

Niels Braczek schrieb:
> Harald Stowasser schrieb:
>
>> `datum_intakt` enum('Gesichert','Tag unbekannt','Monat
>> unbekannt','geschätzt' )
>
> Das müsste ein SET sein; es können zB. Tag *und* Monat unbekannt sein.

Das hängt von der Aufgabenstellung ab.

Bei Geburtstagen z.B. ist es wenig sinnvoll, den Tag zu speichern, wenn
man den Monat nicht weiß. Andererseits könnte zusätzlich noch das Jahr
unbekannt sein (soll bei Frauen besonders häufig vorkommen).

Gruß. Claus

Re: NULL oder "0000-00-00 00:00:00"

Gregor Kofler schrieb:
> Niels Braczek meinte:

>> MySQL hat und kann alles, was man braucht.
>=20
> Naja, Pivot-Tabellen und so OLAP-Datamining-Bullshit-Bingo-Zeugs geht =

> eher wenig elegant bis garnicht.

Letzteres gehört ja nicht wirklich zu den Aufgaben eines RDBMS. Es soll=

lediglich die Daten auf Abruf bereitstellen, die dann mit einem
OLAP-Werkzeug analysiert werden. Die Daten kann man mit beliebigen
Aggregationen herausholen.

MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: NULL oder "0000-00-00 00:00:00"

Niels Braczek schrieb:
> Harald Stowasser schrieb:
>
>> `datum_intakt` enum('Gesichert','Tag unbekannt','Monat
>> unbekannt','geschätzt' )
>
> Das müsste ein SET sein; es können zB. Tag *und* Monat unbekannt sein.

Du meinst es gibt Leute die wissen das sie an 'einem' 5 geboren wurden,
aber nicht in welchem Monat? Ich glaub dann ist der Tag auch schon
Wurs^WEgal.

Ein Set halte ich für schlecht denn: Was sagt Gesichert *und* Geschätzt aus?

Re: NULL oder "0000-00-00 00:00:00"

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: NULL oder "0000-00-00 00:00:00"

Harald Stowasser schrieb:

> Niels Braczek schrieb:
>
>> Harald Stowasser schrieb:
>>
>>> `datum_intakt` enum('Gesichert','Tag unbekannt','Monat
>>> unbekannt','geschätzt' )
>>
>> Das müsste ein SET sein; es können zB. Tag *und* Monat unbekannt sein.
>
> Ein Set halte ich für schlecht denn: Was sagt Gesichert *und* Geschätzt aus?

Dass Du das gleiche übersehen hast wie ich :-)

Man kann ein Datum genau dann als gesichert ansehen, wenn kein anderes
Flag gesetzt ist. Das klappt sowohl mit SET als auch mit ENUM. Damit
wird 'Gesichert' schlicht überflüssig.

Unabhängig davon ist _nirgends_ festgelegt, dass bei einem SET alle
_möglichen_ Kombinationen auch _sinnvoll_ sein müssen. Die Zahl der
sinnvollen Kombinationen kann durchaus niedriger sein.

Gruß. Claus

Re: NULL oder "0000-00-00 00:00:00"

..oO(Andreas Kretschmer)

>Michael Fesser schrieb:
>> Ich schrieb, daß Jahr und Monat i.d.R. bekannt sind, der Tag hingegen
>> nicht immer. Du darfst natürlich gerne einen besseren Vorschlag machen,
>> wie eine solche Situation zu handhaben ist.
>
>Auf das speichern halbkaputter Daten verzichten.

Das wäre in meinem Fall noch schlechter als unvollständige Daten. Selbst
wenn nur das Geburtsjahr bekannt ist, erlaubt das immerhin die Zuordnung
der Person zu einem bestimmten Jahrgang.

>Nun kannst Du mit einer
>Abfrage sogar sehr schnell Dir eine Liste derjenigen Personen machen,
>deren Geburtsdatum Dir nicht bekannt ist,

Kann ich so auch.

>und diese befragen.

Wenn zu jedem in der DB Kontakt bestünde, dann gäbe es dieses Problem
erst gar nicht. Leider ist das nicht der Fall und wird es wohl auch nie
sein. Ergo nehme ich alles an Daten, was ich kriegen kann, selbst wenn
es nicht vollständig ist.

>Ein Datentyp 'DATE' bedeutet für mich, daß man damit Datumsoperationen
>durchführen kann und exakte Ergebnisse bekommt. Ich will gar nicht
>wissen, was MySQL als DOY (day of year) oder AGE() für Deine
>halbkaputten Daten da liefert, weil es einfach nur kapott sein kann.

NULL + Warnung.

Micha

Re: NULL oder "0000-00-00 00:00:00"

..oO(Harald Stowasser)

>Michael Fesser schrieb:
>>
>> Ich schrieb, daß Jahr und Monat i.d.R. bekannt sind, der Tag hingegen
>> nicht immer. Du darfst natürlich gerne einen besseren Vorschlag machen,
>> wie eine solche Situation zu handhaben ist.
>
>Schreibe ein korrektes Datum und benutzte ein Merkmal das dieses Daten
>nicht genau sind:
>
>`datum_intakt` enum('Gesichert','Tag unbekannt','Monat
>unbekannt','geschätzt' )

Etwas in der Art wäre durchaus möglich und ließe sich sogar ziemlich
transparent abhandeln, d.h. in der Benutzeroberfläche könnten weiterhin
unvollständige Daten eingegeben werden und die Applikation kümmert sich
um die korrekte Übertragung in die DB (oder ggf. macht's die DB sogar
selbst per stored procedure).

Allerdings brächte mir das im Moment keinerlei konkrete Vorteile und ich
müßte obendrein auch erstmal prüfen, inwieweit sich das auf bestehende
Abfragen auswirken würde sowie einige Scripte anpassen. Das lohnt im
Moment nicht, da sind andere Dinge wichtiger.

Micha