Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Vera Brie
Kingfisher Applied Sciences
0
|
Posted - 2011.10.22 19:27:00 -
[1] - Quote
I'm trying to piece together all the components needed to make items, it seems like T2 blueprints are missing components in the data dump .. or I'm missing an additional table to include.
For example:
Survey Scanner II Blueprint only shows Trit, Pye, and Morph, nothing else.
Can anyone lend a hand here and point me in the right direction to get these T2 components complete? |
Cyerus
Galactic Dominion Eternal Strife
3
|
Posted - 2011.10.23 01:38:00 -
[2] - Quote
It's a bit tricky to do.
I suggest to start with the 3 queries found on this page -> http://wiki.eve-id.net/Denormalizing_itm/rtr This denormalizes the invTypeMaterials / ramTypeRequirements, basicly combining all the components into one table.
After that you only need to query the new 'materials' table to get a list of materials needed;
Quote:SELECT * FROM materials WHERE blueprintTypeID = 1234 AND activityID = 1; ..to return invTypesID (requiredTypeID) needed to build fictional blueprint 1234.
Don't forget to do the ME calculations afterwards!
---
If you are just looking for a web application to do this all for you, I can suggest http://eve-it.org/market. A website of my own making, still beta, which is exactly what you need. Prices are outdated, but quantities and ME calculations should be accurate. |
Vera Brie
Kingfisher Applied Sciences
0
|
Posted - 2011.10.23 03:55:00 -
[3] - Quote
Ah, the ram tables, I'll have to look into them, thanks. Do the ram tables also cover T3 or was there new tables added for that too? |
Lutz Major
Austriae Est Imperare Orbi Universo
23
|
Posted - 2011.10.23 04:22:00 -
[4] - Quote
First: extra materials (like most T2 components) are in the ramTypeRequirements table.
Second: it you continue to use the dump and do not create your own database, I recommend that you do not create any associated tables and continue to use the existing ones. |
Cyerus
Galactic Dominion Eternal Strife
3
|
Posted - 2011.10.23 11:27:00 -
[5] - Quote
Lutz Major wrote:First: extra materials (like most T2 components) are in the ramTypeRequirements table.
Second: it you continue to use the dump and do not create your own database, I recommend that you do not create any associated tables and continue to use the existing ones.
I have to disagree. Creating the denormalized table will increase performance. It saves you the time and gives you performance by performing those queries only once (when creating the 'items' table), compared to running them for each and every blueprint.
Downsides are the slight increase of memory of the database, and the need to recreate the 'materials' table after each database dump release. Still, the benifits outway the downsides by far. |
Tonto Auri
Vhero' Multipurpose Corp
0
|
Posted - 2011.10.23 12:46:00 -
[6] - Quote
Why not create a view to the database?... Also, how many times you need exactly that aggregated table, and not parts of it? The answer will vary between applications, you have to answer it for yourself, not for me.
Also, hand-crafting any tables cutting short your application lifetime. |
darius mclever
1
|
Posted - 2011.10.23 12:59:00 -
[7] - Quote
Cyerus wrote:It's a bit tricky to do. I suggest to start with the 3 queries found on this page -> http://wiki.eve-id.net/Denormalizing_itm/rtrThis denormalizes the invTypeMaterials / ramTypeRequirements, basicly combining all the components into one table.
Dont use this denormalized table. it makes it almost impossible to get the waste calculation right. use the 2 tables directly.
Tonto Auri wrote:Why not create a view to the database?... Also, how many times you need exactly that aggregated table, and not parts of it? The answer will vary between applications, you have to answer it for yourself, not for me.
Also, hand-crafting any tables cutting short your application lifetime.
can you pass parameters to a view?
If you just want a static view for a certain ME level you could use materialized views when the DB supports it, that way the calculation will also be only done once, but updated when the underlying tables change. |
Lutz Major
Austriae Est Imperare Orbi Universo
23
|
Posted - 2011.10.23 18:21:00 -
[8] - Quote
Cyerus wrote:Lutz Major wrote:First: extra materials (like most T2 components) are in the ramTypeRequirements table.
Second: it you continue to use the dump and do not create your own database, I recommend that you do not create any associated tables and continue to use the existing ones. I have to disagree. Creating the denormalized table will increase performance. It saves you the time and gives you performance by performing those queries only once (when creating the 'items' table), compared to running them for each and every blueprint. Downsides are the slight increase of memory of the database, and the need to recreate the 'materials' table after each database dump release. Still, the benifits outway the downsides by far. Denormalizing tables usually result in decreased performance, because of the bigger overhead, table locking and increased database resource needs. The 'additional' queries aren't a problem either. The database handles smaller queries better. If you really have a performance problem, then use prepared statements or use an application cache to avoid database calls completely.
In this particular case you are also mixing in-game logic about raw (inv) and extra materials (ram), recycle-able components (inv), skills needed (ram), ME wastage calculations (inv), and so on.
|
Vera Brie
Kingfisher Applied Sciences
0
|
Posted - 2011.10.24 02:28:00 -
[9] - Quote
This is what I'm working on: https://github.com/piotrb/eve-production
I'm sticking to just using the core tables as they are, not a fan of painful upgrades each time there is a new dump version out.
I mainly didn't know about the ram tables (not like this stuff seems to documented properly or anything), that explains the big chunk of missing materials, otherwise I'm good. |
Tonto Auri
Vhero' Multipurpose Corp
0
|
Posted - 2011.10.24 13:00:00 -
[10] - Quote
darius mclever wrote:can you pass parameters to a view? You use view the same way you'd use a table. Indeed, you can pass parameters to it to slice the result the way you want it.
Quote:If you just want a static view for a certain ME level you could use materialized views when the DB supports it, that way the calculation will also be only done once, but updated when the underlying tables change. You create a view to the aggregation of tables. Not to a part of one table (it's stupid, use plain SELECT). |
|
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |