Relational Database<--->Objects (ORM)

nitro

nitro

Does anyone have any opinions on what a good Relational Database to Object mapping system (ORM)?

Let me give some constraints. It needs to support C#.Net, Visual studio 2005/2008 and SQL Server.

NHibernate is a very popular one:

http://en.wikipedia.org/wiki/NHibernate

Any other suggestions and what are the advantages over NHibernate?

Thanks.

nitro
 
ObjectSpaces was a flop... I have used a few in addition to nHibernate:

http://www.ormapper.net/
http://www.llblgen.com/defaultgeneric.aspx

Really depends on which flavor is right for specific tasks, skills, and timelines... Also, how a development/ design team prefer to architect and build. The topic in general is like religious or political debate :)

Our preference was Wilson...

VS2008 and LINQ seem to be the rage presently (I have not used it though). We will be researching this technology (and ADO.NET 3.5 implementation) soon.

HTH
 
IMHO it also depends on size of the project you're involved in. For simple projects ( like those with small number of persistent types, without requirements to be highly distributed, without distributed caches requirements, simple concurrency models, and so on, but with rapid development needs ) I would go with LINQ.

On the other hand, if you project is a big one (usually 2+ MLOC), using DMA (Domain Modeling Architecture) or similar methodology, highly distributed (with all the consequnces) , have a high percentage of generated code and so on - NHibernate is good choice.

Of cause there are many more aspects to consider before you actually choose the right ORM solution - the project size is only one of them - it may save you the unnessesary learning curve time.
 
Thanks for all the responses, they are very helpful.

After a bit of reading, it looks like LINQ will probably be ok as a first iteration.


nitro
 
guys what exactly is this and what does it do? what's its application?

I'm really intrested in coding/databases but this all sounds strange to me maybe i been too busy at work missing out on these new stuff lol I'd appreicate if someone explained.


rosy2 with that versant stuff can you create a time-series object? and how much is that thing anyways?


thanks
 
Depends on the type of data you want to to persist. Relational databases aren’t always the way to go. If you're persisting simple trade data across a few tables then it’s pretty clear – stick em in a relational database and be done with it.

However persisting time series data is a whole different ball game. For example, persisting the DOM for an active futures contract could essentially contain many thousands of rows. Even with a bit of clever table partitioning – a relational database just can’t cope. A standard relational mapping is just not good enough for this purpose.

My data requirements are pretty extreme and in the end I rolled my own real-time persistence mechanism in java. All real-time updates are captured in a memory based collection which is subsequently persisted directly into a memory mapped file. With a bit of clever data partitioning i.e. storing time chunks of data in separate time segments, the data is easily manageable and quickly retrievable.

Next stage would be to move to a dedicated commercial time-series database like kdb, however it is not cheap. See http://kx.com/
 
Quote from Batman28:

guys what exactly is this and what does it do? what's its application?

I'm really intrested in coding/databases but this all sounds strange to me maybe i been too busy at work missing out on these new stuff lol I'd appreicate if someone explained.


rosy2 with that versant stuff can you create a time-series object? and how much is that thing anyways?


thanks
More...

i dont know about cost or timeseries objects. I use persistent objects to make transactional systems easier to recover from failure.
 
You must log in or register to reply here.
Back
Top