mysql/mariadb would be where i’m most comfortable. Would be more than happy to write up a PHP based dataentry system. Perhaps if we do this right the community as a whole can help get the information into the database … as you say that is a big job. alternately we limit to one rocket say the F9 while we play with coding and look to add more as time goes on
Tonight I start to write down a alpha version of the database proposal, that should help to bring focus.
I’m usually working on oracle databases, but I’d also prefer mysql/mariadb of the open source databases.
A php data entry system would be perfect, I must admit I’ve only written one line of php code in my life…
A great deal of the data itself already exists in LaunchLibrary… I think it would be wise to tap in to that as a resource as a starting point. That way we don’t have to start from scratch. Then if we have a baseline from X there were Y launches of Z rocket, any time a new launch from Z rocket comes up we can increment said number by 1.
I’ve just had a look the launch library API and there the rocket information. The question is, if you like your data that way, or if you’d prefer a new database, where rockets are made up of parts (e.g. 1x “Falcon 9 Block 5 Booster” as first stage, 2x “Falcon 9 Block 5 Booster” as first stage boosters, 1x “Falcon 9 2nd stage”, 1x “Falcon Fairing”, mix it all together and you have a Falcon Heavy.). Those parts then have stats like dimension, weight, max thrust (those you make as pairs of names and values, that way you can expand it easily.). That would be a much deeper description of the rocket and would allow to filter which part has been used in which rocket. The fairings would be fairly non-descript, but you can add a field like “recoverable”… Fairings are not strictly necessary as parts, but that would be to decide later. You could even go down to the level of engines. The nice thing is you can start with fairly simple rocket parts and later go deeper…
I think it would be nice to keep track of each booster/capsule/fairing so we can show if wanted what missions each has flown on. Not sure where we get that info though. Also for now at least that is mainly a SpaceX / Blue Origin problem. However as more reusabilty comes into the market which it is bound to do it would make sense to already have the srtucture there to deal with it. I suppose it just boils down to how much detail we want to store and how much db space we want to use.
Sorry, there was a misunderstanding, I meant, if you have a booster GEM-60 you can see for this booster what rockets used it, e.g. Delta IV Heavy uses it as a booster, but it could also be the first stage of a sounding rocket.
But of course you could make a part “Falcon 9 Block 5 1234” and then follow it through all flights, once the information becomes available…
Either way, it’s exactly as you said, how much detail do you want to be able to store in usable form (not as a nondescript string) and are you willing to live with more space requirements (not that much more) and (here is the crux) the added complexity for queries…
As always comprimise is king. More detail more storage. So i would think each part needs it’s info storing say eqach engine type merlin/raptor etc. If the info is then avilable each F9 booster would have 9 merlin 1D’s each with indentifiers that booster would also have grid fins etc then for each flight that booster would be paired with a fairing/dragon. We could get quite detailed. I’m not entirely sure where we get some of that info (I’m pretty sure rocket companies don’t publish thier engine serial numbers). Then of course we need to tie each part to the right graphics to build any images or animations. Quite a project.
so i guess we start simple and track rockets and as whole and add depth and resoultion as we progress. Desgining DB and any interfaces with that progession in mind.
The hard part here is the data management and maintenance. LaunchLibrary has a chunk of that already done with a list of volunteers who maintain it. So utilizing that data set as a starting point seems wise. Else who will maintain a new database of entries, launches, etc.
I think the final idea is to get this to display an automagical on-screen element describing things about that rocket and family.
If using the library doesn’t make sense, that’s cool. But when architecting the system I think it is important to remember how it will be updated and maintained. More automation is better. If we have to manually update a bunch of stuff each launch, that defeats the whole purpose. I could just make a photoshop file for that.
That is the beauty of my idea, rocket descriptions can be as simple as the ones from the launch library, but you can scale the detail level up to the single screw if necessary (and if you’re insane). The disadvantage is a bit more disk space and a bit more processor time. If that’s not wanted (I don’t know your available hardware) we can go down to a more mundane database structure that’s less complex.
I’m trying to draw up a diagram, but with gimp that’ll take awhile, we have a software at work, but then the proposal would go to all parties at work and that’s just to much hassle…
cool so lets definatly start simplle and based on Launch Libary with expansion in mind firther down the road. No reason to recreate what someone else has already done and providied an api for
Great, tomorrow I won’t be able to do something, but beginning Friday I can start putting together the table creation scripts, views and a documentation for the database side. I’ll set up a local mysql server on my machine to test it out and (depending on time) write a Perl script to fill it with the rockets from the launch library…
Sounds awesome I expect i’ll be about i’ll PM you some contact details.
web crawlers should be able to get most of the rocket launch dates, they can be fed to a rudimentary app that only requires a quick review, if it is garbage then it is discarded, if legit, stays in the queue.