In response to a posting from "Jeff Flynt" <[EMAIL PROTECTED]> in which he stated:
"...In this modern day who really cares how many bits a piece of data requires? Bits are cheap! Have two! Is the relational database slower? You can bet on that! But it is also doing a lot more. More work requires more time! Even if the internal structures are very inefficient the hardware today can help compensate. ..." In my early days as a programmer, working for a consulting firm, one of my very successful customers said to me, "Take care of the pennies and the dollars will take care of themselves!" That philosophy built him a business that took care of him and his family and a large number of employees for his entire working career, and has stuck with me throughout my career. Later on, when running my own consulting business, I know that I always wanted the most 'bang for the buck' from every piece of equipment that I bought for the business - and that means not wasting disk storage that I paid good money for, just because some programmer did not think it was worth his/her time and effort to choose the most efficient database product, design the file structures sensibly (and with the hashing algorithm in mind!), and write (and document) maintainable and efficient code - which are not mutually exclusive goals. And, as other responders have noted, it is possible to write modern functionality and excellent security into an mv product - and I would expect that it would run faster and use far less resources in hardware and labor than the corresponding big-name database products. One can complain about some of the design and development decisions made on some of the older applications, but should differentiate between shortcomings in the application code and shortcomings in the database product. While disk is cheaper now than it was then, and memory is cheaper, and labor is more expensive, as a business owner or stockholder, I would still expect any manager to be able to cost-justify any practice that uses more resources than were absolutely necessary, whether that be application design, database selection, or leaving all the lights on in an empty building at night. "Take care of the pennies, and the dollars will take care of themselves!" Jeff also said: "...Truth be told, I want a black box database. I do not care how the grand designers implemented the internal structures, i.e., records composed of delimited strings, hashed files... If I have to know that then I have to know to much. Knowing it may have its advantages. ..." If you don't know how it works, you will never know how to tune it to perform efficiently. More importantly, when it breaks, you won't be able to repair it (and yes, I have seen an Oracle database exhibit symptoms that I would call data corruption - I forget what euphemism our Oracle VAR used for it - and we had to restore from a backup, because nobody had the necessary skill set or tool set to repair it, including our VAR and their tech support backup, and we lost data!). I prefer being able to look at a hex dump and make sure that I have done everything possible to ensure the integrity and wholeness of the data entrusted to my care. No black boxes for me, thank you very much! Although it is harder and harder these days to find products where you can look under the hood, sigh... Susan M. Lynch F.W. Davison & Company, Inc. CONFIDENTIALITY NOTICE: This e-mail message, and any accompanying documents, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or copying is prohibited. If you are not the intended recipient, please contact our office by email or by telephone at (508) 747-7261 and immediately destroy all copies of the original message. ------- u2-users mailing list [EMAIL PROTECTED] http://www.u2ug.org/listinfo/u2-users
