>>>>> "big" == big john <Johann> writes:
big> Im relativ new to MySQL but according to recent postings i considered
big> some design flaws (at least they are flaws for me)
big> I think Date-datatypes should definitely be checked whether they are
big> correct or not. The 'leap year formula', etc. are very fast an simple
big> checks which really not affect execution speed.
big> At least it got stressed often enough that most operations to the DB are
big> selects (which is true) and no inserts. Loosing little speed when
big> executing INSERT INTO ... while gaining lots of data integrity would be
big> an acceptable trade-off.
big> Converting completely false dates to 00.00.0000 or somewhat like this
big> should rather be handeled as an exception.
The main reason for not checking dates is actually not speed; MySQL
tries to store dates as you where given them. If you want to store a
false date, that's up to you!
(The above problem pops up if you read wrong dates from some other
system; In this case it's better to save the wrong date than to
convert it to 0000-00-00, as this makes finding problems much easier)
big> I didn't looked into the source but using the julian date internally in
big> favour of dd.mm.yyyy would ease time operations considerably.
Maybe, or maybe not.
In some future MySQL version you will be allowed to store dates of the
YYYY-MM-OO and YYYY-00-00.
This is to store dates when you are not sure about the day or the
month and day (very common when handling patient date)
big> Sorting of data using a language definition would better fit to a CREATE
big> DATABASE than beeing a mysqld - parameter and affect therefore all
big> databases and tables.
I agree; The new ISAM in MySQL 3.23 will fix this problem.