|
I would go with the 2 table design. You have a classic 1 to many relationship (a header table and it's corresponding details table). You can implement it with one table, but unless you actually need a tree structure (i.e. more than one level below a parent), there really is no benefit.
The 2 table design is a lot easier to maintain and expand. Also in a database that supports foreign keys, you can even enforce referential integrity. (i.e. no child can exist without a parent or in this case, no details can exist without an issue)
A lot of developers who find themselves doing the database design as well as code, create a database specifically for the problem at hand. The fewer tables, the reasoning goes, the better. Don't fall into that trap! It is well worth reading an article or two on normalization. A good data model should address 1) current needs, 2) future (expected) needs, and 3) as much as possible, unexpected needs. A normalized model gives you the most flexibility in terms of adding new features. That doesn't mean you can't "denormalize" some things for performance, but it is better to normalize first and then decide where it makes sense to make changes.
Good luck.
|