Re^3: Categories. Table of Contents. Trees?

[tilly]

I smell over-abstraction.

Unless space is truly at a premium, I would strongly suggest a design where you have a book table (with id, name, publisher, etc) and a chapter table (with a book_id, position_id, name, etc). And then not worry about the fact that some chapter names are replaced. Then just use the database in the obvious way for the specific query.

As an example of why, consider how much work it takes with your schema to change the name of a chapter in a book if it was misentered. Think of how little work it takes with my schema. Another example of why, think of how much work you're putting out now to try to figure out how to make hierarchies completely generic. I guarantee that when you're done, your code will be a lot harder to understand and be a lot slower than the obvious, straightforward approach.

My general rule of thumb says, Do not try to come up with an abstraction until I am solving a problem for the third time. Why? Well the first time I have no idea what is important or what kinds of changes I'll have. So I'll over-design for things that I won't need. (Plus I may never face this problem again.) The second time I'll design a great solution for my second problem, and will be shocked at things that are different. (This time I'm more likely to face it again.) But the third time I have enough of a sense of the problem that I have a chance of coming up with something useful. (And if I've faced it three times, I'll almost definitely see it again.)