Greetings all! I am so happy to have found OrientDB as I'm starting a new 
project!

I'm a newbie Python developer with big ideas for a Game Modification file 
sharing webapp. I want to offer video game mods for any game using 
bittorrent transfer technologies that is baked into a seamless Game Mod 
downloader client. I did have some questions regarding OrientDB to ensure 
that I am going about my structuring the right way.

*Clusters*
Awesome idea! I can have a class of game_mod with a cluster per game. I 
read on the docs, "good partitioning allows you to reduce/remove the use of 
indexes".

Can someone define "good partitioning" as in a best practice?

Would it be better to have a class per videogame (minecraft, arma3, 
minesweeper) with a cluster for each type of game modification (missions, 
mods, models, sounds, etc)?

I just don't know the best practice, is there any disadvantages to having a 
ton of classes and clusters or the more the merrier?

Just for reference, on the webapp front-end, content will be categorized by 
game then by type. I'm thinking the best DB structure is one that 
duplicates the webapp's flow?

*Relationships*
Yet again, this is awesome! Before OrientDB, I was dreading my 300+ page 
book on ORM and MySQL training.

Just to be sure I got this right, I can take an document such as $user and 
link to multiple $groups, then I can easily return all $groups the $user is 
a part of to render on the front end (html)?

Is using relationships better then for say, to have a property in the 
record/document of all groups the member is a part of? I guess that's the 
whole point of relationships, to get around the performance penalty of 
parsing an attribute of a record?

*Users*
My webapp will have user registration and authentication with access 
groups, exactly like OrientDB.

Would it be easiest/best to use the OUser for webapp authentication? 
(http://orientdb.com/docs/last/Security.html)

Or should I create a separate class for containing my webapp users?

For more information, I will be using the Document/Object Oriented DB mode 
of OrientDB for my webapp with relationships. From a newbie's perspective 
(assumption), I could structure my webapp's security around the same access 
level the user has to the DB. For example user $jon in the OUser cluster is 
allowed to WRITE to cluster minecraft_missions and therefor is the 
moderator of that section of the website.

Can OUser even be modified to support additional attributes? Is the OUser 
cluster just like any other but with just special use in OrientDB?

*Performance/Other/Offtopic*

So basically here is my idea for structure. I will have a USERS cluster 
that can build relationships to records in the MODGROUP cluster (users 
create groups that they can place Game Modifications into). When the user 
creates a new group, their user record is related to the modgroup record. 
On the frontend, this is shown by returning a query of their user's 
relationships with the MODGROUP cluster.

Then, users can browse records in the GAMEMODS class and build relationship 
between a GAMEMOD record and their MODGROUP record.

Overall, the user sees their MODGROUP records that they created, each with 
their GAMEMODS records per group.

Basically, the webapp user can create groups in which they can place game 
mods into.

Does this all sound sane and possible? Is this the recommended way?
--------------------

Troubles arise though when trying to conceptualize how the users can SHARE 
these MODGROUP records with others. If you have multiple users who can 
browse and build a relationship to a record in the MODGROUP class, how do 
you control permissions? Is there a way to tag or otherwise assign an 
attribute to a relationship such as $joe ---read-only---> $jons_group?

Do I revert to using something like an array attribute of the MODGROUP 
record with each permission? ex: r+w = [joe, john, steve] r-only = [bob, 
andrew] Or is there some other way that uses the graph/relationships 
functionality that I am missing?

*I know this is a ton of questions and higher level talk that isn't exactly 
in par with OrientDB terminology but my excitement is overflowing! Please 
feel free to copy+paste main points and respond inline to questions. I'm 
sure many could benefit from knowing this information :)*

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to