Page 1 of 1
field defintion question
Posted: Wed Feb 20, 2008 10:04 am
by Todlerone
Hello everyone and as usual, thank-you in advance for any responses. I'm really sorry for the (probably) simple question here but I just need some clarification. I'm designing a web site for my baseball team (believe it or not, it is going well with coding). For my scores mysql table I will generally have integers, however, at times I may need to place anyone of 4 letters. In my table definition should the field be a TINYINT or CHAR. I know PHP can flip variables on the fly depending what it determines it is. Just not sure what is the proper thing to do.

Re: field defintion question
Posted: Wed Feb 20, 2008 10:37 am
by Zoxive
Seeings how INT can not hold letters, i would say Char, but do you really want padded values? Instead use varchar.
Or better yet, lets look into this some more.
What's the need of putting 4 letters in a score value? For Some Sort of Tie, or Cancelled game the best would be to put a NULL value, then have another field that specifies if the game was cancelled, etc..
Re: field defintion question
Posted: Wed Feb 20, 2008 10:56 am
by Todlerone
Zoxive wrote:Seeings how INT can not hold letters, i would say Char, but do you really want padded values? Instead use varchar.
Or better yet, lets look into this some more.
What's the need of putting 4 letters in a score value? For Some Sort of Tie, or Cancelled game the best would be to put a NULL value, then have another field that specifies if the game was cancelled, etc..
Thank-you Zoxive, point well taken. I think I will create a new field to capture any undesired outcomes (like rain-outs, forfeits, etc) and leave my other fields as INT(s) as they should be, thank-you.

Re: field defintion question
Posted: Wed Feb 20, 2008 8:29 pm
by califdon
Todlerone wrote:I think I will create a new field to capture any undesired outcomes (like rain-outs, forfeits, etc) and leave my other fields as INT(s) as they should be, thank-you.

That's actually the right move. A field of a table should contain homogeneous data. Always avoid mixing different "stuff" in the same field. A new field for the non-numeric outcomes is exactly the right design.