Hi Stefan On the Data Warehouse project, the technical lead didn't understand Oracle. She was a mainframe programmer and once, in another job, she used VSAM files. WE don't support VSAM files, but she wanted to use them anyway... take data out of Oracle on Unix, pipe it to the mainframe to do some Tranformations (in the ETL), pipe it BACK to Unix and load it in to the Oracle tables... because that's how she knew how to do it... and the technical lead should know everything about EVERY detail of how the project is implimented.
We are doing better... After I got told to sit down and shut up in a couple meetings, and lectured for 2 hours on my attitude in meetings being less than helpful, I quit going and started just rejecting what wouldn't work after they had spent hours or days writing it. They are starting to consider (not use in most cases, but consider) stored procedures. I don't look on it (most of the time) so much as Purgatory, but as a personal challenge. Besides, I have done IMS (DB/DC) and know that Purgatory is having virtual bi-directional pointers interconnecting 6 "tables" in every imaginable configuration, one of them with the only thing that makes it unique in the world being a sequece number and load routines that don't remember where they were in the file when the operators restart the process after an abend. April -----Original Message----- To: Multiple recipients of list ORACLE-L Sent: 3/28/2003 4:23 AM Hi What I don't understand is: If your development department want to go with a VSAM like approach, why do they invest in Oracle. Why not just get a zSeries and stick to VSAM or IMS ? PS: Your working environment sounds like an actual implementation of Purgatory Regards, Stefan Stefan Jahnke Consultant BOV Aktiengesellschaft Voice: +49 201 - 4513-298 Fax: +49 201 - 4513-149 mailto: [EMAIL PROTECTED] Please remove nospam to contact me via email. visit our website: http://www.bov.de <http://www.bov.de/> subscribe to our newsletter: http://www.bov.de/presse/newsletter.asp <http://www.bov.de/presse/newsletter.asp> Sicherheitsluecken mit IT-Security-Konzepten von BOV effizient schliessen! Weitere Informationen unter +49 201/45 13-240 oder E-Mail an mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> . Wie Sie wissen, koennen ueber das Internet versandte E-Mails leicht unter fremden Namen erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um Verstaendnis dafuer, dass wir zu Ihrem und unserem Schutz die rechtliche Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen ausschliessen. As you are probably aware, e-mails sent via the Internet can easily be copied or manipulated by third parties. For this reason we would ask for your understanding that, for your own protection and ours, we must decline all legal responsibility for the validity of the statements and comments given above. -----Urspr�ngliche Nachricht----- Von: April Wells [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 25. M�rz 2003 14:09 An: Multiple recipients of list ORACLE-L Betreff: RE: Database Modeling- Normalization - Dinosaurs or What? Hi Paula Hey... I live in your world. Our "data warehouse" was designed by someone who had never dealt with ANYTHING relational... but based it on VSAM files and tried to make the leap. We have a table with 873 columns in our data warehouse... they call it a FACT table. It has client name and address (well... they are "facts", right... ?). You don't have foreign keys... we don't have PRIMARY keys. We call unique indexes primary keys... but after 10 years of not understanding why queries didn't return data that made sense, they allowed me to put not null constraints on the columns in the unique index (when I told them that they either do that or they answer to the clients). Historically, the DBAs in this company have done little more than implement what programmers designed and then tried to make it work. They WON'T use stored procedures, they don't understand them. THEY write code that sits in files on the OS and call those "programs" via shell scripts. They heard once that it was faster that way in Oracle 2 and so it must be still true, cause COBOL never changes so Oracle must not change. The part I like best, though, is... we have a ONE column table with ONE row... SystemDate... because they can't figure how to get sysdate from dual into a variable and use it in their programs... so they start their data warehouse load run with a truncate to that table, and an insert of the date passed in from the OS so they can load the DW tables. DON'T stop fighting. I think that is what they want. I have been told (in meetings where I have been requested for my DBA input) to sit down and shut up unless I am asked a question when I tried to point out things like... you can't have 1500 columns in a table no matter how fast it will make the queries fly... you can't have table names of 72 characters for descriptive sake... you really can't call a column DATE just because that is what is in it, an arbitrary date... Make them hear you even if they don't listen. Be the biggest pain they can imagine, eventually it will slowly start to pay off, because eventually they will realize (again VERY slowly) that you are right. It is how I got the reputation of being a DBA (Dat Bi#$h April) April -----Original Message----- [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 6:14 PM To: Multiple recipients of list ORACLE-L Guys, The emphasis in many places I have worked is developing quick and dirty systems as quickly as possible and working with developers that don't seem to have very much understanding of Relational Database Theory but who prefer to program using flat files in relational databases - calling it "object-oriented" when it truly is not. Let us just say that it is highly denormalized. As a DBA I care about data integrity, extensibility and scalability but the up and coming esp. SQL Server developer types seem to operate in a world where this doesn't matter - just buy more hardware, denormalize to make the programming easier, etc. I have been losing this battle. So - what is your experience with this? What about the idea of having everyone access all objects in the views so that if need be the DBA's could in fact still make physical changes to the schemas without a large amount of rewriting of code? - as a standard Living without normalization for most things - esp. small systems and w/o fk's except as they are maintained in the application for the sake of getting the application done quickly, cheaply. It turns my stomach but then I wonder about my own sanity - am I making too much out of nothing? What about these stovepipe systems? Case in-point 100,000 row table for asset management - moving different types of addresses to a separate address table and moving different types of people to a person table. Developers are aghast at the performance implications. I am thinking perf. implications not real esp. with small amount but provides extensibility and RI with these reference tables instead of denorma. in multiple tables. They say mostly batch inserts/updates and batch reads - but then they say some OLTP. This is a SQL Server database. I think the separate reference tables provides only way for extensibility and data integrity. I say I will write for them a joined view. They say perf. implications. - AARRRGGHH! Oracle OCP DBA The information contained in this communication, including attachments, is strictly confidential and for the intended use of the addressee only; it may also contain proprietary, price sensitive, or legally privileged information. Notice is hereby given that any disclosure, distribution, dissemination, use, or copying of the information by anyone other than the intended recipient is strictly prohibited and may be illegal. If you have received this communication in error, please notify the sender immediately by reply e-mail, delete this communication, and destroy all copies. Corporate Systems, Inc. has taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses. We specifically disclaim all liability and will accept no responsibility for any damage sustained as a result of software viruses and advise you to carry out your own virus checks before opening any attachment. The information contained in this communication, including attachments, is strictly confidential and for the intended use of the addressee only; it may also contain proprietary, price sensitive, or legally privileged information. Notice is hereby given that any disclosure, distribution, dissemination, use, or copying of the information by anyone other than the intended recipient is strictly prohibited and may be illegal. If you have received this communication in error, please notify the sender immediately by reply e-mail, delete this communication, and destroy all copies. Corporate Systems, Inc. has taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses. We specifically disclaim all liability and will accept no responsibility for any damage sustained as a result of software viruses and advise you to carry out your own virus checks before opening any attachment. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: April Wells INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
