Reply to thread

Message: <blockquote data-quote="Janx" data-source="post: 6210216" data-attributes="member: 8835">I figured something like that.  Keep in mind, it's not Janx's PF Feats Library.  It's Janx's PF Library with Skills, Feats, Monsters, Spells, NPCs inside of it. Hierarchy is important, to organizing data, and recognizing the containing units is part of that.To form a tree representing the data:Owner: Janx--GameSystem: PF----Category: Skills------Fishing------Cooking------Rope Use----Category: Monsters------Orc------Goblin----Category: Feats----Category: Spells----Category: Recipes (or some other crazy thing that nobody else would use this for)etc.This is where professional terminology and normal person terminology collide.  What you describe as records with fields, is called a Table.  A database is a collection of Tables, many of which are related to each other.  A simple rule of thumb, is if you can manage it in one simple sheet in Excel as a list of things with columns describing those things, that's a Table.So all the Tables the users ever make is what constitute a Database and would be stored in  Repository (SQL Server, MySQL, PostGRES, Oracle, etc).  Other kinds of Repositories could be used (object database, document database, flat files, XML, etc), but usually it's something SQL based.One of the challenges you're going to have is that the rule system defines widely varying fields for the same Category.  So the fields needed to describe 2E spells is different than the fields needed to describe 4E spells, even though there is some overlap.So, the system design may require us to call them the same thing (Spells), but the Table structure needed to store 2E spells will be different than what's needed for 4E spells.I spent 3 weeks EXPLAINING a design for a system that can handle this to a group of developers who were going to build it.  Your guy may be able to skip that step as it's "just him" but tread lightly, dynamic database handling is not simple.  Mayhap your guy is using something that's done this already (I've rolled my own 3-4 times), but if he is doing it from scratch, it will take more than a week to complete.Yup.  This part is actually the easy part.  That GridView product I linked to (again, not a sales pitch), incorporates filter/searching it into it, so I get it for free (well, I did pay $1000/year for the license).  There are nice open source solutions as well (jQuery is free and kicks butt!).Probably one of the concerns to have is if I upload all my 2E data (which is NOT OGL), and make that public, I am possibly violating copyright.  Might be good to include a "report suspected violation" button.Here's another wrinkle in the design (meaning, do or do not build this, but know why):Relationships between TablesSkills, Feats, Spells are what we call Lookup data or Meta Data.  They form lists that get associated with other things, but often aren't meaningful on their own (you might look up Swimming to see the rule, but you're really doing it because the Monster you are looking at has the Swimming skill).In D&D, the most common "other thing" to be associated to is Monsters.A Monster has zero or more Spells available to it.A Monster has zero or more Feats assigned to it.A Monster has zero or more Skills assigned to it.Thus, when I view the Orc monster, I would see a Feats section, which is a list of the Feats the monster has.  These are actually hyperlinks to their respective Feat detail block (pop-up, tooltip, whatever).This concept of Relationships is where a Database really forms in the modern parlance.  It's not manageable with just a single worksheet in Excel.Here's the good news, you do NOT have to design for this.  I am simply raising it to your attention that it is possible, and it makes sense to do (later).Instead, when you define the 3e Monster Table with Name, HD, AC, Attacks, Damage, etc for fields, you would put in a field called Feats that is a big text box (remember each field should have a datatype, as in a restriction on what kind of data goes in it, and thus what to show the user for data entry/formatting).When I am entering my new Monster for "Orc", when I get to the Feats section, I can just type in the names of the feats.  And that's what the user will see.  No fancy hyperlinks, etc.Or you could let me paste in hyperlinks from the proper Detail screen for the feats (like we do in the forums).This is basically what I do in my spreadsheet for managing my PC.  I just list my feats in cells, and then hyperlink them to the SRD myself.  A simple solution.Just know that a true Database would handle it Relationally, and you'd get more powerful behavior (at the cost of added complexity).</blockquote>

Verification