I have to decide which method is better for us, in order to make our software a little more as a multi-tenant method, maybe I have to decide between using schema or only a Table "Tenants" and I have a question: how many schemas (limit) can I use in an instance of SQL Server and of Oracle?
In SQL Server, you can have a maximum of 2,147,483,647 objects.
An object can be a table, view, procedure, etc., and also a schema is an object.
https://msdn.microsoft.com/en-us/library/ms143432.aspx
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 know information schema views are part of SQL standard, but I find catalog views as well as DMV "term" used interchangeably
any explanation that clearly tell us difference particularly difference between catalog views and DMV?
Catalog views represent views over some hidden tables. They return data from the database itself (from disk).
DMVs represent views over internal functions. They return data from internal SQL structures (from memory). DMV names always start with sys.dm_.
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
Is there a SQL command that will list all the tables in a database and which is provider independent (works on MSSQLServer, Oracle, MySQL)?
The closest option is to query the INFORMATION_SCHEMA for tables.
SELECT *
FROM INFORMATION_SCHEMA.Tables
WHERE table_schema = 'mydatabase';
The INFORMATION_SCHEMA is part of standard SQL, but not all vendors support it. As far as I know, the only RDBMS vendors that support it are:
MySQL
PostgreSQL
Microsoft SQL Server 2000/2005/2008
Some brands of database, e.g. Oracle, IBM DB2, Firebird, Derby, etc. have similar "catalog" views that give you an interface where you can query metadata on the system. But the names of the views, the columns they contain, and their relationships don't match the ANSI SQL standard for INFORMATION_SCHEMA. In other words, similar information is available, but the query you would use to get that information is different.
(footnote: the catalog views in IBM DB2 UDB for System i are different from the catalog views in IBM DB2 UDB for Windows/*NIX -- so much for the Universal in UDB!)
Some other brands (e.g. SQLite) don't offer any queriable interface for metadata at all.
No. They all love doing it their own little way.
No, the SQL standard does not constrain where the table names are listed (if at all), so you'll have to perform different statements (typically SELECT statements on specially named tables) depending on the SQL engine you're dealing with.
If you are OK with using a non-SQL approach and you have an ODBC driver for the database and it implements the SQLTables entry-point, you possibly might get the information you want!
pjjH
details on the API at:
http://msdn.microsoft.com/en-us/library/ms711831.aspx