When looking at SQL Server Management Studio (SSMS), which one is better and why? Are there cases where we should use one over the other?
I can't tell the difference between them.
INFORMATION_SCHEMA is there for compatibility, it doesn't expose all the information about objects on the instance.
sys however, fully exposes any relevant information, though you do need to write more SQL. INFORMATION_SCHEMA is "easier" to use for new users, as something like INFORMATION_SCHEMA.COLUMNS contains the names of the table, schema, the column and the data type in objects. To get that with sys you would have to use sys.schemas, sys.tables, sys.columns and sys.types.
There used to be a note on SQL Server's documentation on the column TABLE_SCHEMA to suggest it could be wrong. This was changed earlier this year as I questioned it on their Github. The note now states that the information may be incomplete, not incorrect. Again, this is because INFORMATION_SCHEMA doesn't expose all the information about the objects, which sys does.
The INFORMATION_SCHEMA tables are standard tables (well views) that provide relatively consistent descriptions of the database. They are available in many databases.
The system catalog is specific to SQL Server. I suppose that those tables could change between releases, although that doesn't really happen.
My preference is to use the INFORMATION_SCHEMA tables for basic stuff -- like what tables are in the database and what columns are in the tables.
The system tables are more powerful and designed specifically for SQL Server, so there are other cases where you need to use those.
Related
I am curious about the link between actual database commands and deleting rows from database metadata.
For example, is the following command...
drop table products
... the same as this one?
delete from information_schema.tables where table_name='products' (SQL CE)
The above commands is for SQL Server Compact but the question most likely remains valid across all database platforms. Just curious as to if the second command actually does the same job.
No, it is not.
First, the information_schema tables are generally views on underlying tables. So, even if you could delete a row from them, you really couldn't.
Second, dropping a table is way more than deleting just the table. You have to delete the column definitions, the constraints, the indexes, and the triggers. You also have to remove all the pages associated with the table, and free any in-memory copies in the page-cache. And there's probably a bunch of other work going on too.
It sounds like you want to learn more about how databases really work. I encourage you to read documentation available on-line and to seek out good books about database software.
In SQL Server:
What is the difference between INFORMATION_SCHEMA and sysobjects? Does one provide more information than the other or are they used for different things usually?
Is sysobjects the same as sys.objects? If not, what is the difference between these?
The INFORMATION_SCHEMA is part of the SQL-92 standard, so it's not likely to change nearly as often as sysobjects.
The views provide an internal, system table-independent view of the SQL Server metadata. They work correctly even if significant changes have been made to the underlying system tables.
You are always much better off querying INFORMATION_SCHEMA, because it hides the implementation details of the objects in sysobjects.
INFORMATION_SCHEMA is an ANSI standard, somewhat extented in its SQL Server implementation. sysobjects is specific to SQL Server. Old versions of SQL Server did not support it.
So INFORMATION_SCHEMA is more portable (works on other database) and somewhat easier to use than sysobjects. If it has the information you need, I would go for INFORMATION_SCHEMA.
sys.objects sysobjects is only there for SQL 2000 portability.
I am working on an application that will need to communicate with many different applications running on different database platforms. I will know the table schema before runtime but I won't know the database platform (MS SQL 200X, Oracle 9i, 10g, etc, MySQL 4.0.1, 5.x, etc, sybase, etc) until runtime.
It's my understanding that each of these systems have a slightly different dialect. Do I need to use nhibernate to handle the differences when connecting to these systems or can I use ADO.NET and pass raw SQL strings (select * from table)?
If you only need to use ANSI SQL statements, which should be implemented by all of the databases then yes, you can just use ADO.NET.
In my experience the main problem with database-agnostic code is the use of surrogate keys, like sequences or autonumber fields, as all databases implement these differently.
If you do need to use features that differ across databases then I don't think that it is reason enough to go to an object relational mapper like NHibernate - only do that if you have other reasons to do so. You can implement your own handling of syntax differences by generating different SQL for different databases easily enough.
SQL should be standardized for all dbs but they don't all use the same syntax so it really depends on what SQL you're calling. For example, SQL Server uses TOP while Oracle uses rownum. Even if they're all DDL, some syntactically differences between DBMSes can be an issue.
If select * from table is all you want, then there shouldn't be a problem, other than performance hits.
I recently came across http://www.fossil-scm.org/index.html/doc/tip/www/theory1.wiki by D. Richard Hipp, the developer responsible for SQLite.
it go me thinking, is Fossil the only NoSQL database that uses SQL?
Do others uses SQL as a 'High Level Scripting Language'?
From the article, it sounds like Fossil isn't a database any more than git is a database. Yes, it's a thing that contains data, and yes, it's backed by a database, but it seems pretty far from a database itself. So the first part of of your question basically relies on a faulty assumption. There is a database called Friendly which uses MySQL to store schema-less models, but it seems like an awkward bandaid sort of solution at best.
I'm certainly not familiar with all of the NoSQL options out there, but, to my knowledge, none of the well-though-of ones use SQL for anything. MongoDB and CouchDB, the two I'm most familiar with, both use Javascript as part of their query interface, though in very different ways. MongoDB has queries more like what you'd expect from a relational database: you can write an arbitrary query for all documents that match a certain set of attributes. However, unlike a relational database, there's no such thing as a join (you'll only ever get a list of distinct documents back, not compound documents) and you can write arbitrary Javascript code to select documents. CouchDB, on the other hand, does not allow arbitrary queries. Instead, you create views (which are essentially simpler key-value stores) using map/reduce functions written in Javascript and then query those views from a start key to and end key.
In both cases, the type of information being transmitted to the server to perform the query isn't well-suited for the type of problem that SQL is good at solving. The trade-off to SQL being so high-level (to use the logic of the author of the paper) is that it's only suitable for a very narrow set of problems.
The creator of Fossil / SQLite is working and pushing UnQL as the NoSQL standard:
UnQL means Unstructured Query Language.
It's an open query language for JSON, semi-structured and document
databases.
It looks like a stripped down version of SQL.
select sys.database_name,sys.sysevent,sys.login_user from dual;
what is sys in this query?
Can I see the other functions that are in sys?
What is the query for doing so?
In what situations is this sys useful?
Where will be the information about sys is stored in database?
sys is the system schema. It holds various tables and views that support the rdbms.
You might check out the oracle wiki article which talks about the various schemas and their meaning.
http://en.wikipedia.org/wiki/Oracle_database
In many database systems, including the major database products from Oracle, Microsoft and Sybase, groups of related database tables can be pulled together into a schema.
Some large systems (and, for that matter, some not so large systems) use this as a way to control access, or just as a way to keep things well organised.
For example, the tables supporting an online catalog (e.g. Amazon or Barnes & Nobel) might all be Marketing.*, the tables around order fulfillment Sales.* and those around Stock management Stock.*.
The sys schema that you've noticed is where system tables live - tables that you can query to find out details about the rest of the database - such as whether a column already exists.
I agree with Bevan. Here are some answers specific to your questions:
(I'll make the assumption you're talking about Oracle)
Can I see the other functions that are
in sys?
Yes, like any schema you can view the procedures, functions and packages in sys using a database development tool such as Toad, PLSQL Developer or Oracle SQL Developer. However my experience has shown that referring to Oracle documentation (freely available online) is a better way to learn about the available functionality than jumping straight to the source code.
What is the query for doing so?
I'd recommend the use of one of the development tools above. Failing that, try:
select * from user_objects where type in ('PACKAGE', 'PROCEDURE', 'FUNCTION');
Once you've found the functionality you're looking for use the DESCRIBE command in SQLPlus to determine the method signatures and data types.
In what situations is this sys useful?
SYS is most often often used as a super user for adminstrative tasks as it has more privileges than a common schema. SYS also contains a lot of the infrastructure on which Oracle depends - don't mess around with the objects that SYS owns.
Where will be the information about sys is stored in database?
Use the methods I have suggested above - but I recommend you read the online documentation rather than dive straight into the source.