Rails - Jun 2006 - [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.


-- 
Posted via http://www.ruby-forum.com/.

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

-- 
Posted via http://www.ruby-forum.com/.

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.

-- 
Posted via http://www.ruby-forum.com/.

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.  :-)

-- 
Posted via http://www.ruby-forum.com/.