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

[Meshee]

2006/3/13, Karl George Schaefer <address@hidden>:
> Well, the data tables are a little convoluted.  But, at this point they
> work.

Agree

>
> 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.

I was not aware of the goal of one week between NoR release and new ardb release
otherwise i fully agree with you. We shoud make our users happy, then
make ourselves happy with the codebase

>
> 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.

if i have to put a plan here i would do this in several steps:
* include NoR in anarchdb codebase
* i would then put a maintenance release that close all know issues
and the new ones produced from NoR release. This would allow us all to
accustom to the codebase and enhance our team work. By the same time
we will set up a developpemnt plan.
* last step: codebase refactoring.

>
> 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.

Agree, the app is deadly missing developpers docs. we should consider
including doxygen to our building env to generate doc.

>
> 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.
>

Agree. The best way should be to do it user-driven

> 3.  The backend group will be concerned with "refactoring the code."

Yes

>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.

I come from the Java Web application words, where we are used to
reduce couplings between application aeras :
* persistance -- database interaction, including migration and such
* business Logic -- what you do call codebase
* persentation -- The end user UI

>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.

I fully agree with that. One thing to investigate is to register DB
schema version and to include in our release all version-to-version
migration scripts.

>  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.

agree, we should also take care of françois deck morphing issues.

>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),

Yes, i did notice that the codebase does not include any automatic
unit tests. That is something i'm willing to promote.

> 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.

That shouldn't be a big deal.

>
> 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?

I do agree. We won't do much before releasing NoR in anarchDB.

None the less i think we need to evaluate our task force to see what
is acheavable in short and long terms

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

No pb dude

>
> Karl

Sylvain

>
> --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
>
>
>
>
>
>
> _______________________________________________
> Anarchdb-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/anarchdb-devel
>