M: I want to build a quick database on my phone using the program Ninox. So, N-I-N-O-X. It's for Pokemon Go, and so far that's all I'm certain about. Until I tell you to start working on things, just kind of take a mental note of what I'm looking for, okay?

M: Okay, I'm going to be sending this in multiple messages, so you don't need to respond to all of them until I tell you to start, okay? I know you have a compulsion to give some kind of response, just keep it down to one line. Let's see, so the point is to help me keep track of the various little sub-projects that I'm trying to do within the game.

M: No, the entire point is to make a database that will help me keep track of the database stuff and do the little short-term projects and all of that. That's why I'm trying to talk this out. It's because there ends up being different types of little collections and things that I need to remind myself to do and all of that, which likely could all get kept under a fairly simple database structure, but I need to talk it out in order to make sure that I've got the kind of functionality that I'm looking for. I can't just go and start building because I'm not certain what method of reliance and whatever the database will need.

M: Okay, so I'm thinking that what I want to do is try and keep track of, first of all, build my own little index, my own little pokedex, as one of the primary database things. That would be including the primary form of the creature before it evolves, what index number it has in the game, what forms it can evolve to. And then we start getting into the things that I would think I would need. That would include stuff like how much of the candy I have at any given point, which would be manually entered. If possible, it would need to track the last day that I did an update of that number so that I can tell by looking at the number whether or not I might have made some sort of massive change and need to go check that up. Or if it was something that I did yesterday and just forgot. I need to build it so that I can easily add fields for the various projects in a way that can be referenced with relative simplicity. Like, no complex give and take or anything like that, I don't think. Might need to change that later, but I think that'll work out here. It might be better to go with two tables at least for this, one with all of the basic game-provided information, the stuff that's static and can't change, and then a second layer, or sorry, not layer, but table, based on that first entry, which would then keep track of the things like the regular and XL candies, and all of the other stuff for a particular species.

M: My current ongoing project is to try and get the best possible version of each entry that I can get, prioritizing the most evolved version, as well as getting participants for each of the player versus player type situations, which are reasonably attainable, or even unreasonably attainable as just kind of an aspirational thing. So, like, a creature that has two evolutions, as well as its basic form, would need an entry for each type, of course, plus some way of tracking whether or not I've got a version of it, whether or not it can participate easily in one of the player versus player things, because sometimes there's an overlap where... Both forms can get within the right CP level in order to compete, etc. This is where I really need to think about it. The other table type is easy, the one with all the information from the game. The difficulty is coming because I'm not sure whether or not I should have two separate tables for this kind of tracking, because there's also the kinds that are shiny, that are mega, the ones that are both kinds, etc. And I want to keep track of the capacity of each one to be replaced. Like right now, what was it I was looking at? Right now in the Pidgey family, I think I've got creatures that are for each of the PvPs, like 98th percentile at least, and a strongest one that's 44 out of 45 in terms of strength capacity. Now he hasn't been leveled up all the way, and I'd want to keep track of that as well, but the important thing is that I want to be able to mark off in a way that I can use to easily check whether the creatures that are going to be popping up for the next week are something that I don't have a good version of, so I know whether or not I should spend a significant amount of time looking for a replacement, or if they're already pretty much as good as they're going to get, so I can just casually go looking and seeing if I accidentally come up with something that's just a little bit better.

M: By the way, if you're trying to understand what the hell I'm talking about, you're allowed to go online. Some of this terminology is game-specific, and I just play it too much to recognize that it isn't widely known.

M: I might want to be able to mark off if I'm satisfied with a particular situation. Okay, let me expand on that before we start getting into that aspect. Okay, so there are variations on various creatures where, like, for a certain period of time, they have a Halloween costume or a Christmas outfit on or something like that. Some of those have use in the game, like they can evolve just like normal and they just look different, so going out looking for a good one of those is in one category. But then others are, you know, like, locked into a certain form, so they are unlikely or even impossible to think of as the best version to use for competition. So first of all, I need to be able to create outfit variations in each entry. And then, depending on the situation, we get back to how I started this message where... I need to be able to indicate to myself that a particular item being ticked off is good enough and that going out looking for more isn't really going to fill in any kind of particular competitive niche, no matter what I get. Like, for example, if you take a look at Pikachu and all the variations there are, I'd say that more than half of them are completely useless outside of the collection aspect. Like, they can't evolve and often have minimal use in PvP, so they only exist to be collected, not actually kept track of. So every time there's a variation, I go out and I try and catch two or three and hope that I get a good version. But if I don't, I need to be able to indicate to myself that it's not something to really stress myself over.

M: I feel like maybe for the personal information tracking aspect, flags and or associated number fields might be the best way to go. Probably with an emphasis on the flags, at least at the moment. Emphasis should be kept on making the database updatable. Like, don't tie in too many relationships or something that are going to end up breaking if I lose track of them and decide that I want to change the format. Yeah, as I'm talking it out, I think that at least two tables are necessary. One of them being that bedrock information that can be updated in terms of content, but not the kind of thing that really gets changed in terms of database structure. And then a second one which is kind of a personal information gatherer and wrapper for dealing with that. table and anything else I need. Oh, on the base level table, I'd like to keep track of the moves that are useful. That would be kind of a content thing. Oh, that's right, we got to keep track of types. I think that might be its own separate little table just for referencing because that's got the whole, you know, strong and weak against thing to keep track of. Might be the best place to start making sure that that gets taken care of because that's not something that even gets edited that much. I don't know if it has been for the last 20 years. So pinning that down will probably be the best place to start just for simplicity's sake. The thing that says, you know, type A is vulnerable to type B, but strong against type C. Interpreting it might be kind of a pain in the ass, but that's a job for the things that use it, not for the table itself. But yeah, almost has taken care of in the base level table. I'd like to keep track of what moves are good for any particular species. Now that I'm talking through it, there might need to be a third intermediate table, because at the bedrock level, there are the different families of species. Then there are the evolutions that are related to that species, and there are also regional variations, which sometimes change where the evolutions can go. So, yeah, because one of the things I'd like to do is keep track of which moves are best for PvP and which are best for raiding. And then even those kind of have subcategories of speed versus power. Sometimes they overlap, other times they obviously don't. Like for raids, you want the best damage per second. Well, with PvP, you might want the best energy per second because that means you get to use your special move and interrupt the flow of the game that much faster. Not sure what I'm going to do with that, but the point is that the reason why I'm saying that there might need to be a third table as the intermediate is because you've got the families, yes, and even that will need to keep track of which region is being addressed. But in order to keep track of the best moves, each of those families then has to have an entry for each evolution because the available moves for each evolution usually changes.