help in table design

hi,
I need help with the following table designs.
CREATE TABLE dbo.one(
one_a INT IDENTITY(1,1) NOT NULL,
one_b VARCHAR(50),--This will be having a + the value in one_a
one_c VARCHAR(50)
);
--I have put clustered index on one_b
--since this is VARCHAR field and I am simply adding a redundant character a in front of an integer value this index will keep on reshuffling; which is not good
CREATE TABLE dbo.two(
two_a INT IDENTITY(1,1) NOT NULL,
two_b VARCHAR(50),--This will be having b + the value in two_a
two_c VARCHAR(50)
);
--I have put clustered index on two_b
CREATE TABLE dbo.tbl(
tbl_associate VARCHAR(50),--This can have either value from one_b or two_b
tbl_b VARCHAR(50)
);
--since tbl_associate may have value from dbo.one or dbo.two so I had to put some redundant characters such as a,b in both the tables so that I may --know which Id is for which table.
--is there some way to remove such dependency of adding those redundant characters
Is there some other reccommended normalisation rules or some workarounds which may save me
Any help shall be appreciated!

You put the clustered unique index on the identity column (substitute key) and add a (non-clustered) unique index on the natural key.
If you're adding the same single character as prefix to a number, on all rows in your table, then that initial is completely redundant.
If the intended use is that (in a separate table) you can store the initial + number as a reference, where the initial points to the source table, then you could use two columns for this reference: one to identify the table (for instance by its initial) and another one to store the number.
If you're using different tables for similar entities (Client & Supplier) then you could also simplify by having one Entity table, with a column that distinguishes between the types (Client or Supplier). This way, the separate table can simply refer to the ID on the Entity table, and a join on the Entity table will tell you the type of entity.

Hi Adriaan,
[quote user="Adriaan"]If the intended use is that (in a separate table) you can store the initial + number as a reference, where the initial points to the source
table, then you could use two columns for this reference: one to identify the table (for instance by its initial) and another one to store the number.[/quote]
Can You please elaborate more on this.

Say you have MyReference with value "A123", which points to tableA - ID 123, and "B456" which points to tableB - ID 456.
You could have instead two fields: MyTable ("A", "B", ...) and MyReference (123, 456, ...).
***
The idea of having different entities in the same table, is that instead of tableA and tableB, you have a single TableCombo with an ID column, a natural key, and an EntityType ("A", "B", ...). The MyReference on the original table can now just refer to the ID column on TableCombo. If you need to know what type of entity it is, your query can refer to the EntityType on TableCombo.
This is all part of the standard normalization steps that you need to go through when designing your database.

Oh Thanks,
Nicely explained
Thank You very much again