accessibility vs visibility Oracle SQL [closed] - sql

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
my teacher asked me today what's the difference between accessibility and visibility in Oracle SQL for extra points. I'm new to this, I searched the internet but I didn't found anything. Can someone help me? thanks

I searched in Oracle Database Concepts and I found one match for visibility:
Indexes have the following properties:
■ Usability Indexes are usable (default) or unusable. An unusable
index is not maintained by DML operations and is ignored by the
optimizer. An unusable index can improve the performance of bulk
loads. Instead of dropping an index and later re-creating it, you can
make the index unusable and then rebuild it. Unusable indexes and
index partitions do not consume space. When you make a usable index
unusable, the database drops its index segment.
■ Visibility Indexes are visible (default) or invisible. An
invisible index is maintained by DML operations and is not used by
default by the optimizer. Making an index invisible is an alternative
to making it unusable or dropping it. Invisible indexes are especially
useful for testing the removal of an index before dropping it or using
indexes temporarily without affecting the overall application.
This is just a bet. I don't know what your teacher wants.

Related

Oracle products or not? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Is Read Consistency Rollback segments a feature of Oracle products or a general feature of RDBMS?
Same question but this time regarding Storing/Tablespaces?
Lastly are blocks, extents and segments a feature of Oracle or databases in general?
Many thanks in advance to your replies!
Read consistency is an attribute (from my perspective a requirement) of a transactional database.
Rollback segments are (in a nutshell) how Oracle supports transactions. Btw. it's not called rollback segement any longer. It's called UNDO nowadays
Tablespaces are nothing unique to Oracle. Most (if not all) large scale DBMS support that.
All DBMS I know access the filesystem by blocks. A block (sometimes called a page) is usually the smallest (storage) unit a DBMS can read or write.
Extents are nothing unique to Oracle. Other DBMS just have different names for that.
Segments is a name I have only come across in the Oracle world. But I guess the concept exists in any major DBMS in some way or the other.

What is the purpose of Table Hints in SQL Server? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
What is the purpose of table hints in SQL Server like NOLOCK and READUNCOMMITTED?
Please explain this with example.
Also why can't they be specified for tables modified by INSERT, UPDATE, or DELETE operations?
They allow you to set transaction isolation level on a table-by-table basis instead of for the entire query or connection.
They can also be used to trigger some features like minimal logging (use TABLOCK with the right trace flags set on an INSERT and it can be minimally logged).
As a rule it's a better idea to use connection-level settings.
As the commentor pointed out, Books Online has an excellent description (and samples) of Table Hints, including which hints can be used for which operations.
http://msdn.microsoft.com/en-us/library/ms187373.aspx
There is also a big fat caveat at the top of the page, which often goes unnoticed:
Caution Because the SQL Server query optimizer typically selects the
best execution plan for a query, we recommend that hints be used only
as a last resort by experienced developers and database
administrators.
While the accuracy of the optimizer in choosing the best plan can be debatable, the latter half of the warning is certainly true; don't use Table Hints unless you are sure that you need them, and that assurance typically only comes with experience.

Why does the creation of an index take a long time? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I am using SQL Server 2008.
i am creating an NON CLUSTERED index on a table in my database.
What I see while creating that index is that the query is taking a lot of time; in my case now 8-9 mins is done but still create index query is running.
Can somebody help me to get why it is so ?
I would bet there's nothing special causing it to be slow outside of the ordinary considerations. Obviously the number of rows in the database is going to be a primary factor, then the processor speed and amount of memory on your computer. Also, many people do not realize how much the hard disk speed affects sql operations. Depending on how you use sql, you could easily increase speed quite noticeably by just getting a faster hard drive.

Very complex database architecture, how to deal with it? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I have worked on several rails applications and now I work on a very complex one, from the database side. A lots of nested models, several polymorphyc associations...
How you deal with that complexity ? How can I know that we are working in the good direction ? What about performance issues ?
Thansk for your opinions.
First of all, you need to estimate the performance of the queries that your application runs against the database. Then you can try to optimize the queries, for example, by adding some indexes. Maybe in some cases you will also need to consider denormalizing some data to get better performance.
Performance of the queries may also depend on your data size. If you have really big data set and queries are optimal, then you may consider introducing (distributed) caching. Or if data model allows that think of partitioning your database on several nodes to improve query performance.
But still the first step should be a setup of some SQL query performance monitoring.
You should consider a NOSQL solution such as MongoDB or CouchDB. Sometimes an RDBMS is not the right tool for the job.
http://www.mongodb.org/
http://couchdb.apache.org/

What is the best design for these data base tables? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I need to find the best solution to make the DB Normalized with large amount of data expected.
My site has a Table Tags (contain key word,id) and also 4 types of data related to this tags table like(articles,resources,jobs,...).
The big question is:-
for the relation with tags what best solution for optimazaion & query speed?
make a table for each relation like:
table articlesToTags(ArticleID,TagID)
table jobsToTags(jobid,tagid)
etc.
or put it all in one table like
table tagsrelation(tagid,itemid,itemtype)
I need your help. Please provide me with articles to help me in this design
consider that in future the site can conation new section relate to tag
Thanks
I would go for the normalized version of your schema (which is the table-relation). This type of schemas are very useful for scenarios where the application might grow.
The bad thing of having all the data in just one table is that if you have a bunch of attributes for both relationships, you'll end up with a table with a lot of attributes, which when growing will be slow to query, thus becoming a performance hit of your app.
So, finally the problem is to choose simplicity and quick end against well designed code considering scalability as well.
Hope I can help