Page 2 of 2

Posted: Wed Apr 26, 2006 10:44 pm
by alex.barylski
I would agree. You are choosing to give users attributes that have a hierarchy. You can do so, but you don't have to. (In many cases, it is beneficial not to do so).
What do you agree about? The flexibility I choose to offer? Whats not benefitial?
Here, you are giving permissions to a *user*, when in reality, it is more likely that they have *roles*.
If you re-read, you will see that's exactly what I said, only different wording...I used *groups* instad of *roles* :)
Most compliance regulations suggest/encourage/require-by-law that you give groups ("roles") the permissions, and users are made to be "members" of that group
I was unware of any legal issues... :?
In that sense, its not hierarchical. A user has a password, and a role. Another user has a password, and a role. Those roles may be related, but they are not (neccesarily) hierarchical.
Bzzzzzt... :lol:

I think you fell off the bus ;) you have weird sayings dude...I used that one at work today and everyone got a laugh...

A role is hierarchial by it's very nature...what are talking about? :P

Think about it...your authorization roles are reflecting the exact *structure* of your organization...

A companies CEO is not inline with a Janitor...he/she is the end all be all...thee who makes executive decisions...Sure you can have non-hierarchial relationships...for example, two managers which fall under the same *role* or title...in which case they become siblings and no NOT share any parent/child relationship...however they still fit well into a hierarchial structure...if your system only requires linear *roles* then it's either poorly designed, very trivial or not going to be very extensible...
RDBMS are pretty much ideal for storing user data in every way.
Ahh grass hopper...much to learn...they are NOT ideal, in fact they are already antiquated in terms of efficacy and efficiency (in some ways)...the only reason object databases haven't taken off...I imagine...is two fold:

1) Programmer naivety
2) Backwards support (legacy systems/porting issues)

http://www.kuro5hin.org/?op=displaystor ... 2853/11281
Windows handles users and roles this way, as does unix, and most other OS's. I've very rarely seen a truly hierarchical user system, which is why your comment confuses me
Are you sure about that? I'm thinking Windows & Linux have the capability to select your data store...via an abstraction layer, like PAM or PEAR Auth, etc...

I know Windows has it's own version of LDAP appropriately called: Active Directory

http://en.wikipedia.org/wiki/Active_Directory

And on Linux or any other OS you could use LDAP to do exactly as I have said...only not with XML...still both support structure by nature...this is not just the interface either, I'm willing to bet like a DOM, they are implemented using tree's not arrays or vectors...which at the implementation level speeds code up not down. Linear storage man...jesus...thats so last year 8)

From the sounds of things, it looks like what I've suggested is already being considered, but using XML:

http://xml.coverpages.org/saml.html

Still not convinced? Here is some more reading...

http://www.microsoft.com/technet/itsolu ... wsdsu.mspx

Cheers :)

Posted: Thu Apr 27, 2006 11:11 pm
by Roja
Hockey wrote:
Here, you are giving permissions to a *user*, when in reality, it is more likely that they have *roles*.
If you re-read, you will see that's exactly what I said, only different wording...I used *groups* instad of *roles* :)
Thats not the same. A group is a collection of people. A role is a a set of tasks a user performs, not neccessarily including multiple users. Granted, you can make the argument that groups can only contain one member, but the point remains that there was a difference between the two that mattered to the conversation.
Hockey wrote:
Most compliance regulations suggest/encourage/require-by-law that you give groups ("roles") the permissions, and users are made to be "members" of that group
I was unware of any legal issues... :?
Its a bit obnoxious. I don't want to go *way* off topic ranting about how politicians screw up simple concepts when trying to make them laws, so lets leave it at "Yes, there are issues". If you wanna know more, feel free to pm me about it, or make a new topic.
Hockey wrote:
In that sense, its not hierarchical. A user has a password, and a role. Another user has a password, and a role. Those roles may be related, but they are not (neccesarily) hierarchical.
A role is hierarchial by it's very nature...what are talking about? :P
No, its not. You can have a role that has no relation to the hierarchy of your organization. Using your example, both your janitor and your CEO may need to access their HR records on the HR website. They both can have the "role" of HR_User. Notice that the role (a user that accesses HR records) is entirely independent of the hierarchy of the business.

This is quite common, and in fact, you'll find more roles that are NOT related to hierarchy than that are. The number of "domain users" in a business is rarely related to any hierarchy in the business structure.
RDBMS are pretty much ideal for storing user data in every way.
Hockey wrote:Ahh grass hopper...much to learn...they are NOT ideal, in fact they are already antiquated in terms of efficacy and efficiency (in some ways)...the only reason object databases haven't taken off...I imagine...is two fold:

1) Programmer naivety
2) Backwards support (legacy systems/porting issues)
Sorry, I'm not the grasshopper. :)

I'm well-informed about OOD's, and I can give you two actual reasons why they haven't taken off instead of imagined ones:

1) RDBMS work, and work extremely well
2) Theory doesn't match reality

OOD's simply don't have the maturity, development, and optimization that RDBMS's do. As a result, while at a conceptual level we have odd constructs like DAO's, in reality, they end up being extremely efficient, fast, and well-maintained.

Or put another way, switching to OOD's goes against rule #1 for engineers: If it ain't broke, don't fix it.
Hockey wrote:
Windows handles users and roles this way, as does unix, and most other OS's. I've very rarely seen a truly hierarchical user system, which is why your comment confuses me
Are you sure about that? I'm thinking Windows & Linux have the capability to select your data store...via an abstraction layer, like PAM or PEAR Auth, etc...
Those data stores don't change the relationships from relational to hierarchies. Look at the shadow file on linux. The groups file. Look at the user account management system in Windows. The storage doesn't change the fact that all those OS's handle users the same way: Relationally, not hierarchically.
Hockey wrote:And on Linux or any other OS you could use LDAP to do exactly as I have said...
You *can* choose to setup relationships to be hierarchical. You can also embrace roles and relationships. The storage is independent of your choices. Granted, if you are setting up hierarchical roles, you can argue that an OOD would be more appropriate. My point continues to be that most user stores DON'T do so - so if you want to choose to do so, thats fine, but its not the norm.

If you want to go hierarchical, thats your choice, and it may be right in your situation. If so, an OOD might be more ideal. But in general, its not the norm, its not required, and even if you choose to go that way, RDBMS's may still give better performance simply due to its much more mature development and optimization.

Posted: Fri Apr 28, 2006 12:20 am
by alex.barylski
I think your arguing for the sake of arguing... :lol:

I just wasted 30 mins of my time writting a wordy response, but in fear of offending you or upsetting the community I am choosing to drop from argument...and erase my reply.

Thank you come again! :)

Cheers :)

Posted: Fri Apr 28, 2006 12:49 am
by Christopher
I'm not exactly sure what this conversation is about. I think the OP was about "LDAP vs DB." There has been a lot written about when to use one or the other, it really depends on many factors. They also aren't exactly apples and apples because LDAP is a protocol more like SQL than the database itself. A discussion of X.500 and directories in general might shine some light on when either a directory or RDBMS might be good choice. To further muddy things, these directories are often built on top of a RDBMS. Probably the most scalable LDAP server is the Oracle Internet Directory which used Oracle as its datastore.

As for the whole OO database conversation, I hear it brought up in forums regularly (usually by the same few people), but I just don't see the major DB vendors doing much in that direction. I would imagine that the reason is that, even though OO makes sense from in programming, the vast majority of data is and probably will always be essentially tabular in nature.

Posted: Fri Apr 28, 2006 1:26 am
by alex.barylski
arborint wrote:I'm not exactly sure what this conversation is about. I think the OP was about "LDAP vs DB." There has been a lot written about when to use one or the other, it really depends on many factors. They also aren't exactly apples and apples because LDAP is a protocol more like SQL than the database itself. A discussion of X.500 and directories in general might shine some light on when either a directory or RDBMS might be good choice. To further muddy things, these directories are often built on top of a RDBMS. Probably the most scalable LDAP server is the Oracle Internet Directory which used Oracle as its datastore.

As for the whole OO database conversation, I hear it brought up in forums regularly (usually by the same few people), but I just don't see the major DB vendors doing much in that direction. I would imagine that the reason is that, even though OO makes sense from in programming, the vast majority of data is and probably will always be essentially tabular in nature.
Paradigm shifts are never easy...

Look at how difficult it is for people to switch from closed source to open source...

If open source is as great as proponents say it is, why then, hasn't everyone jumped on the band wagon?

Why is linux (kernel anyways) primarily developed in C instead of C++? For performance some might say...I think it's more to due with the fact that GNU and everything linux, open source, etc...has a C feel to it...hell the first linux C++ compilers were actually translators - translating C++ to C then compiling...

Their is a fundametal difference between using an object model and a relational model...so much so...it's like having to re-write software to take advantage of the newest hardware...it's a*massive* undertaking which few companies except those on the bleeding edge or small startups can afford to take advantage of...or willing to bother with (as Roja already said - many view the problem as if it ain't broke don't fix it. Personally I consider myself an inventor and/or innovator constantly seeking better ways of solving problems, so I guess that mantra doesn't apply to me).

Also consider that RDBMS are *very* popular thanks in part to the proliferation of the Internet and DB powered web sites...

If hosting companies realized the potential behind OODBMS and began switching...there would be an uncomprehendable amount of legacy code which wouldnt' work anymore (bye bye Internet)...so much so....it's rediculous to think it'll ever happen until transition is seamless...or over time...applications are weeded out...

It does happen, it just sometimes takes time...and even then sometimes they remain...just look at DOS debug.exe or command.com they both still ship with WinXP SP2 :)

Cheers :)