And now we are down to reality. This is a MySQL list. Views are a wonderful
thing for creating an isolation layer between the application and the
database. However, MySQL's current implementation makes it extremely
difficult in many cases to avoid full table scans when you define the
logical view. {Not poking at the development team I think 5.x is a huge step
forward}.
So you can't hide the underlying structure currently in MySQL. Like all
other things we have to commingle best practices with pragmatism. In other
words do what makes sense while at the same time acquiring a good knowledge
of fundamentals. {Not just slap name address phone1 .... phone n in some
table with an auto-increment ID field and say your done with the design.}
By the way, Date and Codd {both way above me in math and theory} had this
discussion ~20 years ago over a 6 month period in pages and pages of
Database magazine. In the end I believe they agreed to disagree.
-----Original Message-----
From: Martijn Tonies [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 16, 2006 5:33 AM
To: mysql@lists.mysql.com
Subject: Re: Accountability with MySQL
From: <[EMAIL PROTECTED]>
> "Martijn Tonies" <[EMAIL PROTECTED]> wrote on 16/03/2006 11:02:32:
>
> > Well, the question still is if you should store "unknown" at all ;)
> >
> > Not according to Date: you should store what is known. See the remarks
> > about the "true propositions", from which relational databases are
> derived
> > (but you probably know that).
>
> As someone totally unread in the theory of databases, that seems unduly
> puritanical. I assume that what Date would propose is that you have
> another table (related by master key) in which, if you do not know
> something, you do not enter it. But this means that if you have 10
> different pieces of potentially but not necessarily available information
> about a single master record (e.g. a person), you have to do a 10-way join
> in order to retrieve all the information about them. Replacing a
> theoretically ugly null flag with a 10 way join strikes me, as an engineer
> rather than a theoretician, the wrong side of the elegance/practicality
> trade-off.
Using NULLs as well as de-normalization brings the risk of
integrity problems to your storage, storing what is right is only
a good thing.
And when it comes to having to writing JOINs for all your queries,
lo and behold, I bring you the wonder of the VIEW.
;-)
Martijn Tonies
Upscene Productions
http://www.upscene.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
