View Database info in a Node as a (modifiable?) table

We've been using a function that returns an array of states, that way you can reuse the function anywhere within the drupal site and can manage from a single location. You could also setup the array's code to live in a block, then your function might call the block's content, eval it, then return the data, that way you can manage the array without needing to go outside the drupal interface.

There are four ways I can think of doing this. Each of which has their advantage and disadvantages. Here they are.
1) A CCK text (list) field with the States in it.
-- Good for simple sites that does not require extremely advanced search options and will not have more than 2ish content types.
2) Creating a content type called 'State' and then populating that with the list.
-- Good for keeping/storing information about the states that is more detailed than just a name. I would do this if you were going to add population, square miles, and income info about the states as 'content'
3) Create a basic 'tags' taxonomy type.
-- This is great because the names can be added as needed, helps in the search and the terms do not need to be defined in the beginning.
4) Create a detailed taxonomy term field for State.
-- This is great when you want the list to be defined in the beginning, helps in the search greatly, and is very rigid.

I think that covers it...

Thanks to both of you. I'm interested in each (bestrank's array approach and greg.wall's "State" content type, especially), but I'd like to take the example further. In fact, I'll start a different discussion as this is taking a different tack. Thanks again!

Drupal builds everything around Objects. A node is an Object. So is a page, a user, a Views block, a piece of functionality, etc. In your case, I'd look for something like the CCK Address module to handle lists of U.S. states rather than try and write a custom function that returns an array, or store them in a separate table, or whatever else you might think of.

It's been my experience that if you try to find an existing module that bolts your desired functionality onto whatever the lowest common Object is, in this case the CCK Content Type, you're better off in the long run because you don't have to custom code and theme all the possible intersections of the data.