"Apple Juice Corner" says it all. A book title does not. A book called "Refactoring" could contain : 1. Intro 2. Refactoring 3. How to avoid common smells
I would like to know if number 3 is also in the book. If you happened to have read it, could you please tell me ?
I think that I have most trouble to decide how to design tables first. After the design, I'm using it and I find myself in a situation where I should have done it another way. I can refactor. But that could have been avoided.
Ok, reading a book on DB refactoring should undirectly teach about what not to do. I'd better go buy some juice
Joined: Aug 15, 2004
Originally posted by Satou kurinosuke: Ok, reading a book on DB refactoring should undirectly teach about what not to do.
Joined: Aug 15, 2004
Actually prior to this book we dont have any book about database refactoring, or better say any good book incase if there are few not known to me. So I guess we would find related stuff in this book, related to database refactoring.
There might be some kind of tips to come up with a good design given in the book but I believe if you are really interested in how to make a good design then you had better off go for some other good books. Which are relatively more relevent. Inspite of, design database and refactoring database are related to eachother. But a design book would be more appropriate and straight forward for the one looking this book for learning good designs.
Haven't read the book. Just playing hmmmm... juices .
Is there any chapter in your book treating about how to make a good design, and avoid common pitfalls ?
There is one short chapter about "database design smells".
And of course the whole point of refactorings is about improving the design while avoiding common pitfalls, so I'd say, yes, in that sense the whole book is about it.
But I'm not sure whether that really answers your question...?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Satou kurinosuke: I think that I have most trouble to decide how to design tables first.
If you are determined to resolve that situation go and have a look at Terry Halpin's Object Role Model (ORM). I left some links in this topic. If you google around you may find quotes like
It works great, but you throw away the diagrams and just use the sentences after awhile. What drives people nuts is that it takes longer to do ORM than to splash up an ER diagram. But you will get it right, which is not guaranteed by ER."
Just be warned: Terry Halpin's MSDN article reads like it was written by someone way too familiar with the subject matter; he makes assumptions that aren't apparent to a neophyte. And his book can be equally frustrating because he uses concepts before he defines them; this could be alleviated by a good glossary or index, but those don't deliver either - so you are basically committed to reading the book twice.
However, regardless of the notation used, if any, there are never any guarantees. It is always up to the skills of the people involved as to how well you "get it right" to begin with. The important thing with database refactoring is that now you have a safe way to evolve your schema on the off chance that requirements change or that you're not a super-human modeler who is perfect in every way.