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
Related
In Oracle 11G I can easily invoke:
SELECT * FROM TABLE#DB_LINK_NAME;
But how invoke SELECT over DB_LINK that is on another DB_LINK?
Something like this:
SELECT * FROM TABLE#REMOTE_DB_LINK_NAME#DB_LINK_NAME;
First off, architecturally, I'd be pretty leery of any design that involved pulling data over multiple database links. I've seen it done when the eventual source is some ancient version of Oracle that the target database cannot connect to directly so an intermediate database running an intermediate version of Oracle was used. That is very rare in practice, though.
From a performance perspective, this sort of approach is gravely problematic. There is, of course, the issue that the data is going to be sent over the network twice. But more to worryingly, you are taking a difficult problem, optimizing distributed SQL statements, and making it nearly intractable. You'd basically have to either guarantee that you would never query local data and remote data in the same query or you would have to live with the resulting performance if Oracle decides on a stupid query plan because the set of tools left to allow you to optimize this sort of query is minimal.
That being said, the intermediate database would need to have synonyms or views that abstract away the database link. So
On A:
create database link to B
On B:
create database link to C
create synonym table for table#C
On A, you can then
SELECT *
FROM table#B
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
Assume SQL Server 2005+.
Part A:
What is the canonical way to query from the system/internal/meta/whatever tables/views (sorry, not a database ninja) for any user table or column names that use SQL Server keywords (like case)?
I don't mind maintaining the list of keywords if that's not query-able, as it only changes with versions of SQL Server supported (right?).
Looking at available views in SQL Server 2005, I can easily enough query this information from INFORMATION_SCHEMA.COLUMNS and INFORMATION_SCHEMA.TABLES, but I want to be sure it's from the best possible location for future-proofing.
Part B:
Is it possible to get the list of keywords via query?
UPDATE: While a useful concept, I'm specifically not interested in escaping the column/table/etc names in question because I'm hoping to write a tool that will check for tables/columns/etc that share names with keywords and provide useful warnings to developers. The tool would be used during code reviews at my office to point out that the developer might want to consider renaming the entity. (Or hopefully by the developer before code reviews for their own good!) I may even set it up for use with continuous integration in my build scripts, but that's only a thought for the future.
You should properly quote the names used. If you generate code, use the built-in QUOTENAME function. Don't build a list of known keywords, instead quote every name used for every object, including database name, schema name and object name. Also make sure you always adhere to the correct case of the objects involved. As a best practice, develop on a case sensitive collation server instance. Developing code on case insensitive server collation (default) can lead to embarasing failures on production when deployed on case sensitive collation servers.
For Part A
Personally I would go for sys.columns and sys.objects actually. INFORMATION_SCHEMA views are also good, and they're 'portable' in theory, I'm just so much more used to the SQL specific ones though. I choose sys.objects vs. sys.tables because it covers more (eg. views). I would suggest you also cover table valued functions, table valued parameter types (in 2008 only) and temporary #tables and table #variables declared inside stored procedures. That would leave out only temp #tables and table #variables declared in batches sent by clients, but those are basically in client code only.
A: Just use brackets around your identifier.
select [procedure].[case] from [procedure]
B: I'm not sure if you can query for them, but there is a MSDN page about it.
If you need these programmatically, I suggest you insert them all into a table for your own uses.
Why do you need to know the list of keywords? a: they don't change very often, and b: for any regular code (I'm excluding things like "sql server management studio") you can just use square brackets:
SELECT [table].[column], [table].[join]
FROM [table]
I have to develop database development standards for our organisation for SQL Server and any code that interfaces to it. The code used can be anything from .NET code to VBScript to SQL Server Jobs.
Does anyone have a good link for this kind of thing?
My quick list is follows:
1) Naming Conventions
-- Stored Procedures usp_AppName_SPName
-- Functions usf_AppName_SPName
-- Indexes IX_TableName_IndexName
-- Tables AppName_TableName
-- Views VW_Name
2) Allocation of permissions to roles, never directly to users or groups
3) Allocation of roles to groups, never directly to users
4) Use of minimal permissions
5) No inline sql in code, always use SP or Functions
6) Use of explicit transactions
7) Readonly transactions where applicable
8) Always use explain plans to ensure sql is performant.
What other things do we need to cover? I am sure that there are lots of things....
Since we are talking best-practices I'd throw in a few things to avoid:
avoid use of xp_cmdshell
avoid dynamic sql unless strictly
necessary (such as for dynamic pivoting)
avoid cursors (if not on temp
tables)
P.S. Btw - I am doing all of the above ;)
I found the following quite useful:
http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterSQLServerDatabases.aspx
http://www.codeproject.com/KB/database/sqldodont.aspx
Also consider using multiple schemas. Use AppName.TableName instead of AppName_TableName, where AppName is a schema. The AdventureWorks sample does this, for instance.
I have to take issue with your first item right off the bat. While I know a lot of people like to use prefixes for stored procedures, tables, and the like, I've never had much use for that convention. When you start to get a lot of stored procedures that all start with "usp_", and you click to the expand the "Programmability\Stored Procedures" folder in Management Studio, it can be rather unwieldly to navigate.
Instead, require a prefix to match the logical feature set/functional group. What those prefixes are will vary by application or database. Then if you want to distinguish a stored procedure from a table, add your "_usp" requirement as a suffix.
For tables: you want something in your naming convention to distinguish between Application data (lookup tables) and User data.
Aren't roles and groups the same thing in SQL Server?
A few others...
Avoid using UDFs in WHERE clauses
Disallow direct SQL in applications
(always use SPs)
Use comment blocks in front of
views/procs/functions including a
revision history and/or revision
date
Use ANSI join syntax
Limit use of triggers, especially
for replicated tables
I'm looking for a way to validate the SQL schema on a production DB after updating an application version. If the application does not match the DB schema version, there should be a way to warn the user and list the changes needed.
Is there a tool or a framework (to use programatically) with built-in features to do that?
Or is there some simple algorithm to run this comparison?
Update: Red gate lists "from $395". Anything free? Or more foolproof than just keeping the version number?
Try this SQL.
- Run it against each database.
- Save the output to text files.
- Diff the text files.
/* get list of objects in the database */
SELECT name,
type
FROM sysobjects
ORDER BY type, name
/* get list of columns in each table / parameters for each stored procedure */
SELECT so.name,
so.type,
sc.name,
sc.number,
sc.colid,
sc.status,
sc.type,
sc.length,
sc.usertype ,
sc.scale
FROM sysobjects so ,
syscolumns sc
WHERE so.id = sc.id
ORDER BY so.type, so.name, sc.name
/* get definition of each stored procedure */
SELECT so.name,
so.type,
sc.number,
sc.text
FROM sysobjects so ,
syscomments sc
WHERE so.id = sc.id
ORDER BY so.type, so.name, sc.number
I hope I can help - this is the article I suggest reading:
Compare SQL Server database schemas automatically
It describes how you can automate the SQL Server schema comparison and synchronization process using T-SQL, SSMS or a third party tool.
You can do it programatically by looking in the data dictionary (sys.objects, sys.columns etc.) of both databases and comparing them. However, there are also tools like Redgate SQL Compare Pro that do this for you. I have specified this as a part of the tooling for QA on data warehouse systems on a few occasions now, including the one I am currently working on. On my current gig this was no problem at all, as the DBA's here were already using it.
The basic methodology for using these tools is to maintain a reference script that builds the database and keep this in version control. Run the script into a scratch database and compare it with your target to see the differences. It will also generate patch scripts if you feel so inclined.
As far as I know there's nothing free that does this unless you feel like writing your own. Redgate is cheap enough that it might as well be free. Even as a QA tool to prove that the production DB is not in the configuration it was meant to be it will save you its purchase price after one incident.
You can now use my SQL Admin Studio for free to run a Schema Compare, Data Compare and Sync the Changes. No longer requires a license key download from here http://www.simego.com/Products/SQL-Admin-Studio
Also works against SQL Azure.
[UPDATE: Yes I am the Author of the above program, as it's now Free I just wanted to Share it with the community]
If you are looking for a tool that can compare two databases and show you the difference Red Gate makes SQL Compare
You didn't mention which RDMBS you're using: if the INFORMATION SCHEMA views are available in your RDBMS, and if you can reference both schemas from the same host, you can query the INFORMATION SCHEMA views to identify differences in:
-tables
-columns
-column types
-constraints (e.g. primary keys, unique constraints, foreign keys, etc)
I've written a set of queries for exactly this purpose on SQL Server for a past job - it worked well to identify differences. Many of the queries were using LEFT JOINs with IS NULL to check for the absence of expected items, others were comparing things like column types or constraint names.
It's a little tedious, but its possible.
I found this small and free tool that fits most of my needs.
http://www.wintestgear.com/products/MSSQLSchemaDiff/MSSQLSchemaDiff.html
It's very basic but it shows you the schema differences of two databases.
It doesn't have any fancy stuff like auto generated scripts to make the differences to go away and it doesn't compare any data.
It's just a small, free utility that shows you schema differences :)
Make a table and store your version number in there. Just make sure you update it as necessary.
CREATE TABLE version (
version VARCHAR(255) NOT NULL
)
INSERT INTO version VALUES ('v1.0');
You can then check the version number stored in the database matches the application code during your app's setup or wherever is convenient.
SQL Compare by Red Gate.
Which RDBMS is this, and how complex are the potential changes?
Maybe this is just a matter of comparing row counts and index counts for each table -- if you have trigger and stored procedure versions to worry about also then you need something more industrial
Try dbForge Data Compare for SQL Server. It can compare and sync any databases, even very large ones. Quick, easy, always delivers a correct result.
Try it on your database and comment upon the product.
We can recommend you a reliable SQL comparison tool that offer 3 time’s faster comparison and synchronization of table data in your SQL Server databases. It's dbForge Data Compare for SQL Server.
Main advantages:
Speedier comparison and synchronization of large databases
Support of native SQL Server backups
Custom mapping of tables, columns, and schemas
Multiple options to tune your comparison and synchronization
Generating comparison and synchronization reports
Plus free 30-day trial and risk-free purchase with 30-day money back guarantee.