Hi Ross, Answers below:
> *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)? > this could be a good idea, but if you use relationships wisely there is no strict need to have a bunch of clusters > 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? > > In current OrientDB version there is a limitation to ~32.000 clusters per database, just keep it in mind and the rest is ok. > 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? > > this could be, but I'd start from common query patterns and data model rather than 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)? > yes, exactly, you can retrieve linked objects with a very cheap query (O(1) in terms of computation). Documents can be returned in JSON so that you can directly render them to the front-end > > 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? > > definitely! But you also have the alternative to embed documents (eg. think about the items of an invoice, they belong to only one invoice and they do not make sense without the invoice itself, in this case you can have an Invoice document with many InvoiceItem embedded documents) > *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) > > Some people use it in production (it's easy and it allows you to exploit OrientDB profiling and record-level security), some others don't (especially when they want finer control on user management) > Or should I create a separate class for containing my webapp users? > > Yes, if you use application level authentication, but if you decide to go with db authentication you can use OUser class and just add new attributes to that (schema-mixed mode) > 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? > > yes, it is ;-) you can use it as if it were any other class > *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? > It sounds reasonable, but I don't know this domain, so I may be wrong ;-) > -------------------- > > 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 think this will be of interest http://orientdb.com/docs/last/Security.html#record_level_security http://orientdb.com/docs/last/Partitioned-Graphs.html > *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 :)* > Thanks a lot, let us know how it goes :) Luigi > -- > > --- > 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. > -- --- 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.
