This project is read-only.

Thoughts on Data Storage/Persistance

Jul 17, 2008 at 6:15 AM
Edited Jul 17, 2008 at 6:17 AM
So I was originally going to store configuration data in xml config files, specifically account information, domain info, access lists, etc. It seems however much more appropriate to store this content in a database system. I have just finished writing database access classes that can interface with Sql Server, Oracle, and MySql. All three have a free version of their system available for use. I also would feel better knowing that user account data would be stowed away in the database system rather than in a file on disk.

Another vote for the database backend is the accessablity and speed gained for querying and sorting through message header records from server queries as well as web-based applications for accessing e-mail.

Lastly, I'm pretty sure I read somewhere that Exchange server now stores message content within it's own version of SQL Server for increased search performance. Seems to make sense since the DBMS systems are designed for high-performance data storage and retrieval; mult-user locks are taken care of as well, so no worry about file locks.

Negatives? More software to install then the lightweight services I had hoped to develop, thus a larger overall memory footprint.

Jul 30, 2008 at 10:48 PM
If you've looked in the ServerLib project code that is currently released, you can see I had attempted to create a common database library where a developer could create an interface for each type of DBMS client; in fact this library works quite well. SqlServerClient, OracleClient, and even MySqlClient are all represented. Unfortunately, when I rewrote this data interaction library to work with Linq to SQL (DLinq) I was rudely informed that The database context would only receive SqlClient IDbConnection objects; meaning only Sql Server was supported. BLAH! So, in searching for an aswer I came across the DB_Linq project ( A set of DLinq providers that are still in beta, but may be promising access to other DBMS through DLinq. I would certainly love to stick with DLinq since it does provide a nice abstraction layer over the database data.
Aug 13, 2008 at 6:36 PM
Edited Aug 13, 2008 at 6:36 PM
I just read this that apparently A host of database providers are now available for use with DLinq in 3.5 SP1, so I will be going back to the use of the standard DLinq libraries. Not so difficult code-wise, but again, some thrashing in the requirements/coding.