[Question} how best to use attribute driven db with Rails

I designed out a mostly attribute driven database. Originally i was
going to use PHP, but have now decided to use RoR. Being able to use the
built in OR functionality would be nice, but I am not sure how well it
melds with attribute dbs.

If anyone can give me some pointers, I would really appreciate it
(especially since this is my first endeavor and on an important project
as well).


Db Schema: http://urbaninfluencedev.com/schema.html

tbl_workspace is the core table. This is where the working objects are
housed (projects, tasks, to-dos, contacts, invoices, notes, email,
timesheets, ect).

tbl_entities holds the base information for users, groups and such.

the tbl_attributes is then the attributes associated to any given
workspace or entity.

There are 3 primary levels of security in that is database/data driven.

  • the item level active state (boolean - aka tinyint)
  • sec type - which defines if the item is has explicit or relative
    security (for security inheritance)
  • the security table reference which then gives the actual security
    rights.

As such, you will note that there are a lot of relationships between the
differing tables as well as inner-table relationships.

The thing is that i am not sure if the Act As functionality
(act_as_list) will be enough to pull the data as needed and to be as
clean and simple as OR is suppose to be.

Any advice… or even simple smack in the right direction would be highly
appreciated.

Michael,

Am 11.06.2006 um 09:19 schrieb Michael Hamson:

Db Schema: http://urbaninfluencedev.com/schema.html

Rails will not support you much in the way you want to use it since
your schema does not really embrace relational databases. In those,
you would rather create a table for each data type you want to
implement than have a table which stores all objects.

Regards,

Manuel


I have found an elegant and short solution for Fermat’s Theorem
but sadly there is not enough space for it in this signature.

Rails will not support you much in the way you want to use it since
your schema does not really embrace relational databases. In those,
you would rather create a table for each data type you want to
implement than have a table which stores all objects.

True in that this is data-modeled and not structural based. This
requires business rules in logic… but allows for growth of types
without change in the structural schema. aka WinFS-esque

Michael Hamson wrote:

Rails will not support you much in the way you want to use it since
your schema does not really embrace relational databases. In those,
you would rather create a table for each data type you want to
implement than have a table which stores all objects.

True in that this is data-modeled and not structural based. This
requires business rules in logic… but allows for growth of types
without change in the structural schema. aka WinFS-esque

Sounds complicated. I understand that you’ll get lots of flexibility by
going this way, but do you need it that bad? Besides, it’s not that hard
to use migrations to change your structural schema.

If you absolutely need your attributes to be programmatically definable,
then why not just use polymorphic associations with individual tables
for each “entity”? So you’d have:

Person -< Attribute
ToDo -< Attribute

and so on. Attribute would look like:

entity_id
entity_type
name
value

Or something quite like that.

I am building this, and taking my first… absolute first look at Ruby
on Rails… as such there is a lot that I dont know. I decided to dive
in based on the MVC model that RoR uses… which matches what I was
trying to do in PHP, but RoR is so much more elegant (at first look). In
reading further on… I understand now that fitting in the RoR db model
is truly pleasant… I am sure DBEs cringe at this as much as they do
with OR implementations… but truth be told… the RoR model does
address some issues and provides a nice framework. So yes, I will do
this under that guise and see how things go. :slight_smile: