I am a total convert. I used to design the database first. Now I design the database after my fusedocs. The reason for this is that designing the database first means you're figuring out the solution before you truly know the problem. Fusedocs indirectly tell you what the database needs to look like. By knowing what data you need in your site, you know what data needs to be stored.
Once you've created your fusedocs, it suddenly becomes very simple to create that database. Not only that, but many of the fuses can be coded without the database even built. that means your programmers aren't sitting around waiting for the 5th normal form to be figured out. Instead they are building the fuses that do not need the database. I'd suggest creating an data alias map, which is something Hal and I will be talking about in a newsletter in the next few weeks. This alias map is separate from your fusedocs that show which database fields match up with which io data in your fusedocs. This allows your DBA to match up fusedoc variables like "product_description" with fields in the database like table: "products" field: "description". btw, when you do finish your fusedocs, buzz me, i'll help you test them. This testing process will save you if you're having someone else doing the coding. Steve Nelson Kay Smoljak wrote: > Hi all, > > I'm working on architecting a large app where someone else will be doing > the bulk of the CF coding - in the past I've written FuseDocs for other > people to write the HTML but never the whole thing. I'm curious as to > the process other people go through when beginning a big project. > > I got the client to work with a wireframe (which they hated!), then > created a mind map. Using this I worked out the database design, then > created the database and generated a document that is essentially a huge > fusedoc with all the database fields in it. Then I used a modified > fuseminder to roughly generate all the files and switches, and now I'm > going through and writing the fusedocs for each fuse. I use the database > fusedoc to cut and paste the variables into the individual fusedocs. > > It's working out ok, although it's a long laborious process - I never > realised how slack I got when I knew I was writing the fusedocs for > myself. But because the database has already been designed, I keep > feeling like I should include some actual db infomation in the fusedocs > to make it clearer to the coder (who is new to CF as well as Fusebox!) - > things like when a field is from another table etc. At the moment I am > indenting the fields that are coming from a different table, for my own > reference as well. > > I know that the reason why the fusedocs don't have database info is > because in theory the database may or may not be defined already when > they are written - which is fine. But my databases are always already > designed - I consider that one of the first steps once I know what's > going to be involved in a project. I also like to add a length="" > attribute to my strings, so that the html person knows how big to make > the field. If the database is not designed, that would stuff up that > info as well. > > So how do other people do it differently to combat this? How many people > are actually designing their databases *after* the app is designed - and > what's your reasoning? How much do you leave up to the fusecoder - am I > trying to hold their hand too much? > > Thanks if you got this far, > Kay. > ______________________________________ > Kay Smoljak Web Developer > Custom Tags: developer.perthweb.com.au > ==^================================================================ 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 ==^================================================================
