How do you design and manage the development of a web application that should be compatible with multiple database management system such as Oracle and MS SQL Server?
If you can't use ORM like NHibernate or EF, how do you maintain database schemas during the development?
My approach now is to have a development database on SQL Server and to port it to Oracle (with a tool) just before releasing a test patch, to test the software on both rdbms. (The tool also generates a file used by the application to upgrade the database)
Is it a good approach? What about a database project of Visual Studio, could it be a better way to keep my db schema?
EDIT:
This question is not about designing the architecture of the application (I have already an abstract data access layer), but how to maintain database schemas for different kinds of rdbms during the development.
I think the key to this is to make sure that you stick to standard SQL syntax. MS SQL Server ships with Transact SQL (T-SQL) which is a super-set of ISO standard SQL, meaning that it has extra syntax which is not officially part of standard SQL.
SQLZoo is a good site that allows you to compare the syntax support of different databases. You will find that most of the syntax that you use from day to day will be the same between most DBs, but there are a few quirks out there. The best way to find them is to check each of your queries in each environment and then check them into source control.
Your idea to use a database project is a good one. It will allow you to deploy your changes to multiple databases quickly and test them automatically.
Model-driven architecture (MDA): use a generic Database modelling tool to design your database schema. You define the tables/relationships/primary keys/etc. in a generic fashion and then have the designer generate the necessary SQL script (most support output to a variety of databases). As you change the DB model, the tool will generate the necessary SQL code to update the database, or generate it from scratch. The tools also assist in generating documentation and assisting with database versioning, amongst many other things...
I use Context Database Designer and am exceptionally happy with the tool and price. Enterprise Architect also looks like an excellent tool, with the ability generate and reverse-engineer code.
Realistically the only way to handle this is to decouple your database access from you core application so that you can customize the access code for each database. In other words, exactly what Nhibernate and EF do. If you cannot use one of these tools you will still effective end up writing one any way. Which can be fun and interesting, but will also take up a large amount of time. So I'd be asking some serious questions about why you cannot use an ORM.
Related
I'm developing an application, in part to learn new technologies - in this instance Entity Framework.
I'm using .NET 4.5, Visual Studio 2013. I need some way to store data that doesn't involve running an SQL server on my tired old laptop (not even the lightweight one) and works with Entity Framework. Ideally I would like something that just stores data in a file. I have a few basic requirements:
A simple relational database. Max 10 tables, this is a prototype, so
the tables won't get very big
Ability to design the database in some
sort of GUI tool
Ability to generate Entity Framework database model
from the DB. I don't want to type those in manually.
No proprietary software other than what I'm already using - i.e. I don't own a MS Access license
Something that ACTUALLY
WORKS
I've spent the better part of today trying to get VS2013 to connect me to an SQLite database that I've created. I never got anywhere. SQLite is simply not listed among the available types of data sources. I've read StackOverflow posts about this issue, I'm done trying to make it work. (this is where the frustration you can sense in this post stems from - this is SO not the point of the exercise, yet I've wasted so much time with it)
Is there any other file based database technology I could use?
Your needs are not compatible, the best choice is SQLite but you can not generate model from database and must use EF as CodeFirst .
and your problem with SQLite can easily fixed by using correct provider and configuration : http://www.bricelam.net/2012/10/entity-framework-on-sqlite.html
I suggest you use SQL Server Compact in combination with my free SQL Server Compact Toolbox VS extension:
A simple relational database. Max 10 tables, this is a prototype, so the tables won't get very big
SQL CE supports all standard relational paradigms, and has a max database size of 4 GB
Ability to design the database in some sort of GUI tool
The extension allows you to do this in Visual Studio
Ability to generate Entity Framework database model from the DB. I don't want to type those in manually.
Yes, fully supported
No proprietary software other than what I'm already using - i.e. I don't own a MS Access license
SQL Compact is free and freely distributable
i developed C# application for windows the back end is mysql database but the problem is, if i want to run it in different computer it requires mysql server software or other wise it cant open the data base. is there any way to add plugins to the s C# application or adding open source software to my installation package to run the database file. please note i'm new to C# this is for education purpose sorry for if my questions asking method is not professional.
Front end : visual studio 2013
Back End : Mysql server 2008
I dont know if i got your question right but i assume it a general Data Access Layer strategy question.
If you "bind" your application with mySQL or any other db then that's it.
Depending on the size of the application you could use open source db like SQLite It is a one file db that can be stored with your application.
If you really want to be able to use your software with many underlying DBs then you have alot of job.
THIS question in SO debates that maybe it is not a good idea or at least it is a partially good idea. Partially means that you could abstract basic db behavior to be db independent but you will not get rid off the dependencies 100%
Another good approach would be to use an ORM. Either a micro ORM like dapper or afull ORM like Nhibernate
ORMs let you do just that. You can use an OleDb provider and have access to many underlying sources at a cost of course of not using 100% the native capabilities of the DB....
This is quite a long one, but I'd very much appreciate your thoughts and suggestions.
We are busy rebuilding a legacy system which was written in PHP and MySQL and replacing its components with ASP.MVC in C# and SQL Server. The legacy architecture leaves much to be desired and there is a serious issue with spaghetti code, no referential integrity in the DB, unused code and database fields and just generally bad coding.
As much as I'd love to, we can't just rip out all of the old code and replace it. The company needs to stay functional during the development process, so we will need to build new functionality while using the old databases to ensure that their data is accurate at all times. The level of data accuracy isn't real-time, but if we had 2 systems, they would have to be in sync 100% of the time. The old system uses 6 different MySQL databases, all on the same server, running Linux. We will be running Windows 2008 R2 on the new server for the new system and we are planning to use the latest version of SQL Server.
The problem I'm having to solve is: I need to somehow map all of these databases into a consolidated model that we can use through C# to develop the new system on. Once we have moved all the functionality over to C#, we need to port the data into a DB that matches our code model. This DB will be running on SQL Server. I'm not too worried about the migration just yet; my current issue is finding an ORM tool that will allow me to map these 6 MySQL databases into a single, well planned out and designed model that we can use for the new development.
The new model might have additional fields that we would have to store in a new MySQL database until we port the data across at some stage, so the ORM should support easily building entities that span multiple tables and databases.
Is what I'm trying to do possible? Is it viable in terms of effort? Is there an ORM that can do all of this? and what other way is there to maintain operational capacity of the company whilst developing on the system actively?
I have looked at these ORM options:
SubSonic (great, but I think too lightweight for what we are trying)
Entity Framework (looks like I might be able to use this if I use very dirty models with tons of stored procedures for inserts, updates and deletes)
NHibernate (the client does not want us to use this due to bad experiences in the past)
LLBLGen (seems like it can do what we need it to, but long term support could be a concern with the client)
Anything else I should look at? Is there a different approach I could try?
ORMs aren't designed to solve the problem you have. That said, a quality ORM will get you some percentage of the way toward a solution.
NHibernate is the easy choice. LLBLGen would be my second choice. I wouldn't even bother with EF or SubSonic as they are very feature poor compared to the other two and you need decent feature support in your scenario.
You'll likely have to invest a lot of time in writing custom code around your migration requirements. Your use case is not a standard, well traveled path.
For Entity Framework: if you're prepared to maintain one complete set of stored procedures with a static interface (i.e. same signature) you could implement them all in Transact-SQL on the SQL Server box, with linked servers (to the MySQL farm).
When the time comes, you could migrate the data into SQL Server and update your stored procedures.
Basically, design a nice model with nice stored procedures, and as a temporary solution implement any ugliness inside the stored procedures. Once MySQL is out of the way, you can replace the stored procedures with better ones.
SQL Server has a tendency to retrieve the entire remote table when you're running queries against a linked server, so if performance is a concern it might eventuate that all your stored procedures are wrappers around OPENROWSET (see Example A for running a query on a remote server).
I am, a beginner to databases, and am very inexperienced at programming generally. For a C# console app (I'm writing with VS Express), which after testing will have a UI added, I need to use a database to store its data.
Can someone tell me, or point me to, bare beginner's explanations, and pros and cons, of these database access methods so I can decide which I should use?:
SQLClient
ORM
OleDB
ODBC
ADO.NET
nHibernate
MS Enterprise Library
Quite the mix there ... first some explanations ...
1) SQL Client
An SQL client is an application that connects to a SQL Database for the purpose of querying / managing / working with the data in an SQL Database. (any program accessing a database, phpAdmin, SQLite Administrator, etc...).
2) ORM is object-relational mapping. Its a way to convert different types of data when data types are incompatible. Think about a car class that incorporates four instances of a tire class. This type of structure doesn't translate well directly to the types available in database design and may be a reason to use ORM. (To relate the objects (car, tires, etc..) into the plain database types (integer, float, blob, etc..)
3) OLE (pronounced Olay) DB Is the Microsoft method (API) for connecting to Database using COM. OLE DB is part of the MDAC Stack (grouping of MS technologies working together in a framework for data access).
4) ODBC is Open Database Connectivity and its an alternate API for for Database Management Systems (DBMS). Where OLE DB is a COM (Component Object Model) way to integrate with databases, ODBC aim's to be language independent.
5) ADO.NET is a set of base classes (API) for use in the .NET languages to connect to and communicate with Databases.
I would suggest starting with ADO.net for your C# background, OLE is typically for older (VB classic) applications, There is a good beginner tutorial here http://www.csharp-station.com/Tutorials/AdoDotNet/Lesson01.aspx
Don't let all the terminology scare you off, once you jump in and start tinkering you will understand all of the answeres provided better...
Best of Luck in your coding!! :-)
SQLClient, OleDB, ODBC are the DBMS Drivers/ADO.NET implementations of different DMBSs (err, hope that makes sense). For example, SQLClient is the ADO.NET implementation for connecting to a SQL Server database. The choice between these drivers is just which database you want to use. For a beginner, I would suggest SQL Server as you probably already have some version of that installed.
ORM is Object-Relational-Mapping. This is a code-based implementation of an auto-mapping between your code-based models, and your database that stores it. If you don't want to manually touch the database for the time being as you are learning, this is a good option - it is something useful for pros and beginners alike, as it allows you to not worry about the underlying database implementation, or writing CRUD (create, read, update, delete) functionality yourself. Take a look at ActiveRecord for .net (http://www.castleproject.org/activerecord/index.html)
If you are looking for an easy introduction to databases in C# you want to use LINQ and a data context.
Simply add a "Data Context" to your project. Double click the file to open the designer for the LINQ data context. Open the "Server Explorer" in visual studio (under View) and connect to your SQL Server. Using that you can drag and drop your tables onto the LINQ designer in visual studio.
Jump on google and have a look at using linq with a context to do work on your DB.
I'll jump in here with LINQ to say that it encourages you to write better database code, that doesn't pull the whole dataset out in one go and operate on it, you defer queries and you can benefit greatly from the functional infrastructure they've built upon it.
But this has a big learning curve, best way to do it is to try different kinds of code and see the ones that make sense to you.
I have a simple app written using SQL Server, Entity Framework, C# and WCF. When I wanted to share this app with my friends, I realised they didn't use SQL Server on their machine. I could go for SQL Server Express edition, as the usage of my app is personal and non-commercial.
I found MySQL as a popular alternative to SQL Server.
1) Would I be required to update my entities when moving to MySQL?
2) Should I anticipate code changes in my BL layer due to change in entities layer? (I am wondering whether entities was built for SQL Server)
Are there any databases similar to MS Access that is lightweight compared to MySQL?
Are there any databases that need not be installed but can be copied around like MS Access?
Appreciate your response!
Sounds like you want SQLite.
SQLite is a software library that
implements a self-contained,
serverless, zero-configuration,
transactional SQL database engine.
Very easy to deploy. Also, check out System.Data.SQLite.
According to the System.Data.SQLite page ...
Supports nearly all the entity
framework functionality that Sql
Server supports, and passes 99% of the
tests in MS's EFQuerySamples demo
application.
You should be good. :)
Im not sure how your BLL looks like and i have no experience with entity framework, but ive experienced multiple times that linq-to-sql works much better with sql-server as with any other database.
So unless you have a good reason not to use sql express, i'd advice to stick to sql express.
After all, you should always install something when deploying (unless you use xml as storage, which is quite well possible with linq-to-xml).
VistaDB Express Edition is also free for non-commercial usage and integrates good into .NET and VS. afaik it also works on a single local data file thus requires no specific installation on your friends' computers.
Otherwise I recommend using PostgreSQL over MySql since it is more standards compliant and has a nicer license.
I think what you're after is just a change in providers. What you need to use MySQL is the .Net Connector which supports most everything simple. It's not very mature yet so something very complex you may have issues on, but it should do most of what you want through Entity Framework.
With Entity Framework yes you can do updates, it's LINQ-to-SQL that doesn't update against any other databases (unless you use a third party provider like DotConnect)
SQLite is one alternative, but since multiple threads against it can cause major issues with it's operation, so if you need a major data store I'd go SQLExpress or MySQL.
Yes, you could use MySql with EF but I don't know if it would require changes.... I wouldn't be surprised if it does though. At the very least your physical DB would have to be ported / converted to MySql and that will take time.
I would assume that if you need to install a DB on your friends Pc's why not stick with SQL Express since you already developed in SQL Server on your box. Should be less issues with this than migrating to MySql.
I'd also vote for VistaDB 3 as it's so easy to deploy.