Database wrapper - Heterogeneous service - mysql

Problem
I have 3 databases type Oracle, Mysql, Microsoft SQL. data are the same in all databases.
Is there any way to have 1 database, whatever it is, and store data on it, and have a database wrapper in front of It, that handle JDBC, ODBC connections "Oracle, Mysql, MicrosftSQL". so the wrapper layer "Heterogeneous Services" / "Database Gateway ..etc", receive oracle, Mysql ..etc queries and translate them to the database being chosen and response with the result.
Result
So instead of managing 3 types of database and backup, update ..etc. I end up managing one database type, for example, "Hive". but still accepting both JDBC, ODBC connections from different applications.

Related

postgres schemas and roles in mySQL

I have been using PostGresSQL as the database for one of my applications. To support multi-tenancy, I used schemas and roles for each tenant so as to limit access and prevent data leaks in event of an SQL injection. I am maintaining a single connection pool and then doing a SET ROLE after determining the tenant context so he can access only his own schema. This all works well. However, what is the equivalent design in mySQL ? I saw that mySQL does not have "roles" and a schema / database is the same conceptually, how can I achieve something similar in mySQL ? I ask because I am designing another application and am being told to use mySQL instead of PGSQL.
Thanks
Since mysql does not have the concept of roles, you either have to use different mysql database users and databases to achieve the same logical separation of data. Effectively, after determining the context, you have to connect to mysql using a different myswl user account and a different default database. The drawback is that this solution will render connection pooling inert. Fortunately, in MySQL establishing a new connection to the database is quick and does not require too much resources.
Alternatively, you can use a single database and mysql user account and distinguish between you users on application user account level. Obviously, this means that your users' data will not have the same logical separation as you currently have, but you can still use connection pooling.
As a third alternative with limited number of users you can use the same mysql user account and default database to connect to mysql, but store actual user data in separate databases only accessible using separate mysql user accounts. However, in that default database create separate views for each and every table in the user databases. In the create view statement set the definer clause to the mysql user account that can access the given database where the table is stored and set sql security clause to definer. This way you can still use connection pooling, since the connections are made using a common user id to a default database. The client data will be logically separated in the databases. The drawback is that through the views within the default database all data will be accessible and any modification to the underlying data structure must be reflected in the views as well.

Relationship between catalog, schema, user, and database instance

To compare databases of different vendors (Oracle, SQL Server, DB2, MySQL, and PostgreSQL) how can I identify any object uniquely and do I need a catalog? For instance, In Java's DatabaseMetadata I should specify catalog and schema fooPattern at least.
Is it true that catalog is just an abstraction of data storage?
In Oracle:
server instance == database == catalog == all data managed by same execution engine
schema == namespace within database, identical to user account
user == schema owner == named account, identical to schema, who can connect to database, who owns the schema and use objects possibly in other schemas
to identify any object in running server, you need (schema name + object name)
In PostgreSQL:
server instance == db cluster == all data managed by same execution engine
database == catalog == single database within db cluster, isolated from other databases in same db cluster
schema == namespace within database, by default public is used
user == named account, who can connect to database, own and use objects in each allowed database separately
to identify any object in running server, you need (database name + schema name + object name)
In MySQL:
server instance == not identified with catalog, just a set of databases
database == schema == catalog == a namespace within the server.
user == named account, who can connect to server and use (but can not own - no concept of ownership) objects in one or more databases
to identify any object in running server, you need (database name + object name)
In Microsoft SQL Server:
server instance == set of managed databases
database == namespace qualifier within the server, rarely referred to as catalog
schema == owner == namespace within the database, tied to database roles, by default dbo is used
user == named account, who can connect to server and use (but can not own - schema works as owner) objects in one or more databases
to identify any object in running server, you need (database name + owner + object name)
So I think answer to your questions is:
It depends on implementation, whether catalog name is needed to identify objects. The meaning of catalog, schema and database vary from one implementation to another.
Yes, a catalog is an abstraction of data storage. I think it should be also defined as a self-contained isolated namespace, but not all SQL engines do it.
Database and schema are pretty well defined by all vendors. Catalog is sometimes synonymous to "database" (at least in Oracle and Postgres), sometimes synonymous to "schema", and sometimes synonymous to both. The term catalog also often means metadata collection (aka system tables).
Schema is what programmers should use to organize artifacts in SQL database as it represents a logical namespace with access control layer.
For DB2, schema is used as namespaces. So if you want to uniquely identify an object in a database you would say *schema.object_name*. This is a very handy way to achieve multitenancy. You can have a separate schema for each tenant in your database. This provides for good separation of concerns from both security as well as management aspects. You can have 32K schemas in a single DB2 database.
A catalog in DB2 is simply a collection of system tables that contain metadata about the database. In general, it is considered a bad practice to access catalog objects directly. It is best to use the facilities provided by your API (e.g. JDBC) to explore the catalog and the metadata it contains.
DB2 also has other abstraction layers. You can have multiple instances of DB2 running on the same machine. Each instance can manage 256 separate databases (each with 32K schemas). The number of DB2 instances on a server is limited only by the amount of memory you have available. At one point in time we had 120 instances of DB2 (each with one database and 10 connections) running on Amazon EC2 m1.large.
You can also have multiple installs of DB2 on a single server. it is useful when testing a new version you plan to migrate to. I do find it confusing though often forgetting to switch to the right install.
What is mentioned here about mysql in post by filiprem seems to be incorrect. As per following links, in mysql the jdbc catalog corresponds to database. The jdbc schema is not supported .
http://forums.mysql.com/read.php?39,137564,137629#msg-137629
http://bugs.mysql.com/bug.php?id=23304
http://books.google.com/books?id=a8W8fKQYiogC&pg=PA25&lpg=PA25&dq=jdbc+catalog+schema&source=bl&ots=oj0HAA91zL&sig=vRjgPLV_3J6o2kqh6epwvZNZgcM&hl=en&sa=X&ei=3k7zT-_qBueW2AXSjdDkAw&ved=0CFYQ6AEwAg#v=onepage&q=jdbc%20catalog%20schema&f=false
I'm sharing my results in the point of client(driver)'s view.
product: result of the getProductName()
c_term: result of the getCataglogTerm()
s_term: result of the getSchemaTerm()
T_CAT: distinct values of TABLE_CAT from the result of getTables(null, null, "%", null)
T_SCHEM: distinct values of TABLE_SCHEM from the result of getTables(null, null, "%", null)
product
c_term
s_term
T_CAT
T_SCHEM
Apache Derby
CATALOG
SCHEMA
<empty>
SYS SYSIBM
H2
catalog
schema
TEST
INFORMATION_SCHEMA
HSQL Database Engine
CATALOG
SCHEMA
PUBLIC
INFORMATION_SCHEMA, SYSTEM_LOBS
SQLite
catalog
schema
null
null
MySQL
database
<empty>
performance_schema, information_schema
null
MariaDB
database
schema
information_schema
null
PostgreSQL
database
schema
pg_catalog, information_schema
pg_toast

MySQL to SQL Server migration

I have a mysql database full of data which I need to keep but migrate to SQL Server 2008.
I know end to end where the data should go, table to table but I have no idea how to go about moving the data. I've looked around the web but it seems there are 'solutions' which you have to download and run. I'd rather if possible do something myself in terms of writing scripts or code.
Can anyone recommend the best way to do this please?
You have several options here:
On the sql server side, you can set up a connection to your old mysql db using something called a linked server. This will allow you to write sql code for sql server that returns data from the mysql tables. You can use this to build INSERT or SELECT INTO statements.
You can write queries for mysql to export your data as csv, and then use the BULK INSERT features of sql server to efficiently import the csv data.
You can use Sql Server integration services to set move the data over from mysql.
Regardless of which you choose, non-data artifacts like indexes, foreign keys, triggers, stored procedures, and security will have to be moved manually.
Have you tried tool from MSFT called SQL Server Migration Assistance for MySQL ???
https://www.microsoft.com/download/en/details.aspx?id=1495
Try this tutorial it is very easy to perform migration to SQL Server from Mysql and is straightforward as mentioned
http://www.codeproject.com/Articles/29106/Migrate-MySQL-to-Microsoft-SQL-Server
Thanks
You can use the Import/Export Wizard that comes with SQL Server Standard Edition.
Select your 'data source' from MySQL using the ODBC data source. Note: You will need to first install the from ODBC driver for MySQL (ODBC Connector). Then, select your SQL Server destination. Select all tables, and fire it up. You will need to add your primary and foreign keys, and indexes manually.
A bit more automated means would be by using the SQL Server Migration Assistant for MySQL, also free. It has the benefit of recreating the relationships and indexes automatically for you. Probably your best bet.
I did it once, some time ago. First you could couple your mssql server to the mysql server using the odbc mysql connector
http://dev.mysql.com/downloads/connector/
After the connection is made you can write you database procedure as you would if it were two mssql db's. Probably easiest to write some sql batch scripts including a cursor where you run through every every row of a table an decide on a field basis where you will need the field in the future.
example of a cursor: http://www.mssqltips.com/tip.asp?tip=1599
If you decide to go with the cursor, you can play with the parameter to increase performance. I especially remember the FORWARD_ONLY parameter giving a big boost.

Trying to access two different databases with the same connection string with LINQ

I'm trying to access two different databases with the same connection string with LINQ. However I'm getting an error which suggests my LINQ statement is using the default database as named in the connection string.
I'd rather not add another connection in the web.config and want to use the same connection string but to a different db on the same db server.
I realise I need to do something with mappingSource when I initialise the source, but my searches so far have drawn a blank.
If you only need to query data out of a second database on the same db server you could create views on the first database that point to the second.
I'd caution against doing the view creation if the databases are on separate servers as you can get pretty bad latency issues. For that matter I'd caution against joining tables from multiple servers at all...

What's the difference between Oracle and Mysql when interpreting "Create Database "?

I used to use mysql, and in mysql database hold tables, but these concepts doesn't apply to oracle, so I don't quite understand the differences.
Update: The problem I am facing is, I need to do migration from Mysql to Oracle.
I have two switching databases called A and B, in Mysql all the tables are in their corresponding databases.
In mysql database is a logical concept, it use database to hold tables, in oracle database is physical concept, I don't know how to design this in oracle.
Do I need to use "CREATE DATABASE" to create two databases in oracle to achieve the same effect?
To answer your question you want to create a schema (CREATE USER) not an instance/database (CREATE DATABASE).
The Oracle definition of a database is the files on disk. These can be shared between instances (Real Application Clusters) or only used by a single instance (on the same server for example, the most common).
Background: The concept of "database" is different between database vendors. As an Oracle DBA I'm careful when talking to someone who is from an MySQL, DB2, SQL Server background, what they call a "database" in Oracle is a user/schema (difference between user and schema being a schema contains tables and a user is only a login). Whenever someone, developer especially, uses the word "database" question in what context.
Oracle's SQL Developer documentation has a chapter comparing MySQL with Oracle. Find it here. The reason it is here is because SQL Dev includes the Migration Workbench which supports migrating MySQL to Oracle. You might want to consider using the tool in your endeavours. It is free.
Anyway, the documentation has this answer to your specific question:
"When migrating MySQL databases to
Oracle, SQL Developer maps each MySQL
database to a tablespace in Oracle.
Database objects, such as tables,
indexes and views are stored in the
respective tablespaces and are
referenced from the Oracle schema for
the user that owns them."