I'm developing an asp.net application with Database factory pattern which allows the application to support both Sql Server and Oracle. I've created an abstract class that has the methods common to Sql Server and Oracle, like the CreateConnection and CreateCommand methods. This class is implemented by SqlServer and Oracle classes. Now, is there an easy way to write in-line sql queries with parameters common to both Sql Server and Oracle. I mean, I understand that we use "#" symbol in Sql Server and ":" in Oracle for parameters. Just for this reason, I'm writing queries twice in each of the class. Is there a way to write such queries common to both the databases? (or interpret the parameters from one common query?)
Thanks.
The only way to write one query that will work for both Oracle and Sql Server is to use only the syntax that is common to both platforms. Once you use features that are different between the two languages (like parameters or joins), you either have to write two different queries or hack together a "translator" class that converts a query from one platform to the other.
I've done a lot of this type of programming (database-agnostic software), and with .Net a relatively pain-free way of doing this is to write your main application to work entirely with ADO.Net DataTables/DataSets, with a wrapper class that handles generating the DataTables from either Oracle or Sql Server tables under-the-hood, and also handles persisting changes made to the DataTables back into Oracle or Sql Server. This approach isolates your DB-specific code in one place, although it's not necessarily a viable approach if the data your application needs access to is large.
You could write some kind of translator, but I would suggest that in some cases you'll need to write db-specific code for performance reasons anyway, so you'll have to put up with the maintenance burden of two versions of some queries.
What is the point of using ORACLE and not using all its non standard functions (analytics, pivots etc) ? ORACLE is a powerful tool.
Other DBs have there own strenght also, so why use the lowest common denominator just to be able to work on ALL of them? You will just lose in performance.
Just pick one DB, and use it fully with all its functionalities !
Pardon my ignorance here, but can't something like an ORM (object relational mapper) work for both SQL and Oracle?
I had similar requirements, to support both Sql Server and Oracle, and summarized my two years of experience with such problems in these articles:
Writing ANSI Standard SQL is not practical.
Think ANSI Standard SQL Is Fully Portable Between Databases? Think Again.
Related
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'm wondering for those enterprise programs, how do they link to various type of database just by stating the connection string?
Issues like different syntax, variable type will definitely be there.
Apart from stored procedures for each type of database, how else do they handle in terms of their programming?
1 way that came to my mind is just if else checking of database in order to populate different query.
Asking as I'm curious while using a engine which is built in C++ and jsp, but could support SQL Server, Access, MySQL, Oracle
ORMs tackle this problem by introducing a level of abstraction between the database and the domain model. For example with Hibernate you change the connection string and the dialect and HQL queries and Criteria APIs are automatically translated into the proper SQL for the target database.
Of course this assumes you never write a single line of SQL in your application or anything which is specific to the database.
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 client wants to support both SQL Server and Oracle in the next project. Our experience comes from .NET/SQL Server platform. We will hire an Oracle developer, but our concern is with the DataAccess code. Will NHibernate make the DB Engine transparent for us? I don't think so, but i would like to hear from developers who have faced similar situations.
I know this question is a little vague, because i don't have Oracle experience, so i don't know what issues we will find.
You can easily use NHibernate to make your application database-agnostic by following some basic practices:
Design your object model first.
Do not use any database-specific code. You need somebody with good C# experience, not an Oracle developer. Do not rely on stuff like triggers, stored procedures, etc.
Let NHibernate generate the DB schemas at least initially (you can tweak things like indexes later) It will choose the best available datatypes for each DB.
Use a DB-agnostic POID generator (hilo or guid) instead of sequences or identity.
Try to avoid using SQL. HQL and Linq work fine in 99% of the cases.
Avoid NH features that are not supported by all of your target DB (for example, Future, MultiCriteria, etc)
NHibernate has a great community. You can always ask your questions in http://groups.google.com/group/nhusers besides posting here.
There are three things to consider - the ISession object, the SQL queries that are generated and your plain-old-clr-objects that are mapped to tables.
NHiberante will generate the required SQL queries based upon the chosen database dialect. If you configure NHibernate to use the SQL Server dialect it will generate SQL server correct SQL statements. This can easily be configured dynamically at runtime based on configuration.
You also need to configure your session to connect to the right type of database. Again, various configuration methods can support dynamic ISession creation at runtime.
Your actual data objects which are mapped to tables should not need to change based on database choice. One of NHibernates strengths is flexibility it provides in supporting multiple databases via a (fairly) simply configuration change and some up-front architectural thought.
See http://codebetter.com/blogs/karlseguin/archive/2009/03/30/using-nhibernate-with-multiple-databases.aspx for some examples of how you might abstract the underlying database away from the creation and usage of NHibernate.
What are the reasons behind Microsoft implementing its own SQL extension as Transact SQL (T-SQL)? What are its advantages over the normal SQL?
Everybody extends SQL.
SQL isn't procedural, it's declarative. You describe what you want, and it figures out how to retrieve it using whatever indexes or hashes or whatnot is available.
But sometimes, that's not sufficient. T-SQL gives syntax to run procedural code inside of your queries. This lets you do control structures (begin-end, if-then-else), iteration and move values between local variables, temporary tables and other sources.
Transact-SQL (T-SQL) is Microsoft's and Sybase's proprietary extension to SQL. Microsoft's implementation ships in the Microsoft SQL Server product. Sybase uses the language in its Adaptive Server Enterprise, the successor to Sybase SQL Server.
Transact-SQL enhances SQL with these additional features:
Control-of-flow language
Local variables
Various support functions for string processing, date processing, mathematics, etc.
Improvements[citation needed] to DELETE and UPDATE statements
http://en.wikipedia.org/wiki/Transact-SQL
Wiki connects you to much more expanding information and details.
What are the reasons behind Microsoft implementing its own SQL extension as Transact SQL (T-SQL)?
To make your life easier.
What are its advantages over the normal SQL?
There is no such thing as "normal SQL"
Transact-SQL both enhances the set-based abilities of SQL and adds procedural abilities.
Other systems (like Oracle and PostgreSQL) clearly distinguish between SQL and procedural languages (PL/SQL and pl/PgSQL).
Microsoft doesn't make such a strict distinction.
Transact-SQL was developed by Sybase around the middle of 80's, when there was no standard at all (the first one was proposed in 1986).
By that time each vendor already had a burden of legacy applications to support, and rewriting their databases to conform to the standard would break the compatibility.
There is more or less commonly supported standard, SQL:92, but it still misses very very much to be really of use.
That's why almost every task beyond a simple SELECT with a JOIN needs some proprietary support to be implemented efficiently.
A thing to note is that while most RDBMS providers make a clear distinction between their extensions to SQL and the programming languages used to write stored procedures and triggers and so on, Microsoft and Sybase do exactly the contrary, they mix these two concepts into one, namely, T-SQL. You use T-SQL when you write normal queries, but you also can (and usually do) use T-SQL when you are writing stored procedures and triggers.
This has the controversial benefit of encouraging (or at least making very easy) the creation a mix of procedural and SQL code[*].
Nowadays Microsoft makes a distinction between T-SQL stored procedures and those written for the CLR (ie, .NET), but this is a relatively new development (from SQL Server 2005 onwards).
[*]: Controversial because people who don't speak SQL will be tempted to write procedural code (usually very inefficient in databases) instead of learning SQL (the proper thing to do).
The applicable SQL Standard for control-of-flow, local variables, etc (i.e. procedural code) is known as SQL/PSM (Persistent Stored Modules).
According to Wikipedia it was adopted in 1996 but I suspect it's the usual problem: vendors were already committed to their own extensions and therefore take up of the Standards is postponed for long periods of time
...but not necessarily indefinitely, there is hope. For example, common table expressions (CTEs) and OLAP functions in SQL Server 2005 and temporal data types in SQL Server 2008 indicate that extensions to TSQL will keep close to the publish Standards.
One other really important reason why vendors create their own flavors of SQL is performance tuning. There are many ways of writing more performant queries using vendor specific code that is written to take advantage of how that particular database engine works.