tag:blogger.com,1999:blog-6411920579549337139.post1725800811497203307..comments2023-12-31T05:26:17.608-08:00Comments on DATABASE DEBUNKINGS: This WeekFabian Pascalhttp://www.blogger.com/profile/01346669716885494092noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6411920579549337139.post-73817536819839238542017-01-31T11:43:49.352-08:002017-01-31T11:43:49.352-08:00Pretty good observations.Pretty good observations.Fabian Pascalhttps://www.blogger.com/profile/01346669716885494092noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-2331702809058262792017-01-31T04:19:04.568-08:002017-01-31T04:19:04.568-08:00I see at least 2 things wrong with that picture. ...I see at least 2 things wrong with that picture. First there is no conceptual model presented upon which to derive a logical model. Second, the logical model options being discussed (i.e. 1 table, 3 tables) are based not on a conceptual model but instead on unquantified performance considerations which, even if quantified, still belong at the physical level. This is a good example of the logical physical confusion (LPC) you write about that many of us practitioners suffer from and slip into without realizing it.<br /><br />On the bright side at least the writer has started asking some questions that should be directed toward the client to start the process of creating a conceptual model. <br /><br />Quote of the week is great. "Ensuring data is *physically stored*", and "requires data to be *stored*". I see why we should be shaking our heads. The RM is a logical model and leaves the physical storage to be defined by the implementor in any way they see fit so long as the logical model of presenting data only as relations is not violated. <br /><br />Looking forward to reading your explanations of what was wrong with the picture and continuing to learn from those.Todd Everetthttps://www.blogger.com/profile/00974811298237514426noreply@blogger.com