RE: Criteria for handoff from development
Nope. I don't. It was over a year ago so (being wildly optimistic) I expect that flaw was fixed. Kimberly SmithTo: Multiple recipients of list ORACLE-L ksmith2 [EMAIL PROTECTED] @myfirstlink.cc: net Subject: RE: Criteria for handoff from Sent by: rootdevelopment 01/07/2002 09:10 PM Please respond to ORACLE-L Hum, do you know what was being used for serving up the servlets? We used Tomcat here and did not experience those issues. I believe it was 4.0 although that version does seem to have a memory leak (at least on Unix). -Original Message- [EMAIL PROTECTED] Sent: Monday, January 07, 2002 7:50 AM To: Multiple recipients of list ORACLE-L I was just the DBA, not the JAVA developer, but -- We had a Database server using JDBC to talk to an application server. The application was written in Java and used Java thin client to talk to the client (endusers). The endusers had any Java compliant browser. No applets (security issues -- I don't remember what), only servlets on the application server. It worked great for the developers (2). As soon as the customer accepted the application we let the head developer go (since the customer didn't want to pay for his time anymore). After about the third or fourth customer employee started up a browser session to the application server the browsers started timing out. Tracked it all down and the Java thin client was loosing track of which message went to which workstation. Kimberly SmithTo: Multiple recipients of list ORACLE-L ksmith2 [EMAIL PROTECTED] @myfirstlink.cc: net Subject: RE: Criteria for handoff from Sent by: rootdevelopment 01/07/2002 10:25 AM Please respond to ORACLE-L We never had that issue where I am at. Can you explain it a bit more. What do you mean the client was unable to handle more then two or three connections? Do you mean that you where connecting multiple times from the same java application to the same database? -Original Message- [EMAIL PROTECTED] Sent: Monday, January 07, 2002 6:00 AM To: Multiple recipients of list ORACLE-L Last Java project that I worked on (about 1 year ago), the Java thin client was not robust enough to handle more than two or three connections simultaneously. More than that and the threads got twisted. Client application would hang waiting for a response from the database. The database had sent the response long ago but it never got to the client. Hopefully this has been fixed in later versions of Java. -- 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Kimberly Smith INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists
RE: Criteria for handoff from development
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 FTo: Multiple recipients of list ORACLE-L NDATFM [EMAIL PROTECTED] @labor.state.cc: ny.us Subject: RE: Criteria for handoff from Sent by: rootdevelopment 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 s 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
RE: Criteria for handoff from development
Last Java project that I worked on (about 1 year ago), the Java thin client was not robust enough to handle more than two or three connections simultaneously. More than that and the threads got twisted. Client application would hang waiting for a response from the database. The database had sent the response long ago but it never got to the client. Hopefully this has been fixed in later versions of Java. -- 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).
RE: Criteria for handoff from development
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 FTo: Multiple recipients of list ORACLE-L NDATFM [EMAIL PROTECTED] @labor.state.cc: ny.us Subject: RE: Criteria for handoff from Sent by: rootdevelopment 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 s 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
RE: Criteria for handoff from development
We never had that issue where I am at. Can you explain it a bit more. What do you mean the client was unable to handle more then two or three connections? Do you mean that you where connecting multiple times from the same java application to the same database? -Original Message- [EMAIL PROTECTED] Sent: Monday, January 07, 2002 6:00 AM To: Multiple recipients of list ORACLE-L Last Java project that I worked on (about 1 year ago), the Java thin client was not robust enough to handle more than two or three connections simultaneously. More than that and the threads got twisted. Client application would hang waiting for a response from the database. The database had sent the response long ago but it never got to the client. Hopefully this has been fixed in later versions of Java. -- 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Kimberly Smith 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).
RE: Criteria for handoff from development
Actually, even if the database is going to be synced with another sequence generated numbers is still the best. I worked on a replication project once and what we did is have one database generate even numbers and the other generate odd numbers. I don't remember how we did it exactly and am to lazy to try it but it worked well. -Original Message- [EMAIL PROTECTED] Sent: Monday, January 07, 2002 5:50 AM 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 FTo: Multiple recipients of list ORACLE-L NDATFM [EMAIL PROTECTED] @labor.state.cc: ny.us Subject: RE: Criteria for handoff from Sent by: rootdevelopment 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 s 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
RE: Criteria for handoff from development
I just read up on the Extreme Programming. Its a pretty neat concept. Very solid I think. -Original Message- Sent: Monday, January 07, 2002 7:06 AM To: Multiple recipients of list ORACLE-L 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 FTo: Multiple recipients of list ORACLE-L NDATFM [EMAIL PROTECTED] @labor.state.cc: ny.us Subject: RE: Criteria for handoff from Sent by: rootdevelopment 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 s 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,
RE: Criteria for handoff from development
I was just the DBA, not the JAVA developer, but -- We had a Database server using JDBC to talk to an application server. The application was written in Java and used Java thin client to talk to the client (endusers). The endusers had any Java compliant browser. No applets (security issues -- I don't remember what), only servlets on the application server. It worked great for the developers (2). As soon as the customer accepted the application we let the head developer go (since the customer didn't want to pay for his time anymore). After about the third or fourth customer employee started up a browser session to the application server the browsers started timing out. Tracked it all down and the Java thin client was loosing track of which message went to which workstation. Kimberly SmithTo: Multiple recipients of list ORACLE-L ksmith2 [EMAIL PROTECTED] @myfirstlink.cc: net Subject: RE: Criteria for handoff from Sent by: rootdevelopment 01/07/2002 10:25 AM Please respond to ORACLE-L We never had that issue where I am at. Can you explain it a bit more. What do you mean the client was unable to handle more then two or three connections? Do you mean that you where connecting multiple times from the same java application to the same database? -Original Message- [EMAIL PROTECTED] Sent: Monday, January 07, 2002 6:00 AM To: Multiple recipients of list ORACLE-L Last Java project that I worked on (about 1 year ago), the Java thin client was not robust enough to handle more than two or three connections simultaneously. More than that and the threads got twisted. Client application would hang waiting for a response from the database. The database had sent the response long ago but it never got to the client. Hopefully this has been fixed in later versions of Java. -- 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Kimberly Smith 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
RE: Criteria for handoff from development
create the first sequence as start with 1 increment by 2 and the second as start with 2 increment by 2 --- Kimberly Smith [EMAIL PROTECTED] wrote: Actually, even if the database is going to be synced with another sequence generated numbers is still the best. I worked on a replication project once and what we did is have one database generate even numbers and the other generate odd numbers. I don't remember how we did it exactly and am to lazy to try it but it worked well. -Original Message- [EMAIL PROTECTED] Sent: Monday, January 07, 2002 5:50 AM 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 FTo: Multiple recipients of list ORACLE-L NDATFM [EMAIL PROTECTED] @labor.state.cc: ny.us Subject: RE: Criteria for handoff from Sent by: rootdevelopment 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 s 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
Re: Criteria for handoff from development
- Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Monday, January 07, 2002 17:30 I just read up on the Extreme Programming. Its a pretty neat concept. Very solid I think. If you want punchy slogans that are instantly memorable, XP is right up your alley. You may check out a wise critique of XP - Cutting Through the Hype... in ObjectiveView #3 at http://www.ratio.co.uk/objectiveview.html#issue3 hth, Marin ...what you brought from your past, is of no use in your present. When you must choose a new path, do not bring old experiences with you. Those who strike out afresh, but who attempt to retain a little of the old life, end up torn apart by their own memories. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Marin Dimitrov 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).
RE: Criteria for handoff from development
eXtreme Programming is like extreme skiing, it's a high risk endeavor and those who can do it perform amazing feats... Of course failure sometimes results in death so it's not for everyone. ;-) Steve Orr -Original Message- Sent: Monday, January 07, 2002 9:28 AM To: Multiple recipients of list ORACLE-L - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Monday, January 07, 2002 17:30 I just read up on the Extreme Programming. Its a pretty neat concept. Very solid I think. If you want punchy slogans that are instantly memorable, XP is right up your alley. You may check out a wise critique of XP - Cutting Through the Hype... in ObjectiveView #3 at http://www.ratio.co.uk/objectiveview.html#issue3 hth, Marin ...what you brought from your past, is of no use in your present. When you must choose a new path, do not bring old experiences with you. Those who strike out afresh, but who attempt to retain a little of the old life, end up torn apart by their own memories. -- 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).
RE: Criteria for handoff from development
Thanks to everyone that replied to this note - Rachel, Kimberly, Jared, Tom, Scott, John, Craig, tday6. I feel that I have gained a better perspective on what my role should be in moving a data model into production. Thanks to all Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Friday, January 04, 2002 1: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: 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).
RE: Criteria for handoff from development
Hum, do you know what was being used for serving up the servlets? We used Tomcat here and did not experience those issues. I believe it was 4.0 although that version does seem to have a memory leak (at least on Unix). -Original Message- [EMAIL PROTECTED] Sent: Monday, January 07, 2002 7:50 AM To: Multiple recipients of list ORACLE-L I was just the DBA, not the JAVA developer, but -- We had a Database server using JDBC to talk to an application server. The application was written in Java and used Java thin client to talk to the client (endusers). The endusers had any Java compliant browser. No applets (security issues -- I don't remember what), only servlets on the application server. It worked great for the developers (2). As soon as the customer accepted the application we let the head developer go (since the customer didn't want to pay for his time anymore). After about the third or fourth customer employee started up a browser session to the application server the browsers started timing out. Tracked it all down and the Java thin client was loosing track of which message went to which workstation. Kimberly SmithTo: Multiple recipients of list ORACLE-L ksmith2 [EMAIL PROTECTED] @myfirstlink.cc: net Subject: RE: Criteria for handoff from Sent by: rootdevelopment 01/07/2002 10:25 AM Please respond to ORACLE-L We never had that issue where I am at. Can you explain it a bit more. What do you mean the client was unable to handle more then two or three connections? Do you mean that you where connecting multiple times from the same java application to the same database? -Original Message- [EMAIL PROTECTED] Sent: Monday, January 07, 2002 6:00 AM To: Multiple recipients of list ORACLE-L Last Java project that I worked on (about 1 year ago), the Java thin client was not robust enough to handle more than two or three connections simultaneously. More than that and the threads got twisted. Client application would hang waiting for a response from the database. The database had sent the response long ago but it never got to the client. Hopefully this has been fixed in later versions of Java. -- 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Kimberly Smith 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Kimberly Smith 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
RE: Criteria for handoff from development
Title: RE: Criteria for handoff from development Dennis, Just a couple of more points that I've found useful in the past: 1) Start looking at the CORE software requirements (assuming requirements or use cases are being developed) so you can get a good understanding of what the system is to do. I said CORE because there is typically a small subset of requirements that have a lot of influence on the design. I typically use this to help understand why the design is the why it is and what will be the hot-spots within the design. 2) Start evaluating the design early (during development) - do not wait until the end of development. I find developers are much more amendable to changing a design when the coding has not been completed. It is also much cheaper for the organisation. 3) Write a standards or design guidelines document before you start and try to get buy-in from the developers/data architect. This will help with producing a consistent design and one that meets your standards. It will also help clarify your own evaluation criteria and allow your criteria to be communicated to the design/development teams so they have an early warning on what is and is not acceptable. This document could also contain some form of data dictionary, for example all money values shall be defined as number(38,6) and will always be associated with a currency column. Or all countries will be stored as ISO Country Codes. I've also written a relational design patterns document which our developers find useful because it gives them the answers to common design problems. 4) Get a strong justification for any de-normalisations that are made. I've found that developers will de-normalise a design from PERCEIVED performance problems. I said perceived because typically there hasn't been any testing to verify that it will be a problem. Anyway, I hope this helps. Good luck. Cheers, Craig. -Original Message- From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]] Sent: Saturday, 5 January 2002 6:45 AM To: Multiple recipients of list ORACLE-L Subject: Criteria for handoff from development 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).
RE: Criteria for handoff from development
Title: RE: Criteria for handoff from development Hi, Just a word of warning about enforcing foreign key relationships. Depending on the Java technology that you use, you might find it impossible to implement foreign keys. For example, some EJB application servers do not understand relationships between entity beans and will insert the data in the wrong order. Cheers, Craig. -Original Message- From: Mercadante, Thomas F [mailto:[EMAIL PROTECTED]] Sent: Saturday, 5 January 2002 7:50 AM To: Multiple recipients of list ORACLE-L Subject: RE: Criteria for handoff from development 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 s 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
RE: Criteria for handoff from development
Title: RE: Criteria for handoff from development Dennis, I would be very careful with RAID 5 if your system is going to be very write intensive. There is a very good white paper on implementing RAID for Oracle on the www.quest.com site. Here is the link for your reference http://www.quest.com/whitepapers/Raid1.pdf Cheers, Craig. -Original Message- From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]] Sent: Saturday, 5 January 2002 10:30 AM To: Multiple recipients of list ORACLE-L Subject: RE: Criteria for handoff from development John - Thanks for bringing up these critical issues: 1. Tools - This is our first Java adventure, so everyone is nervous. Please point out any Java pitfalls that have bitten you. 2. Hot-spot tables - Good issue, will keep it in mind. We are just creating the logical model today. 3. Storage and Tablespace layouts - That would be me. Some input into hardware decisions. On Compaq Tru64 our sys admins have had good luck with RAID5, so will probably insist on that on Sun Solaris. 4. Availability - 24X7. We are looking at RMAN. Too early to think about size, but not terribly large. Maybe 100-gig. tops. Well within the limits of 5. Data transfer not a big issue yet. They have toyed with the idea of replication, and I tried my politically-savvy best to discourage them (as politically-savvy as Dilbert). Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Friday, January 04, 2002 4:55 PM To: Multiple recipients of list ORACLE-L Dennis, In addition to the points mentioned by Tom, I would also ask the following questions: * What tools/clients will be used to populate the data and extract it for reporting? Depending on the tool, your 'performance' will vary... I wouldn't want an MSAccess/ODBC type query running against a 1mil row table that is joined to another 2mil table.. The DBA invariably gets blamed at the end for *any* performance problem! * What is the concurrency requirements and are they being met? In other words, are hot-spot tables present and if so, how can this be mitigated? Note: Increase in no.of.users = decrease in concurrency! * Who's gonna decide the STORAGE parameters and Tablespace layout? Would you have inputs in the Hardware side of things? * What are the availability requirements? How is the backup going to being done? How big would the database grow to? * What is the data transfer requirements between this database and the rest of the databases in the organization? What are the mechanisms to achieve that? (i.e. replication has a significant overhead not only on the network, but also in Admin time!) In short - take a look at all the Production issues that come up in this list and apply the relevant ones. John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 Fear is the darkroom where Evil develops your negatives. Wanna break free of fear? Click on 'http://www.needhim.org' ** The opinions and statements above are entirely my own and not those of my employer or clients ** -Original Message- From: Mercadante, Thomas F [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 12:50 PM To: Multiple recipients of list ORACLE-L Subject: RE: Criteria for handoff from development 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 s 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
RE: Criteria for handoff from development
Your manager is full of sh** (in technical terms). Poorly written queries are usually the problem, more so than any data model. Let me guess, he's the manager for the development team? Scott Shafer San Antonio, TX 210-581-6217 Common sense will not accomplish great things. Simply become insane and desperate. -Original Message- From: DENNIS WILLIAMS [SMTP:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 1:45 PM To: Multiple recipients of list ORACLE-L Subject: Criteria for handoff from development 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: 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).
RE: Criteria for handoff from development
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 s 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).
RE: Criteria for handoff from development
Dennis, In addition to the points mentioned by Tom, I would also ask the following questions: * What tools/clients will be used to populate the data and extract it for reporting? Depending on the tool, your 'performance' will vary... I wouldn't want an MSAccess/ODBC type query running against a 1mil row table that is joined to another 2mil table.. The DBA invariably gets blamed at the end for *any* performance problem! * What is the concurrency requirements and are they being met? In other words, are hot-spot tables present and if so, how can this be mitigated? Note: Increase in no.of.users = decrease in concurrency! * Who's gonna decide the STORAGE parameters and Tablespace layout? Would you have inputs in the Hardware side of things? * What are the availability requirements? How is the backup going to being done? How big would the database grow to? * What is the data transfer requirements between this database and the rest of the databases in the organization? What are the mechanisms to achieve that? (i.e. replication has a significant overhead not only on the network, but also in Admin time!) In short - take a look at all the Production issues that come up in this list and apply the relevant ones. John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 Fear is the darkroom where Evil develops your negatives. Wanna break free of fear? Click on 'http://www.needhim.org' ** The opinions and statements above are entirely my own and not those of my employer or clients ** -Original Message- From: Mercadante, Thomas F [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 12:50 PM To: Multiple recipients of list ORACLE-L Subject: RE: Criteria for handoff from development 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 s 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
RE: Criteria for handoff from development
John - Thanks for bringing up these critical issues: 1. Tools - This is our first Java adventure, so everyone is nervous. Please point out any Java pitfalls that have bitten you. 2. Hot-spot tables - Good issue, will keep it in mind. We are just creating the logical model today. 3. Storage and Tablespace layouts - That would be me. Some input into hardware decisions. On Compaq Tru64 our sys admins have had good luck with RAID5, so will probably insist on that on Sun Solaris. 4. Availability - 24X7. We are looking at RMAN. Too early to think about size, but not terribly large. Maybe 100-gig. tops. Well within the limits of 5. Data transfer not a big issue yet. They have toyed with the idea of replication, and I tried my politically-savvy best to discourage them (as politically-savvy as Dilbert). Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Friday, January 04, 2002 4:55 PM To: Multiple recipients of list ORACLE-L Dennis, In addition to the points mentioned by Tom, I would also ask the following questions: * What tools/clients will be used to populate the data and extract it for reporting? Depending on the tool, your 'performance' will vary... I wouldn't want an MSAccess/ODBC type query running against a 1mil row table that is joined to another 2mil table.. The DBA invariably gets blamed at the end for *any* performance problem! * What is the concurrency requirements and are they being met? In other words, are hot-spot tables present and if so, how can this be mitigated? Note: Increase in no.of.users = decrease in concurrency! * Who's gonna decide the STORAGE parameters and Tablespace layout? Would you have inputs in the Hardware side of things? * What are the availability requirements? How is the backup going to being done? How big would the database grow to? * What is the data transfer requirements between this database and the rest of the databases in the organization? What are the mechanisms to achieve that? (i.e. replication has a significant overhead not only on the network, but also in Admin time!) In short - take a look at all the Production issues that come up in this list and apply the relevant ones. John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 Fear is the darkroom where Evil develops your negatives. Wanna break free of fear? Click on 'http://www.needhim.org' ** The opinions and statements above are entirely my own and not those of my employer or clients ** -Original Message- From: Mercadante, Thomas F [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 12:50 PM To: Multiple recipients of list ORACLE-L Subject: RE: Criteria for handoff from development 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 s 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
Re: Criteria for handoff from development
the manager is wrong -- as a model will NOT tell you where additional indexes could be helpful. While a look at the queries could. What I've always done is sit with the architect and go over each entity and see if it should be denormalized for performance (it's all well and good to have a separate table for addresses for a customer, but it still might be worthwhile to keep the primary address within the customer table itself). Check that all foreign keys are properly defined, you'll need to know them to build the indices so you don't hang on updates. Hm look for common sense changes. As an example, at one place we ended up with this insane set of tables to define address because an address could be a street address, email address, phone number, etc etc. We had address_element, address_element_format, address_element_in_address etc etc at which point I just said NO. that should get you started Rachel --- DENNIS WILLIAMS [EMAIL PROTECTED] wrote: 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). __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael 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).
Re: Criteria for handoff from development
You're getting lots of good replies to this Dennis. One thing I wanted to mention that I had seen yet: A data architect is going to give you a data model. This does not necessarily resemble the logical data model or the database design. When handed a model to implement as a database, there is likely yet a lot of work today. The bigger and more complex the model, the more the database may differ from it. What is on the model is entities, attributes and relations. This may not be a 1 to 1 translation to tables, and is actually not likely to be. A model will contain UID's or Unique Identifiers. Many DBA's ( myself included ) will NOT use these for Primary Keys. Add your own Primary Keys and use the UID's as Unique Keys. It will save you a lot of work later when the business rules change ( they *always* change ) as long as you don't use the UK's in FK relations. Just use PK's for those. As for business rules, the data architect will likely map those out in some form, but the won't show up on the ERD. Even rules that can be expressed in an ERD need to be defined somewhere else, even if it's just MS Word. As for those BR that can't be defined in the ERD, where will they reside? In a middle tier? Triggers and packages? Or in the ( shudder ) application code? A data model is a *long* way from a working database, so there are a lot of places for you to exercise your discretion as a DBA. Jared DENNIS WILLIAMS DWILLIAMS@LIFE To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] TOUCH.COMcc: Sent by: Subject: Criteria for handoff from development [EMAIL PROTECTED] m 01/04/02 11:45 AM Please respond to 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: INET: [EMAIL
RE: Criteria for handoff from development
The only Java pitfall I have seen is making sure that developers close their statements after they are done with them. Other then that I have seen no issues (related to Oracle that is). -Original Message- WILLIAMS Sent: Friday, January 04, 2002 3:30 PM To: Multiple recipients of list ORACLE-L John - Thanks for bringing up these critical issues: 1. Tools - This is our first Java adventure, so everyone is nervous. Please point out any Java pitfalls that have bitten you. 2. Hot-spot tables - Good issue, will keep it in mind. We are just creating the logical model today. 3. Storage and Tablespace layouts - That would be me. Some input into hardware decisions. On Compaq Tru64 our sys admins have had good luck with RAID5, so will probably insist on that on Sun Solaris. 4. Availability - 24X7. We are looking at RMAN. Too early to think about size, but not terribly large. Maybe 100-gig. tops. Well within the limits of 5. Data transfer not a big issue yet. They have toyed with the idea of replication, and I tried my politically-savvy best to discourage them (as politically-savvy as Dilbert). Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Friday, January 04, 2002 4:55 PM To: Multiple recipients of list ORACLE-L Dennis, In addition to the points mentioned by Tom, I would also ask the following questions: * What tools/clients will be used to populate the data and extract it for reporting? Depending on the tool, your 'performance' will vary... I wouldn't want an MSAccess/ODBC type query running against a 1mil row table that is joined to another 2mil table.. The DBA invariably gets blamed at the end for *any* performance problem! * What is the concurrency requirements and are they being met? In other words, are hot-spot tables present and if so, how can this be mitigated? Note: Increase in no.of.users = decrease in concurrency! * Who's gonna decide the STORAGE parameters and Tablespace layout? Would you have inputs in the Hardware side of things? * What are the availability requirements? How is the backup going to being done? How big would the database grow to? * What is the data transfer requirements between this database and the rest of the databases in the organization? What are the mechanisms to achieve that? (i.e. replication has a significant overhead not only on the network, but also in Admin time!) In short - take a look at all the Production issues that come up in this list and apply the relevant ones. John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 Fear is the darkroom where Evil develops your negatives. Wanna break free of fear? Click on 'http://www.needhim.org' ** The opinions and statements above are entirely my own and not those of my employer or clients ** -Original Message- From: Mercadante, Thomas F [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 12:50 PM To: Multiple recipients of list ORACLE-L Subject: RE: Criteria for handoff from development 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 s 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
RE: Criteria for handoff from development
Well, I would fire your manager for starts. You most definitely need to see the SQL. Having the most excellent design in no way stops developers from being stupid. However, that being said, you should review the design. You are the one that has to live with it. Number one, make sure they are consistent. This is especially true with things like where the same column is in multiple tables (for whatever reason) and is a different length in each. Make sure that all the tables have primary keys and that those primary keys are not intelligent. Make sure the appropriate foreign keys are present. Make sure that they keep the design somewhat in 3rd normal form. Blah blah blah Question anything that you think is funny looking. Go to them and say why did you do this that way? They should be able to explain it to you and you should get a warm and fuzzy. If you don't keep at them. I am a big supporter of having ones work reviewed. As the DBA you are the best person to review the Data Architect. -Original Message- WILLIAMS Sent: Friday, January 04, 2002 11:45 AM 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: Kimberly Smith 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).
RE: Criteria for handoff from development
you reminded me of another few: make sure that number columns/primary keys are really numeric (I have a 3rd party design that doesn't) make sure that char columns really need to BE char columns. This can cause you problems way down the line on the other hand, don't indiscriminately create varchar2 columns of length 255 or 2000 or whatever the max is in the version you are running. Just because you CAN do it is not necessarily a reason TO do it --- Kimberly Smith [EMAIL PROTECTED] wrote: Well, I would fire your manager for starts. You most definitely need to see the SQL. Having the most excellent design in no way stops developers from being stupid. However, that being said, you should review the design. You are the one that has to live with it. Number one, make sure they are consistent. This is especially true with things like where the same column is in multiple tables (for whatever reason) and is a different length in each. Make sure that all the tables have primary keys and that those primary keys are not intelligent. Make sure the appropriate foreign keys are present. Make sure that they keep the design somewhat in 3rd normal form. Blah blah blah Question anything that you think is funny looking. Go to them and say why did you do this that way? They should be able to explain it to you and you should get a warm and fuzzy. If you don't keep at them. I am a big supporter of having ones work reviewed. As the DBA you are the best person to review the Data Architect. -Original Message- WILLIAMS Sent: Friday, January 04, 2002 11:45 AM 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: Kimberly Smith 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). __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael 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).
RE: Criteria for handoff from development
make sure they use Java prepared statements, especially if they are using lots of literals. mine didn't -- I had to turn cursor_sharing=force on to solve shared pool problems --- Kimberly Smith [EMAIL PROTECTED] wrote: The only Java pitfall I have seen is making sure that developers close their statements after they are done with them. Other then that I have seen no issues (related to Oracle that is). -Original Message- WILLIAMS Sent: Friday, January 04, 2002 3:30 PM To: Multiple recipients of list ORACLE-L John - Thanks for bringing up these critical issues: 1. Tools - This is our first Java adventure, so everyone is nervous. Please point out any Java pitfalls that have bitten you. 2. Hot-spot tables - Good issue, will keep it in mind. We are just creating the logical model today. 3. Storage and Tablespace layouts - That would be me. Some input into hardware decisions. On Compaq Tru64 our sys admins have had good luck with RAID5, so will probably insist on that on Sun Solaris. 4. Availability - 24X7. We are looking at RMAN. Too early to think about size, but not terribly large. Maybe 100-gig. tops. Well within the limits of 5. Data transfer not a big issue yet. They have toyed with the idea of replication, and I tried my politically-savvy best to discourage them (as politically-savvy as Dilbert). Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Friday, January 04, 2002 4:55 PM To: Multiple recipients of list ORACLE-L Dennis, In addition to the points mentioned by Tom, I would also ask the following questions: * What tools/clients will be used to populate the data and extract it for reporting? Depending on the tool, your 'performance' will vary... I wouldn't want an MSAccess/ODBC type query running against a 1mil row table that is joined to another 2mil table.. The DBA invariably gets blamed at the end for *any* performance problem! * What is the concurrency requirements and are they being met? In other words, are hot-spot tables present and if so, how can this be mitigated? Note: Increase in no.of.users = decrease in concurrency! * Who's gonna decide the STORAGE parameters and Tablespace layout? Would you have inputs in the Hardware side of things? * What are the availability requirements? How is the backup going to being done? How big would the database grow to? * What is the data transfer requirements between this database and the rest of the databases in the organization? What are the mechanisms to achieve that? (i.e. replication has a significant overhead not only on the network, but also in Admin time!) In short - take a look at all the Production issues that come up in this list and apply the relevant ones. John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 Fear is the darkroom where Evil develops your negatives. Wanna break free of fear? Click on 'http://www.needhim.org' ** The opinions and statements above are entirely my own and not those of my employer or clients ** -Original Message- From: Mercadante, Thomas F [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 12:50 PM To: Multiple recipients of list ORACLE-L Subject: RE: Criteria for handoff from development 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 s 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
RE: Criteria for handoff from development
It must have been my blah, blah, blah that reminded you;-) -Original Message- Carmichael Sent: Friday, January 04, 2002 6:56 PM To: Multiple recipients of list ORACLE-L you reminded me of another few: make sure that number columns/primary keys are really numeric (I have a 3rd party design that doesn't) make sure that char columns really need to BE char columns. This can cause you problems way down the line on the other hand, don't indiscriminately create varchar2 columns of length 255 or 2000 or whatever the max is in the version you are running. Just because you CAN do it is not necessarily a reason TO do it --- Kimberly Smith [EMAIL PROTECTED] wrote: Well, I would fire your manager for starts. You most definitely need to see the SQL. Having the most excellent design in no way stops developers from being stupid. However, that being said, you should review the design. You are the one that has to live with it. Number one, make sure they are consistent. This is especially true with things like where the same column is in multiple tables (for whatever reason) and is a different length in each. Make sure that all the tables have primary keys and that those primary keys are not intelligent. Make sure the appropriate foreign keys are present. Make sure that they keep the design somewhat in 3rd normal form. Blah blah blah Question anything that you think is funny looking. Go to them and say why did you do this that way? They should be able to explain it to you and you should get a warm and fuzzy. If you don't keep at them. I am a big supporter of having ones work reviewed. As the DBA you are the best person to review the Data Architect. -Original Message- WILLIAMS Sent: Friday, January 04, 2002 11:45 AM 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: Kimberly Smith 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). __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael 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
