Who has time for that? Sometimes, in the spirit of delivering on "Internet time," they just jam it into production and fix it later... after the company becomes dependent on it... when it's hard to "schedule" down time. :-)
Are you familiar with XP? It's not a Microslop product but stands for "eXtreme Programming." Check it out at: http://www.extremeprogramming.org/ Steve Orr -----Original Message----- Sent: Monday, January 07, 2002 7:20 AM To: Multiple recipients of list ORACLE-L Taking a slight diversion away from data modelling issues a set of Production type issues need to be addressed prior to going live These could include Signed off user acceptance testing, Backup strategy, devised, tested and signed-off Expected performance targets and response times (part of an SLA really) Signed off volumetric testing. Some of the major issues when going live appear when real volumes of data have been entered and a query that ran well against 500 rows in developmenbt does not do quite as well against 500,000 in live. Network impact assesment Data archiving and houskeeping routines agreed and tested I am sure there are many others items that listers can supply John -----Original Message----- Sent: 07 January 2002 13:50 To: Multiple recipients of list ORACLE-L I agree with the column naming comments. I would find it hard to over-emphasize the need for a column naming convention that allows you to know what table a column belongs to, whether it's a primary or foreign key, and ,if it's a foreign key, then what the name of the base table and column are. I also agree with the comments on choosing a primary key. If the database is never going to by synched with an outside database then the best choice for a primary key is a sequence generated number. Personally, I wouldn't worry too much about normalization problems if they're deliberately done. It's easy to gong developers over normalization, but sometimes a denormalized table is necessary for performance. In fact, if the data model is perfect 3rd normal form then you'll probably have to do some denormalization. All that being said, it's silly to have the developers present you with a data model. You should have been involved in developing the data model from the very beginning. But life, or management, is always presenting us with new "opportunities." Good luck. "Mercadante, Thomas F" To: Multiple recipients of list ORACLE-L <NDATFM <[EMAIL PROTECTED]> @labor.state. cc: ny.us> Subject: RE: Criteria for handoff from Sent by: root development 01/04/2002 03:50 PM Please respond to ORACLE-L Dennis, First of all, I would tell your manager that 90% of tuning is in writing good queries no matter what the data model looks like. Unfortunately, you receiving a data model and expecting to perform miracles is pretty naive of the organization. This is a classic example of how NOT to do things. Saying that, I would look closely at the model and check for the following: Look closely for normalization problems. If you see repeating fields in a table, reject it and tell them to change it. Look for column-naming standards. If they do not have them, make some up and enforce them. Some common naming standards would use a suffix to indicate the type of data the column is holding. Things like _DATE _NBR _FNAME _LNAME _ID and _CODE would indicate date, number, standard length first and last name, Id type columns indicating it is a primary key (possibly) an integer value, and a Code column indicating that this is a foreign key to another table. This is soooo important for report-writing people on the back-end of the project. They can implicitly see that the column has a certain value by the name. Ask how they determined primary key values for all tables. Specifically, how do they KNOW that the values will be unique. Question everything you see. This is probably the biggest area of concern that I would have. Non-db designers will always make a mistake here. I developed a db once that used the soc-sec as the pk. WRONG! The db was at a college. Want to know how many parents use their personal soc-sec on the application for the child? :( Look for obvious foreign key relationships and enforce them. Develop a standard where the related columns in database tables (like FK columns) have the same name in both tables (like soc_sec_number is named the same in all tables). This is not an easy thing to do. You should have been involved in the meetings from the very get-go. Hopefully, this is not a 300-table design that will take you very long to review. Hope these help! Tom Mercadante Oracle Certified Professional -----Original Message----- Sent: Friday, January 04, 2002 2:45 PM To: Multiple recipients of list ORACLE-L Can anyone provide some criteria of what you look for when a data model is handed off from production? We are starting a large development project and I lobbied management to hire a data architect. As they have talked to these people, they are getting statements such as "and then the DBA will check out the data model to make sure there won't be any performance problems". I am concerned about what will be expected of me and wondered how other DBAs handle this situation. What do you look for in a model in terms of making sure the performance will be good? I said that I could look at the queries that would be run to see how many tables would need to be joined to retrieve the data, but the manager replied that a good DBA wouldn't need to see the queries, should just be able to look at the model. Up until this point, our client-server design tools have tended to protect the developers from doing dumb stuff, but now in the Java world some of those safeguards. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Mercadante, Thomas F INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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). ========================================================= This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ========================================================= -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Orr, Steve INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).
