So basically I have 2 superusers, postgres and eric, each with their own databases. What I want to do is, while being connected to one of them, access the database (tables to be more precise) of the other. The tables of both databases are in public schema.
I am using this query, which I found on another question on the forum, but without any result:
SELECT table_name
FROM information_schema.tables
WHERE table_schema='public'
I have changed the owners of the databases, offered all the privileges to both roles, but nothing. All I get are only the tables of the database under that user, not both.
Any idea what I could be missing? Thanks.
P.S: I am using PostgreSQL 9.3, and coding in Python 2.7
Superusers can always access everything in the whole cluster.
This sentence makes no sense:
Both databases are in public schema.
Cluster -> database -> schema -> table. Start with the manual here.
While connected to a particular database you can only access tables of this particular database. You have to connect to a different database to work with tables there.
Or you can use dblink or FDW.
PostgreSQL has a firewall between different databases. They might as well be on totally separate servers. You can use dblink or fdw or something like those to bridge between them.
Related
I have two companies using same application running in Oracle Database. Now the companies are merging and making a single company. The databases are huge with an approximate size of 10 TB.
We wanted to have the application in two databases to be merged and have a single application pointed to both the databases with minimal work.
Help is highly appreciated.
Regards
Bjm
Using DB Links feature in Oracle
For more information you can use below link regarding Database Links:
https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm#ADMIN12083
It would enable you to build a SQL statement that references tables from the two different databases.
If you want to access the data in instance B from the instance A, you can use below query and edit the details accordingly:
CREATE DATABASE LINK dblink_example
CONNECT TO xxusernamexx IDENTIFIED BY xxpasswordxx
USING
'(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=xxipaddrxx / xxhostxx )
(PORT=xxportxx))
(CONNECT_DATA=
(SID=xxsidxx)))';
Now you can execute the below query to access the table:
SELECT * FROM tablename#dblink_example;
You can perform any operation DML, DDL, DQL using DB Link
I have a few instances of DB2 10.5 server running on one physical Linux machine, let name them INST1 and INST2.
All of them contain multiple schemas, however schema-naming is unique accross whole machine, for example
INST1_SCHEMA_A,
INST2_SCHEMA_A etc.
What I would like to do is to somehow create a user that can access all of those schemas as they were on one instance, so it would be possible to make a queries like:
SELECT ID
FROM INST1_SCHEMA_A
UNION
SELECT ID
FROM INST2_SCHEMA_A
How can I achieve that? Should I just link databases and alias schemas?
Federation
is the keyword for your request. DB2 LUW to DB2 LUW is included in the license and this could be done across multiple databases - not matter if they reside within the same instance, another instance on the same server or even a different server.
Set FEDERATED = YES in the DBM CFG, define a server and set up Nicknames for remote tables. For details refer to this article or this one or the IBM Knowledge Center.
I'm am currently developing one project of many to come which will be using its own database and also data from a central database.
Example:
the database "accountancy" with all accountancy package specific tables.
the database "personelladministration" with its specific tables
But we also use data which is general and will be used in all projects like "countries", "cities", ...
So we have put these tables in a separate database called "general"
We come from a db2 environment where we could create foreign keys between databases.
However, we are switching to MS SQL server where it is not possible to put foreign keys between databases.
I have seen that a workaround would be to use triggers, but I'm not convinced that is a clean solution.
Are we doing something wrong in our setup? Because it seems right to me to put tables with general data in a separate database instead of having a table "countries" in every database, that seams difficult to maintain and inefficiënt.
What could be a good approach to overcome this?
I would say that countries is not a terrible table to reproduce in multiple databases. I would rather duplicate static data like that than use more elaborate techniques. There is one physical schema per database in sql server and the schema can not be shared. That is why people use replication or triggers for shared data.
I can across this problem a while back. We have one database for authentication, however, those users have to be shared across multiple applications some of which have their own database.
Here is my question on this topic.
We resorted to replication and using an custom Authentication/Registration service agent to keep the data up to data.
Using views, in what Sourav_Agasti suggested in his answer, would be the most straight forward approach for static data. You can create views and indexed views and join data from databases on linked servers.
Create a loopback linked server and then create a view(if required, on each database) which accesses the table in this "central database" through this linked server. There will be a minor performance impact but it more than enough compensates by being very simiplistic.
I read a write up about database schema.
A SQL Server schema is a container of objects. For example you may have a large enterprise application and then is a good practice to use different schemas for different purposes (e.g. put HR related tables into HR schema, accounting related tables into Accounting schema and so on). A schema can be owned by any user, and the ownership is transferable.
They said: use different schemas for different purposes (e.g. put HR related tables into HR schema, accounting related tables into Accounting schema and so on)
Do they mean create new database for HR and again new database for accounting?
Because when we create a database then a single schema is created so we cannot create multiple schema in single SQL Server database as far I know.
So please tell me how is it possible to create different schemas for different purposes in a single database? Thanks
Purpose of Schema
Schemas in sql server were introduced in sql server 2005, The main purpose was to eliminate User's ownership of objects in sql server. or you can say to separate users from objects in sql server.
Prior to Sql server 2005 objects in sql server (Tables, views, Store proceders etc) were owned by users. Typically the user who created it.
And that user had to give permissions to other users to use that particular object.
Imagine a scenario where 12 developers are working in a company and all developers are creating sql objects left, right centre. Now all the developers had to give permissions to other 11 developers if they had to work objects created by that one developer. quite a bit of mess isnt it??
Since sql server 2005 came with Schema. All the objects were Owned by a Schema Not a User. if you havent created any custom schema it will be under default Schema dbo.
Now anyone who has permission to dbo schema has permission to any object under dbo schema.
Why it is a good idea to create different schemas for different departments in your case. It may be because HR people doesnt need to know anything about Finance stuff. so you can create a HR schema and give HR people permission only on HR schema. and vice versa with finance people. That will restrict their access to only objects related to their departments.
And we can create multiple Schemas in one database if you have ever worked with Adventureworks database, it has Schemas like 'Production', 'Sales' etc etc.
Read here to learn more about schemas in sql server.
No they mean create a schema. Create schema works within a database. There are all sorts of uses for it, I tend to think of it as either namespacing or a more natural way of partitioning a smallish database and keeping role based access, where you can think of schema as a user group.
Unfortunately, there are two meanings to the word "schema" in the database world.
One means the overall design of the database tables. "Show me your database schema", for example. This would be the collection of "create table" commands, or and ERD diagram.
The other is a synonym for "namespace", which the article in question is referring to. You can store tables, functions etc in different namespaces to ease cognitive load or use for security grouping.
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.