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 F" To: Multiple recipients > of list > ORACLE-L > <NDATFM <[EMAIL PROTECTED]> > @labor.state. cc: > ny.us> Subject: RE: Criteria > for > handoff from > Sent by: root development > > > 01/04/2002 > 03:50 PM > Please > respond to > ORACLE-L > > > > > > > Dennis, > > First of all, I would tell your manager that 90% of tuning is in > writing > good queries no matter what the data model looks like. > > Unfortunately, you receiving a data model and expecting to perform > miracles > is pretty naive of the organization. This is a classic example of > how NOT > to do things. > > Saying that, I would look closely at the model and check for the > following: > > Look closely for normalization problems. If you see repeating fields > in a > table, reject it and tell them to change it. > > Look for column-naming standards. If they do not have them, make > some up > and enforce them. Some common naming standards would use a suffix to > indicate the type of data the column is holding. Things like _DATE > _NBR > _FNAME _LNAME _ID and _CODE would indicate date, number, standard > length > first and last name, Id type columns indicating it is a primary key > (possibly) an integer value, and a Code column indicating that this > is a > foreign key to another table. This is soooo important for > report-writing > people on the back-end of the project. They can implicitly see that > the > column has a certain value by the name. > > Ask how they determined primary key values for all tables. > Specifically, > how do they KNOW that the values will be unique. Question everything > you > see. This is probably the biggest area of concern that I would have. > Non-db designers will always make a mistake here. I developed a db > once > that used the soc-sec as the pk. WRONG! The db was at a college. > Want to > know how many parents use their personal soc-sec on the application > for the > child? :( > > Look for obvious foreign key relationships and enforce them. Develop > a > standard where the related columns in database tables (like FK > columns) > have > the same name in both tables (like soc_sec_number is named the same > in all > tables). > > This is not an easy thing to do. You should have been involved in > the > meetings from the very get-go. Hopefully, this is not a 300-table > design > that will take you very long to review. > > Hope these help! > > Tom Mercadante > Oracle Certified Professional > > > -----Original Message----- > Sent: Friday, January 04, 2002 2:45 PM > To: Multiple recipients of list ORACLE-L > > > Can anyone provide some criteria of what you look for when a data > model is > handed off from production? We are starting a large development > project and > I lobbied management to hire a data architect. As they have talked to > these > people, they are getting statements such as "and then the DBA will > check > out > the data model to make sure there won't be any performance problems". > I am > concerned about what will be expected of me and wondered how other > DBAs > handle this situation. What do you look for in a model in terms of > making > sure the performance will be good? I said that I could look at the > queries > that would be run to see how many tables would need to be joined to > retrieve > the data, but the manager replied that a good DBA wouldn't need to > see the > queries, should just be able to look at the model. Up until this > point, our > client-server design tools have tended to protect the developers from > doing > dumb stuff, but now in the Java world some of those safeguards. > > Dennis Williams > DBA > Lifetouch, Inc. > [EMAIL PROTECTED] > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: DENNIS WILLIAMS > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing > Lists > -------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Mercadante, Thomas F > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing > Lists > -------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > === message truncated === __________________________________________________ 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).
