Was this:
I might be naive, but Oracle is supposed to be this big powerful RDBMS engine but it can't handle anything. I think we're overpaying for it. The design should have nothing to do with performance. Oracle must be able to handle everything.
The design should have nothing to do with performance....
Think about that statement for a moment.
The design (the most fundamental thing, the cornerstone of the 'system', the key piece, the thing were much time should be spent...) should have nothing to do with performance.
The design should have nothing to do with performance....
I keep saying it over and over and it still sounds, well, not smart.
Think about a car: "the design should have nothing to do with performance".
Think about anything, "the design should have nothing to do with performance".
It is all about the design, from day 1, the key component to performance is the design - maybe the only component in fact.
Two others have commented on this as well. First was Pete-S and second was Tim Hall. I agree with their sentiment.
The following is the opening section of both Expert One on One Oracle (modified from the original a bit) and Expert Oracle Database Architecture and sums up my thoughts on this (which are 180 degrees opposite of "design should have nothing to do with performance":
I spend the bulk of my time working with Oracle database software and, more to the point, with people who use this software. Over the last 18 years, I’ve worked on many projects—successful ones as well as complete failures—and if I were to encapsulate my experiences into a few broad statements, they would be
An application built around the database—dependent on the database—will succeed or fail based on how it uses the database. Additionally, in my experience, all applications are built around databases. I cannot think of a single useful application that does not store data persistently somewhere.
Applications come, applications go. The data, however, lives forever. In the long term, the goal is not about building applications; it really is about using the data underneath these applications.
A development team needs at its heart a core of database-savvy developers who are responsible for ensuring the database logic is sound and the system is built to perform from day one. Tuning after the fact (tuning after deployment) typically means you did not give serious thought to these concerns during development.
These may seem like surprisingly obvious statements, but I have found that too many people approach the database as if it were a black box—something that they don’t need to know about. Maybe they have a SQL generator that they figure will save them from the hardship of having to learn the SQL language. Maybe they figure they will just use the database like a flat file and do keyed reads. Whatever they figure, I can tell you that thinking along these lines is most certainly misguided: you simply cannot get away with not understanding the database. This chapter will discuss why you need to know about the database, specifically why you need to understand
The database architecture, how it works, and what it looks like.
What concurrency controls are, and what they mean to you.
That performance, scalability, and security are requirements to be designed into your development efforts, not something to hope you achieve by accident.
How features are implemented in the database. The way in which a specific database feature is actually implemented may not be the way you might envision. You have to design for how the database works, not how you think it should work.
What features your database already provides for you and why it is generally better to use a provided feature than to build your own.
Why you might want more than a cursory knowledge of SQL.
That the DBA and developer staff members are fighting for the same cause; they’re not two enemy camps trying to outsmart each other at every turn.
This may initially seem like a long list of things to learn, but consider this analogy for a second: if you were developing a highly scalable, enterprise application on a brand-new operating system (OS), what would be the first thing you would do? Hopefully, your answer is, “Find out how this new OS works, how things will run on it, and so on.” If you did not do this, your development effort would fail.
Consider, for example, Windows versus Linux. Both are operating systems. Each provides largely the same set of services to developers, such as file management, memory management, process management, security, and so on. However, they are very different architecturally. Consequently, if you’re a longtime Windows programmer and you’re asked to develop a new application on the Linux platform, you would have to relearn a couple of things. Memory management is done differently. The way in which you build a server process is considerably different. Under Windows, you develop a single process, a single executable, with many threads. Under Linux, you do not develop a single stand-alone executable; instead, you have many processes working together. In summary, much of what you learned in the Windows environment doesn’t apply to Linux (and vice versa, to be fair). You have to unlearn some old habits to be successful on the new platform.
What is true of applications running natively on operating systems is also true of applications that will run on a database: you need to understand that the database is crucial to your success. If you do not understand what your particular database does or how it does it, then your application is likely to fail. If you assume that because your application ran fine on SQL Server, it will necessarily run fine on Oracle then, again, your application is likely to fail. And to be fair, the opposite is true: a scalable, well-developed Oracle application will not necessarily run on SQL Server as is without major architectural changes. Just as Windows and Linux are both operating systems, but fundamentally different, so Oracle and SQL Server (pretty much any database could be noted here) are both databases, but fundamentally different.