1. It is all about data; meaning applications built on the database, around the database will succeed or fail based on how they use the database. So solve your needs as simple as possible, use all the functionality already provided within the database you purchased.
Today soa, j2ee, web services etc. is popular, yesterday it was cobol, client server etc. The interfaces come and go but the database is the one constant, because your data live here.
2- ..all databases are fundamentally different and, when designing your application, you must approach each as if you never used a database before. Things you would do in one database are either not necessary, or simply won’t work in another database.
In Oracle you will learn that:
* Transactions are what databases are all about; they are good.
* You should defer committing as long as you have to. You should not do it quickly to avoid stressing the system, as it does not stress the system to have long or large transactions. The rule is commit when you must, and not before. Your transactions should only be as small or large as your business logic dictates.
* You should hold locks on data as long as you need to. They are tools for you to use, not things to be avoided. Locks are not a scarce resource.
* There is no overhead involved with row level locking in Oracle, none.
* You should never escalate a lock (for example, use a table lock instead of row locks) because it would be ‘better on the system’. In Oracle it won’t be better for the system – it will save no resources.
* Concurrency and consistency can be achieved. You can get it fast and correct, every time.
..
From Expert Oracle, Signature Edition: Programming Techniques and Solutions for Oracle 7.3 through 8.1.7, Berkeley, Apress, April 2005.
Thomas Kyte, http://asktom.oracle.com
Extract(Read) > Transform(Test&Apply) > Load(Learn) Blog 