Appropriate Index

I have a table where data is deleted, inserted and updated. What kind of
index is appropriate for the column
where data is deleted ?
where data is inserted ?
where data is updated ?
Thanks for any input."DXC" <DXC@.discussions.microsoft.com> wrote in message
news:945F0AE5-AB17-4D18-8A35-312F4DB6E16F@.microsoft.com...
> I have a table where data is deleted, inserted and updated. What kind of
> index is appropriate for the column
> where data is deleted ?
> where data is inserted ?
> where data is updated ?
> Thanks for any input.
This depends on many things. If you post some DDL, we can help you out.
Read up on Indexes in the BOL for some tips on which columns are good
candidates for indexes and which ones are not.
Rick Sawtell
MCT, MCSD, MCDBA

Appropriate Index

I have a table where data is deleted, inserted and updated. What kind of
index is appropriate for the column
where data is deleted ?
where data is inserted ?
where data is updated ?
Thanks for any input.
"DXC" <DXC@.discussions.microsoft.com> wrote in message
news:945F0AE5-AB17-4D18-8A35-312F4DB6E16F@.microsoft.com...
> I have a table where data is deleted, inserted and updated. What kind of
> index is appropriate for the column
> where data is deleted ?
> where data is inserted ?
> where data is updated ?
> Thanks for any input.
This depends on many things. If you post some DDL, we can help you out.
Read up on Indexes in the BOL for some tips on which columns are good
candidates for indexes and which ones are not.
Rick Sawtell
MCT, MCSD, MCDBA

Appropriate Index

I have a table where data is deleted, inserted and updated. What kind of
index is appropriate for the column
where data is deleted ?
where data is inserted ?
where data is updated ?
Thanks for any input."DXC" <DXC@.discussions.microsoft.com> wrote in message
news:945F0AE5-AB17-4D18-8A35-312F4DB6E16F@.microsoft.com...
> I have a table where data is deleted, inserted and updated. What kind of
> index is appropriate for the column
> where data is deleted ?
> where data is inserted ?
> where data is updated ?
> Thanks for any input.
This depends on many things. If you post some DDL, we can help you out.
Read up on Indexes in the BOL for some tips on which columns are good
candidates for indexes and which ones are not.
Rick Sawtell
MCT, MCSD, MCDBA

Applying Full Text on a document whose path is stored in the database

Hi,

Can we create full-text index on a document that resides on a file system and we have got the path to that document in the database.

Thanks and regards
Salil

I don't think you can do this in current versions of SQL, though i have seen it suggested for future versions. Whether it will be in 2008 or not is probably a question for the Katmai forum.

In saying that, I think a possible workaround is to use Index Server to index your documents which can then be queried via a linked server.

Of course, you are able to store the documents in an IMAGE/VARBINARY(MAX) column which can be fulltext indexed.

HTH!

Applying Full Text on a document whose path is stored in the database

Hi,

Can we create full-text index on a document that resides on a file system and we have got the path to that document in the database.

Thanks and regards
Salil

I don't think you can do this in current versions of SQL, though i have seen it suggested for future versions. Whether it will be in 2008 or not is probably a question for the Katmai forum.

In saying that, I think a possible workaround is to use Index Server to index your documents which can then be queried via a linked server.

Of course, you are able to store the documents in an IMAGE/VARBINARY(MAX) column which can be fulltext indexed.

HTH!

Anyway to quick ntext Search

Helloo..
I there anyway to make ntext search faster'
I have a table of legal documents with 2 million text record, While no full
text index & search on text fields searching with "Like is very very slow".
I need anyway to make it faster using any techniques..
Do i need to use cursor or how can i solve this issue'
I can't use nvarchar coz of size limititionIslamegy wrote on Wed, 23 Nov 2005 14:18:28 +0200:

> Helloo..
> I there anyway to make ntext search faster'
> I have a table of legal documents with 2 million text record, While no
> full text index & search on text fields searching with "Like is very very
> slow". I need anyway to make it faster using any techniques..
> Do i need to use cursor or how can i solve this issue'
> I can't use nvarchar coz of size limitition
Any particular reason why you can't use Full Text Search?
Dan|||Because Full Text index dosn't apply of Text Fields of type "text",
"ntext"!!!
"Daniel Crichton" <msnews@.worldofspack.co.uk> wrote in message
news:ujyy8%23C8FHA.956@.TK2MSFTNGP10.phx.gbl...
> Islamegy wrote on Wed, 23 Nov 2005 14:18:28 +0200:
>
> Any particular reason why you can't use Full Text Search?
> Dan
>|||Islamegy wrote on Wed, 23 Nov 2005 15:27:02 +0200:

> Because Full Text index dosn't apply of Text Fields of type "text",
> "ntext"!!!
Yes it does. I'm using it on a text column in one of my databases!
Dan|||Yes, performing a non-indexed search on the text of 2 million documents is
going to be slow. I'm surprised that it's just optimization you are
concerned with and the actual feasability.
Of course, consider using the Full-Text feature.
If you must perform LIKE comparisons on the rows, perhaps it would be
possible to run a process that parses the text of each document and then
stores key words in something like a 120 length varchar column.
For example:
Jacobs;California;McNeal;disability;insu
rance;claim
Once done, this column could be used for LIKE searches.
"Islamegy" <NULL_Islamegy_NULL@.yahoo.com> wrote in message
news:OoYHFgC8FHA.1420@.TK2MSFTNGP09.phx.gbl...
> Helloo..
> I there anyway to make ntext search faster'
> I have a table of legal documents with 2 million text record, While no
> full text index & search on text fields searching with "Like is very very
> slow".
> I need anyway to make it faster using any techniques..
> Do i need to use cursor or how can i solve this issue'
> I can't use nvarchar coz of size limitition
>|||Why would you think that? It does in fact work on text and ntext columns.
Robbe Morris - 2004/2005 Microsoft MVP C#
http://www.masterado.net
"Islamegy" <NULL_Islamegy_NULL@.yahoo.com> wrote in message
news:evIRZGD8FHA.2036@.TK2MSFTNGP14.phx.gbl...
> Because Full Text index dosn't apply of Text Fields of type "text",
> "ntext"!!!
> "Daniel Crichton" <msnews@.worldofspack.co.uk> wrote in message
> news:ujyy8%23C8FHA.956@.TK2MSFTNGP10.phx.gbl...
>|||How do u do it' When i try to use "Contain(Text column,"some words").. it
don't accept my query!!
As i know from my research it dosn't work on text..
Anyway my database is Arabic, so i thought ntext is ok but when i converted
it to text it became 20% faster.
Also finally i discovered that collation is work as a magic. When i switched
it from Arabic_CI_AI to Arabic_BIN this cut the search time to the half. for
now this is really so great success, if you have anyone have ideas for more
improvment plz let me now..
thanx
"Daniel Crichton" <msnews@.worldofspack.co.uk> wrote in message
news:%23wC2$MD8FHA.2676@.TK2MSFTNGP15.phx.gbl...
> Islamegy wrote on Wed, 23 Nov 2005 15:27:02 +0200:
>
> Yes it does. I'm using it on a text column in one of my databases!
> Dan
>|||Islamegy wrote on Wed, 23 Nov 2005 15:48:54 +0200:

> How do u do it' When i try to use "Contain(Text column,"some words").. it
> don't accept my query!!
> As i know from my research it dosn't work on text..
I'm guessing you haven't created the FTS index yet. Read BOL on how to do
this.

> Anyway my database is Arabic, so i thought ntext is ok but when i
> converted it to text it became 20% faster.
> Also finally i discovered that collation is work as a magic. When i
> switched it from Arabic_CI_AI to Arabic_BIN this cut the search time to
> the half. for now this is really so great success, if you have anyone have
> ideas for more improvment plz let me now..
Using FTS you might see a significant improvement. You'd do well to post
questions about it microsoft.public.sqlserver.fulltext
Dan|||Keep in mind that text stores text in ANSI (1 byte per character) and ntext
stores the text in Unicode (2 bytes per character) format. This is why ntext
will require more disk storage and operations on the data will be somewhat
slower. If the character set is Arabic, then you have no other choice but
the use Unicode.
"Islamegy" <NULL_Islamegy_NULL@.yahoo.com> wrote in message
news:OretoSD8FHA.1248@.TK2MSFTNGP14.phx.gbl...
> How do u do it' When i try to use "Contain(Text column,"some words").. it
> don't accept my query!!
> As i know from my research it dosn't work on text..
> Anyway my database is Arabic, so i thought ntext is ok but when i
> converted it to text it became 20% faster.
> Also finally i discovered that collation is work as a magic. When i
> switched it from Arabic_CI_AI to Arabic_BIN this cut the search time to
> the half. for now this is really so great success, if you have anyone have
> ideas for more improvment plz let me now..
> thanx
> "Daniel Crichton" <msnews@.worldofspack.co.uk> wrote in message
> news:%23wC2$MD8FHA.2676@.TK2MSFTNGP15.phx.gbl...
>

Anything wrong with this query?

For a given table, I want to know all the columns that are included in
an index. I have looked on the web and come up with this, which seems
to work, but just wanted some verification. Are there any reasons why
I should be using the metadata functions like OBJECT_NAME?

Thanks
Bruce

SELECT
DISTINCT c.name
from sysusers u,
sysobjects o,
syscolumns c,
sysindexes i,
sysindexkeys k
WHERE o.uid = u.uid
AND u.name = user
AND o.name = 'ing_customer'
AND o.id = i.id
AND i.indid = k.indid
AND OBJECTPROPERTY( i.id, 'IsMSShipped' ) = 0
AND 1 NOT IN ( INDEXPROPERTY( i.id , i.name , 'IsStatistics' ) ,
INDEXPROPERTY( i.id , i.name , 'IsAutoStatistics' ) ,
INDEXPROPERTY( i.id , i.name , 'IsHypothetical' ) )
AND i.indid BETWEEN 1 And 250
AND k.id = o.id
and k.colid = c.colid
and c.id = o.id
ORDER BY c.nameBruce (sandell@.pacbell.net) writes:
> For a given table, I want to know all the columns that are included in
> an index. I have looked on the web and come up with this, which seems
> to work, but just wanted some verification. Are there any reasons why
> I should be using the metadata functions like OBJECT_NAME?

object_name() is just a quick-step to sysobjects.name, which is a
documented column, so which one you use, is no big deal.

On the other hand, the information returned by objectproperty() and
indexproperty() is hidden in undocuemented columns, so in this case,
you should definitely use the metadata functions.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp