I am in the planning stages of a database app for personal use. I have a good bit of the database structure planned, but as I think about how I'm going to write the program, it made me wonder if I'm doing this in the right order.
Which should I be planning first, the db structure or the classes?
They most often develop together, although it's often easiest to start designing the basic structure of the database, and then move to the code. You'll find that depending on the size of your application the database will change frequently along the way to final product.
I typically plan as best I can, then I start creating the database per the planning/design specs I wrote for myself.
Then, I use something like Linq-To-SQL to generate some basic DAL classes -- wrap those in a repository class that manages most of my CRUD situations.
Depending on the complexity of the app, I then write a GUI which consumes the repository directly (quick/dirty) or I write a domain logic class (and potentially Data-Transfer-Objects or dumb POCOs) which wraps up the functionality in the repository.
Obviously, the best planning misses things, so make sure you take in to account that you'll have to go back and add fields, change types, add relationships etc.
I think designing your data model first is a very good idea.
If the app is to be database driven it is a good idea to have an solid understanding of what your data model is going to look like before even attempting to write any code.
You can still conceptualize how you think the classes may look as your thinking about your data model. Keeping this in the back of your mind as you determine your requirements will help when you begin to write some code as well.
Of course, as you begin to write code you will probably have to revisit your data structure, so it is an iterative process, but good planning at the onset of the project is a good idea.
I think you will get a differnt answer from data centric poeple vice application centric people. Personally I always start with the data but an application programmer would probably start with the classes.
In reality, I think you need to work on the two at the same time.
If the purpose of your system is to store, retrieve and report on data, then I would say by all means it is appropriate to design the database first.
If, on the other hand, the purpose of the system is to implement a business process or processes using software, then it will often be more efficient to design the "domain model" first, modeling out the business process into objects/classes, then determining how to persist them to/from a database later.