Showing posts with label book. Show all posts
Showing posts with label book. Show all posts

Monday, March 26, 2012

Info on data replication on sql server 2000.

Hi,
I'm in need of detailed information on how data replication works on the
sql server 2000. If someone knows about a book or articles that
describes how data replication works with transactions, stored
procedures and/or merging databases I would like to be pointed in the
right direction.

/Zero_Addiction.Hi

This is a new release from MVP, Hilary Cotter, and I haven't had a chance to
read it myself yet, but it does says there are 45 pages of information on
internals!

http://www.nwsu.com/0974973602.html

John
"zero_addiction" <j-e@.mail.com> wrote in message
news:cmlng6$6mh$1@.news.cybercity.dk...
> Hi,
> I'm in need of detailed information on how data replication works on the
> sql server 2000. If someone knows about a book or articles that describes
> how data replication works with transactions, stored procedures and/or
> merging databases I would like to be pointed in the right direction.
> /Zero_Addiction.

Wednesday, March 21, 2012

Indexing strategies

Dear all,
I'd like to explore more about indexing strategies and would appreciate
a reference to some good resources this regard including book names.

Best regardsThis is your best choice (In my opinion)

Inside Microsoft SQL Server 2000
by Kalen Delaney
http://www.amazon.com/exec/obidos/t...=glance&s=books

Denis the SQL Menace
http://sqlservercode.blogspot.com/

Wednesday, March 7, 2012

indexes on foreign key columns?

I read recently in an ADO.NET book that I should create indexes on foreign
key constraints if they will commonly be used when joining. I can't
remember where, but I could swear that I had read somewhere else that
indexes were automatically created when you assign a foreign key constraint
to a column. What's the deal?
Joel Lyons
Hi Joel
You should create (yourself) indexes on referencing columns in a foreign key
constraint as it will improve things like the checking of the column when you
change a referenced value (for instance when you delete a row in the
referenced table). The referenced table will already have a primary key or a
unique index on the column being referenced.
John
"Joel Lyons" wrote:

> I read recently in an ADO.NET book that I should create indexes on foreign
> key constraints if they will commonly be used when joining. I can't
> remember where, but I could swear that I had read somewhere else that
> indexes were automatically created when you assign a foreign key constraint
> to a column. What's the deal?
> Joel Lyons
>
>
|||Hi Joel
Indexes are NOT automatically created on foreign keys, and it is usually a
good idea to create them. Even if you don't specifically write joins between
foreign and primary keys, if you ever allow deletes or updates to the
primary keys, SQL Server does an internal join to find matching FK values,
and an index can help the performance of the data modification.
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://sqlblog.com
"Joel Lyons" <joell_REMOVE_@.novarad.net> wrote in message
news:eTWbqWyIIHA.1212@.TK2MSFTNGP05.phx.gbl...
>I read recently in an ADO.NET book that I should create indexes on foreign
> key constraints if they will commonly be used when joining. I can't
> remember where, but I could swear that I had read somewhere else that
> indexes were automatically created when you assign a foreign key
> constraint
> to a column. What's the deal?
> Joel Lyons
>

indexes on foreign key columns?

I read recently in an ADO.NET book that I should create indexes on foreign
key constraints if they will commonly be used when joining. I can't
remember where, but I could swear that I had read somewhere else that
indexes were automatically created when you assign a foreign key constraint
to a column. What's the deal?
Joel LyonsHi Joel
You should create (yourself) indexes on referencing columns in a foreign key
constraint as it will improve things like the checking of the column when yo
u
change a referenced value (for instance when you delete a row in the
referenced table). The referenced table will already have a primary key or a
unique index on the column being referenced.
John
"Joel Lyons" wrote:

> I read recently in an ADO.NET book that I should create indexes on foreign
> key constraints if they will commonly be used when joining. I can't
> remember where, but I could swear that I had read somewhere else that
> indexes were automatically created when you assign a foreign key constrain
t
> to a column. What's the deal?
> Joel Lyons
>
>|||Hi Joel
Indexes are NOT automatically created on foreign keys, and it is usually a
good idea to create them. Even if you don't specifically write joins between
foreign and primary keys, if you ever allow deletes or updates to the
primary keys, SQL Server does an internal join to find matching FK values,
and an index can help the performance of the data modification.
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://sqlblog.com
"Joel Lyons" <joell_REMOVE_@.novarad.net> wrote in message
news:eTWbqWyIIHA.1212@.TK2MSFTNGP05.phx.gbl...
>I read recently in an ADO.NET book that I should create indexes on foreign
> key constraints if they will commonly be used when joining. I can't
> remember where, but I could swear that I had read somewhere else that
> indexes were automatically created when you assign a foreign key
> constraint
> to a column. What's the deal?
> Joel Lyons
>

indexes on foreign key columns?

I read recently in an ADO.NET book that I should create indexes on foreign
key constraints if they will commonly be used when joining. I can't
remember where, but I could swear that I had read somewhere else that
indexes were automatically created when you assign a foreign key constraint
to a column. What's the deal?
Joel LyonsHi Joel
You should create (yourself) indexes on referencing columns in a foreign key
constraint as it will improve things like the checking of the column when you
change a referenced value (for instance when you delete a row in the
referenced table). The referenced table will already have a primary key or a
unique index on the column being referenced.
John
"Joel Lyons" wrote:
> I read recently in an ADO.NET book that I should create indexes on foreign
> key constraints if they will commonly be used when joining. I can't
> remember where, but I could swear that I had read somewhere else that
> indexes were automatically created when you assign a foreign key constraint
> to a column. What's the deal?
> Joel Lyons
>
>|||Hi Joel
Indexes are NOT automatically created on foreign keys, and it is usually a
good idea to create them. Even if you don't specifically write joins between
foreign and primary keys, if you ever allow deletes or updates to the
primary keys, SQL Server does an internal join to find matching FK values,
and an index can help the performance of the data modification.
--
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://sqlblog.com
"Joel Lyons" <joell_REMOVE_@.novarad.net> wrote in message
news:eTWbqWyIIHA.1212@.TK2MSFTNGP05.phx.gbl...
>I read recently in an ADO.NET book that I should create indexes on foreign
> key constraints if they will commonly be used when joining. I can't
> remember where, but I could swear that I had read somewhere else that
> indexes were automatically created when you assign a foreign key
> constraint
> to a column. What's the deal?
> Joel Lyons
>