MySQL database design questions - TechHui2024-03-28T22:32:48Zhttp://www.techhui.com/forum/topics/mysql-database-design?commentId=1702911%3AComment%3A59329&feed=yes&xn_auth=noSure, looks good.
Rick Payto…tag:www.techhui.com,2010-04-08:1702911:Comment:593292010-04-08T03:25:03.785ZJesse Barroshttp://www.techhui.com/profile/JesseBarros
Sure, looks good.<br />
<br />
<cite>Rick Payton said:</cite><blockquote cite="http://www.techhui.com/forum/topics/mysql-database-design?commentId=1702911%3AComment%3A59309&xg_source=msg_com_forum#1702911Comment59309"><div>I actually decided on separate tables for each item (land, soldiers, generals, weapons), I just didn't include that info as I was trying to keep the post simplified.<br></br> <br></br> I didn't think about adding a log of when you bought and sold land / soldiers / weapons / generals, but's…</div>
</blockquote>
Sure, looks good.<br />
<br />
<cite>Rick Payton said:</cite><blockquote cite="http://www.techhui.com/forum/topics/mysql-database-design?commentId=1702911%3AComment%3A59309&xg_source=msg_com_forum#1702911Comment59309"><div>I actually decided on separate tables for each item (land, soldiers, generals, weapons), I just didn't include that info as I was trying to keep the post simplified.<br/> <br/>
I didn't think about adding a log of when you bought and sold land / soldiers / weapons / generals, but's on the to-do list now.<br/>
<br/>
Aside from all that though, am I on the right track? :P</div>
</blockquote> I actually decided on separat…tag:www.techhui.com,2010-04-07:1702911:Comment:593092010-04-07T23:40:14.019ZRick Paytonhttp://www.techhui.com/profile/mauirixxx
I actually decided on separate tables for each item (land, soldiers, generals, weapons), I just didn't include that info as I was trying to keep the post simplified.<br />
<br />
I didn't think about adding a log of when you bought and sold land / soldiers / weapons / generals, but's on the to-do list now.<br />
<br />
Aside from all that though, am I on the right track? :P
I actually decided on separate tables for each item (land, soldiers, generals, weapons), I just didn't include that info as I was trying to keep the post simplified.<br />
<br />
I didn't think about adding a log of when you bought and sold land / soldiers / weapons / generals, but's on the to-do list now.<br />
<br />
Aside from all that though, am I on the right track? :P Sure, looks good so far.
For…tag:www.techhui.com,2010-04-07:1702911:Comment:592572010-04-07T03:53:55.482ZJesse Barroshttp://www.techhui.com/profile/JesseBarros
Sure, looks good so far.<br />
<br />
For the UserLand table, you don't necessarily need to have a surrogate key like the userID and landID columns in the Accounts and Land tables. MySQL (and other database engines) let you define a composite primary key, which is a primary key made with multiple columns. For a throwaway app, it's probably not worth the trouble, but it's something you may want to look into for other designs.<br />
<br />
Do you want to be able to track the changes in land and property ownership over…
Sure, looks good so far.<br />
<br />
For the UserLand table, you don't necessarily need to have a surrogate key like the userID and landID columns in the Accounts and Land tables. MySQL (and other database engines) let you define a composite primary key, which is a primary key made with multiple columns. For a throwaway app, it's probably not worth the trouble, but it's something you may want to look into for other designs.<br />
<br />
Do you want to be able to track the changes in land and property ownership over time? You may want to add a createtime, modifytime, deletetime, etc. column.<br />
<br />
I don't play Castle Age, but depending on how land, soldiers, and weapons behave, you could either create separate tables for each, or combine them in a single table called Items or something like that. I'm not sure which way is better, but my wild guess would be separate tables.