[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mysql-developer
Subject:    Design inefficiencies
From:       Michael Widenius <monty () monty ! pp ! sci ! fi>
Date:       1999-06-03 4:39:22
[Download RAW message or body]

>>>>> "big" == big john <Johann> writes:

big> Hi!
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> 1.)

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 
following types:

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> 2.)

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.

Regards,
Monty

---------------------------------------------------------------------
Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before
posting. To request this thread, e-mail developer-thread67@lists.mysql.com

To unsubscribe, send a message to the address shown in the
List-Unsubscribe header of this message. If you cannot see it,
e-mail developer-unsubscribe@lists.mysql.com instead.

[prev in list] [next in list] [prev in thread] [next in thread]