Taking a peek into the information_schema database and peeking at the metadata for one of my pet projects, I'm having a hard time understanding what (if any) differences there are between the create schema command and the create database command for MySQL.
Are there any differences? If not, is this a rather typical pattern of behavior for relational databases (I've heard that for other databases, such as Oracle, a schema exists in a database, rather than being on the same level as a database).
Thanks!
The documentation of MySQL says :
CREATE DATABASE creates a database
with the given name. To use this
statement, you need the CREATE
privilege for the database. CREATE
SCHEMA is a synonym for CREATE
DATABASE as of MySQL 5.0.2.
So, it would seem normal that those two instruction do the same.
Mysql documentation says : CREATE SCHEMA is a synonym for CREATE DATABASE as of MySQL 5.0.2.
this all goes back to an ANSI standard for SQL in the mid-80s.
That standard had a "CREATE SCHEMA" command, and it served to introduce
multiple name spaces for table and view names. All tables and views were
created within a "schema". I do not know whether that version defined
some cross-schema access to tables and views, but I assume it did.
AFAIR, no product (at least back then) really implemented it, that whole
concept was more theory than practice.
OTOH, ISTR this version of the standard did not have the concept of a
"user" or a "CREATE USER" command, so there were products that used the
concept of a "user" (who then had his own name space for tables and
views) to implement their equivalent of "schema".
This is an area where systems differ.
As far as administration is concerned, this should not matter too much,
because here you have differences anyway.
As far as you look at application code, you "only" have to care about
cases where one application accesses tables from multiple name spaces.
AFAIK, all systems support a syntax ".",
and for this it should not matter whether the name space is that of a
user, a "schema", or a "database".
Strictly speaking, the difference between Database and Schema is inexisting in MySql.
However, this is not the case in other database engines such as SQL Server. In SQL server:,
Every table belongs to a grouping of objects in the database called database schema. It's a container or namespace (Querying Microsoft SQL Server 2012)
By default, all the tables in SQL Server belong to a default schema called dbo. When you query a table that hasn't been allocated to any particular schema, you can do something like:
SELECT *
FROM your_table
which is equivalent to:
SELECT *
FROM dbo.your_table
Now, SQL server allows the creation of different schema, which gives you the possibility of grouping tables that share a similar purpose. That helps to organize the database.
For example, you can create an schema called sales, with tables such as invoices, creditorders (and any other related with sales), and another schema called lookup, with tables such as countries, currencies, subscriptiontypes (and any other table used as look up table).
The tables that are allocated to a specific domain are displayed in SQL Server Studio Manager with the schema name prepended to the table name (exactly the same as the tables that belong to the default dbo schema).
There are special schemas in SQL Server. To quote the same book:
There are several built-in database schemas, and they can't be dropped or altered:
1) dbo, the default schema.
2) guest contains objects available to a guest user ("guest user" is a special role in SQL Server lingo, with some default and highly restricted permissions). Rarely used.
3) INFORMATION_SCHEMA, used by the Information Schema Views
4) sys, reserved for SQL Server internal use exclusively
Schemas are not only for grouping. It is actually possible to give different permissions for each schema to different users, as described MSDN.
Doing this way, the schema lookup mentioned above could be made available to any standard user in the database (e.g. SELECT permissions only), whereas a table called supplierbankaccountdetails may be allocated in a different schema called financial, and to give only access to the users in the group accounts (just an example, you get the idea).
Finally, and quoting the same book again:
It isn't the same Database Schema and Table Schema. The former is the namespace of a table, whereas the latter refers to the table definition
CREATE SCHEMA is a synonym for CREATE DATABASE. CREATE DATABASE Syntax
Database is a collection of schemas and schema is a collection of tables. But in MySQL they use it the same way.
So, there is no difference between MySQL "database" and MySQL "schema": these are two names for the same thing - a namespace for tables and other DB objects.
For people with Oracle background:
MySQL "database" a.k.a. MySQL "schema" corresponds to Oracle schema.
The difference between MySQL and Oracle CREATE SCHEMA commands is that in Oracle
the CREATE SCHEMA command does not actually create a schema but rather populates it
with tables and views.
And Oracle's CREATE DATABASE command does a very different thing than its MySQL counterpart.
there is no difference between MySQL "database" and MySQL "schema": these are two names for the same thing
Related
I'm new to SQL Server, and I'm asking if can I create a database in other database like this:
mydatabase1[database] -> mydatabase2[database] -> mytable[table]
No. SQL Server stores data in a hierarchy, consisting of:
Tables are in schema.
Schema are in databases.
Databases are in servers.
The full access for a table uses a four-part naming convention: server.database.schema.table. However, most code does not use all four.
If you are thinking that databases are like folders and tables are like files, then that is the wrong analogy.
A colleague of mine has given me a task to ensure all table name and pages in a stored procedure contains the relevant schemas?
For example if I have a table in a database that is dbo.table1, then in a query if I have:
Select * from table1
He wants me to change it to:
Select * from dbo.table1
This is same for pages that start with Support.
What is the significance of adding in a scheme like dbo. At the start when manually writing SQL? Is it suppose to be better for performance as it seems to know where the tables even if I don't include .dbo at the start?
I'm using SQL server 2012 and its management studio.
Thank you
You may not notice the performance if you write the schema in all of your queries. If you don't specify it, the engine will look through all of your schemas in your databases ( I'm not pretty sure if the engine will check the sys schemas too ) until it finds the table you're getting the data; It's recommended as a best practice to write it because you are telling to the engine what schema need to search the table.
I hope this answer was helpful.
dbo is the schema which is used as part naming convention for tables in a mssql database
look at this post SQL Server edits the table name with dbo as prefix
I have two different data base, one is DEVORADB which i use for development, and another one is UATORADB which tester use for testing. UATORADB have the most updated data which is not in development. I want to query tables from UATORADB database in DEVORADB. I was writing in DEVORADB in such a way but not getting the result:
SELECT * FROM TABLE_NAME#UATDEVORADB.
For Oracle,
CREATE DATABASE LINK ...
e.g.
With a database link created and tested, you can do a query (of the style you showed) to retrieve rows from a remote database.
Reference: http://docs.oracle.com/cd/E11882_01/server.112/e41084/statements_5005.htm#SQLRF01205
FOLLOWUP
NOTE: In Oracle, the term "database" refers to the datafiles and logfiles associated with an Oracle "instance". To retrieve data from a second "database" means you need a second connection to the other database. Oracle provides a facility called a "database link". That allows a session(connection) to one database instance to connect to another database instance. (Without this facility, a client would need to create two separate connections, and would need to query the two databases separately.)
If this question is regarding querying from two separate "schemas" within the same database, as long as the user has sufficient privileges on objects in the second schema, the identifier can be qualified with the name of the schema, e.g.
SELECT * FROM UATDEVORADB.TABLE_NAME
To access data on a separate database, a database link can be used...
CREATE DATABASE LINK UADEVORADB
CONNECT TO user
IDENTIFIED BY password
USING 'uadevoradb' ;
(This will require an appropriate matching entry in the tnsnames.ora file on the Oracle server, or the oracle names server, or the connection details can be spelled out in place of a tnsnames.ora entry, something like:
CREATE DATABASE LINK UADEVORADB
CONNECT TO user IDENTIFIED BY password
USING '(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=uadevorahost1)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=uadevoradb.domaindb)))'
If the "user" specified in the database link differs from the "owner" of the table on the remote system, and there's no synonym that references the table, the table identifier will need to be qualified with the owner...
SELECT * FROM OWNER.TABLE_NAME#UADEVORADB ;
We have live and demo systems, each using of a pair of databases.
One database often reports from the other.
Quite often the demo site has a reference like this
SELECT Columns
FROM OtherDatabase_demo.dbo.Tablename
So the live version would say:
...FROM OtherDatabase.dbo.Tablename
When it comes to publsihing I compare the stored procedures between live and demo (using dbForge Schema Compare in my case) every differing reference is highlighted, and creates a lot of noise.
Is there any way to abstract these references so I can make that distinction in one single location?
Yes, use a synonym. In one database:
CREATE SYNONYM dbo.MyTableName FOR OtherDatabase_demo.dbo.Tablename;
And in the live version:
CREATE SYNONYM dbo.MyTableName FOR OtherDatabase.dbo.Tablename;
Now your script can say...
SELECT Columns
FROM dbo.MyTableName
...in both databases, allowing your procedures to be identical.
Your diff scripts may pick up the different definitions for the synonyms, but hopefully you can ignore those (either with the tool or just consciously).
We've asked for the ability to alias a database, but they don't understand how useful this could be:
http://connect.microsoft.com/SQLServer/feedback/details/311079/expand-synonym-to-other-entities-database-linked-server
http://connect.microsoft.com/SQLServer/feedback/details/288421/allow-create-synonym-for-database
I'm having a slight terminology meltdown as I design some classes. In Sql Server 2005, 'schema' refers to a namespace, and an organizational system for database objects. But for relational databases in general, 'schema' means the DDL design of tables, fields, etc. If I'm right about this, it explains a lot of the dissonance when I am trying to read microsoft documentation, and understand the various data access APIs. Can you explain what's going on here, is there really that much difference in the definition of 'schema'?
Yes, the word "schema" unfortunately has become overloaded among database vendors.
"SQL-99 Complete, Really" says:
An SQL Catalog is a named group of Schemas. ...
An SQL Schema is a named group of SQL-data that is owned by a particular
. ... Every Schema Object has a name that must be unique
(among Objects of its name class) within the Schema it belongs to. The Schema Object name classes are:
Base tables and Views
Domains and UDTs
Constraints and Assertions
Character sets
Collations
Translations
Triggers
SQL-server Modules
SQL-invoked routines
Oracle uses "schema" and "user" interchangeably, which always makes my eyebrows raise.
MySQL uses SCHEMA as a synonym for DATABASE.
PostgreSQL uses "schema" but uses "database" to refer to what standard SQL calls a "catalog."
You are correct. When in SQL 2005/2008, "schema" refers to a namespace, while in a relational database discussion "schema" would refer to the logical structure of the tables, views, procs, functions, etc.