|  | Posted by Erland Sommarskog on 10/25/05 01:14 
heromull (heromull@gmail.com) writes:>> Don't design a database schema around a user interface.
 >
 > I think this is our first mistake.
 
 An unusually candid confession!
 
 >> If they all have the same schema, then there is a strong
 >> indication of that you should have one single table.
 > ...
 >
 > Yes, this is the case.  They share the same schema.
 
 You should make them one table, adding one more column that specifies
 the entity that is now hidden in the table name. That table would look
 like:
 
 CREATE TABLE [Answers] (  --Table1 thru Table200
 [CustomerId] [int] NOT NULL ,
 TableNo      int   NOT NULL,
 RowNo        smallint NOT NULL,
 [Value] [nchar] (1024),
 PRIMARY KEY (CustomerID, TableNo, RowNo)
 
 I've added RowNo, beause I don't know if one customer can add more
 than one value in the same form. If he can't RowNo should not be
 there. I've very deliberate taken out the IDENTITY column, because
 this table should have a composite key. My RowNo is indeed a surrogate,
 but only in the sub-realm of CustomerId, TableNo. (And TableNo is just
 a name I use, in lack of knowledge about the business domain.)
 
 I put the key on CustomerID, TableNo, but depending how you use the
 table, you may also have a need for an index on (TableNo, CustomerID).
 CustomerID first is good for queries like "what is customer 1233 up to"?,
 but not for "What do we have in table 12?".
 
 > It does and I say that only to mean that it's not too late for us to
 > implement a better design.
 
 That's great to hear!
 
 > begin
 >      declare @CustomerId int
 >      declare @RecordId int
 > select
 >      @RecordId = Table1Id,
 >      @CustomerId = CustomerId
 > from
 >      inserted
 
 Uh-uh, classic mistake. A trigger fires once per statement, not once
 per row. Yes, as long as data through that form, it will only come
 one by one, but then suddenly there is a batch processing loading lots
 of data at the same time. So write your trigger as:
 
 INSERT interview (...)
 SELECT ...
 FROM   inserted
 
 > insert into
 >      interview
 
 And INSERT without a column list is very poor practice in production code.
 Someone adds a column to the table, and the statement blows up. That's
 bad.
 
 
 
 
 --
 Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
 
 Books Online for SQL Server SP3 at
 http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
  Navigation: [Reply to this message] |