Kay Smoljak wrote: > Hmmm... that's interesting. I have been looking at it the other way - > you don't know enough to start writing Fusedocs until you understand the > data you are storing. I look at the requirements for the app - say > there's an events listing - I then figure out I need to store the name, > venue, time, ticket price etc. Then I say well, ticket prices are fixed > in categories so that should be a separate table... and so on. Once I > figure out everything I design the database, THEN design the app. Too > late now but next time I might try it the other way - I'm not really > sure how it will work though :)
Well, the idea is that by the time you're doing your fusedocs, you've already created the prototype. The prototype is going to answer a hell of a lot more questions for the client than a database will. The prototype defines the data you need for both the fusedocs and the database. I've found that if you have the prototype, creating the fusedocs next is easier than creating the database. > > I'd suggest creating an data alias map, which is something > > This sounds like the kind of thing that would fill the gap, I guess. No > sneak-previews? I'd be more than happy to show you, but I don't have anything that I'm in love with yet. I do love the idea, it fills in the gap like you mentioned. I've been kicking around the idea of using an excel spreadsheet for this, that way you could start with your fusedoc variables, and the DBA can alias the database fields. Steve Nelson ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
