As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have read on many pages that "All DDL commands are AutoCommit in Oracle". It's okay DDL commands are autoCommit, but my question is: What's the reason for doing it?
Meaning, why are all DDL commands AutoCommit in Oracle?
Is there a reason of doing it?
The Concepts Guide chapter on Transactions includes DDL as one of the markers for End of Transaction. Find out more.
Why? The short answer is, because.
The slightly longer answer is: DDL writes to the data dictionary. If DDL didn't issue implicit commits the data dictionary could get hung up in long-running transactions, and that would turn it into a monstrous bottle neck. Remember, every single SQL statement queries the data dictionary.
"Other DBMS seem to be able to handle transactional DDL without
problems"
Yes, but are those other databases as scalable in a multi-user environment as Oracle? Perhaps they are, but that's what makes this a contentious question and why I voted to close.
The fact is, Oracle is a venerable product: they made architectural decisions in the early days which are baked into the database kernel at a very low level. Some changes just have too great an impact to be worthwhile.
If implementing transactional DDL had been feasible Oracle wouldn't have put all that effort into developing Edition-based Redefinition. And now that we have got Edition-based Redefinition what further benefits would transactional DDL deliver us?
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Personally I find database normalization really interesting(in fact really enjoy doing it) but while designing the schema and normalizing it for the asset manager(containing generic and project specific assets with each having types of arbitrary relation depth) I am currently working on, I came to this basic question i.e. to what extent should one normalize a database(I am aware of 3NF) such that making multiple query, insert etc, doesn't become more costly than programmatically taking care of data inconsistencies, redundancy etc which normalization tries to avoid?
In designing your database you should normalize it to the fullest extend (well, with common sence in mind). While developing you'll notice some potential performance issues. In this case you may want to resort to using views or even denormalize a bit.
Though this differs from case to case, since some programs have serious requirements on performance. Others may be used by just a few users, in this case performance may not be that important.
In order to make a good decision on whether or not to denormalize and thus being able to execute simpler queries, you should run some performance tests for both cases. Keeping in mind what denormalizing would cause to the maintenance of your database.
In case of denormalizing, be sure to document this to the fullest extend.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the best database to start learning stored procedures.
Taking into account that each database has its own syntax. Like Postgresql has functions, SyBase, Oracle, MS SQL, DB2 has some sophisticated procedures..
Is there is some db, you think is good one to use, let's say, for students to demonstrate the principles, knowing which, the students could jump to some specific database without big problems? Something that stays at the middle of the popular set of dbs.
As you know that almost all modern DBMS support stored procedures and vary in syntax. So that's pretty much the personnel choice. But the most easy to use DBMS is MySQL. That can be comparatively more helpful then Oracle, MSSQL or DB2 especially for new students.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Why is a data layer used while we can write most of the code in stored procedures itself? What are the advantages and disadvantages in it?
Data layer is an important layer in 3 tier architecture, which handles all the database related tasks. My question is that, whether we can achieve this using a stored procedure itself in most of the cases? In that case, what is the major advantage in using that layer?
EDIT:
The question was just to get clear idea about the usage of data layer and database stored procedures. I have got an answer below which helped me in that.
The 3-tier approach is for when you wish to maybe use different Database Engine types.
From Multitier architecture
Data tier
This tier consists of database servers. Here information is stored and
retrieved. This tier keeps data neutral and independent from
application servers or business logic. Giving data on its own tier
also improves scalability and performance.
In stored procedure goes your query logic, in data access layer you connect with database engine
MSDN,
N-Tier-Architecture-and-Tips have good insight on n-tier architecture
You can't unit test stored procs very easily because you can't easily mock the data in the database
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm looking for a document oriented database to store over millions of invoices with fast reporting speed.
I find some options such as MongoDB, Ravendb, Couchdb but I don't know the risk of performance failure vs. Sql Server Xml type column.
The source of this question is here.
Fast reporting is something that you want to do in sql server. I'm not aware of a good NoSQL solution for this scenario.
RavenDB has the index replication bundle that enables you to replicate an index to a sql table, so that you can do some advanced reports on them.
Reza,
RavenDB seems like a good match here. It all depends on what you are actually calling "reporting".
Doing things like "how many invoices are there for last month" is easy in RavenDB.
As is doing things like "how much money does Northwind owe us?"
We don't recommend RavenDB for reporting for the specific case where you have dynamic reporting needs such as the need to do on the fly aggregation.
What is it that you are actually trying to do with regards to reporting?
That aside, invoices is a nice place where RavenDB truly shines, especially given the other parameters of this question with the dynamic nature of the invoices.
but I don't know the risk of performance failure vs. Sql Server Xml type column.
Epic fail already here. Invoices are relational data in most cases (in all you need) so address links, line items, numbers and prices are in tables, not XML data type. This is the "ok, so - you planned to wkr at McDonalds, not in our team?" level design decision.
What line items and invoices may have is additional data in XML (like timesheets etc.) but if you run accounting, you dont run it as documents.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I was asked to write a report on different data storage types.
Data can be stored in
Text files.
Different possible data bases:
Oracle db
Microsoft SQL Server
DB2
MySql
PostgreSql
SqLite
excel sheet.
Microsoft access.
Proprietary database.
I was able to gather a little information on this, any help can be appreciated. Please!!
In what ways can data be stored, so that it can be queried using a programming language and data can be extracted by using a programming language.
The real answer is, any structure that persists between application sessions. This includes flat files (text, csv, xml, etc.) and RDBMS (Relational Database Management Systems).
MySql/DB2/Oracle/SQL Server, these are all RDBMS'. Excel sheet, text files, etc. these are flat files.
Each has their own place. For high performance and a lot of Online Transaction Processing (OLTP) you'll want to go with a full-blown RDBMS. For small data that isn't often written to, something like an XML file would suffice.
What you're asking is a gigantic topic that many devote a large portion of their professional careers with. It's impossible to give you an all-encompassing lesson on these.