Back when we showed you how logging can save you, we touched on the subject of listing fields prior to building your database.
Once you’ve been building software for a while, you may find yourself jumping into the development stage before you’re ready. In some cases this may work just fine, but if you end up missing some critical functionality, you’ll look pretty silly.
Planning the structure of your database can help you to avoid missing out key fields and build the application right first time. Here’s a working example.
Sponsor
Transactions
Typical fields you might use when dealing with transactions include:
- Unique Id
- Description
- Credit
- Debit
- User Id
This would get you started, but there are some gaping holes in this list. Where’s the date? How about the balance?
Content Management
Fields you might need when dealing with content management include:
- Unique Id
- Title
- Content
- User Id
- Created Date
This should work for a basic system. In the future you might add things like tags and categories – but should you build everything into the first release? This shows it may be worthwhile to keep things simple to begin with – otherwise, you could add every possible field and never release the system.
There’s also the subject of whether to store the data for an area of functionality in one table or multiple tables. For instance, in the content table, you might have a status field that includes values such as Draft, Scheduled, Published, Private, and Deleted. How many of these are essential for the first release? Would you put these in a separate table or just as a single field in the content table?
Generally speaking, it’s good to have a plan from the start, and try to be consistent throughout the system. Otherwise, things can get very messy.
Photo by Tim Morgan
0 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.