Sunday, November 6, 2005, Pete wrote: > 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.
Dare I say, me too. I'm a great believer in the developer owning the code and the data definition, but the data belongs to the customer - and they need to work with that data without learning some confusing technobabble like SQL. > 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. ... while behind the scenes, your code and the logic embedded in the data definitions take care of niceties like entity integrity and referential integrity. However, the end user doesn't need to know about such things, because your application lets them interact with *their* data in a way that is natural to them. > 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> Also, in my world the programmer doesn't own the data and the nearest a programmer should get to live data is the test environment plus a small number of proving cases. The exception is troubleshooting - but that's only limited interaction to fix the underlying code etc. >> Now, if you didn't have the "comment" field, you have >>these steps: >> - find ms smith in the patient table [...] >> >>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) Here's how it really goes if you DO have a comment field. - Look down the med_patient table for smith-aspirin - Act on the data - Look embarrassed when it comes to light that an update has created an anomaly between your comment and the "real" data and what says "smith-aspirin" in the comment is really "jones-paracetemol" when the IDs are traced back to the primary tables. This happens because your data isn't even in second normal form because the comment field does not depend on a candidate key, which means that data anomalies can (and will) occur as the comment values in the intersection table become "out of step" with the values in the primary tables. How it should work is that (if you must) you create a view on the data or a calculated field so that the DBMS generates the "comment" from what's there - as opposed to what was there when the tuple was created! > 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. The last thing you want is users messing with raw SQL. FWIW, I get all jittery every time I have to clean up a customer's data and there's no rude awakening like you get if you forget to put the WHERE clause in a DELETE FROM statement! However, there is often a need for an "Admin" interface - for example to let managers change parameters like a restocking threshold. > No, my complaint is not time spent adding the data twice, it's the > "chinese whispers" - errors creeping in. [...] > 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. Obviously, not in 3NF then. With a data entry (as opposed to data warehouse) system, sooner or later you'll get data anomalies if you don't normalize the data. IMO, you should store each primary entity once only and then let your users pick from that data when they create tuples of an intersection. > So, I don't mind you doing it, if you feel that you have to, > but don't do it on my systems - <G> ... nor mine - I'm still having enough fun with about 120 tables in one inherited SQL Server/ASP application where some data isn't even in 1NF! <G> Cheers, -- Geoff Lane Cornwall, UK ------------------------ 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/
