Managed .NET Embedded Database
-
I'm looking for an embedded .NET database that operates completely in managed code. So far the only one I've found is TurboDB.NET (and I am not sure whether that operates completely in managed code). Are there others?
-
I'm looking for an embedded .NET database that operates completely in managed code. So far the only one I've found is TurboDB.NET (and I am not sure whether that operates completely in managed code). Are there others?
Why do you care? Is there something that Jet can't do that you need to do? While a wholly-managed application doesn't incur any interop overhead, a P/Invoke call (to a flat API) only has about 10 machine instructions overhead, while a COM Interop call has about 50 machine instructions overhead (source: Managed/Unmanaged Code Interoperability[^]. Some people have reported that ODBC connections from ADO.NET (using System.Data.Odbc classes in Framework 1.1, or Microsoft.Data.Odbc from the download for Framework 1.0) perform better than OLE DB connections. If you're doing anything serious with the database, though, the interop overhead is likely to be swamped by the cost of actually reading and writing to files, and looking up records in indexes. If you need your application to be portable across CLI implementations (and across operating systems) then you will have to consider an alternative. 'Pure managed' code on .NET is far less important than for Java, where performance with unmanaged code is reportedly poor.
-
Why do you care? Is there something that Jet can't do that you need to do? While a wholly-managed application doesn't incur any interop overhead, a P/Invoke call (to a flat API) only has about 10 machine instructions overhead, while a COM Interop call has about 50 machine instructions overhead (source: Managed/Unmanaged Code Interoperability[^]. Some people have reported that ODBC connections from ADO.NET (using System.Data.Odbc classes in Framework 1.1, or Microsoft.Data.Odbc from the download for Framework 1.0) perform better than OLE DB connections. If you're doing anything serious with the database, though, the interop overhead is likely to be swamped by the cost of actually reading and writing to files, and looking up records in indexes. If you need your application to be portable across CLI implementations (and across operating systems) then you will have to consider an alternative. 'Pure managed' code on .NET is far less important than for Java, where performance with unmanaged code is reportedly poor.
Hi Mike. I am an experienced programmer and am new to databases. Please be nice. Maybe a bit more background about the application will help. I am writing a server application that runs on a dedicated host. I don't need to do complicated SQL queries and I'd be perfectly happy to use a custom API instead of SQL queries. Doing SQL queries may be fine too. The main reasons I have been looking at databases is to get atomic transactions so that the database is always in a consistent state. In my situation recovery is also nice although it's less important than atomic transactions. The ability to access the database from multiple threads would be extremely helpful. Benefits of staying in managed code for this application are type safety, debuggability, and security. Benefits of embedding the database over using a database server are relative ease of deployment and system management. If performance is better using embedding than a database server, that would be another benefit. As you say though, maybe performance will be about the same either way. You mentioned Jet.. Is Jet something that can be used directly from my C# application, or does it have to be used with a higher level package like Access? If it can be used directly, is there somewhere I can read about Jet from a non-propaganda standpoint? I looked around some in Google and found mostly Jet error messages and security bulletins. I have been avoiding Access because my understanding is that Access does not perform well with large databases.
-
Hi Mike. I am an experienced programmer and am new to databases. Please be nice. Maybe a bit more background about the application will help. I am writing a server application that runs on a dedicated host. I don't need to do complicated SQL queries and I'd be perfectly happy to use a custom API instead of SQL queries. Doing SQL queries may be fine too. The main reasons I have been looking at databases is to get atomic transactions so that the database is always in a consistent state. In my situation recovery is also nice although it's less important than atomic transactions. The ability to access the database from multiple threads would be extremely helpful. Benefits of staying in managed code for this application are type safety, debuggability, and security. Benefits of embedding the database over using a database server are relative ease of deployment and system management. If performance is better using embedding than a database server, that would be another benefit. As you say though, maybe performance will be about the same either way. You mentioned Jet.. Is Jet something that can be used directly from my C# application, or does it have to be used with a higher level package like Access? If it can be used directly, is there somewhere I can read about Jet from a non-propaganda standpoint? I looked around some in Google and found mostly Jet error messages and security bulletins. I have been avoiding Access because my understanding is that Access does not perform well with large databases.
Maybe Bamboo Prevalence can help you. See article here[^] for more info...
Have a look at my latest article about Object Prevalence with Bamboo Prevalence.
-
Maybe Bamboo Prevalence can help you. See article here[^] for more info...
Have a look at my latest article about Object Prevalence with Bamboo Prevalence.
Thanks, that is a good possibility. I had looked into in-RAM databases a bit before, and your note inspired me to look at them some more.