# Abstract Data Layer Part 1: Object ID Types And Conventions

DevFeed: [Abstract Data Layer Part 1: Object ID Types And Conventions](<https://devfeed.tech/articles/abstract-data-layer-part-1-object-id-types-and-conventions-33392.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2012/03/19/abstract-data-layer-part-1-object-id>)

Published: 2012-03-19T00:00:00Z

Content type: article

Language: en

Sources: [Tim Kellogg](<https://devfeed.tech/sources/tim-kellogg.md>)

Topics: [MongoDB](<https://devfeed.tech/topics/mongodb.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [Object-relational mapping](<https://devfeed.tech/topics/orm.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [C#](<https://devfeed.tech/topics/csharp.md>), [Node.js](<https://devfeed.tech/topics/node-js.md>)

Tags: [c-sharp](<https://devfeed.tech/tags/c-sharp.md>), [database](<https://devfeed.tech/tags/database.md>), [mongodb](<https://devfeed.tech/tags/mongodb.md>), [node-js](<https://devfeed.tech/tags/node-js.md>), [orm](<https://devfeed.tech/tags/orm.md>), [sql](<https://devfeed.tech/tags/sql.md>)

## AI overview

The first part of a series examines object ID types and conventions for an abstract data layer that can accommodate both MongoDB and relational databases. It discusses MongoDB's distributed model, enterprise SQL requirements, and the choice of NHibernate as an ORM.

## Source excerpt

In February I went to the MongoDB conference in Boulder. That day was my first real taste of any sort of document oriented database. Since then I've played around with Mongo in C#, Node.JS and natively in the Mongo shell. Since then, I also can't help feeling overwhelmingly happy when thinking about how I can use Mongo for a project.At Alteryx we're entering a project where we require some specific business needs. We require an extremely fast and scalable database, hence Mongo. But we also need to package our product for on-premise installations, which I hear requires that we also support certain SQL databases....I don't actually understand why enterprises insist on using SQL. I'm told that enterprise DBA's want control over everything, and they don't want to learn new products like MongoDB. To me, it seems that 3rd products that are bought would be exempt from DBA optimizations & other meddling. But I guess I wouldn't know what it takes to be an enterprise DBA, so I'll shut up about this now. Just my thoughts...Since relational databases are a lot different than document oriented databases I decided to use NHibernate as an ORM since they've already figured out a lot of the hard problems. I chose NHibernate over Entity Framework mainly because I already know NHibernate, and I know that it has good support across many databases. Nothing against EF in particular.I've been working on this for a week or so. I've gotten pretty deep into the details so I thought a blog post would be a good way to step out and think about what I've done and where I'm going. The design is mostly mine (of course, I stand on the backs of giants) and really just ties together robust frameworks.Convention Based Object ModelIn order to remain agnostic toward relational/document structure, I decided that there would have to be some basic assumptions or maxims. I like the idea of convention-based frameworks and I really think its the best way to go about building this kind of infrastructure. Also,