Hi,

Is there any possibility to create UNderived models which only exist in a document-db like MongoDB and mix/join data from these de-normalized entities with entities from the relational model ? That would be awesome.

For example, we're using an Administration entity which holds Company-data in the RDBMS. In MongoDB, we're storing EventLog-data which contains a FK-value for the Administration that's being worked in. This EventLog 'entity' does not exist in the database, but we would like to join/relate to this data from the Administration entity. Or build a TypedList that contains data from both environments.

Is this conceptually possible, creating a hybrid data-access world ?

Kind regards, Danny

DvK wrote:

Hi,

Is there any possibility to create UNderived models which only exist in a document-db like MongoDB and mix/join data from these de-normalized entities with entities from the relational model ? That would be awesome.

For example, we're using an Administration entity which holds Company-data in the RDBMS. In MongoDB, we're storing EventLog-data which contains a FK-value for the Administration that's being worked in. This EventLog 'entity' does not exist in the database, but we would like to join/relate to this data from the Administration entity. Or build a TypedList that contains data from both environments.

Is this conceptually possible, creating a hybrid data-access world ?

Where would the join take place? Not in Mongo nor in the RDBMS. To produce the resultset, one would need to pull all the data in either source from the databases, then filter them on the client to produce the resultset.

I don't see how that can be done efficiently.

What would be nice in my opinion is that if you could define 'entities' just like database-bound entities from a code/database-first perspective, but then for data existent in Document-storage based systems. Like you write in your documentation, this data always inherits from some kind of coded structure (entity-like).

Now you need an existing entity to derive from, and in our case this entity does not exist in the relational database. It would be awesome if you could handle the data within this Document database in the exact same manner (CRUD) as for normal relational-bound entities using LINQ or the low-level predicate-system.

Is this (thinking) to far-stretched ?

Regards, Danny

DvK wrote:

What would be nice in my opinion is that if you could define 'entities' just like database-bound entities from a code/database-first perspective, but then for data existent in Document-storage based systems. Like you write in your documentation, this data always inherits from some kind of coded structure (entity-like).

Now you need an existing entity to derive from, and in our case this entity does not exist in the relational database. It would be awesome if you could handle the data within this Document database in the exact same manner (CRUD) as for normal relational-bound entities using LINQ or the low-level predicate-system.

Is this (thinking) to far-stretched ?

Regards, Danny

The derived model is a denormalized entity model, so it's based on the entity model. If the entity model is seen as 'abstract', there's no entity model in the code, just the derived model and it's documents. The documents then are used in the document DB like mongo. If you need the entities in mongo, you define derived elements in a derived model, and then use the generated classes in the derived model to persist/fetch them.

The thing is: in a document db there are no 'joins': data in a document is the data for the graph you need: the join isn't needed as the data is in the graph already: a customer document contains the order documents inside itself. You might decide to have 2 collections, one for customer and one for order, and store customer documents in the customer collection and order documents in the order collection in mongo, but there's no join between them: you might store the ID of the customer in the order document, and do 2 fetches: one for the customer and one for the orders for the customer, based on the id of the customer, but joining isn't used: if you need to use data together you store it in 1 document.

This does mean data is stored multiple times. That's the side effect of using documents and no-sql db's: your data is denormalized to a given point.

So the entity model in the designer is the theoretical base on which the document definitions are based: they're denormalized projections of the entity model. That's also why you can create multiple documents based on the same entity: e.g. the Order document which is inside the Customer document (and thus stored inside the Customer document in the DB, and which can e.g. have a different subset of fields than other documents based on Order) and the Order document you defined next to the Customer are based on the same abstract entity, but denormalized differently, for different purposes. E.g. the Order document defined next to Customer as a root derived element in the model, contains a denormalized CompanyName field from the related Customer, the one inside Customer doesn't.

Today you still have to select an ORM for the entity model even though you just want the documents to use in a document db. This will change in a future version but we couldn't fit it in v5.0 due to time constraints. (so you then simply select 'no framework' and you don't need to map the entities to anything. )