bmgoa
asked on
Index design and synchronization
Hello,
we have a table like:
Table X
(
id bigint,
nam varchar(10),
stock varchar(5),
Updated_Date datetime
)
we insert records into the above Table X at a high rate in a multi-threaded fashion.
now, the id should be picked up from another table RefId.
Table RefID
(
NextUseID int
)
This RefID table stores the Id to be used next when inserting into X and then we have to increment NextUseId by 1.
I query Table X extensively on nam and stock fields.
the updated_datetime is to be populated using getdate().
Now my question i)is what would be the ideal candidates for indexes on X
2)how should i ensure the NextUseId is
not corrupted via multithreaded references.i.e. several clients wanting to insert into X will read nextuseid and then increment it by 1.If this is simulaneous, then there will be data integrity issues.
we have not yet decided on whether to use Sql2k or 2005. so a genric soln would be appreaciated
Regards
bm
we have a table like:
Table X
(
id bigint,
nam varchar(10),
stock varchar(5),
Updated_Date datetime
)
we insert records into the above Table X at a high rate in a multi-threaded fashion.
now, the id should be picked up from another table RefId.
Table RefID
(
NextUseID int
)
This RefID table stores the Id to be used next when inserting into X and then we have to increment NextUseId by 1.
I query Table X extensively on nam and stock fields.
the updated_datetime is to be populated using getdate().
Now my question i)is what would be the ideal candidates for indexes on X
2)how should i ensure the NextUseId is
not corrupted via multithreaded references.i.e. several clients wanting to insert into X will read nextuseid and then increment it by 1.If this is simulaneous, then there will be data integrity issues.
we have not yet decided on whether to use Sql2k or 2005. so a genric soln would be appreaciated
Regards
bm
I totally agree with Angelll ( identity )
Table X
(
id bigint IDENTITY (1, 1) NOT NULL,
nam varchar(10),
stock varchar(5),
Updated_Date datetime
)
As for indexing
" query Table X extensively on nam and stock fields."
You've answered your own question here then - "name" & "stock"
Table X
(
id bigint IDENTITY (1, 1) NOT NULL,
nam varchar(10),
stock varchar(5),
Updated_Date datetime
)
As for indexing
" query Table X extensively on nam and stock fields."
You've answered your own question here then - "name" & "stock"
ASKER
Hello ,
Yeah , i thought of that but i need to recycle the ID i.e. when the ID value crosses a certain threshold, i need to reset it to an old value. e.g. ID is greater than 99999 then reset it to 33333.
can this be safely done in an multithreaded insert enviroement using identity?
Yeah , i thought of that but i need to recycle the ID i.e. when the ID value crosses a certain threshold, i need to reset it to an old value. e.g. ID is greater than 99999 then reset it to 33333.
can this be safely done in an multithreaded insert enviroement using identity?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
if your resetting id's like that perhaps a re think of your database design might be useful. In particular a good look at exactly what you are trying to achieve here and why ?
re using id's, I've always found this to be a bit dangerous !
re using id's, I've always found this to be a bit dangerous !
SOLUTION
![Avatar of Guy Hengel [angelIII / a3]](https://filedb.experts-exchange.com/files/public/2013/11/25/ddbe0ea6-aa6e-4279-b781-57b735dd3ea0.jpeg){kind=small}
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Kevin,
would you please elaborate when u say it is "dangerous"?
thn
Regards,
would you please elaborate when u say it is "dangerous"?
thn
Regards,
perhaps "dangerous" was a bit strong - I should have said be careful
What I meant was, you need to make sure you don't re use an ID value that you have previously used and need to preserve.
What I meant was, you need to make sure you don't re use an ID value that you have previously used and need to preserve.
why no just make the field ID a identity field?
that way, the "incremental" values will be provided directly from SQL server, safe for multiple user inserts.
after the insert, a SELECT SCOPE_IDENTITY() can tell you the value generated.