Arthur Fuller
artful at rogers.com
Fri May 21 11:15:31 CDT 2004
Thanks, but only the context of bad performance made me look good. Anyone on this list would not have done it that way, and I would have been groping for optimizations of 10% rather than brain-dead-simple opts that deliver 100%. That said, there are guys and gals hanging a shingle out there who don't even comprehend what a PK or FK is, and why they are important. I've never been much of a fan of certs, but I'm beginning to rethink my stance on this. Yes, it's money in my pocket -- about which I never complain. (Fuller's Second Law: money never arrives at an inopportune moment.) But part of me wishes that the client shouldn't have to re-pay for such low-level and obvious design decisions. The client got hosed, pure and simple, and it angers me that I'm in the same business as the previous developer. Oh, one more thing. When the problem I was hired to fix was explained to the previous developer, he quoted a MONTH. I quoted a day. I was wrong; it took three. I billed for two and the client happily paid. A MONTH! He must be operating from the premise that if the client is ignorant enough to accept the proposal, nuff said. I'm beginning not to like this business. Arthur -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence (AccessD) Sent: Friday, May 21, 2004 7:27 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various Congratulations :-) Arthur. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Arthur Fuller Sent: Thursday, May 20, 2004 5:32 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] On DB Bloat, Bad DB Design, and various Just a note on this bloat subject. I acquired a new client recently, whose DB was 220 MB. They burned me a CD containing same last weekend, so I could work on it while they were closed. Dumbass previous developer hadn't even split it into FE-BE! Everyone was loading the same instance of the whole thing across the net! They had a problem which I fixed. I estimated a day but once I got into it, 3 days elapsed. I split the difference and billed for 2 days. Upon inspection of said database, I discovered some incredible and bizarre anomalies/stupidities. Several tables of critical importance had no PKs and no FK indexes! Unbelievable! Anyway... I split the datbase, then made some mods to the BE which in theory ought to have almost doubled it (i.e. I made copies of every transaction table, but not the static lookup tables). Then I ran compact/repair, and the db came down to (gasp) 40 MB. This includes the doubled tables and the new PK and FK indexes that I added. From 200+ MB to 40 MB -- and this with doubled transaction tables. Once we get the s**t sorted out, I expect that it will come down to 25 MB. I have never programmed in an automatic compact/repair before -- I suppose because I tend to be available and do it as a matter of course. But this app has caused me to rethink that. More seriously, this app has caused me to rethink the virtues of certification. No BE! No PKs! No FK indexes! No wonder the bloddy app was slow with only 20 users on a net! The up side is, it's really easy to look good in a situation like this. The performance gains were spectacular. I got high-fives from all directions :) This is a strange business :) Arthur -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com