Re: [Anarchdb-devel] Re: database layout questions?

[Karl George Schaefer]

Well, the data tables are a little convoluted.  But, at this point they 
work.

Most of us are coming to the code for the first time and will need to 
become accustomed to it.  We also want to hit a release date of less than a 
week after NoR.  We want to keep our users happy and still meet the needs 
of the new set.

After we hack together the first release, we should have ~9 months until 
the next set, so that should give us some time to work out a development 
plan.

Here are some ideas that I have about a development plan:
1.  Create scripts and readmes that will allow the building of ardb to be 
easier on Windows platforms.  This is mostly completed (I'm guessing) for 
linux.  Ease of building will allow less strong developers to aid the 
project more easily.

2.  A UI group focused on good UI design that encompasses a heuristic 
methodology about user interaction will give ARDB a higher level of polish. 
This group doesn't need a lot of programmers.  This group needs to have 
people that can sketch new UI designs and determine where the UI currently 
fails the user.  There currently isn't a lot here that we need to concern 
ourselves with, the tool is pretty straight forward.  The inventory section 
will need some work and will probably be the focus of most of these efforts.

3.  The backend group will be concerned with "refactoring the code."  I 
think that there are two main areas to be concerned about (granted, this is 
a quick overview, so there may be more): database and codebase.  The 
database has some wonkiness about it.  You've already pointed this out.  In 
part trasnforming data from flat-file (the WW CSV files) to a well-formed 
3NF database can be tricky, if you going to do it programmatically.  We 
also want to look into ways the code can be self-expanding (handling new 
disciplines and clans without adding lines to the code).  We need database 
designers here that can plan a reproducible work-flow that transforms the 
WW files into our needs.  On the code side, we need to update to the latest 
libraries, tighten up the code (it may be tight already, I haven't really 
delved into it too deeply), and ensure cross-platform buildability (I had a 
problem with roundf on Windows, I changed the line to cast to an int 
instead and divide back out, but those sort of cross-platform problems need 
to go away).

4.  Because we are storing decklists as XML, we can create new output 
formats with the application of XSLs.  The JOL format is dead; it should be 
updated to JOL3.  The new VTES Online has its own format, which is XML, and 
we can transform to it.

5.  Request for features from users.

There are probably other focus areas and perhaps 2 and 3 should be swapped 
in order (and most of 4's tasks will be short and can be folded in during 
downtime on other parts).  Anyone else have any ideas about this?

We really need to worry about this stuff *after* we get an ARDB that will 
handle NoR.  Is everyone agreed on that?

Oh and sorry if this is all jumbly, but it's all off the top of my head.

Karl

--On Monday, March 13, 2006 9:44 PM +0100 Meshee <address@hidden> 
wrote:

> 2006/3/13, Meshee <address@hidden>:
> > Heya there, i did lies to you earlier... i did dive in the code base.
> >
> > Here is the result of my work:
> > a sql database schema of the core tables.
> >
> > As i did build the DB schema it raises some questions, if you guys
> > could help me  answering theme it would be much appreciate:
> >
> > * *cards_names* -- table i do not understand what this table stand
> > for. It looks like an attempt to have ALL cards in the same tables but
> > i do not see the point. As a result it just add a level of indirection
> > in the DB schema. The card_table field is the most mysterious.
> >
> > * *cards_XX_ignored* -- once again i do not see the purpose of thoses
> > tables... missmatching cards during DB update?
> >
> > * *cards_types* -- according to the <FK> this tables contains card
> > type (Action, Action Modifier etc) AND Vampire Clans O_O. Even if it
> > looks non problematic at first, merging concept in the same table if
> > prone to troubles on the long run. I wonder if something escape me?
> >
> > * *disciplines* -- this table looks to not be related to anything
> > else, what does it stand for?
> >
> > * *rarity_types* -- i just wonder how anarchdb handles multiple rarity
> > for a same card (Immortal Grapple)
> >
> > * *url* -- what does this fielsd use to contains? my guess is
> > monger.vekn.org card url. If i guess right monger allow a search per
> > name so may be it can be remove.
> >
> > * *cards_crypt* -- i see many fields with similar purpose:
> > disciplines, inferior, superior, wha
>
> hum humm bad click... well i go on here
>
> why do we has thoses fields AND one field per disciplines?
>
> Last question:
> * library_selection/crypt_selection what do they stand for? no <PK>
> <FK> i wonder if they are used at all
> >
>
> bbfn
>
>
> _______________________________________________
> Anarchdb-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/anarchdb-devel