Single table or multiple tables for optional keys

Performance will be very similar. GHz difference is not essential because e.g. E5-2690 has 3.8GHz Max Turbo Frequency vs 3.5GHz on E5-2643. You can find full comparision here:

http://ark.intel.com/compare/64596,64587

The big thing may be licensing. If you are using Standard Edition or Standard Edition One per CPU licensing they are licensed per socket. So in case you buy second E5-2643 you will also have to buy one more Oracle license. Of course that it not the case with the Enterprise Edition.

If licensing is also not an issue then you still have two decide between two choices:

• buying 2nd E5-2643 will be just cheaper now. Why not to save some money if everything else is the same?
• if you buy E5-2690 and after some time you will hit CPU bottleneck again you will have an option to buy 2nd E5-2690 and once again double the performance.

Also with such amount of memory you really really should use Huge Pages. Of course that means no more AMM and back to ASMM. But especially if you have many connections to Oracle the difference can be really big. You can read about configuring Huge Pages e.g. here:

http://www.oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-linux-64.php

Not sure why one of the answers made such bold statement . Regardless: everything can be modeled in relational model

create table entry 
( 
  id number(12) primary key, 
  name varchar2(256) not null unique,  
  customer_id number not null references customer(id)
);

create table datatypes
(
 id number primary key,
 name varchar2(256) not null unique
);
create table entry_data ( 
  id number(12) primary key, 
  datatype_id  number not null references datatypes(id),
  value     varchar2(256),  --or CLOB ,no index
  value_geometry geom  ,    -- no index
  --value_blob   blob -- if you neeed, no index
  entry_id number not null references entry(id),
);

your task is related to the multi-valued attributes task. Datatypes table will abstract your datatypes, however 2 value** columns are created in entry_data due to the fact that your data can be different in nature(belong to different Classes), thus would need different storage. But as far as varchar2 vs. number vs.date -- all can be placed into varchar2 , just would need later on some casting. And with very simplistic logic of NVL in code you can determine which column was populated out of value or value_geometry.