Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 New to SQL Server Programming
 Which is better in this scenario

Author  Topic 

Grofit
Starting Member

11 Posts

Posted - 2009-11-26 : 03:46:59
Hi,
Im trying to port a dialog system i used to use in an old web game into a new SQL server DB from MySQL... although looking at the tables im just wondering if its worth me just putting it all into 1 table...

Here is a rough table design:


dialogs (table)
id - int (autoincrement PK)
text - text
link_type - byte
link - int

dialog_options (table)
id - int (autoincrement PK)
text - text
parent_dialog = int
link_type - byte
link - int


Now each dialog can lead to many things, be it another dialog, an event, a set of responses etc. So in the above example i used to have 2 tables one for dialogs and one for options, and if its link type wasnt either of these 2 then it was up to the code to run a script or something...


SELECT dialogs.*
FROM dialogs
WHERE dialogs.id = @ID;


Anyway if you look at the 2 table designs they both pretty much share an IDENTICAL layout other than the options need to know the parent_dialog (which is the id in the dialog table it links to) as each dialog could have many dialog_options...


SELECT dialog_options.id, dialog_options.text, dialog_options.link_type, dialog_options.link
FROM dialog_options
WHERE dialog_options.parent_dialog = @ID;


So im really just wondering if it is best to keep these as 2 separate tables or should i just add the column parent_dialog into the dialogs_table then just have them both in the same table...


SELECT dialogs.id, dialogs.text, dialogs.link_type, dialogs.link
FROM dialogs
WHERE dialogs.parent_dialog = @ID;


I wanted to keep them separate originally as i thought for performance lookups would be faster on the dialogs (As there would not be as many rows in that table), and i would always need to do another query afterwards once the dialog is returned to get the options if there are any...

So what are your professional opinions, am i over worrying and putting them all in one table for the sake of an extra int per row would keep similar data together, or should i keep them seperate even though the tables are near identical...

I could always take like a hybrid approach and make a shared dialogs table that contained the shared data then have a smaller table that contained option specific stuff, but this would mean it would always need a left join to see what type the current dialog is, as currently i can distinguish if its a dialog or an option based on its originating table...

visakh16
Very Important crosS Applying yaK Herder

52326 Posts

Posted - 2009-11-27 : 01:47:56
will you be always required to display dialog as well as its options? or is it mostly dialogs you're interested in and you show options only less frequently? if thats case you may put them in separate table. alternatively you could keep them in same table just like a hierarchial format with parent column having fk to pk column.
Go to Top of Page

Grofit
Starting Member

11 Posts

Posted - 2009-11-27 : 03:11:47
*Usually* every dialog will end with multiple options, however in some cases a dialog may link to another dialog, so they are daisy chained... although i would say options would be as frequent as dialogs...
Go to Top of Page

visakh16
Very Important crosS Applying yaK Herder

52326 Posts

Posted - 2009-11-27 : 22:20:52
then i think you can go for hierarchial design
Go to Top of Page
   

- Advertisement -