EVE Technology Lab

So, i tried adding the foreign keys that are commented out in the SDE to the tables, e.g. this part:





This leaves me with:


Which is obvious, because invNames.itemID is bigint and agtAgents.agentID is int.

Since I imagine that CCP uses those FKs themselves, what is the magic to make them work? If I were to add ALTER statements to modify the clomuns I'd have to drop all FKs referencing the columns first, then alter the column, and then recreate all FKs, which would mean that i'd have to extract all those FKS from the dump.

Has anyone tried to get those FKs working, and if so, how?

which since they don't use them explains why you found many that are outdated and don't work The next question is why you think you need to use them? The reason I ask is that everything you are doing with the SDE should be read-only which won't get any type of performance increase as well by having them and will if anything be slowed down as well. What can be helpful is to look at the your own queries and maybe add a few extra indexes for stuff you do if one of your queries seem to be slower than you need/want it to be.

Since you are using an ORM you wouldn't notice the performance hit from the FKs because of the greater ORM overhead most of them have. As to probably why they left them in but commented out is so they can be used by people like you and me and maybe even the DB people at CCP much like a programmer comment their code to make things more clear when working with it later. It sounds like some of them have not been maintained as things have been updated like they should be but that really not uncommon from what I've seen else were in programming

If I was to make a guess where most of them became dated was when CCP switch from 32 bit ints for IDs to 64 bit IDs so you could probably do a simple replace on the FK stuff to correct them. CCP has also changed/deleted some of the tables as well which is a harder thing to do updates for and would probably require you do them manually like you been doing.

Well, if you think ORMs are evil you must think that every layer of abstraction is evil and that we should still write ASM code?!

I have agreat understanding of databases and SQL, working with Oracle, IBM DB2, MySQl and other systems and also work with relational algebra, tuple-relations calculus and safe tuple relation calculus. So I really now my way around databases and I am actually able to write SQL queries like my second native language, for more then one RDBMS vendor.

Deeming a tool evil "just because" is short sighted at best, foolish at worst.

I agree with you to a certain degree that for someone ho doesn't know anything about databases, hiding their workings behind a framework can lead to obscure results as people do not understand the consequences of their actions and lack the understanding of interpreting the effects they see. But that can be said about any framework ever constructed, about any level of abtsraction ever built. Yet we do not longer write 0 und 1 to write our programs, we don't even write assembler code anymore. We have developed layer upon layer of abstraction and frameworks.

You are using Twitter Bottstrap on your very own site. Did you now that CSS frameworks are evil? They divorce people from the CSS mindset and lead to some really /stupid/ things being thrown at the browsers. Sure, you can avoid that, but that's by understanding what's actually going on in the browser when it parses and interprets the CSS file(s) and by writing your very own CSS declarations with all the hacks and tricks needed to get it working cross-browser or by solely targeting one browser and using only it's own proprietary features.

In short: Your usage of an abstraction layer contradicts your opposition of an abstraction layer in itself.

If you have ever developed enterprise applications then you'd know the values of ORM. But honestly I didn't come here for a fundamental discussion of the pros and cons of ORM systems. ORMs have - as all tools - their pros and cons, but what seperates a software developer / engineer who excels at his job from a mediocre one is the ability to weight the pros and cons of the given tools for the given task and to choose the proper one. Yet you jumped simply to the conclusion that ORMs are evil without any substantial argument for it, other then basically "just because", and without knowing what my goals really are. So yeah, maybe you want to give that a more in depth thought and decide in which situations ORMs are indeed not the best choice (hint: there are such situations - as well as there exist valid scenarios in which you'd use very low-level programming languages [hint: embedded systems]).

I've read many of your posts and I'm very well aware of the tools you offer and that you work much with the SDE. But honestly I am a little bit shocked that someone like you demonstrates such short sightedness. I had expected more. I guess the old saying "With a hammer, everything looks like a nail" is true after all.

WelI can't agree more. But you really made it sound as if you were just against ORM without much considerations. My apologies if a came off a little bit blunt, in retrospect i my have worded it a little bit less controversial ;)

As I said i'm working on JPA bindings for the SDE, and I have already mapped all of the inv* and dgm* tables. It allowed me to prototype a basic fitting API in a matter of hours (no gui, only programmatically at this point). The beauty of having proper ORM mappings is that you don't need to concern yourself with actually reading the data (well, you have to pay attention to what data is fetched eagerly and what data is fetched lazily and a little bit about when to open & close sessions), but instead can focus on working with the data. Which makes it so much fun to work with.

Yes, jQuery might have been a better example, theres even a meme of it on stackoverflow (use jquery - http://meta.stackexchange.com/questions/45176/when-is-use-jquery-not-a-valid-answer-to-a-javascript-question) that is somewhat related, but Bootstrap was the first that came into my sight and had to do.

But for stupid mistakes, they also occur without ORM. I've seen bits of code where someone would slap 10k+ selects with quite complex onto the DB in a for-loop, just because he needed all of those entries. This kind of thing is painful. Though Hibernate can make some of the real bad mistakes harder to spot, especially for beginners. I definitely wouldn't advise anyone to use an ORM to learn how databases work. But on the other hand, i wouldn't recommend Zend Framework for someone who doesn't know a cent about OOP to learn PHP in an object oriented way either ;)

As I said I'm working with databases for years, both small sized and bigger ones, from different vendors, and even know some of the internal workings of them. So It's definitely not an issue about "learning SQL" for me (though I can always learn some new amazing facts about some RDMS that I didn't know before).