An ORM, or framework for turning innocuous model objects into incomprehensible error messages because you missed out a virtual.
<RANT>
Printable View
An ORM, or framework for turning innocuous model objects into incomprehensible error messages because you missed out a virtual.
<RANT>
Get a proper dbms and some Connections. You'll be fine ;)
In fairness post magic unicorn it's not bad at all. Would I rather be doing nhibernate mappings? Not really.
Still, as my mother used to say about a very unreliable car, it still beats the hell out of walking, or writing T-SQL *shudder*.
What gets me about T-SQL is how arse about face it is.
SELECT <relies on knowledge from next stanza>
FROM <oh yeah, lets not put this first, the middle, that makes sense>
WHERE <condition which merges all projections and filters together>
I mean even the simplest example is just wrong. T-SQL is just horrible for its job.
*chortle*
you're not a database person then? :devilish:
Given it's based on English, arse-about-facedness was really going to be a given. My nlp lecturer always used to joke about how people try to claim that language is designed to clarify meaning, but in his opinion it's actually far more true to say that language is designed to help disguise meaning.
Then again, can you imagine the looks you'd get if you asked someone "From the cupboard, get me the pen, the fat blue marker"?
I like SQL, but that's because I am a database person, and I've used it a lot. Things like EF and nhibernate give me the willies, because I have no idea what it's actually doing to my data under the hood....
Which version are you using? It's come on a lot from the original version and MUE (magic unicorn edition aka EF5 IIRC) wasn't too bad, not great though
It's still not much comparison to Linq2SQL with some nifty bulk inserts and quickness to use with the differences in code first, design first etc, I'll always have a db first, simple as that really (unless it's a quick hack with no prior data reqs in which case I'll have a nosql db like Raven for speed in development)
Currently been doing it code first, which I prefer in a way. The storing of data isn't important or hard in 2014. It should be based on the design of the domain as dictated by the systems requirements.
Modelling data relationships just doesn't work in most RDBMS, they focus only on single dimension relationships, people hack their contravariance.
:oQuote:
Originally Posted by TheAnimus
Maybe not in the domains you're working in, but you can't honestly believe that's true in all cases?
Not even vaguely true. Modelling relationships is dead easy in rdbms, you just need to know what you're doing. Are more to the point, implementing the relationships is dead easy once you've modelled them. If you just start by randomly trying to throw tables together and hope something sticks, then sure, you'll struggle, but if you're architecting properly then there really shouldn't be a problem.Quote:
Originally Posted by TheAnimus
What you say of modelling data, and what I say of modelling data is different. I am guessing you are coming from a RMDB point of view.
Modelling relationships to a degree in a RDBMS is easy, but it isn't necessarily correct. I mean you omitted the most important part of my sentance, contravariance.
Then when you try and use a traditional relationship it creates all kinds of problems. Let's take something you want to store thats a matrix. Now lets say that you have about 5 different forms of this matrix, and you have about 1000 entities which has one or more of these forms per day. You have history for say 10 years.
Now how do you store that? Do you have one row per matrix? How? Do you have every column combination possible? Bloat your size. Do you store it as a keyvalue pair thing (ie one row per point) you'll have a massive table, but you could partition it by Entity that the matrix belongs to, then by Date. Performance would suck.
Yeah, terrible. So you end up hoping you can fit it in some binary structure that you can have one column contain, pulling out only columns that you want as an index. But then you constantly have to fit between code that can parse the binary blob and manage your index columns creation / destruction. You also have a major sync issue, as you have the replication. But lets ignore those. You now have say ~12M rows. Now say you've a couple of tables like that, you have a relationship between your Entities declartion table. All of a sudden adding / removing an Entity takes forever.
The storing of data today shouldn't be important. It really shouldn't be. The idea of defining your Tables, Relationships and Indexes manually should be out of date. You should be able to constantly determine these based on the code Model Objects.
Erm ... mu? Still too abstract. How am I supposed to model data interactions based on "theres some matrices that are slightly different and you need to store lots of them", let alone then suggest an implementation? Implementation plans require concrete requirements, which that most certainly isn't.Quote:
Originally Posted by TheAnimus
Yes, we almost certainly think of modelling data in different ways, but that's not because I'm a DB person, it's because I'm a data person. Data is more than just how you persist the current and previous states of your program. And personally I like being able to control how the validation and integrity of that data is being managed. I'm not sure you can effectively and efficiently do that with EF.
A matrix is too abstract?
Ok, you have a series of "Implied Volatility Matrices" these have an axis of time duration ie (1M,2M,3M,6M,1Y) and percentage strike (50%,70%,80%,90%,100%,110%,120%,130%,150%), that has a double precision floating point value for it.
But some have different tenors (time duration sets) others have different percentage strikes (say every 5%).
Obviously this fits horribly in a RDBMS.
Do you know what I mean by contravariance in an OOD world? It is a classic example of a problem that doesn't fit in the limited dimensional world.
Most real world problems are n-space (multidimensional, n-connected in graph theory).
I'm really into EF at the mo, when I first tried it a few years ago now, it was absolutely godawful. The code the code-first command-line migrations tool comes up with is a bit ropey still if your model is complex - that could definately use some improvement - but simple enough to correct. Great for prototyping stuff practically without touching RDBMS software.
Which version of EF you are using? Can you post you Entity classes? It sound like some relationships didn't match. Code first usually don't have such problem.