Semi-automated Vintage trend analysis

[AmbivalentDuck]

So, to keep this moving along, someone needs to take charge of the database portion of this.  Clearly, I'm not the best candidate for that portion.

So, someone please step forward???  Also, I can potentially physically host the db (easiest if it's mysql or postgres) if necessary.  I have a funny feeling that all of the heavy math will end up happening on my compy anyways, so might as well have the data on it.

Until someone gets a database to stick the data into, writing parsers is an empty exercise.

Please volunteer!??!

[Harlequin]

I've finished building out the tables in MSAccess 07 (for lack of a more sharable tool), and I'm about 10% through populating some sample data into them.  I'll have some time this weekend to fill in sample data and build some useful queries.

Agian my hosting knowledge is basically non-existance.  So I can send this DB to anyone who wants it - send me a PM with your email address or something and I'll toss it out.  Again it will be like 2-3 days until the sample is ready.

[eaglewolf]

Table Deck_Reg

Key - Deck_ID
Key - Card_ID
Key - MainDeck_TF (or some other indicator for maindeck vrs sideboard
Field - Card_Quantity

Sorry if someone already mentioned this, but I haven't finished reading the thread yet.

I think it would be better to have two quantity fields; one for maindeck and a second for sideboard.


I might be able to whip something up in perl for parsing morphling.de; it seems a lot better suited to this sort of task than any of the other languages mentioned and the DBI module means I can use the same database code for just about any database backend. I'm very pressed for time lately, so I can't make a commitment right now, but I want to see this project work

[Harlequin]

I had thought about that, but it makes the parser more complex for really.... not that much benefit.  Mostly because when people reg thier decks they write it out like this:

Maindeck:
2 card
4 card
3 Trygon Preditor
2 card

Sideboard
1 Trygon Preditor
1 Tormods Crypt

It all depends on what the parser looks like.  If it reads that top to bottom, it would have to hold the maindeck in memory and recycle over itself to ultimately create the line for: Trygon Preditor | 3 | 1
Unless you could have it "Upsert" data into the table ie:
Upsert -> Trygon | 3 | <null>
Upsert -> Trygon | <null> | 1
And set the table default for null to 0.  That ~could~ work as well.

In general I don't mind if tables are complex so long as it makes input or extraction easier.

[AmbivalentDuck]

The suggestion from Meadbert's wife was to just add a copy of the card to the deck every time it occurs.  So, you look up Trygon Predator by name and stick its ID  into the deck once for each copy in the deck.

Since the max quantity is 4 and in practice many cards with be one-ofs, this doesn't add much weight.

[Harlequin]

That would get ugly on a database.  You need to have uniqueness in the key.  So you would end up with extra bagage in the form of some sort of Card# or at least some sort of auto-number index (which IMO is "bad design" in otherwords 'auto-number' is the 'goto' of databases and should be avoided at all costs).  You can't have:

myDeckID | Trygon
myDeckID | Trygon
myDeckID | Trygon

Because it causes a "key violation" you need some sort of sequence number to make it unique:

either:

myDeckID | Card#27 | Trygon
myDeckID | Card#28 | Trygon
myDeckID | Card#29 | Trygon

or:

myDeckID | Trygon | #1
myDeckID | Trygon | #2
myDeckID | Trygon | #3

And this gets into "single normal form 101" basic theory.  When you get into problems where you cannot have #3 without #2... you shouldn't have #2 in the table.  And thus you end up only recording:

myDeckID | Trygon | 3

Where "myDeckID | Trygon" is the unique key and 3 is a quantity field. 

[AmbivalentDuck]

Why does the deck needs row IDs 1-60?

You can have non-unique rows.

Ie.  CardID for trygon is 2.  3 maindeck trygons, 1 sb trygon

CardId  SB
2          0
2          0
2          0
2          1

[emidln]

If the parser inputs the maindeck and sideboard in different routines it wouldn't be all that much effort to check if a card is represented and choose between an update or insert. If you're just inputting from a text file in apprentice format ala:

// some comment
4 Merfolk of the Pearl Trident
56 Island
SB: 14 Mountain
SB: 1 Island

I put a basic example parser here: http://tmd.pastebin.com/f4934ecbe (it works on a sqlite database but this could easily be changed).

Granted this code isn't complete (I'd need more information about the actual frontend and we'd be likely working with an input stream and not an actual file (not that python cares much)) but it's a very close representation of what's needed to do the actual parsing. This would let you put the decks in their own tables or could be easily adapted to read a deck name from a comment (or some other special syntax in-file) to get something like deckname|cardname|main|sb if you go that way.

* The supertr class is here if you need it to help see stuff http://tmd.pastebin.com/f74c2d162

[AmbivalentDuck]

Ok, so, someone needs to provide a SQL script or I need to give people access to a SQL database on my compy or something.

This is stalling out for lack of a place to store everything.  And that's just dumb.  We see to have plenty of people who can volunteer to take a site and write a parser.  And I'm happy to write the math routines once I see data structures.

So, can someone volunteer to write a SQL script that will just get an appropriate database set up?  I can't imagine this is more than a 30 minute job for someone who knows what they're doing.