XML or YML?

Hello,

I'm probably being really dumb but I can never figure this out.

I want to store things like categories, salutations, image type etc etc
but it seems dumb to create a database table for each of these.

Is there any way I store this structured data in XML or YML so I can
still call:

asset.category.name etc?

Thanks!

Scott

I'd like to second this request -
I found myself fleshing out a lot of the details of my data base
structure using categories, salutations, image_types etc tables, which
I could then populate via a scaffold, and select in other tables using
a collection select. The problem is, when you want to go back and
alphabetize the categories list, for example, you get the record id's
changing, and then an object with a category_id of 12 is now pointing
to a different category than it was before (since you reordered the
table), which forces you to create after_save actions to update all
the objects that reference the categories table.

But if categories were in an xml/yml file, then their database table
id would be irrelevant etc.

The problem is, when you want to go back and
alphabetize the categories list, for example, you get the record id's
changing, and then an object with a category_id of 12 is now pointing
to a different category than it was before (since you reordered the
table), which forces you to create after_save actions to update all
the objects that reference the categories table.

What? I think you might be doing it wrong. You don't need to change
anything in the database to show the categories in alphabetical order:

Category.find(:all, :order => 'title')

http://github.com/binarylogic/settingslogic

Scott Holland wrote:

Hello,

I'm probably being really dumb but I can never figure this out.

I want to store things like categories, salutations, image type etc etc
but it seems dumb to create a database table for each of these.

It's not dumb to put these in the database.

Is there any way I store this structured data in XML or YML so I can
still call:

asset.category.name etc?

Thanks!

YAML might work well here. XML is almost always overkill.

Scott

Best,

No, I know. what i'm caying is, if you *do* somehow reorder the
categories, then your objects which reference them are all re-
categorized. that's bad - it's a dependency that is unnecessary.

??

Only if the "somehow" you re-order them by is to change the content of
the object because you assume "id" is "position".

what Scott was asking for originally was a way to enumerate options
without having to reference their position in a list. if you use a
database to create the list, then you necessarily have to reference
their position get to them, but if you define the list with, say, a
yml file, then position is irrelevant. So, you can alter the list at
will without having to worry about the consequences for objects which
reference the list - you just can't delete an item in the list.

I second Tim’s observation, but wish to add:

From a design perspective, a more generic approach that preserves everything you know and love about AR models is to create the following tables/models:

Category
id
name
description
abbreviation

SystemType
id
category_id
name
description
abbreviation

Something like that. You can make SytemType acts_as_list if you like to order them, and categories can acts_as_tree if you want them to be hierarchically related. Knock yourself out. Can be as simple or complex as you wish to make it.

Category will have a one-to-many relationship with SystemType.

Where you would otherwise be tempted to add a table, instead add a Category record. When adding a new SystemType, you must relate it to a Category. The type system can grow without needing migrations.

You can also add static methods to SystemType to return all types for a given category. Let’s say one of those is ‘Image’ (denoting an image type), inside SystemType you can do something like this:

chewmanfoo wrote:

what Scott was asking for originally was a way to enumerate options
without having to reference their position in a list. if you use a
database to create the list, then you necessarily have to reference
their position get to them, but if you define the list with, say, a
yml file, then position is irrelevant. So, you can alter the list at
will without having to worry about the consequences for objects which
reference the list - you just can't delete an item in the list.

Nope, wrong. Primary key is not "position in a list". Please learn a
bit more about how SQL databases actually work.

Best,

Wow ok.

So, the following:

Class Shape < ActiveRecord::Base
  attr_accessible :color_id
  belongs_to :color
end

Class Color < ActiveRecord::Base
  has_many :shapes
end

Now, in the console:

sh = Shape.last
...
sh.color_id
12
sh.color.name
"red"
...
c = Color.find(12)
c.name = "blue"
c.save!
...
sh.color.name
"blue"

Oops! Now, every shape with shape.color_id =12 is now blue. You've
changed a Color, but inadvertently changed a Shape as well. That's
uncomfortable if not bad.

But maybe it's just me.

if you use a
database to create the list, then you necessarily have to reference
their position get to them

No - you reference their "primary key". This does not equate (unless
you have a *very* bad approach to DB design) to position.

but if you define the list with, say, a
yml file, then position is irrelevant.

No - again. If you have a yaml data source, you're probably going to
be storing a string value for the object. Exactly the same as if you'd
stored the string description (assuming the field was called
"description") of a db-table record. Absolutely no reference to
"position" is given.

So, you can alter the list at
will without having to worry about the consequences for objects which
reference the list - you just can't delete an item in the list.

If you're worried about referential integrity, then check for it
before allowing records to be deleted.

I have a strong feeling, Chewmanfoo, that you aren't grasping some of
the fundamental principles of SQL, and using relational databases to
store representations of objects.

Why would you *ever* change a colour's name? If it's blue it's blue.
It's immutable; atomic.
It's a value in a *lookup* table.

If you want to store the "name" of the colour instead of its id
(because you find yourself often doing hideous things like changing
the values in lookups), then do so; you'll just have a poor,
inflexible DB.

If it's immutable, then why is it in a database?

<slaps head in disbelief>

well... because I find it hard to web-enable these stone tablets :-/

What I'm saying is, if it's immutable, then you put it in config/
initializers, not in the database.

chewmanfoo wrote:

If it's immutable, then why is it in a database?

What he's saying is that it is "immutable" by policy. If you have a
database that stores orders where each order contains an order number
(not a primary key, but rather a number given to a customer), by policy
that order number should never change. If it did you would lose track of
the order.

This has nothing to do with position in the database. Order number is
simply a reference to one specific order. A reference that *must* be
immutable and atomic.

wow, I didn't expect such a response!

Maybe I should be storing this data in the db like I am at the moment,
it just seem a bit overkill to have a table with:

Image_type
1 => Photo
2 => Document
3 => Print

There *must* be some way I can define these values in the application
and still have all the associations work?

Thanks

I’d like to second this request -

I found myself fleshing out a lot of the details of my data base

structure using categories, salutations, image_types etc tables, which

I could then populate via a scaffold, and select in other tables using

a collection select. The problem is, when you want to go back and

alphabetize the categories list, for example, you get the record id’s

changing, and then an object with a category_id of 12 is now pointing

to a different category than it was before (since you reordered the

table), which forces you to create after_save actions to update all

the objects that reference the categories table.

But if categories were in an xml/yml file, then their database table

id would be irrelevant etc.

Hello,

I’m probably being really dumb but I can never figure this out.

I want to store things like categories, salutations, image type etc etc

but it seems dumb to create a database table for each of these.

Is there any way I store this structured data in XML or YML so I can

still call:

asset.category.name etc?

Thanks!

Scott

Posted viahttp://www.ruby-forum.com/.

You received this message because you are subscribed to the Google Groups “Ruby on Rails: Talk” group.

To post to this group, send email to rubyonrails-talk@googlegroups.com.

To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.

For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.

You received this message because you are subscribed to the Google Groups “Ruby on Rails: Talk” group.

To post to this group, send email to rubyonrails-talk@googlegroups.com.

To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

You are right, creating a database table for something like this does
feel like overkill. Personally, I often use constants if it's a very
small amount of data.

class Image
  VALID_IMAGE_TYPES = ['png', 'gif', 'jpg']
end

or
IMAGE_TYPES = {:1 => 'Photo', :2 => 'Document', :3 => 'Print'}