# \[Question} how best to use attribute driven db with Rails **URL:** \ **Category:** Rails\ **Created:** [June 11, 2006, 9:19am UTC](https://www.ruby-forum.com/t/question-how-best-to-use-attribute-driven-db-with-rails/63054 "2006-06-11T09:19:01Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![teddio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@teddio](https://www.ruby-forum.com/u/teddio)\ **Post date:** [June 11, 2006, 9:19am UTC](https://www.ruby-forum.com/t/question-how-best-to-use-attribute-driven-db-with-rails/63054/1 "2006-06-11T09:19:01Z")
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](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. ---
**Author:** ![teddio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@teddio](https://www.ruby-forum.com/u/teddio)\ **Post date:** [June 11, 2006, 9:37am UTC](https://www.ruby-forum.com/t/question-how-best-to-use-attribute-driven-db-with-rails/63054/2 "2006-06-11T09:37:45Z")
Michael, Am 11.06.2006 um 09:19 schrieb Michael Hamson: > Db Schema: [http://urbaninfluencedev.com/schema.html](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. ---
**Author:** ![teddio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@teddio](https://www.ruby-forum.com/u/teddio)\ **Post date:** [June 11, 2006, 10:21am UTC](https://www.ruby-forum.com/t/question-how-best-to-use-attribute-driven-db-with-rails/63054/3 "2006-06-11T10:21:52Z")
> 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 ---
**Author:** ![teddio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@teddio](https://www.ruby-forum.com/u/teddio)\ **Post date:** [June 11, 2006, 4:34pm UTC](https://www.ruby-forum.com/t/question-how-best-to-use-attribute-driven-db-with-rails/63054/4 "2006-06-11T16:34:31Z")
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. ---
**Author:** ![teddio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/b3f665/32.png) [@teddio](https://www.ruby-forum.com/u/teddio)\ **Post date:** [June 11, 2006, 4:48pm UTC](https://www.ruby-forum.com/t/question-how-best-to-use-attribute-driven-db-with-rails/63054/5 "2006-06-11T16:48:03Z")
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. 🙂