(excuse the cross-post while the new [EMAIL PROTECTED] list is getting started)...
Hi Drew, For me the ER diagram, at the initial stages of a project, plays the part of a glossary. It ensures that I understand what the client means when s/he talks about some "thing" or other. Furthermore, by including relationships, the ER diagram defines the "things" in terms of the other "things". Without this minimal understanding of the domain, I am like one of those dogs in the Larson cartoon... What clients say: "The Master Report then extends the Signatory's Competencies" What Lee hears: "The ruff ruff then ruff the ruff ruff ruff." See ya, LeeBB Drew Harris wrote: > Well, Here I am. > Here is my last post from the other list to get us started. > Yes, I agree. > I thought that it was just because I've worked as a DBA and database > designer prior to my career as a fusebox developer. The first web > applications that I built were ASP solutions with an access backend. I > had > to develop the database before my app could be coded. It's good to know > I'm > not the only one. > ERD Entity Relationship Diagram = Critical first step to requirements > gathering > I guess that I am old fashioned too. > > And I'm not convinced that coding can really begin until the database > development is complete. > Sure there is a custom tag that will return a fake recordset for coders > to > use. > Most of the time at least 1/4th of each of my circuits are real queries. > And normally there are complex joins and outputs using grouping and what > not. > How is this effect achieved with a query sim? > > The other thing is that many businesses have some kind of data that > already > exists and needs to be merged with new data. The larger the business, > the > more messy it gets. ColdFusion with SQL and sometimes XML is an > excellent > way to do some data conversions. > > two of my cents. > -Drew Harris > > -----Original Message----- > From: hal helms [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 11:08 PM > To: [EMAIL PROTECTED] > Subject: RE: Conversations #16 > > > Folks, > > I've just created a [EMAIL PROTECTED] discussion group. (Thanks to Patrick > McElhaney for his excellent suggestion.) Shall we inaugurate the group > by continuing this interesting discussion over there? To subscribe, send > an email to [EMAIL PROTECTED] Once you're subscribed, send > messages to [EMAIL PROTECTED] (this isn't case-sensitive, btw). > > Hal > > -----Original Message----- > From: Balazs Wellisch [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 11:43 PM > To: [EMAIL PROTECTED] > Subject: RE: Conversations #16 > > > I must be a dummy or something, but the domain analysis usually takes me > a lot longer then a couple of hours. It's more like a day or two and > more often than not it takes several meetings between the client and > myself. > > Actually, the real reason for this is that a lot of times the clients > themselves don't have a clear idea of how they're doing things. At least > this has been my experience... > > Balazs > > > > -----Original Message----- > From: BORKMAN Lee [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 7:24 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Conversations #16 > > > I find that I cannot do any kind of wireframe or prototype until the > client and I have done at least a basic domain analysis. In other > words, I need to know what the business-level "things" are that the > application is intended to deal with, and I need to know how they relate > to each other. Until this happens, then I am likely to waste > substantial time thinking that a "Master Report" is a particular kind of > beast (you know, a "report"), when it's actually a completely different > kind of animal (a work authorisation). > > The domain analysis I use is essentially an entity-relationship diagram > with only a few important attributes included. It's really just named > boxes with one-to-one, one-to-many, many-to-many connections drawn. I > think of it as a rich kind of glossary, so that the client and I can > each understand what the other is talking about. This is what *I* mean > by "commensurability", ie, our terms match up, and our conversations are > useful rather than frustrating. > > This analysis is unlikely to take more than a couple of hours, and is > certainly not anything like a complete data design, but until I have at > least this kind of information, I don't think that I can help the client > at all, because I can't *understand* what we are doing or why - I can > only make wireframe or prototype changes at the client's request, while > thinking "okay, I don't know why the hell you'd want to have that page > right there, but you're the client, and you obviously know what you're > doing." > > Inevitably this domain analysis evolves as the wireframing and > prototyping proceeds, but by the time the Fusebox architecting is ready > to proceed, I have the substantial makings of the data design ready to > go too. > > I guess I'm an old-fashioned kind of guy... > > LeeBB > > > > > -----Original Message----- > From: Hal Helms' Occasional Newsletter > [mailto:[EMAIL PROTECTED]] > > > Conversations > Informal talks on software development with Hal Helms and Steve Nelson > Topic: When Do You Design the Database? > Steve Nelson: Well, we're back in business. > Hal Helms: Yep. Last week, we talked about various community resources. > Steve Nelson: One guy wrote me an email saying he thought the topic was > "too controversial". Hal Helms: Community resources controversial? Steve > Nelson: Hey, I just read the email. Hal Helms: Wow, he should hear some > of the ideas we reject! Steve Nelson: So, what was your most > controversial idea? Hal Helms: About development? Steve Nelson: Yeah. > Hal Helms: I suppose it would be the one where I suggested that > corporate accountants be chained to the damned cubicles they're so fond > of. Not forever, you know, but maybe for a year. Steve Nelson: Chained > there, huh? Hal Helms: Right. I mean, since they're so productive a work > environment and all and so people friendly, let's let them stay there > for a while. Their families could come and visit them on weekends. They > could try to do intellectual work with more noise than a train station > at rush hour. I think it might be...enlightening. Steve Nelson: And that > was controversial? Hal Helms: Well-it was among accountants. Steve > Nelson: How about other controversial ideas? Hal Helms: Well, I have one > that-when I say it-people look at me like it's the oddest thing I've > ever said. Steve Nelson: Gee, they must not know about the > accountant-cubicle idea. Hal Helms: Right. Steve Nelson: So, what is it? > Hal Helms: I tell people: when you're building a new application, design > the database last. Steve Nelson: Well, it certainly does fly in the face > of conventional wisdom. Hal Helms: But you do that, right? Steve Nelson: > Absolutely. Now, sometimes, I can't - the database is already built, but > when possible, I do it after all the architecture is done. Hal Helms: > Sounds controversial, all right. Why wait until the last to design it? > Steve Nelson: What happens on a typical project? We have some > requirements documents, some graphical comps and then-bam! Start on the > database! Hal Helms: Yes, that's pretty much right. Steve Nelson: So, > you've got the coding folks waiting on the database to be built. And > then, you have to populate it with some data so your queries work. All > this time, the programmers are waiting. Lots of pressure to "get the DB > done!" And so, it does "get done", but usually, that pressure yields a > design that isn't thought through completely and so the database ends up > changing while coding is going on. Hal Helms: The worst of all possible > worlds. Steve Nelson: Brought about by the best of motives: Let's get > coding! Hal Helms: Or, the flip side of that is that enough time is > given to the database design and then the coders start running out of > time. Bad stuff. Steve Nelson: So, what do you recommend people do? Hal > Helms: I think that until you have identified the people and things that > are going to populate the model world you're building-and that's > essentially what writing software is-creating a model world. Steve > Nelson: Right. Hal Helms: Until you know what the inhabitants and > furniture and stuff of that model world are going to be, you're not > ready for a database. Once you have determined that- Steve Nelson: > Something that you do by architecting the application. Hal Helms: Yes, > once that's done, only then are you in a position to ask the much more > mundane question, "How shall we store all this stuff?" And that's really > all databases are there for: to store stuff. Steve Nelson: That doesn't > sound very...sophisticated: databases are there to "store stuff". Hal > Helms: Hmm...good point. How's this? Databases are there to make objects > persistent. Steve Nelson: Ah, much better. And it means the same thing. > Hal Helms: Seriously, though, the point is that what's important are the > things being stored and NOT the boxes we store those things in. > Relational databases sometimes obscure this point because they do > require a high degree of sophistication to properly store things. Steve > Nelson: I sometimes tell clients when they get hung up with technical > details, "Imagine that we have magical technology that lets us do > whatever we want to do, just by wishing it into being. Now, the REAL > question remains, What do we want to do?" Hal Helms: That's really good. > The problems we run into aren't usually ones of "we know exactly what we > want to do, but can't figure out how to implement it". It's much more > common that we haven't really thought through our scale model world to > make sure that everything is coherent. Or-here's a sophisticated > word-commensurable. I learned that one in philosophy class. Steve > Nelson: Nice word! It means? Hal Helms: Just means that everything fits > together and there are no logical inconsistencies. So what we're both > saying is that doing the database last makes sense because it gives us > time to discover the things that make up our model before trying to > determine how to store those things. Steve Nelson: Yes. And if you think > about it, it also helps out the project schedule, because the database > design can be done while coding is beginning. It takes the database > design off the "critical path", in project management lingo. Hal Helms: > Ah, but what are the coders going to use to test out their pages that > require record sets returned by queries? Steve Nelson: I think some guy > wrote a custom tag to help out with that. QuerySim.cfm, if I remember > correctly. Hal Helms: Why, that's mi-[must...control...ego]-I mean, why > don't you explain how to use that, Steve? Steve Nelson: Why, I'd be > delighted to. It works as a tag pair. The first line indicates-well, why > don't you look at this and see if it makes sense. <cf_QuerySim> > CoolGuys > firstName,lastName > Steve|Nelson > Hal|Helms > </cf_QuerySim> > Hal Helms: So, "CoolGuys" is the name of the record set to be returned. > Steve Nelson: Yep. And the record set has two fields or columns: > firstName and lastName Hal Helms: And then this particular QuerySim > returns two rows of data. Steve Nelson: You got it. Cool, huh? Hal > Helms: Say, Steve, you don't happen to know who-you know-WROTE that tag, > do you? Steve Nelson: I don't remember exactly, but I do remember that > Bert Dawson took the original code-which was apparently pretty bad-and > made it lots easier to use. Can you believe it? The original author made > it so you had to use a separate .ini style file for the recordset > contents! Good thing Bert fixed that! Hal Helms: Doh! Steve Nelson: > What's that? Hal Helms: Oh...nothing. Well, what if you don't want any > rows of data returned? Steve Nelson: You just omit the data lines > altogether. Hal Helms: And if you want certain fields left blank? You > can't just have pipe symbols next to each other and expect CF to know > those represent empty elements in a pipe-delimited string. I mean, it > won't work. Steve Nelson: You can just use the word "null" in there and > the tag will replace that with an empty string. Hal Helms: Gee, that's > some clever programming, wouldn't you agree, Steve? Steve Nelson: I'm > telling you-that Bert Dawson is a clever guy. Hey, what's the matter? It > sounds like you're choking or something. Hal Helms: Oh, don't worry > about ME! I'll be all right. Steve Nelson: Oh, OK. Good. Hal Helms: So, > is that it for today? We both agree on the efficacy of doing the > database design last. Steve Nelson: Yes, I'd tell people to whom this > sounds like heresy to try it out on a little project. I thought it was > weird at first, too, but there's nothing so convincing as success. So, > yeah, I guess we're done. Good thing, too, as we're running out of room. > You have anything else? Hal Helms: Just a little thing. A question, > really, is all. In the example record set you gave-CoolGuys-you had > Steve Nelson first and THEN Hal Helms. I know it seems silly, but that > might imply to certain readers that-and again, I know this is silly-but > it might sound like you're saying that you are cooler than I am! Steve > Nelson: No, that's not silly at all. It's absolutely true. In the > coolness scale, I'm way ahead of you, my friend. That's what we call a > "universal truth"-a little phrase I picked up in philosophy class. Hal > Helms: Well, if you're going to be like that, then I have to tell > everyone that the AUTHOR of the QuerySim tag- Steve Nelson: Sorry, > buddy, but we're out of space. Gotta run. See you all next week. Man, > you sure you're OK? You gotta do something about that choking noise > you're making... Steve Nelson runs SecretAgents.com, a site for putting > together clients and developers. If you need consulting or help on > project management, you can reach Steve at [EMAIL PROTECTED] > > Hal Helms provides training on Fusebox and FLiP, and writes and speaks > on software development methodology and architecture. His site is > www.halhelms.com. You can reach him at [EMAIL PROTECTED] To > unsubscribe/change profile: click here To subscribe: click here > > > Email list management powered by http://MailerMailer.com > ==^================================================================ 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 ==^================================================================
