Forum: Ruby on Rails best way to store this data in the database

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Scott K. (Guest)
on 2009-01-03 01:41
i have bunch of item properties that need to be stored in the database.
the options for the properties are:

-unknown
-yes
-no

what do you think is the best way to store this data?

should i use a tinyint and only store 0, 1, 2 for the respective options
or just use a varchar(10) and store the name of the result?

what is the usual standard?
tonypm (Guest)
on 2009-01-05 22:23
(Received via mailing list)
I tend these days to always use the full descriptive words - memory
implications are small, but it is easier to directly display the value
than have code to expand it wherever it is used.  It also tends to
make the code logic easier to follow.

tonypm
Marnen L. (Guest)
on 2009-01-06 07:05
(Received via mailing list)
On Jan 5, 3:22 pm, tonypm <removed_email_address@domain.invalid> wrote:
> I tend these days to always use the full descriptive words -

Definitely not in a case like this.  The set of three values here maps
*perfectly* to SQL-style 3-valued logic -- so use it!  Store this as a
boolean value.

A larger set of strings could be stored directly in a character field
in the database, but if the number is under 100 or so, I'd advise
creating a separate table and simply referring to the strings by
foreign key.  This practice will avoid all sorts of data normalization
issues.  I'd never dream of storing a small number of repeating
strings as literal text the way you're suggesting.

> memory
> implications are small, but it is easier to directly display the value
> than have code to expand it wherever it is used.  

Not really -- especially if the application should run in more than
one language.

> It also tends to
> make the code logic easier to follow.

Again, not really.  You have to explicitly test for == 'yes' rather
than simply testing for truth or falsehood.

>
> tonypm

Best,
--
Marnen Laibow-Koser
removed_email_address@domain.invalid
http://www.marnen.org
This topic is locked and can not be replied to.