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.
Related
In HTML+CSS+JS world, http://jsfiddle.net/ is very helpful tool for asking / making example about web development. And I also saw several browser(javascript)-based programming language compilers and REPLs. But I can't find online / web-based test environment for database operations( especially for RDBMS ).
Is there any open/free database service with web-based interfaces for testing queries?
Added: This tool will be good for this situation; If I'm troubling with complex queries, then create a sample table via web interface and ask it on stackoverflow with the 'sample table URL'. Anyone can access to the URL and test their queries on web site. (Yes, queries are running on 'real' database system) And also the query results can be tracked, then we can even make 'ranking' for it :)
Try SQL Fiddle.
You can try your SQL query and execute/test it.
There are free "disposable" database servers like db4free and even MonoQL.
As far as the web-based interfaces and short URLs go, I don't think you'll have much luck.
To manage your data you have to stick to what is provided (usually phpMyAdmin or similar) and there is no short-URL to query mapping. One other caveat of such system is that (without the appropriate user permissions) one user could easily destroy all your test data -- and remember that (relational) database versioning is much more expensive than plain text versioning, so that's pretty much out of the question.
For non-RDBMS, I can think of try.mongodb.org -- but it suffers from the same problems.
Almost forgot, the Stack Exchange Data Explorer, lets you practice T-SQL queries (with permalinks).
PS: As a personal side-note, I think it's a cool idea and I would love to see something like that implemented, perhaps even mashed-up with SchemaBank or similar - that would be just awesome.
You can't really test a query without the right underlying dbms, schemas (or databases), tables, constraints, stored procedures, and permissions, which tend to be highly application specific. (That is, not readily reusable among multiple users.)
Instead, the database world has grown up into database management systems that you can freely download and install locally. Then you can build and populate your own tables, and test your queries however you like.
Most of these come with both a command line interface and some kind of graphical interface. It's not clear to me what a web-based interface would give you that doesn't already exist in one form or another.
I think that, to do what you want, would require commercial licenses for Oracle, DB2, SQL Server, and Sybase. That's a pretty high barrier to entry for a free web site.
Trouble with a web based query analyser is that you'd need to let it 'tunnel' on to your box to run the queries and for many making a development/test box open to the internet is not a possibility.
For a non web based tool you could look at LinqPad http://www.linqpad.net/ - it does Linq & Sql and other stuff too - very handy tool indeed
We're currently using VincentVega (now rolled into Tarantino) for our database CI. We're using CruiseControl.Net for our web app (C# using TFS).
VincentVega has worked out relatively well since it's very explicity and handles the two scenarios of create and update (while preserving existing data) equally well. I'm looking into upgrading to Tarantino, but I'd like to know if anyone might suggest some alternatives I should look into? Tools like SQL Compare that "automagically" produce delta scripts are out of the question, unfortunately, since our database is highly normalized with over 500 tables.
Thanks
Eric Tarasoff
There is also another project which may be worth looking at by Rob Reynolds; RoundHousE
http://code.google.com/p/roundhouse/
The wiki is at https://github.com/chucknorris/roundhouse/wiki
There's a similar tool by Paul Stovell and friends called DbUp.
One notable difference between Tarantino and DbUp is that while Tarantino is typically called from a build script (like Nant or msbuild), DbUp has .NET classes you use within your application. This potentially allows for better fallback handling in case a script doesn't go as planned.
http://code.google.com/p/dbup/
Here's the original announcement of DbUp from Paul Stovell's blog:
http://www.paulstovell.com/dbup
I think it might be of interest to post another answer since Redgate now has a new offering, ReadyRoll, that satisfies your key concerns.
"it [SQL Compare] just doesn't put together a synch script correctly"
Yes, diffing tools can sometimes get the script wrong. Often it's not that the script doesn't work, but it doesn't apply the change in the desired way. ReadyRoll's best-of-both-worlds approach uses SQL Compare under the hood to create each migration script, but crucially it allows the developer to customize the script afterwards.
"RoundHousE and tools like it already operate in a model similar to what we're doing now"
ReadyRoll's approach is, like RoundHousE, migrations-based, managing the upgrade process by running a series of consecutive scripts. This tool was built in recognition that many development teams prefer working this way.
"One last reason for choosing RoundHousE: Chuck Norris"
I will have to concede defeat on this point...
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 am creating a quick and dirty prototype (C#) of an object-relational mapping tool. I would like to support at least two kinds of databases - one will be Microsoft SQL Server 2005/2008 and the other most probably MySQL.
Is there any way to use a single data base access mechanism for both database engines and what would it be?
Of course, I know that there will be differences in SQL query syntax, but in my case it is not that important - I'll use a tool to generate SQL queries which suit the certain db engine and user will be able to optimize those SQL queries.
The main idea is to have as flexible data provider solution as possible. Can it be done or not and how can it be done easier?
Note that I am not using this for a production system, just for a prototype, but still I'm curious how it is achieved in production OR/M tools - are they using completely separate access mechanism for each data provider or there are something common? And are they using DataReaders or there is some more appropriate way to retrieve data if I intend to transform data to business objects?
Thanks for any ideas, links etc.
Ok, I found it:
http://www.15seconds.com/issue/040127.htm
the solution is to use IDbxxx or Dbxxx as described in msdn.microsoft.com/en-us/library/ms379620(VS.80).aspx
Now I can specify only once what kind of DataProvider I use and then just use Db/IDb everywhere else.
I recommend nhibernate - which does what you want I think.
nhibernate.info
Should I use a hand-written schema for my projected developed in a high-level language (such as Python, Ruby) or should I let my ORM solution auto-generate it?
Eventually I will need to migrate without destroying all the data. It's okay to be tied to a specific RDBMS but it would be nice if features such as constraints and procedures could be supported somehow.
I never go with ORM-generated schema.
I find that the ways in which the ORM wants to generate the schema are often at total odds with how I want my database to be structured. Also, and I know this is trivial, the nomenclature scheme is usually poor.
Database structure has its own constraints, that I find that usually the ORM autogeneration tools don't consider fully. And if you're going to be wanting to run reports on your database later (and you will), then having good database structure and design is very important.
See this Coding Horror article and links for discussion on that migration you'll eventually need to do. Plan for it now.
Also see Martin Fowler on database evolution; I particularly recommend the notion that test data generation is part of database set-up. The idea may be a little underdeveloped, in that there is not a clear delineation of the different problems in different environments, development versus QA versus production.
Let the ORM generate the schema it wants. Then you can always change things that are too slow or that you want differently. But it allows you to quickly get started and have something working plus the ORM people usually know what they do when it comes to generating schemas.
Let your ORM solution generate it, but don't just blindly use it; read through it and sanity-check it.