Customer support db backend design

Results 1 to 5 of 5

Thread: Customer support db backend design

  1. #1
    Keith M Guest

    Default Customer support db backend design

    Hi all-<BR><BR>Looking for ideas on how to lay out a customer support database (MS SQL 2000). The database I&#039;m currently working with has two tables:<BR><BR>Support:<BR>----------<BR>Incident_ID (INT, IDENTITY, NOT NULL)<BR>User_ID (INT, NOT NULL [linked to User Table])<BR>DateOpened (DATETIME)<BR>Category (INT)<BR>&#060;other fields&#062;<BR><BR>History:<BR>----------<BR>AutoID (INT, IDENTITY, NOT NULL)<BR>Incident_ID_H (1 to many from Support.Incident_ID)<BR>MsgDate<BR>MsgSource<BR>&# 060;other fields&#062;<BR><BR>This works just fine, but I&#039;m worried about scalability. Since the History table will hold all messages for all IncidentIDs, will I encounter problems as the number of rows gets very large (not sure what very large may be? &#062;10,000? &#062;100,000?)?<BR><BR>Should I create a new table for each User_ID? Currently have 250+ users... that may get ugly as far as administering... Or run a query that archives messages older than a specified date? Or... any other ideas?<BR><BR>Any input would be appreciated! TIA<BR><BR>-Keith M

  2. #2
    65535 Guest

    Default Seems OK....

    ...i am sure you are not worried about space but mainly speed...what i can sugfgest is you have a view of the open requests and select from there...since most queries will be only for open requests....if the request is closed then you could still have queries but that can be a bit slow....but i really do nto think it will be to an extent where you really need to worry...<BR><BR><BR>another thing is maybe archive the old onle say over 6 months old<BR><BR>""Akhilesh

  3. #3
    Keith M Guest

    Default RE: Seems OK....

    Thanks for the input Akhilesh -- I hadn&#039;t thought of creating a view. I have a few different status (statuses? stati?) than just open, so I guess I&#039;ll be creating several views :)<BR><BR>-Keith

  4. #4
    Join Date
    Dec 1969
    Los Angeles, CA

    Default NO dont do that.... lose the whole purpose.<BR><BR>just keep the table i am sure it is not going to be bad to actually worry about it....just make sure the index in in place

  5. #5
    Keith M Guest

    Default RE: NO dont do that....

    OK -- looks like I need to hit the SQL books to review some stuff... thanks again for the advise!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts