Use Rails or PHP?

Rails
1

I’m new to RoR and have used PHP. I want to develop a personal
organizer that allows me to add lists (tables) and search them. The
ActiveRecord concept seems to allow me to set up something that works
with an existing table, but I want the ability to add tables without
programming. I know how to do this in PHP and I can put the SQL into
queries in RoR, but does ActiveRecord let me make a new table/object and
refer to it without preprogramming? Keep in mind I want each table to
have different attributes/columns.

Sorry if this is vague and if I’m not clear. Here’s what I’m talking
about:

I make a table of CDs. So I say I want three columns (id, title,
description) and then add it. Can i use ActiveRecord?

2

On 7/2/06, Todd F. [email protected] wrote:

about:

I make a table of CDs. So I say I want three columns (id, title,
description) and then add it. Can i use ActiveRecord?

Why does a “list” need to be a database table?

3

ActiveRecord concept seems to allow me to set up something that works
with an existing table, but I want the ability to add tables without
programming. I know how to do this in PHP and I can put the SQL into
queries in RoR, but does ActiveRecord let me make a new table/object and
refer to it without preprogramming? Keep in mind I want each table to
have different attributes/columns.

ive been working on something i’ll call ‘rad’. sort of a rails-on-rails.
theres also something called ‘streamlined’. in terms of production
systems that do what you want, check out DabbleDB. youll find many of
its concepts familiar if youve used rails, eg the ‘belongs_to/has_many’
paradigm.

im not convinced modifying tables in realtime, per user request, is the
most efficient way to go about things (although you could fire off
migrations from a controller, if you want a wild rodeo going on in your
schema). you might want to use something like ActiveRDF instead of
ActiveRecord, so you can use a store which is more open to run-time
extensibility. or try to figure out a generalized schema that doesn’t
require continual migrations and layer some (meta)programming logic on
top…

good luck, and keep us updated on your solution…

4

Joe Van D. wrote:

On 7/2/06, Todd F. [email protected] wrote:

about:

I make a table of CDs. So I say I want three columns (id, title,
description) and then add it. Can i use ActiveRecord?

Why does a “list” need to be a database table?

List should be searchable (filterable), sortable, etc. I don’t know any
other way to store the data.

5

carmen wrote:

… im not convinced modifying tables in realtime, per user request, is the
most efficient way to go about things (although you could fire off
migrations from a controller, if you want a wild rodeo going on in your
schema). you might want to use something like ActiveRDF instead of
ActiveRecord, so you can use a store which is more open to run-time
extensibility. or try to figure out a generalized schema that doesn’t
require continual migrations and layer some (meta)programming logic on
top…

I thought about other ways. E.g., program lets me make tables, all have
id, title, description. others have other attributes added to a query
by a left join (each attribute). so

LIST_OF_LISTS
id
list_name

LIST_COLUMN_HEADINGS
list_id
list_item_title (column heading)
list_item_type (vc or date – below)

TABLES
id
title
description

TABLE_ATTRIBUTE_LINK_VARCHAR (I need only vc255)
table_id
list_id
additional_attribute_value

TABLE_ATTRIBUTE_LINK_DATE (for all date attributes)
table_id
list_id
additional_attribute_value

A list might be generated like this:

For a particular list, which has an id X,

  • first get the list column headers by searching LIST_C_H
  • the result set will be the columns
  • then use those to construct a query for rows
  • select from table where list_id is X
  • programmatically (using scripting language like php/rails/whatever)
    … add a join for each attribute
    … joining from either vc or date depending on the attribute.
  • then limit to cull null rows

In effect, i might get something like this (assume three attibutes)

List: Songs (list_id 1)

+ID—Title—Descr—Date----Artist-----Label—+
! 1 I know Good 1/1/06 Team Band garage !
±-----------------------------------------------+

Date comes from a row in T_A_L_D
Artist comes from a row in T_A_L_V
So does label

I’d like a better way, but I have made this work.

6

Todd: you can do this fine in ActiveRecord. But not the way you’ve
envisaged it.

You don’t need a seperate table for each list. Instead, you have a
table called “lists”, which handles the lists themselves, and a table
called “list_items”. List has_many :list_items .

Job done. Then you store all your list items in one table, with a
foreign key pointing to which list they’re in. And then you can
filter/search the results to your heart’s content.

You could do this by adding tables, but it misses the point of Rails:
ActiveRecord isn’t just about simple ORM; the pattern is about having
one database table to represent one data object. Your data object
class is the concept of a “list”. “List1” and “list2” are both
instances of a List class; as such, they should be in the same table.
This is pretty fundamental thinking to Rails, and you need to get it
now before you go much further.

So, like I said: think about lists and list items. Creating a new list
is just inserting into the lists table; creating new items in a list
goes into the other table. Then you can get at list1.list_items and
list2.list_items, and go from there.

Does that make sense?

7

You don’t need a seperate table for each list. Instead, you have a
table called “lists”, which handles the lists themselves, and a table
called “list_items”. List has_many :list_items .

Job done

not so fast. how do you display multiple lists in a table and get the
items to line up by column? with untyped ‘items’, its going to be a
mishmash. with SingleTableInheritance, youre going to have to migrate
the SQL tables whenever you want to add a new property or list-item
type, and on top of that end up with a majority of your cells as NULL in
the database. neither of these are close to optimal.

implying that the original poster needs to just ‘learn rails’ and the
above problem will just go poof is silly. but rails is flexible enough
that you can even go semantic without installing a Triple-Store and 3rd
party gems:

with triples, you just need a ‘dodginess’ property - use that as the
predicate for anything else - eg: ‘tandoor chicken. dodginess: maybe’
(in the db, the chicken and dodginess would each be id numbers, and
‘maybe’ would be a 2 columns, one for the Type of the literal, and one
for the literal’s foreign key). then you can view all your food and even
non-food items sorted by dodginess, with no wasted cells…and no
continual DB schema migrations… even the schema is simple. rails rules

8

Further to that: regarding each list having different properties: you
might want to google for Single Table Inheritance. That way you can
retain your abstracted, one-table-per-model structure (which is
correct) and still have a varying number of fields.

It’s not pretty, though, if you take it too far.

The example you’ve given (extra tables for each of the types of extra
field you might need) isn’t bad, really. STI lets you ram all that
metadata into single fields that can still be accessed through your
ActiveRecord layer. It’s ideally suited to doing things like this.

9

Hello,

Any approach to unzip(extract) a zip file in rake. Like unzip task in
ant?

Your answer is appreciated!
-Jon

10

implying that the original poster needs to just ‘learn rails’ and the above problem will just go poof is silly.

Um, not really. I never professed to be 100% correct; nor did I
suggest it’d go away - hence the second post, when I misread the
first. But taking a framework with a one-model-to-table architecture,
and then trying to dynamically add new tables seems (to me) to be
immediately trying to go around the framework, when, as you and I have
suggested, there are other alternatives that are less brutal. It’s not
so much “learning rails” as “trying to work with it instead of against
it”. One table per instance, instead of model, is going to quickly
give you a cluttered database.

Maybe I’ve misunderstood STI, but I thought the point of it was that
you didn’t need to migrate SQL tables when you altered properties.
Obviously I need to brush up on that - apologies for confusing the
matter.

Your solution does sound best, though, Carmen.

11

carmen wrote:

…rails is flexible enough
that you can even go semantic without installing a Triple-Store and 3rd
party gems:

with triples, you just need a ‘dodginess’ property - use that as the
predicate for anything else - eg: ‘tandoor chicken. dodginess: maybe’
(in the db, the chicken and dodginess would each be id numbers, and
‘maybe’ would be a 2 columns, one for the Type of the literal, and one
for the literal’s foreign key). then you can view all your food and even
non-food items sorted by dodginess, with no wasted cells…and no
continual DB schema migrations… even the schema is simple. rails rules

I’m trying to get a better handle on this, but I’m coming from a
different world and am not familiar with this approach. Can you relate
it to my example earlier?