Is it possible to have same table name on different schema with different data on the tables within the one database? I think rather than create multiple database (that hold same table name) i should create multiple schema instead.
Something like:
Schema 1:
table A, table B
Schema 2:
table B, table X
PS: table B hold different data for each schema
And most basic question did every schema (user) hold different table set? In SQL Server and MySQL every user on same database have same table set, the difference was only on roles, how about Oracle?
Thanks
Yes this is possible. A schema in Oracle is what a MySQL user would call a database.
However, you need to be careful when accessing either of the tables now if the user you connect with to the database instance has access to both. To unambiguously reference a table in a specific schema, use schema.table.
Here's the documentation on namespaces: https://docs.oracle.com/en/database/oracle/oracle-database/20/sqlrf/Database-Object-Names-and-Qualifiers.html#GUID-3C59E44A-5140-4BCA-B9E1-3039C8050C49
As jackrabbit says objects in different schemas have different namespaces.
Each schema in the database has its own namespaces for the objects it contains. This means, for example, that two tables in different schemas are in different namespaces and can have the same name.
Within a schema things are a little more complex.
Because tables and views are in the same namespace, a table and a view in the same schema cannot have the same name. However, tables and indexes are in different namespaces. Therefore, a table and an index in the same schema can have the same name.
Related
Can I implement symmetricDS in identical databases?
My scenerio
I have to databases:
Database A
Database B
Whatever data change happens in either one of them should reflect in the other:
Current situation:
Even though the DB are identical, database B have less tables that database A
Consider a table tableA from database A and same table in database B
But pk id for same records are actually different in two tables
Can i expand and implement symmetricDS if i want to expand to a third database
Currently i am using a mapping table and API to handle datasync.
Can i move to symmetricDS for syncing data
Yes, go ahead
SymemtricDs allows for bidirectional synchronization of databases
Only the tables of database B will be configured for synchronization. The extra tables from database A might be added to the mix using table transformation.
As long as there are constraints of uniqueness on columns in, for example, database A that are PKs in database B that will not be a problem.
You can add as many types and instances of those types of databases. Bear in mind that the graph of database relationships must satisfy the definition of a tree.
When designing databases, I have been following the conventions of the Microsoft AdventureWorks sample database. They use schemas to logically separate groups of tables, e.g. Person, Production or Sales. It makes a lot of sense from a security point of view as well as from an organizational pov.
However, I have some tables that are used in multiple schemas. For example, a Country table that contains all countries. It wouldn't make sense to assign a sepecific schema to it, e.g. Person.Country or Production.Country as it is used in tables of different schemas.
Therefore, which schema do I assign it to?
you can use the "dbo" schema, its the default schema for sql-server and many others.
My database has been created with table names looking like this for the user information:
DROP TABLE [dbo].[webpages_Membership];
DROP TABLE [dbo].[webpages_OAuthMembership];
DROP TABLE [dbo].[webpages_Roles];
DROP TABLE [dbo].[webpages_UsersInRoles];
Is this somewhat of a standard when it comes to table naming conventions? If I now want
to make some new tables would it be reasonable to also name them things like
admin_application
admin_account
or do DBAs normally assign tables used to hold different things to different users when they want to group table types?
I would just like to find out how people normally group tables in an application. Am I
right to assume they are all under one owner in this case dbo or do people leave the
table names alone and have them stored in different owner accounts?
Yes, the best way is to use schemas to divide logically grouped tables. Good example of this is Adventure works database you can download from CodePlex. They have several schemas for different parts of the company such as Person, Production, Purcahsing, Sales and other. See more details on how MS designed this DB.
Have a look at schemas:
create schema webpages authorization dbo;
GO
create table webpages.Membership (...
create table webpages.OAuthMembership (...
create schema admin authorization dbo;
GO
create table admin.application (...
It used to be that before SQL Server 2005, you needed to create a database user in order to create a schema. However, since then, you can create schemas for organizational purposes. Schemas cannot contain schemas, so it's a single level. Schemas can contain any database object, i.e. tables, stored procedures, etc..
Schemas need to have an owner, hence the authorization bit above. Specifying dbo here will make it the same as if you had created it in the dbo schema.
is there a way to group tables into Postgres's schema like structure? We have a Postgresql server we want to move to Oracle DB. We use a lot of schemas to categorize tables. Anything Similar in oracle? Oracle has Schemas but there is a one to one relation between schema and a user. Schema == User.
Is there another stack-exchange that might be more appropriate for this question?
You will need to create the same amount of schemas in Oracle as you did in PostgreSQL. The fact that each schema is also associated with a user should not bother you.
You don't have to log-in with all those users if that's what you are wondering.
Just create one "application" user, and grant the necessary privileges on the tables you create in the various schemas to that application user.
If you used PostgreSQL's search path feature to avoid fully qualified table names, then you'll need to create synonyms (owned by the "applicatoin" user) that point to the tables in the various schemas.
Situation
I have 5 Access DB files, each one has 10 tables, 40 queries and 8 macros. All 5 Access DB files have same table name, table structure, same queries and same macros. The only different is the data contain in the table. If it matters, some tables on each database has rows between few hundreds to 100K+.
What I am trying to achieve
I am migrating these 5 Access DB files to single SQL Server (2008) database. Edit: After migrating, I do need to know which tables belong to which database since each original Access DB is associated with company's department so I need to keep track of this.
My Solutions or Options
Tables will be imported to SQL Server as tables. Queries will be imported as Stored Procedures. Macro will be imported as new Stored Procedures.
Import each Access DB's tables and queries to SQL Server DB and rename each tables and queries by giving them prefix to identify which tables belong to which database.
Same as #1, however, only import tables. As for the queries, only import one set of queries (40 queries) and modify them to dynamically select, insert, update or delete from the tables.
Import table A from 1st Access DB, table A from 2nd Access DB, table A from 3rd Access DB and so on, to one new table in SQL Server and give them unique identifier to identify which row of data belong to which database.
What do you think is the best approach? Please tell me if there is better way to do this than what I have listed. Thanks!
I would migrate them to MS SQL like so:
Import all tables from database 1 into corresponding tables from SQL Server, but add a new primary key with the name of the old one, rename the old pk and identifier for the database.
Update all foreign keys to the new pk field using the old pk and the identifier.
Repeat for databases 2-5
Either delete the identifier or keep it, depending if you need to know where the rows came from (same for old primary keys)
Only import queries/macros once, as they are the same.
When doing it this way, you keep the pk-fk relations and the queries intact and still know where the rows came from.
I would say number 3. You would get no duplication code and much easier maintenance.
One example of easier maintenance is performance tuning. You say the queries are the same in the 5 access DBs: say you detect one of the queries runs too slow and you decide that you need to create an index on an underlying table. In option #1 and #2 this would mean recreating the same index on 5 "twin" tables.
In access for each of these databases, you could assign each of the department field id (new field) with it's on identifier in a new table (each department has different value), and then add this value to each of the tables that is to be imported. Create a new table that has the department information in it, then create join table that connect these tables. Thus, each department is differentiated between each other.