tag:blogger.com,1999:blog-4545081472093386800.post6313836587788859836..comments2023-05-09T05:34:51.555-04:00Comments on the Garden of Forking Paths: Database RefactoringZach VanderVeenhttp://www.blogger.com/profile/02442507412891534071noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-4545081472093386800.post-35484472874530475132011-10-31T21:32:11.598-04:002011-10-31T21:32:11.598-04:00I like this rule--don't think of databases in ...I like this rule--don't think of databases in terms of objects. One of Bill Karwin's anti-patters has to do with trying to do polymorphism in SQL!Zach VanderVeenhttps://www.blogger.com/profile/02442507412891534071noreply@blogger.comtag:blogger.com,1999:blog-4545081472093386800.post-90266970641937755302011-10-31T13:57:57.918-04:002011-10-31T13:57:57.918-04:00Well, that's always the trick, isn't it? ...Well, that's always the trick, isn't it? Especially if you're talking to OO programmers.<br /><br />For me, I have to do both, which sometimes makes it hard to do one or the other well. The biggest issue I run into is NOT making tables that resemble objects, and vice versa. For this aspect, I think the key is to recognize that the database is really a storage medium for organizing and managing related information. Therefore, any tables you create should be done with that intent in mind. Now, the real blurring comes in with the indexes; good indexing strategies will cover the most common usage scenarios without negatively impacting overall performance. So now you have to look at HOW the data is accessed and used, not just how to store it.<br /><br />This thought process is different than what OO does. The focus is on objects, and then describing those objects, then describing what they do. Whereas in the database, you want to focus on how the object descriptions inter-relate with each other. I may not be doing the best job with this, but I think you get the gist of it.Scout7https://www.blogger.com/profile/07719913257786053421noreply@blogger.comtag:blogger.com,1999:blog-4545081472093386800.post-14592751873231198872011-10-29T09:41:04.547-04:002011-10-29T09:41:04.547-04:00It's funny how weird databases are--and all pr...It's funny how weird databases are--and all programmers think they know SQL! Do you have any other suggestions for how to explain the difference between database and object oriented programming? It seems to me like a big one, which I mention above, is that you can't start from scratch with a database by recompiling. Set logic, like you mention, is a big one too!Zach VanderVeenhttps://www.blogger.com/profile/02442507412891534071noreply@blogger.comtag:blogger.com,1999:blog-4545081472093386800.post-68256866246252079742011-10-28T15:21:47.411-04:002011-10-28T15:21:47.411-04:00I think the big key is how the applications access...I think the big key is how the applications access the database and the data. I have always shied away from writing SQL code in an application for this reason (along with others), while on the db side I try to force applications to use specific accounts and go through stored procedures as much as possible. Doing so makes changing your database at least somewhat easier.<br /><br />The real issue, though, is that database design, architecture, and programming requires a different mindset than other programming languages. I think that the db stuff tends to be more abstract, and requires thinking about things in a non-standard fashion.Scout7https://www.blogger.com/profile/07719913257786053421noreply@blogger.com