What needs to consider when adding a password to the table

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2008 » T-SQL (SS2K8) » What needs to consider when adding a password...

What needs to consider when adding a password to the table

Rate Topic

Display Mode

Topic Options

Author

Message

asita

Posted Thursday, March 14, 2013 2:41 PM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, May 10, 2013 7:46 AM
Points: 106, Visits: 206

Hi There,

Could you please help me out, i have table with 9 columns and about a million rows,

i need to add primary key, so what things do i need to consider here,

what if my table has no unique column / columns(composite), wat can do in this situation

adding a id field (just 1 to .... so on) and then making this pk, does makes any sense?

could you please help me out here

Thanks a ton in advance
dhani

Post #1431268

Sean Lange

Posted Thursday, March 14, 2013 3:01 PM

SSCrazy Eights

Group: General Forum Members
Last Login: Friday, May 17, 2013 8:46 AM
Points: 8,547, Visits: 8,204

Yes if there is no natural key you should add something like an identity column and make that your primary key.

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs

Post #1431275

asita

Posted Thursday, March 14, 2013 4:16 PM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, May 10, 2013 7:46 AM
Points: 106, Visits: 206

Thank you Sean Lange

so by adding like this does help any way data retrival,

also one more doubt is, in this table (where i want to add primary key),

in the procedue (runs daily) loads data to the above table (several updates/deletes/inserts to this table)

does having pk at table level will be help full? or in the proc itself first remove pk then do several actions (DML) then add pk at end does better?

which one do you suggest

please help me...

thanks
dhanvi

Post #1431289

Jeff Moden

Posted Thursday, March 14, 2013 9:12 PM

SSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 9:57 PM
Points: 32,893, Visits: 26,771

asita (3/14/2013)

What is your join criteria for the updates and deletes?

--Jeff Moden

"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Post #1431342

asita

Posted Thursday, March 14, 2013 11:31 PM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, May 10, 2013 7:46 AM
Points: 106, Visits: 206

hi jeff,

thank you,

the criteria is mainly on account number, which is part of or primary key,

please suggest to have pk at table level rather every time remove pk before proc executes then add it at the end of proc execution?

thank you
dhanvi[quote][/quote]

Post #1431362

Eugene Elutin

Posted Friday, March 15, 2013 6:07 AM

SSCrazy

Group: General Forum Members
Last Login: Friday, May 17, 2013 10:59 AM
Points: 2,525, Visits: 4,324

please suggest to have pk at table level

I guess you have no choice here. PK can only be set "at table level"

...every time remove pk before proc executes then add it at the end of proc execution?

That would be worse possible design. PK shouldn't be dropped and recreated in order to run any stored proc (eg. the one which populates table.)
If you worry about data which potentially will not load due to duplicate values in the PK column, use staging table where it's not PK, validate and then load only valid data into your final destination table.

_____________________________________________
"The only true wisdom is in knowing you know nothing"
"O skol'ko nam otkrytiy chudnyh prevnosit microsofta duh!" BigGrin

(So many miracle inventions provided by MS to us...)

How to post your question to get the best and quick help

Post #1431489

« Prev Topic | Next Topic »

Permissions