As i need to synchronise a CouchDB with a SQL Server i need your help. I'm totally new to this and I don't really know a proper way to implement this. Is it even possible without typing thousands of lines of code? If it is, what's the easiest way to do that?
Moving data one way or the other in a specific case should be straight-forward. Read and parse the changes feed, convert the JSON documents to SQL statements that you then execute on the SQL Server side.
The general case (bi-directional, continuous sync between an MVCC and a non-MVCC database) is a hard problem without keeping extra state somewhere.
CouchDB has first-order support for conflicted documents, SQL Server does not. If you need your synchronisation to be bi-directional and stand up to concurrent modification of documents you will have a problem: CouchDB will quite happily accept multiple versions of the same document, a concept which has no direct equivalent on the SQL-Server side.
Related
I am working with industrial equipment that inserts some text data into a SQL Server 2008 database every time it cycles (about every 25 seconds). I am looking to forward that data to a mongo database in real time to use with an internal Meteor application.
Would there be any obvious starting point? The closest answer I have found is at: https://github.com/awatson1978/meteor-cookbook/blob/master/cookbook/datalayer.md
Q: Well, how am I suppose to use the data in my SQL database then?
Through REST interfaces and/or exposing the SQL database as a JSON stream. We put the ORM outside of Meteor. So, the trick is to move your data from your SQL database into Meteor's Mongo database, and have Mongo act as an object store or caching layer.
Apologies, if it is something obvious.
You need to use Mongo, but as simple repository for your MySql database.
This maintains all Meteor's characteristics and uses Mongo as a temporal repository for your MySql or PostgreSql databases.
A brilliant attempt to that is mysql-shadow by #perak (https://github.com/perak/mysql-shadow). It does what it says, keeps Mongo synchronized both ways with MySql and let's you work your data in MySql.
The bad news is that the developer will not continue maintaining it, but what is done is enough to work with simple scenarios where you don't have complex triggers that update other tables or stuff like that.
This works with MySql of course, but if you look at the code the MS SQL implementation is not hard.
For a full featured synchronization you can use SymmetricsDS (http://www.symmetricds.org), a very well tested database replicator. This involves setting up a new java server, of course, but is by far the best way to be sure that you will be able to convert your Mongo database in a simple repository of your real MySql, PostgreSQL, SQL Server , Informix database. I have to check it myself yet.
For now MySQL Shadow seems like a good enough solution.
One advantage of this approach is that you can still use all standard Meteor features, packages, meteor deployment and so on. You don´t have to do anything but set up the synch mechanism, and you are not breaking anything.
Also, if someday the Meteor team uses some of the dollars raised in SQL integration, your app is more likely to work as is.
I have a vb.net project that uses a SQLite database. I do this by using dataset/table adapters. The client is happy and all works well. However I have just heard that they plan on providing this product to another customer that wishes to use their SQL Server database. So I am writing this post so I can mentally prepare for this before I begin. I am not a database pro and have really enjoyed the simplicity of setting up and managing an SQLite database.
So any ideas on the easiest way to support SQL Server as well? I am happy to run them parallel to each other. Can I just make a separate service / middleware that syncs the SQLite database to the SQL Server on a timer and does not care about what the main app is up to?
Any pointers are appreciated.
Synchronizing two databases is possible, if rather complex. You need some mechanism to find out which records have changed, and if it is possible to have new changes in both databases, you also have to resolve conflicts.
A timer-based approach doesn't sound efficient: in most cases, the timer doesn't have anything to do; and after some data change, there is some amount time where the databases are not synchronized.
Can't you just replace SQLite with MS SQL Server?
I.e., have some configuration settings that determines whether your program's data lies in SQLite or on a server?
Assuming that an SQL Server database with the required structure already exist, this would, in theory, need nothing more than a changed connection string, and supplying some user name/password (if the server isn't configured to automatically use Windows logins).
There shouldn't be any big differences in the SQL dialects used. You have, of course, to test all your queries.
Is there seriously no way of using a shared access non-server driven database file format without having to use an SQL Server? The Entity Framework is great, and it's not until I've completely finished designing my database model, getting SQL Server Compact Edition 4.0 to work with Visual Studio that I find out that it basically cannot be run off a network drive and be used by multiple users. I appreciate I should have done some research!
The only other way as far as I can tell is to have to set up an SQL server, something which I doubt I would be able to do. I'm searching for possible ways to use it with Access databases (which can be shared on a network drive) but this seems either difficult or impossible.
Would I have to go back to typed DataSets or even manually coding the SQL code?
Another alternative is to try using SQL
Install SQL Server express. Access is not supported by EF at all and my experience with file based databases (Access, SQL Server CE) is mostly:
If you need some very small mostly readonly data to persist in database you can use them (good for code tables but in the same time such data can be simply stored in XML).
If you expect some concurrent traffic and often writing into DB + larger data sets their performance and usability drops quickly. They are mostly useful for local storage for single user.
I'm not sure how this relates for example to SQLite. To generate database from model for SQLite you need special T4 template (using correct SQL syntax).
Have you tried SQLite? It has a SQL provider, and as far as I know EF supports any provider. Since it's file-based, that might be a plausible solution. It's also free.
I don't know between ADO, DAO and DLookUps and such. Does anyone know?
I find that the application bottleneck is usually the actual SELECT/INSERT/UPDATE on the DB and not how the application calls it. if you are worrying about speed make sure you have well designed tables and indexes.
Regarding DAO vs ADO, I'm not sure about a difference in performance but there is a difference in available functionality.
There is a microsoft article showing the differences in a nice table. Choosing ADO or DAO.
It also states:
"In particular, ADO is a good choice if you are developing an Access database solution that will later be upgraded to SQL Server — you can write your ADO code to minimize the number of changes that will be required to work against a SQL Server database. In addition, ADO is a good choice for developing new data access components that work with SQL Server, multidimensional data, and Web applications."
Seems like ADO might be the way to go.
I don't know anything about DLookUps though.
Our application uses Hibernate with Sql Server 2005.
Being a DBA, I am not an expert of Hibernate yet. And our developers do not understand Sql Server very well, so I need a middle ground to make sense out of this.
I am looking for some info on how Hibernate works with Sql Server 2005. Any best practices or any issues with the combination or anything like 'lessons learnt'.
I do not have any particular question as such, but in general if there is anything that I need to know to improve the performance overall.
Please let me know if you have links to any such articles.
thanks,
_UB
Some titbits that i learned when i used hibernate :
Dont hard code queries with params. Use named queries. For more info click
here
Make sure you dont append params to query strings to avoid sql injections
You can use stored procedures whenever necessary to update data
(AFAIK, Hibernate doesnt support
nested transactions)
Use the container features to Encrypt passwords needed to connect to
db.
I ll add as and when i come up with certain best practices.
I would like to add to Cshah's statement:
Use caching when it is appropriate... if you are inserting a ton of items into a database that you don't plan on caching, set the Cachable attribute to false before you save.