[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Karl George Schaefer
Subject: Re: [Anarchdb-devel] Re: database layout questions?
Date: Mon, 13 Mar 2006 16:23:51 -0500

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.


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


Anarchdb-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]