Is there anyway that I could generate database from one schema to another?
For example, I would like to run my application from oracle to sql server or from sql server to postgresql?
I'm looking for something that's free....
Also I would like to know if there's a schema initializer to go with it
thanks a lot
The best tool I found so far is to use Squirrel's DBCOPY plugin. It really does the job
This doesn't really fall under the "free" category, but if you already have the tools (Microsoft Visual Studio and appropriate .NET providers), it might be a possibility.
The idea is to generate a data model from one database in Visual Studio and then use the Model First functionality to go from the conceptual model to another database. The steps would be something like this:
In a VS2010 application, add a new item to the project: ADO.NET Entity Data Model
Choose your existing database the source for this new model and select the desired tables and click through the wizard.
After the model is created, make sure the conceptual model is visible (.edmx file). In the properties for the model, there should be a DDL Generation Template option. Change this to the desired target type. This is the really iffy part; I don't know how many providers support this, but a quick search seemed to turn up at least one for Postgres.
Right click on the model and choose Generate Database from Model. This should produce the DDL for the new database.
This certainly would not lend itself well to an automated process, but for a one-time process, it might be okay.
Related
I'm just starting to use Entity Framework Designer. I would like to ask how should I create my Entity files. I would like to have like 10 tables and all of them will be linked to at least one other table by some row. Should I create just one file and put all my models there or create a separate file for each model.
I don't know if this is even a question but I could find my answer on Google. I didn't know how to define it actually... :D
So if you have any tips on how I should model my database that will be awesome. Also if you have any more information on when I should use different Entity files that will be useful too.
I have used MySQL designer in the past but in there as far as i can remember you just move the model into the designer and you can make relations. So I'm kinda keen into doing that (all models in one Entity File) but wanted to check with you first guys.
just try this plugin for VS http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d to generate your classes from existing db
I've been thinking of ways to improve managing changes to our database structure. I have a build server that creates nightly builds, so I was thinking we could somehow create database dumps, backups, and scripts from the test environment as part of the build process. Then when deploying an update to the client we could use a tool like DBDiff to create the database update script.
Is anybody doing something similar? Is it even a good idea? Maybe some good tips what to use to create these dumps on build server?
Rather than identifying the differences, I recommend to keep a proper script that creates a database from scratch.
We are quite satisfied with using Liquibase to manage all DB migration in our projects. It knows which "patches" have been applied and ensures that only those that are missing will be applied to the target database.
this is possible.
the differencing is the hard part. once you identify the differences, you need to construct the appropriate sql, then apply it. you can either apply it directly, or create some script that you can run after review.
when both sides change, then you need to decide if the target system should keep its change or if that should be completely removed.
remember that when the target system changes also include data, and if you remove some table or column, then your referential integrity might be completely ruined.
one more thought. you will need access to the target system in order to determine the diff. if this is a generic utility, you will need to make it an executable after the fact, not part of the build.
You will find the Visual Database Tools very useful here.
http://msdn.microsoft.com/en-us/library/y5a4ezk9.aspx
There is a schema compare built right into Visual Studio (it can also be run from the command line). There is also a database project that contains a complete set of scripts for the database and the objects that it contains. This can be checked into source control along with your source code.
You can deploy a new database based on these scripts with a context menu click.
Have a look at http://www.codeproject.com/KB/architecture/Database_CI.aspx and http://www.martinfowler.com/articles/evodb.html - there's a fair amount of thinking that's already available.
We are currently looking at the Juneau CTP release, SQL Tools for Visual Studio. It has a snapshot and schema comparison feature. Basically, it can auto-generate scripts between two schemas for you. If you use this against two versions of your database, it will give you an upgrade script.
http://msdn.microsoft.com/en-us/data/gg427686
Here at Red Gate we're close to releasing a solution which solves that precise issue using SQL Source Control and SQL Compare. We have an early access program which will allow you to try this out. Please visit the following link for sign-up details.
http://www.red-gate.com/MessageBoard/viewtopic.php?p=46951#46951
When using the Entity Framework there are basically two ways to create your model. You either create the model in SQL server or in Visual Studio EF designer. Those are outlined below.
Start with Database
You first create the model in your SQL server DB then point EF to create the .edmx file for you. By using this approach you can use SQL server management studio to create all of your models and relationships.
Start with Visual Studio EF Designer
This approach is to create the model first in Visual Studio and from that create your database. By doing this it seems like you don't have to be soo concerned with tables and relationships.
Here is what I do and why I do it that way
I start by creating my model using SQL server management studio. I do this because I think its easier to create and modify tables using that tool, also I know exactly what is being created. I create my EF model by pointing it to my existing database. After that I create a Visual Studio Database Project so that my database is scripted into files which I put into version control. When I need to make changes, I change the database and then update my .edmx file as well as my database project.
I was wondering what are the pros and cons to these different approaches and what should be the criteria to decide which to use? Am I doing it wrong? Should I be creating my model first in Visual Studio?
I don't think that there's a 'right' or 'wrong' way to do this, a lot depends on how you deploy your code, where it goes to etc. There is also a third way, which Scott Guthrie blogged about recently:
http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx
As a side note, even if you start with the model designer, I think you always have to think about your tables/relationships, as getting these wrong in the database can cause you big problems further down the line.
I don't think there is a right or wrong way.
At our company we are developing the database changes directly first, apply them to the edmx model for existing models.
For new models, we create the edmx model first, then generate the database. From that point on we usually update the database directly. After we have tested our code internally and it runs correctly, and we know that our SQL database is correct (and of course prior to checking in), we'll then apply the changes to the database project by doing a SQL compare on the database to the database project.
This has worked very well for us.
Up until now, my experience with databases has always been working with an intermediate definition layer that we have where I work. i.e. SQL wasn't directly written for the table definitions, but generated from an intermediate file which wrote out SQL scripts for creating the appropriate tables, upgrade scripts between schema changes, and helper functions for doing simple queries/updates/inserts/deletes from the database.
Now I'm in a situation where I don't have access to that, for reasons I won't get into, and I find myself somewhat lost at sea regarding what to do. I need to have a small number of tables in a database, and I'm unsure what's usually done to manage the table definitions.
Do people normally just use the SQL script that does the table creation as their definition, or does everyone just use an IDE that manages the definition in a separate file and regenerates the SQL script to create the tables?
I'd really prefer not to have to introduce a dependence on a specific IDE, because as we all know, developers are whiners that are prone to religious debates over small things.
Open your favorite text editor -> Start writing CREATE scripts -> Save -> Put in Source Control
That script now becomes the basis for you database. Anytime there are schema changes, they get put back into the scripts so that they don't get lost.
These become your definition.
I find it more reliable than depending on any specific IDE/Platform generating those scripts for you.
We write the scripts ourselves and store them in source control like any other code. Then the scripts that are appropriate for a particular version are all groupd together and promoted to prod together. Make sure to use alter table when changing existing tables becasue you don't want to drop and recreate them if they have data! I use a drop and recireate for all other objects though. If you need to add records to a particular table (usually a lookup of sometype) we do that in scripts as well. Then that too gets promoted with the rest of the version code.
For me, putting the scripts in source control however they are generated is the key step. This is how you know what you have changed for the next release. This is how you can see earlier versions and revert back easily if there is a problem. Treat database code the same wayyou treat all other code.
YOu could use one of the data modelling tools that creates scripts for you if you are starting out on a database design and the eventually want to create it for you. Some tools for that are Erwin, Fabforce etc... (though not free)
If you have access to an IDE like SQL Management studio, you can create them by using an GUI thats pretty simple.
If you are writing your own code, Its always better to write your own scripts based on a good template so that you cover all the properties of the definition of the table like the file_group, Collation & stuff. Hope this helps
Once you do create a base copy generate scripts and have a base reference copy of it so that you could do "incremental" changes on them and manage them in a source control.
Though I use TOAD for Oracle, I always write the scripts to create my database objects by hand. It gives you (and your DBA's) more control and knowledge of what's being created and how.
If your schema is too difficult to describe in SQL, you probably have other issues more pressing than which IDE. Use modelling documentation if you need a graphical representation, but yeah, you don't need an IDE.
There are multiple ways out there for what you are asking.
Old traditional way is to have a script file ready with your application that has CREATE TABLE statement.
If you are a developer, and that too a Java enterprise developer, you could generate complete schema using a persistence library called Hibernate. Here is a how to
If you are a DBA level user, you could take schema export from one environment and import that in to your current environment. This is a standard practice among DBAs. But it requires admin access as you can see. Also, the methods are dependent on the database you are using (oracle, db2 etc)
How do you create a database from an Entity Data Model.
So I created a database using the EDM Designer in VisualStudio 2008, and now I want to generate the SQL Server Schema to create storage in SQL Server.
From what I understand you are not just supposed to use EDM as a "pretty" database designer, in fact EDM does not depend on a specific storage layer. It tries to abstract that part for the developer. There are design schemas (CSDL) and storage schemas (SSDL). Anyway, don't mean to lecture you. ;)
There is EDM Generator, which you use to create models and class, etc.. For a DDL kind of export, I've never done that but what I did was map my EDM to an existing database, which was easier for me to get started.
There is a great tutorial on MSDN, which details step by step instructions on how to go about using an existing database, but also touches the how to start from scratch approach.
http://msdn.microsoft.com/en-us/magazine/cc163286.aspx
The Feature "Generate Database Schema from Model" is scheduled for a future release of Entity Framework. V1 does'nt support schema generatiorn based on EF models.
I believe the other answers implied this, but just to be explicit - use SSMS (or whatever equivlent if you're a brave sole and not using SQL Server provider) to design the DB layout and then suck that into EDM - and then apply application changes as necessary to the model.
I spent about an hour trying to do it your way first (leftover habit from some other Java ORM tools) - I eventually gave up and now do it the 'Right Way' (tm)
Eventually it would be nice (as JRoppert indicated) to have the generate databse schema from model feature - then you could get your DDLs for various DB flavours automagically.
Generating databases from model is a feature planned for vNext of Entity Framework.
Check out this blog post of Entity Framework Design explaining the planned features for database generation from a model.
What you must do right now is either 1) generate the database by hand, or 2) parse the CSDL file and write your own generator. I think option 1) is probably a better option.
Avilable in EF 4:
http://blogs.msdn.com/b/efdesign/archive/2008/09/10/model-first.aspx