Is there a cross platform solution for sql? My prototype was in sqlite. I am switching to a server that offers tsql and i was considering mysql in the past for my webservers(maybe i should stick to tsql and sqlite). I am wondering if theres a .NET lib that allows me to write sql compatible with all.
Some annoyance i had was in create table. I thought primary keys auto increased but they dont. I have to write identity(1,1). When i ported my sqlite code to mysql i had issues also with create table but i am sure there will be other places once my sql statements get more complex. So i thought trying a lib may be a good idea.
I personally use SubSonic as an ORM. It supports both SQL-Server and MySQL, as well as SQLite. Database creation is always a tricky question, but you generally don't perform it often. I have chosen SQLite, as it is very portable, and should also be available when I port code using Mono. TSQL (SQL-Server) is a windows-only product, and is not portable. My databases also won't be very large (< 100 Mb) and this may also need to figure in your choice.
I would recommend (for the moment, until VS 2010 is out) that you don't use Entity Framework, as it is a traditional v1.0 MS product, and very problematic. Essential features are not present, and artificial restrictions make it less useful than other ORMs. No doubt the next version will be better, but the current version is not worth your time compared to something like SubSonic.
An ORM like NHibernate or Entity Framework will support all those sql backends, and more. It will also save you from writing all your SQL queries yourself.
You might want to take a look at ADO.NET Entity Framework. It supports a lot of different backends.
Related
Imagine an application which is supposed to work with different database vendors. As we all know the syntax for SQLs (especially DDL) is not portable. How do you deal with maintaing the SQL scripts?
Until now I see three options:
to store SQLs in format of one of the databases and have a tool which automatically converts from one syntax do another (do you know such tools?)
to store SQLs in some artificial language and a have a tool which is able to generate vendor-specific SQLs on demand (any recommendation here?)
to store SQLs in many database formats neglecting the redundancy (this is the worst one, isn't it?)
Do you recommend any of them? Do you have a better idea?
The development environment tries to follow the continuous integration principles, so automation is a key feature here.
Have a look at Liquibase (that's essentially your second item on the list)
http://www.liquibase.org
It's not perfect (e.g. it does not support check constraints) but it is quite useful
This video shows a solution using the Subsonic project http://subsonicproject.com/docs/Using_SimpleRepository and its data migration capabilities. The strategy is to use a general language and apply it to different databases.
Hope this is what you were looking for
Use some kind of ORM framework with schema generation capability.
The dev tools for SQL in Visual Studio are great.
Is it possible to develop an app for Microsoft SQL Server, and then deploy a MySQL-compatible database instead?
The dev tools for Microsoft SQL Server are really nice (i.e. LINQ support), but a MySQL-compatible column database has better performance for huge datasets.
You would need to use MySql .net connector
http://dev.mysql.com/doc/refman/5.1/en/connector-net.html
With this, you get some of the functionality that you have with SQL server (entity framework, designer, etc) there are still a bunch of things that are not supported, but it's a good start
It's possible, but a number of specifics might tend to prevent a full implementation on SQL Server, particularly with respect to stored procedures.
However, if the intent is to build a scaffolding on VisStudio and finish the development using the MySQL tools, it would work okay. You'll have to learn both SQLs quite thoroughly. The sooner you do that, the less grief there will be in the conversion.
One method for doing this would be to abstract away the database itself. That be done at least a couple of ways; the first way, you could use classes to build the SQL that your application requires, and then just use that; then all that has to happen is that it has to know how to generate the right SQL for the right server. One of the drawbacks of doing it that way, though, is that if you depend on functionality that exists on only one DBMS, you'll have to emulate it in that abstraction layer.
The other method that you could use is to create two versions of your classes that talk to the RDBMS, one for MySQL and one for Microsoft's SQL Server. Use an interface and derive from it in order to do the actual implementation. Of course, you'll want to make sure that the only responsibility of the class is to interact with the database, so if you're doing this for business layer objects, you'll be implementing those sorts of things with two classes: a low-level one for the database API, and a high-level one for actually providing the API that your application is going to consume.
Perhaps not a direct answer to your question, but the dblinq project may be of use to you.
It may be worth a look just to see the MySQL implementations within the project in order to determine what the real differences between SQL Server and MySQL are going to be and how they're going to affect you. The more you can abstract out those differences behind a dependency implementation, the easier it'll be to swap out one implementation for another.
You can write your code for SQL Server and then switch to Devart LinqConnect.
For example, you can create a LINQ to SQL model using Entity Developer (in VS integration mode or in standalone mode), then change the connection to the MySQL-specific one and run Update Database from Model wizard (don't forget to select the Regenerate Storage check box).
As a result, you will obtain a MySQL database, having structure identical to the SQL Server one.
I have an object model that I want to store using an embedded database. I have so far been looking at db4o, NHibernate to SQLCE (w/ linq), and RavenDB. This would be used in a desktop C# application.
The key features I am looking to leverage are: Linq or similar for queries (no SQL or HQL), Embedded data engine, pocos, poco first model, no install (no registry or similar)
Can any one suggest one? Are the three I am looking at the best choices? Are there other options? Of the three, can anyone recommend one over the other?
Thanks
Well the three suggested databases are very different in their nature. SQLCE with Hibernate as RDBMS with a ORM, db4o as object database and RavenDB as document database. Each of them has its strengths.
SQL CE & NHibernate-Combo
The good:
Extremely good support in tooling, the knowledge and a big community is there
Easy to upgrage to MS SQL servers
Extrem good reporting support
The power of SQL
The bad:
Needs mapping
The mapping between the OO and relational world is not easy and can lead to issues with complex models.
RavenDB
The good:
Doesn't need any mapping
Easy to use
Powerful indexing
JSON & HTTP access
The bad:
If your domain doesn't fit to a document-oriented approach, it will be quite painful
It does not support the .NET Framework Client Profile (which is of particular importance as the OP's question is concerning embedded databases)
db4o
The good:
Doesn't need any mapping
Easy to use
The storage model is close the object-model. This also works for very complex models.
-
The bad:
Tooling support is weak.
Afaik all three support LINQ and POCO-first approach. However since NHibernate & SQL CE still need tons of mapping its not as friction free as it could be.
I think if your focus is on POCO first, LINQ-support, ebedded usage and easy to use, I would try RaveDB or db4o.
If your focus is on 'safety', community-knowledge, tool-support and reporting I would go with NHibernate and SQL CE.
Firebird is a terrific embedded database which has long supported all the modern features of an enterprise database:
ANSI SQL
ACID
Stored procedures
Triggers
You can get the .NET provider (last updated May 24th according to the site) and it supports Entity Framework and Linq.
See this question. For LINQ support, check out DbLinq, or since you already intend to use NHibernate you can use NHibernate's own LINQ provider.
A client wants a database converting from MS SQL to MySql.
Personally I wouldn't do this, I prefer MS SQL for larger databases and like the tools available when working with MSSQL.
However I do use MySql on smaller projects. I've never moved a database from one to the other, or made much use of sprocs when using mysql.
Is there a lot of work involved in rewriting the sprocs, considering I have no prior knowledge of the ms sql database itself, so will need to first gain an understanding of what each sproc does.
This isn't a discussion on which to use as that's already been decided by the client for a few reasons.
have you seen this?
I haven't done this before, but I can only assure you mysql is good for big projects, too.
Does anyone know if it's good solution to use SQLite in multi-thread environment.
I want to replace SQL Server with more simple and built-in database as there is no need to feed such big server DB. The supposed max size of DB would be 4 gigabyte after 4-5 years of usage. Is it normal for built-in DB? Could it affect performance?
It depends on the type of queries you would use. If the queries are simple selects with plain joins, then SQLite could do fine but I think you would still be better off with e. g. Firebird 2.5 when the stable release gets out (RC3 is available now). You would have somewhat richer SQL to work with. I don't know how much bulk loads are important for you, but neither SQLite nor Firebird are very strong in this area. If you need good bulk insert performance and low cost, then you should look at PostgreSQL or MySQL. There is also a very interesting looking database I happened to stumble upon recently called CUBRID. I have only installed it so far, so I can't tell how good or bad it is but it certainly seems worth a look.
You might also want to look at this wikipedia article:
http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
I don't know which distro you're talking about here. I've only used SQLite.NET and I know it works well on multithreaded applications.
It can also be deployed on client-server systems so you need not worry at all.
Considering Vinko's statement of 'real' databases, you can ignore him. SQLite is really worth it's salt.
If you're working with .NET, you might find this link useful:
http://sqlite.phxsoftware.com
According to the documentation SQLite is thread safe but there are caveats.
You can use SQLite in a multithreaded environment, but if and only if you build a special version of it (and find out if the library you'll be using it supports it and tweak it if it doesn't.) So, assuming your library supports multithreaded SQLite, if you really need a high level of concurrency to the database you may prefer to use a 'real' database. Be it MSSQL or any other falls out of the scope of the question.
Consider MySQL and SQL Server Express, for example.
If your concurrency level is low, SQLite can cope with it.
I would also suggest you to take a look at the CUBRID database. It has nice optimizations for Web applications and it is easy to learn.