> I realized I was in for a beating when I made the original > post, and its not like I don't understand the benefits of > breaking data apart into separate tables, nor fail to > understand the black-box nature of data thats been input > free-form.
It's clobberin' time! Just kidding. > My point was simply that this was presented as a very, very > simple need and, if it were me, I'd spend a bit of time > chatting with the guy, throwing out some ideas for the future > to see if he can envision - or is interested in - something > that can eventually grow to control his inventory (you > mentioned buying paprika) or if all he's really after is a > little ol' recipe book. Unfortunately, end-users (and clients in general) can be pretty short-sighted. It's our job, as developers, to foresee the issues that'll come up with version 2.0, because even if this guy doesn't want that feature now, or think he'll want it later, he probably will, and he'll be upset when you tell him "well, we could have made that work, but we can't now, because we made the initial database design very simple to meet your needs at the time" - he won't understand that, and he won't care anyway, because he'll want what he wants. > Your point about this not being db-related and a ui issue > is very well-taken, but I can't see how the two can be > separated from one another in this case, as one seemingly > defines the other. Oh, there's no need for that. You can build whatever UI you want. For example, you could have a textarea, in which every separate line is an ingredient. In the same page, you could use the CFWDDX tag to store the recordset of ingredients in a JavaScript array. You could then use JavaScript event handlers to check every line in the textarea, compare what's been entered against the array, find the matching ingredients, and store their IDs in a hidden field. If the user entered an ingredient not in the array, you could use DHTML or a new window to ask the user whether they meant to enter the closest match (assuming there is one) or add a new ingredient entirely. This is just one potential solution - I haven't really fleshed it out, but you could certainly do something close enough to this to provide the necessary functionality. Now, admittedly, this can be pretty complex in HTML/DHTML/JavaScript. However, that's what programmers are supposed to do, if necessary. In addition, this illustrates the appeal of using Flash as a UI, instead of HTML, because you can provide this sort of dynamic functionality a lot easier than you could otherwise. In any case, though, even if you couldn't provide that sort of interface now, it's a lot easier to rewrite interfaces than it is to restructure databases. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
