In message <[EMAIL PROTECTED]>, emccormick06 <[EMAIL PROTECTED]> writes >It's quite likely you'll ALSO disagree >with my >actual intention as well - in fact, I'll predict it - but we might as well be >sure.
Ah - an argument! Great - let's go... <G> Well, for my part, we are talking about different applications - different 'programs'. I wouldn't write anything that *needed* a DBA. I want the blonde in reception to be able to use it. That way, I can take the money for coding it, and either go and sit in the sun, or take someone else's money for doing something else. I enjoy data shuffling (sad, innit) - like taking your 70 table database and correcting it. I wouldn't type anything, though... >Let me give you an example. Ms smith is being taken off of aspirin and put on >AspPlus. >Obviously, you wouldn't change the row devoted to Apirin to AspPlus (as >somewhat >strangely you implied in your message), Having worked in Health some years ago, I know that every so often, something happens with a drug, and it is removed and replaced with something else. So, I proposed that Aspirin was no longer safe, and that we should treat all patients with a new wonder drug, AspPlus. > you would add a row for AspPlus, add a >row to the >lookup table relating Ms Smith to AspPlus, and nuke the original row relating >her to Apirin. Yes, why not. >Anyway, adding the new relation was easy. You fire up the admin screen you >wrote (you're >not doing this day in and day out editing raw SQL, obviously). First you >choose >the "add >medicine" screen and type in the info for "AspPlus". Then you go to the >"assign >medicine >to patient screen", select "ms smith" from one drop-down menu and "AspPlus" >from >another one. The PHP code dutifully creates a new row in med_patient, with Ms >Smith's >patient ID and AspPlus's med id. It also helpfully adds the comment "smith - >aspPlus" to >the comment field (note: automatically, by PHP code; no manual data entry >involved). OK, automatically. Although, on my system, the blonde would go to Mrs Smiths screen, ensure that she had the correct Mrs Smith, and would see on screen all Mrs Smiths medicines. That way, we can be sure that we have the correct patient, and that the drug does interact with something else that she is taking. >So now you go to stop the asprin assignment. You go to the "delete medicine >assignment" >screen and - oh no, it's not working. Maybe someone changed a library you >needed. >Maybe you haven't finished it. Do you call Ms smith and tell her she can't >switch the >medicine until you finish updating that admin screen? "I should have that for >you by the >end of the month". No, of course not. Even if you're going to drop >everything >you're >doing and finish that screen, you're STILL going to manually type in the SQL >to >delete the >row in question first. Now you called the programmer in. And the programmer doesn't do data entry... Most clients would not want their programmer doing data entry, that's for the chimpanzees to do, and they are cheaper than programmers <G> But I left a free form text field available for all patients, so the staff just type something in there, a note to say only give one drug. > Now, if you didn't have the "comment" field, you have >these steps: > - find ms smith in the patient table > - write down her ID > - find aspirin in the med table > - write down its ID > - do a delete with those two IDs. > - go back and confirm that ms smith is no longer on aspirin, using the > regular >administrative interface. > >Here's how it goes if you DO have the comment field: > - Look down the med_patient table (which you have sorted on the comment > field) >for >smith-aspirin. (if you don't see it, do it the "old way" above; that's the >cost >if the comment >field is missing for whatever reason) >- Having found the row that has "smith-aspirin" in the comment, do a select on >the med >and patient ids you have there. This is your check - it should show ms smith >and aspirin. >- delete that row, using it's ID. > - go back and confirm that ms smith is no longer on aspirin, using the > regular >administrative interface. I follow what you are doing, but I believe that it's overkill. >The MAIN reason I prefer the second way is that it makes things a LOT easier >(at >least, it >seems to me) when you're using a tool like phpMyAdmin. Once the program goes live, there should be no need for Admin tools. And if I had to, then I would just look the details up in the tables. > You don't have to type >any raw >sql commands, I usually create a number of admin screens, because things do go wrong sometimes. > you can just click on the different tables to see what's going on. >And you >can do it quickly and accurately. It makes less of a difference if you're NOT >using a >graphical db manager, but then...why aren't you? (I use SQLYog). >However, one doesn't get better if you >say "I >understand" when you don't! There are very real time-saving advantages that >come from >the "comment-field-in-link-tables" technique (pattern?) I suggested above. >(it >may not >seem like a lot reading one example, but do it for 20 patients, and it's the >difference >between 20 minutes and two hours). I still don't see why a DBA needs it - how long does it take to type in a SQL command, or create a screen if the job is repetitive. And changing data is not the job of a skilled person like you and me... > I think I've addresses the major complaint >Pete rased >(extra data entry time) No, my complaint is not time spent adding the data twice, it's the "chinese whispers" - errors creeping in. > but I look forward to other opinions, observations, or >criticisms. Or >who knows, even compliments... My tables are big enough already, and many have multiple relationships. In a simple system like the one we are talking about, you could get away with it, I suppose. I worked on one large system (by co-incidence, Health Insurance) where the clients name had to be entered on about three different screens (when I took over!), and often would get separated because they were typed in differently. So, I don't mind you doing it, if you feel that you have to, but don't do it on my systems - <G> >Ed -- Pete Clark http://www.hotcosta.com http://www.spanishholidaybookings.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/CefplB/TM --------------------------------------------------------------------~-> The php_mysql group is dedicated to learn more about the PHP/MySQL web database possibilities through group learning. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/php_mysql/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
