Ive run into the issue where I need to query 2 separate databases(same instance) in one query.
I am used to doing this with mysql, but Im not sure how to do it with DB2.
In mySQL it would be something like:
SELECT user_info.*, game.*
FROM user_info, second_db.game_stats as game
WHERE user_info.uid = game.uid
So the question is how i translate a query like that into DB2 syntax?
Equivalent of this
Is there a reason why you have the tables in a separate database? MySQL doesn't support the concept of schemas, because in MySQL a "schema" is the same thing as a "database". In DB2, a schema is simply a collection of named objects that lets you group them together.
In DB2, a single database is much closer to an entire MySQL server, as each DB2 database can have multiple schemas. With multiple schemas inside the same database, your query can run more or less unchanged from how it is written.
However, if you really have 2 separate DB2 databases (and, for some reason, don't want to migrate to a single database with multiple schemas): You can do this by defining a nickname in your first database.
This requires a somewhat convoluted process of defining a wrapper (CREATE WRAPPER), a server (CREATE SERVER), user mapping(s) (CREATE USER MAPPING) and finally the nickname (CREATE NICKNAME). It is generally easiest to do these tasks using the Control Center GUI because it will walk you through the process of defining each of these.
Related
. I have two databases in same azure sql server .i want that both database interact to each other using trigger. i.e If any record is inserted in Customer table of first database the trigger gets fired and record is inserted in another database.
We had / have the same problem with triggers that we use for insert-update-delete where we write a record to Database-1 that has the primary table, but also updates Database-2 where we hold "archive" versions of the tables.
The only solution we have identified and are testing is to bring all of the tables into a single database and separate the different tables under separate database schemas in the one database.
Analysis so far of this approach looks promising.
I think what you're trying to do is not allowed in Sql Azure. From my expertise what you are trying to do is a bad practice on-premise as well (think backups-restore and availability issue scenarios).
You should move the dependency in the application and have the application update both databases, as appropriate.
Anyway, if you want to continue with this approach please take a look over Elastic Query feature: https://learn.microsoft.com/en-in/azure/sql-database/sql-database-elastic-query-overview
Please let me know if I can help with something
We are using H2 as test database for junittest suite. The actual application has tables in multiple databases like db1.s1.table1 and db2.s1.table2 (in other words database.schema.tablename) . To replicate that functionality we need to create two databases db1 and db2 and then create schema and tables accordingly. Also we have a dbscript.sql which loads all data before running test suite.
Please let us know if there is a way to create multiple databases in H2. If yes, what will be the exact command to do that as part of the script.
Since H2 creates the database specified as part of jdbc URL. Is there a way to specify multiple databases as part of URL so we can have them created.
we are working on data migration of sql server 2000 to Oracle 11g. Sql server has 4 databases which has to be migrated. These 4 databases are used for 6 different standalone applications. Oracle is installed in Unix server. Can we create a single database and different schemas for each sql server database or do I need to create multiple databases or can I use single database, single schema and multiple tablespaces or any other procedure to maintain the performance?
You can create multiple Oracle databases. Or you can create a single database with multiple schemas. Or you can create a single database with a single schema an put everything there if all your object names are unique.
The most similar approach would generally be to create a single Oracle database with four schemas. That gives you four separate namespaces in case you have objects in two different SQL Server databases that have the same name. And a single Oracle database per server generally gives the best performance since you're not allocating multiple SGAs and PGAs in memory or running multiple sets of background processes.
Tablespaces in Oracle are a completely separate concept. They have nothing to do with namespaces or permissions. They simply allow you to determine which objects reside in which physical data files. Barring something extremely unusual, tablespaces have nothing to do with performance. You could have the objects in all four schemas use a single tablespace. Or you could create four separate tablespaces. Or you could create multiple tablespaces that each have objects from different schemas. My guess is that the simplest approach is to create one tablespace per schema so that you can manage each application's disk space allocation separately.
I have the following scenario
I have 4 different (sql server) databases (legacy), one for each geo (NA,AP,LA,EMEA). The schema is the same in all the db's.
I am in the process of creating a front-end which will go across 4 different db's based on the users selection.I am thinking of using Entity framework. The db's are on different servers. What is the best way to create the entities? should i create 4 different edmx? there will be scenarios when the users results need to come from one or more db's
Thanks,
Nagendra
If databases are exactly same you can create edmx file only for one of databases (the mapping will be same for all DBs) and use 4 ObjectContext instances with different connection strings. The problem here can be with your second requirement. Querying more DBs means that you have to query each DB separately and merge/union results in memory on the application server. So such scenario is not very good for advanced querying where you need to run complex queries on all databases at the same time.
I’m after a bit of advice on the best way to go about this is SQL server 2008R2 express. I have a number of applications that are in separate databases on the same server. They are all “plugins” that use a central staff/structure list that will be in a separate database. The application is in the process of being migrated from JET.
What I’m looking for is the best way of all the “plugin” databases being able to see the central database and use those tables in standard queries and views etc.
As I’m using express that rules out any replication solution and so far the only option I can think of is to use triggers or a stored procedure to “push” out all the changes to the plugins. The information needs to be populated on a near enough real time basis however the number of changes will be very small maybe up to 100 a day and the biggest table only has about 1000 rows at the moment (the staff names table).
Hopefully that will cover all everything but if anyone needs any more details then just ask
Thanks
Apologies if I've misunderstood, but from your description it sounds like all these databases are hosted on the same instance of SQL Server - it's your mention of replication that makes me uncertain.
Assuming that's the case, you should be able to replace any copies of tables from the central database which are held in the "plugin" databases with views or synonyms which reference the central tables directly, since SQL server allows you to make references between databases on the same server using three-part naming (database_name.schema_name.object_name)
For example, if each plugin db has a table StaffNames, you could replace this with a view by dropping the table, then creating a view:
drop table StaffNames
go
create view StaffNames
as
select * from <centraldbname>.<schema - probably dbo>.StaffNames
go
and your code should continue to work seamlessly, as long as permissions are set up.
Alternatively, you could replace all the references to the shared tables in the plugin databases with three-part name references to the central database, but the view method requires less work.