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.
Related
I suspect the answer is no, but I just wanted to check if anyone has a way to implement triggers in DuckDB?
I have a SQLite database that relies heavily on views with INSTEAD OF INSERT/ UPDATE/ DELETE triggers to mask the underlying table structure from applications. Having heard good things about DuckDB I was hoping to try a port, but the lack of triggers (or an alternate mechanism for achieving the same goal) is a show stopper. I've no great desire to reimplement all of the functionality in the various host languages that access the database.
No.
The documentation of DuckDB (as of Oct'2022) doesn't contain any reference to database triggers.
That said, given the nature of the project -- an analytical (OLAP) database, instead of a transactional (OLTP) one -- I would say the developers have few incentives to implement this feature, anyway.
Also, this issue on GitHub DuckDB.
Both SQLite and DuckDB are two fantastic tools! But very different beasts. Use the best tool for your job.
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.
is there a windows xp utility to make a database such that its support by sql server, oracle, and other db management systems.
the database schema is very huge so i would like to know what to use to make it so its protable from sql server to oracle if future demands that change?
In short, what you seek is nearly impossible to do successfully. Every database product has enough quirks that building such database would not perform well and would be too limiting in terms of the features you were able to use. I.e, you have to play the game of lowest common denominator with respect to features that all products implement you want to support. A far better solution is to abstract the data layer into its own library accessed via interfaces so that you can swap out your data layer. ORMs, as Rafael E. Belliard suggested, makes this simpler but it can also be done manually.
I would recommend building your database using an ORM like Hibernate for Java (or NHibernate for .NET). This would allow you to seamlessly transition from one database type to the other with little to no issues. They would allow you to logically create the database schema without a specific database in mind, which you could then move from one database to the other.
I have created applications which change from SQL Server to MySQL to Oracle to MS Access to SQLite easily (clients love that flexibility).
However, you would need to know your way around programming...
I was just wondering if a storage engine type existed that allowed you to do version control on row level contents. For instance, if I have a simple table with ID, name, value, and ID is the PK, I could see that row 354 started as (354, "zak", "test")v1 then was updated to be (354, "zak", "this is version 2 of the value")v2 , and could see a change history on the row with something like select history (value) where ID = 354.
It's kind of an esoteric thing, but it would beat having to keep writing these separate history tables and functions every time a change is made...
It seems you are looking more for auditing features. Oracle and several other DBMS have full auditing features. But many DBAs still end up implementing trigger based row auditing. It all depends on your needs.
Oracle supports several granularities of auditing that are easy to configure from the command line.
I see you tagged as MySQL, but asked about any storage engine. Anyway, other answers are saying the same thing, so I'm going delete this post as originally it was about the flashback features.
Obviously you are really after a MySQL solution, so this probably won't help you much, but Oracle has a feature called Total Recall (more formally Flashback Archive) which automates the process you are currently hand-rolling. The Archive is a set of compressed tables which are populated with changes automatically, and queryable with a simple AS OF syntax.
Naturally being Oracle they charge for it: it needs an additional license on top of the Enterprise Edition, alas. Find out more (PDF).
Oracle and Sql Server both call this feature Change Data Capture. There is no equivalent for MySql at this time.
You can achieve similar behavior with triggers (search for "triggers to catch all database changes") - particularly if they implement SQL92 INFORMATION_SCHEMA.
Otherwise I'd agree with mrjoltcola
Edit: The only gotcha I'd mention with MySQL and triggers is that (as of the latest community version I downloaded) it requires the user account have the SUPER privilege, which can make things a little ugly
CouchDB has full versioning for every change made, but it is part of the NOSQL world, so would probably be a pretty crazy shift from what you are currently doing.
The wikipedia article on google's bigtable mentions that it allows versioning by adding a time dimension to the tables:
Each table has multiple dimensions
(one of which is a field for time,
allowing versioning).
There are also links there to several non-google implementations of a bigtable-type dbms.
I think Big table, the Google DB engine, does something like that : it associate a timestamp with every update of a row.
Maybe you can try Google App Engine.
There is a Google paper explaining how Big Table works.
The book Refactoring Databases has some insights on the matter.
But it also points out there is no real solution currently, other then carefully making changes and managing them manually.
One approximation to this is a temporal database - which allows you to see the status of the whole database at different times in the past. I'm not sure that wholly answers your question though; it would not allow you to see the contents of Row 1 at time t1 while simultaneously letting you look at the contents of Row 2 at a separate time t2.
"It's kind of an esoteric thing, but it would beat having to keep writing these separate history tables and functions every time a change is made..."
I wouldn't call audit trails (which is obviously what you're talking of) an "esoteric thing" ...
And : there is still a difference between the history of database updates, and the history of reality. Historical database tables should really be used to reflect the history of reality, NOT the history of database updates.
The history of database updates is already kept by the DBMS in its logs and journals. If someone needs to inquire the history of database upates, then he/she should really resort to the logs and journals, not to any kind of application-level construct that can NEVER provide sufficient guarantee that it reflects ALL updates.
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.